Ben, thanks for following up-- inline below. > -----Original Message----- > From: Ben Campbell [mailto:[email protected]] > Sent: Tuesday, January 24, 2012 1:58 PM > To: Henderson, Thomas R > Cc: Russ Housley; David Harrington; [email protected]; draft- > [email protected]; The IESG; [email protected]; > Yoshifumi Nishida; [email protected]; [email protected] Review Team > Subject: Re: new version of draft-ietf-tcpm-rfc3782-bis posted > > (Adding Gen-ART to the CC List) > > Hi Tom, > > Thanks for the response. Further comments inline. I've removed sections > that don't seem to need further comment. > > > On Jan 20, 2012, at 5:58 PM, Henderson, Thomas R wrote: > > [...] > > > >> > >> -- Appendix A refers the reader back to RFC 3782 for additional > >> information. But this draft purports to obsolete that RFC. If there > is > >> important info in it that is not covered by this draft, then it > >> doesn't really obsolete it. Is there a reason that information was > not > >> brought forward into this draft? > > > > This Appendix was written as a result of comments from the WG review, > with the intention to consolidate the informational material for the > sake of clarity. The current version (-05) keeps this appendix as is > since it was addressing previous WG comments. > > I guess my point was not the existence of the Appendix so much as the > references to information in an RFC to be obsoleted by this draft, > where ever it might occur. I guess these are informational reference, > so they are by definition not necessary to fully understand this draft. > But it still seems odd to me to reference information in a RFC > obsoleted by this one, rather than pull the material forward (perhaps > in an appendix). I tend to read "obsolete" to mean there's really no > reason to ever read it other than historical ones. That is, for most > practical reasons, we could pretend it no longer existed. I realize > this is a point of process more than a content issue, so if others are > okay with it, I will back away :-)
My interpretation was that obsolete referred to the current validity of the specification aspects, but not that the obsolete RFC couldn't be referred to for informational purposes. I don't care strongly; perhaps others could advise on a course of action here. > > > > >> > >> -- There is very little 2119 normative language. On a quick scan, I > >> see one capitalized SHOULD NOT and one MAY. Yet it seems like there > >> are other statements that are just as important for correct behavior > >> as those. For the sake of consistency, it might be easiest to just > >> drop > >> 2119 language entirely. > > > > I have followed your suggestion; the draft now says: > > > > Note that this specification > > avoids the use of the key words defined in RFC 2119 [RFC2119] since > > it mainly provides sender-side implementation guidance for > > performance improvement, and does not affect interoperability. > > > > That works for me--except there's a vestigial SHOULD in section 5. (and > a 2119 reference for the purpose of saying you aren't using it. I see > nothing wrong with that, but it spins IDNits for a loop :-) ) > The vestigial SHOULD is intentional; it is within a quoted sentence from RFC 5681 so I am hesitant to change it for the sake of making idnits happy (under the assumption that the RFC editor can later ignore this nit). - Tom _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
