Re: RIM 0.55 distribution

[Farrukh Najmi <Farrukh.Najmi@east.sun.com>]

Klaus,

I am told by Nagwa or QR team that the QR team has agreed to take new versions
of specs by tonight to facilitate the ability for RR to submit specs that have
already addressed the known issue by QRT.

IMHO when the bride and the groom agree to get married then the priest should
just bless the ceremony (old middle eastern saying).

I have just gotten done with a 4 hour session with Nagwa on the Registry
Services document and was told by her to go ahead and submit the changes.
Having causes enough problems and confusion for the day, I will refrain from
submitting the new RS document unless you (Klaus the priest) give the blessing.

IMHO, we could optimize the process tremendously. If you are open to
suggestions I will be gald to oblige.

Finally, My thanks to the QR team and specially Nagwa for their flexibility,
hard work and the *WILL* to make these specs good enough for consideration by
QR.

--
Regards,
Farrukh


Klaus-Dieter Naujok wrote:

> On Fri, 19 Jan 2001 12:27:52 -0600, Nieman, Scott wrote:
>
> >Finally, for the future, I am authorizing Farrukh to make revisions to the
> >document that are ONLY editorial in nature and submit revisions to QRT on
> >behalf of the team .  "Editorial in nature" is an assumption that changes
> >only provide clarification to QRT concerns.  Any substantive changes will
> >require VOTE by the registry team.  I am assuming that the StC will not
> >object this the process (please let me know asap if this is an issue).
>
> Scott,
>
> I understand what you are trying to achieve, however, we have a
> very lean (simple) process in place that we must follow. I am not
> aware that there is currently a so to say "interactive" process
> between QRT and the project team that has submitted a
> specification to revise on the fly the specification under review.
> Therefore I don't understand your suggestion for Farrukh to be
> allowed to submit editorial changes to QRT. I should point out
> that QRT has approved the TA specification but at the same time
> had many comments to be addressed as part of the next review.
> However, the QRT comments against the RIM were more than of
> editorial nature that could be to be taken care of in the next
> editing session and therefore they rejected the request to go out
> for public review.
>
> The process is very simple, a PT approves by vote (min 67%) its
> draft to go for the first public review. It is submitted to QRT
> for quality review. If QRT recommends that the specification can
> go out for review, it is made public including any comments from
> QRT. At the end of the review cycle the PT reviews the public and
> QRT comments in order to create its next revision. After approval
> by the PT it goes out for the second cycle using the same process
> with QRT. At the end of the second review the PT takes again the
> public comments and QRT comments to prepare the final
> specification. This version will be made available to the ebXML
> community 2 weeks before a ebXML meeting in order to approve it
> during the closing plenary.
>
> Should QRT reject the specification, and the Executive does not
> overrule the QRT, than the PT will have to address the issues by
> either revising the document or countering the QRT comments. If
> the PT revises the document PT approval is required to present it
> back to QRT. Should the PT disagree with QRT it must present it
> counter arguments to QRT. In the case that QRT disagrees, the
> Executive will review the issue(s) and make a recommendation to
> the StC which will take a decision at the earliest time via a
> conference call. Should the QRT agree with the counter arguments
> the document as submitted will go out for review.
>
> In the case that QRT rejects the specification and the executive
> disagrees with the rejection, there are two possible actions. If
> the Executive feels that the reasons are not of technical
> substance it can take the decision to go out for public review. If
> the Executive feels that the technical issues raised are not a
> show stopper or are not valid it will asked the StC to take the
> decision to allow the specification to go out for review or not.
>
> In closing, the main reason for having the PT submit the request
> to QRT via the StC was to make sure that all PT lead and the
> Executive were aware of the fact that a specification was entering
> the review process.
>
> Scott, I hope I clarified the process and reasons for it. I have
> no intentions to put road blocks up, the opposite is true, I want
> to make sure that we follow our simple process so that no one can
> claim we short circuiting it, which would mean in the end more
> work by back tracking.
>
> Have a great weekend, looking forward to reading you
> specifications as they go out for review.
>
> Regards,
>
> Klaus
>
> --
> Klaus-Dieter Naujok                          ebXML & TMWG Chair
> Netfish Technologies, Santa Clara, CA, Chief Technology Officer



begin:vcard 
n:Najmi;Farrukh
tel;work:781-442-0703
x-mozilla-html:FALSE
url:www.sun.com
org:Sun Microsystems;Java Software
adr:;;1 Network Dr. MS BUR02-302;Burlington;MA;01803-0902;USA
version:2.1
email;internet:najmi@east.sun.com
fn:Farrukh Najmi
end:vcard