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

[Ben Campbell <[e-mail]>]

(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 :-)

> 
>> 
>> -- 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 :-)  )

[ AD comment sections removed]