Hi Wes, > In TCPM, it was determined that RFC 1122 is not wrong or flawed, just > potentially unclear.
That's a judgment call that the WG's entitled to make, of course. (Side comment: it would be useful for reviewers outside the WG if writeups noted why a document was in a particular category when there might be some question about it.) > There are many non-standards-track RFCs that include 2119 language, True, where the document is self-contained (e.g. an Experimental specification). But it goes with my previous point - either it's normative, in which case it should be standards track, or it isn't, in which case using RFC 2119 seems inconsistent. This is definitely IMHO but I see from Dave Harrington's DISCUSS that he has the same questions. Regards Brian Carpenter On 2011-06-05 15:08, Wesley Eddy wrote: > Just commenting on the non-editorial portion: > > On 6/4/2011 5:51 PM, Anantha Ramaiah (ananth) wrote: >> >> ... >> >> Why is this Informational? If it matters, it should be a Standards Track >> document updating RFC 1122. >> >> ANA> I agree, it should have been a standards track document since it >> clarifies the RFC 1122 wording. I believe the TCPM chairs and WG group >> had >> ANA> approved us to come up with a informational RFC that clarifies >> the intention of RFC 1122 regarding persist state. We have no problems >> making ANA> this a standards track, I'll leave it to the chairs to >> comment on this. > > In TCPM, it was determined that RFC 1122 is not wrong or flawed, just > potentially unclear. > > The current draft is a clarification rather than actually augmenting, > correcting, extending, or updating any of the specs and guidance in > 1122. > > As I recall, Informational was purposefully chosen by TCPM; this is > more implementation guidance than anything warranting standards track. > As for adding Updates 1122, this may be a good idea; I don't recall if > it was specifically discussed by the WG. I noticed at least one other > RFC which includes clarifications is Informational and doesn't Update > its parent documents (RFC 4718 is the example) > > >> If it's not a Standards Track document, why is it using RFC 2119 >> language? >> >> ANA> I think we need to remove the RFC 2119 language if the target is >> informational. > > There are many non-standards-track RFCs that include 2119 language, so > it's unclear what the hangup is here. That said, I think either way, > the meaning of this document will be clear, so don't have strong > personal feelings one way or the other. > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
