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

From: Ben Campbell <[email-masked]>
Date: Tue, 24 Jan 2012 15:58:08 -0600

(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]

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 24 Jan 2012 23:29:48 -0800

Ben, thanks for following up-- inline below.

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Tuesday, January 24, 2012 1:58 PM
> To: Henderson, Thomas R
> Cc: Russ Housley; David Harrington; [email-masked]; draft-
> [email-masked]; The IESG; [email-masked];
> Yoshifumi Nishida; [email-masked]; [email-masked] Review Team
> Subject: Re: new version of draft-ietf-tcpm-rfc3782-bis posted
> 
> [...]
> > 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. 

> 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

---

From: Ben Campbell <[email-masked]>
Date: Wed, 25 Jan 2012 08:42:23 -0600

On Jan 25, 2012, at 1:29 AM, Henderson, Thomas R wrote:

[…]

> I don't care strongly; perhaps others could advise on a course of action here. 

From separate email, I gather the aforementioned  "others" share your viewpoint. So at this point I suggest leaving it as-is.

> 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 lat…

You are absolutely right--I was globally searching for 2119 words, and missed the context. Sorry for the confusion.