[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: OMG RFI/RFP/RFC process



yes, the OMG RFCc are indeed different from IETF RFC. Perhaps thats what
somebody pointed out to Juggy in one of the meetings. 
In any case, given the current state of affairs, I will be surprised to
see an OMG RFC for CORBAMed being accepted without debate!
Tx for the pointers, Steve.
Jinny.

 On Fri, 12 Jun 1998, Steven Luis wrote:

> 
> To clarify the lively van ride conversation home from the technical
> meeting, I submit the following:
> 
> http://www.omg.org/about/rfpxplan.htm
> http://www.omg.org/about/rfixplan.htm
> 
> Esentially, the OMG RFC is an unsolicited spec submitted by a contrib. or
> domain contrib member. It still goes through all the hoops, with the added
> thrill of allowing members to comment on it. If someone submits
> significant disagreement to RFC within 90 days, it fails-- an RFP can 
> be initiated to pass the spec.
> 
> I have included the IETF RFC process references below to point out that
> "Internet RFC" are not immediately adopted as standards as was implied in
> the OMG technical Meeting. In fact, the IETF goes to create lengths to
> insure that RFC "wannabies" are truely Internet Standards and not some
> companies or individuals attempt to have a proprietary standard adopted.
> >From 6-12 months are needed of public inspection before the standard goes
> to a vote. 
> 
> I'd say that OMG's RFP process is even more proactive with RFIs-- the
> process takes time as a measure of sanity, IMHO ;)
> 
> -steve
> 
> 
> http://www.ietf.org/tao.html#RFCs_and_I_Ds
> http://src.doc.ic.ac.uk/computing/internet/rfc/rfc2026.txt
> 
> 
> 4.  THE INTERNET STANDARDS TRACK
> 
>    Specifications that are intended to become Internet Standards evolve
>    through a set of maturity levels known as the "standards track".
>    These maturity levels -- "Proposed Standard", "Draft Standard", and
>    "Standard" -- are defined and discussed in section 4.1.
> 
> 6.2  Advancing in the Standards Track
> 
>    A specification shall remain at the Proposed Standard level for at
>    least six (6) months.
> 
>    A specification shall remain at the Draft Standard level for at least
>    four (4) months, or until at least one IETF meeting has occurred,
>    whichever comes later.
> 
>    These minimum periods are intended to ensure adequate opportunity for
>    community review without severely impacting timeliness.  These
>    intervals shall be measured from the date of publication of the
>    corresponding RFC(s), or, if the action does not result in RFC
>    publication, the date of the announcement of the IESG approval of the
>    action.
> 
> 
> 
> 
> -steve
> 
> 
> To unsubscribe send a note to majordomo@cs.fiu.edu with the body of the message
> being: unsubscribe cadse-orb
> 

To unsubscribe send a note to majordomo@cs.fiu.edu with the body of the message
being: unsubscribe cadse-orb