Re: [Gen-art] new version of draft-ietf-tcpm-rfc3782-bis posted

["Henderson, Thomas R" <[e-mail]>]

Ben, thanks for following up-- inline below.

> -----Original Message-----
> From: Ben Campbell [mailto:[e-mail]]
> Sent: Tuesday, January 24, 2012 1:58 PM
> To: Henderson, Thomas R
> Cc: Russ Housley; David Harrington; [e-mail]; draft-
> [e-mail]; The IESG; [e-mail];
> Yoshifumi Nishida; [e-mail]; [e-mail] 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