Re: draft-housley-two-maturity-levels

24.03.2011 17:42, Joel M. Halpern wrote:
> As far as I can tell, your proposal does not match the meaning we use 
> for Historic.
> More importantly, there does not seem to be a problem that needs to be 
> addressed in this area.
> Most importantly, if there is a problem, it should in my opinion be 
> addressed separately from the topic of this draft.  Please do not 
> conflate the two.
While it is not directly related to the draft's topic, it it just an 
attempt since this draft is very likely to become published unlike the 
separate proposal on this topic.
Mykyta
> Yours,
> Joel M. Halpern
>
> On 3/24/2011 11:32 AM, Mykyta Yevstifeyev wrote:
> > Russ, all,
> >
> > Another proposal as for your document. So, it fails to mention what are
> > the procedures for reclassification of Standards Track RFCs to Historic.
> > Therefore, I propose the following text:
> >
> > > 6. Procedures for Reclassification of Standards Track RFCs as Historic
> > > Documents
> > >
> > > Under some circumstances Standards Track RFCs may be reclassified to
> > > Historic document (i. e. its initial status may be changed to
> > > Historic). RFC 2026 [1], as well as its predecessors, contains some
> > > words about the Historic RFCs, but it failes to define the procedures
> > > for reclassification of RFCs to Historic status. Such situation, of
> > > course, causes misunderstandings of the members of the community. This
> > > document removes this uncertainty; it defines the circumstances under
> > > what the Standards Track RFC should be moved to Historic status and
> > > describes the procedures for such action.
> > >
> > > The Standards Track RFC, either Proposed Standard or Internet
> > > Standard, should be considered to be appropriate for reclassification
> > > as Historic document if (a) there is another document that replaces it
> > > or (b) it described the protocol or other technology that got 
> > > out-of-use.
> > > In the case mentioned as (a) above the superseding document should
> > > just have the notice of the necessity of reclassification of its
> > > predecessor to Historic. However such action is not obligatory.
> > >
> > > In the case mentioned as (b) above the procedure is as follows. If the
> > > individual or a group of individuals (e. g. IETF working group) assume
> > > that the protocol or other technology defined in the Standards Track
> > > RFC is now out-of-use and is very unlikely to become widely used in
> > > the future, they SHALL apply to IESG to request the reclassification
> > > of such document to Historic. IESG SHALL then issue the IETF-wide Last
> > > Call on this action, not shorter than 2 weeks, in order to determine
> > > whether there is the community consensus on reclassification. If Last
> > > Call did not reveal community objection to this action, this document
> > > SHALL be reclassified to Historic.
> > >
> > > During the sunset period, set by this document, Draft Standards SHALL
> > > be reclassified to Historic using the procedure as defined above.
> > ... and renumber the following sections.
> >
> > What do you think about this proposal?
> >
> > Mykyta Yevstifeyev
> >
> > 14.03.2011 1:32, Russ Housley wrote:
> > > There have been conflicting suggestions about the best way forward. We
> > > have constructed an updated proposal. It has been posted as
> > > draft-housley-two-maturity-levels-04.
> > >
> > > Russ
> > > _______________________________________________
> > > Ietf mailing list
> > > Ietf(_at_)ietf(_dot_)org
> > > https://www.ietf.org/mailman/listinfo/ietf
> > _______________________________________________
> > Ietf mailing list
> > Ietf(_at_)ietf(_dot_)org
> > https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf