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

Ben Campbell <ben@estacado.net> Tue, 24 January 2012 21:58 UTC

Return-Path: <ben@estacado.net>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4CC11E8088; Tue, 24 Jan 2012 13:58:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeV8oq4g6U+Q; Tue, 24 Jan 2012 13:58:50 -0800 (PST)
Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9A97111E8079; Tue, 24 Jan 2012 13:58:49 -0800 (PST)
Received: from [10.0.1.2] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id q0OLw9iP010418 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Jan 2012 15:58:14 -0600 (CST) (envelope-from ben@estacado.net)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=windows-1252
From: Ben Campbell <ben@estacado.net>
In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4CF2319D99@XCH-NW-10V.nw.nos.boeing.com>
Date: Tue, 24 Jan 2012 15:58:08 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <64A41C1A-3031-440A-BD45-26A54513F231@estacado.net>
References: <7CC566635CFE364D87DC5803D4712A6C4CF2319D99@XCH-NW-10V.nw.nos.boeing.com>
To: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
X-Mailer: Apple Mail (2.1251.1)
Cc: tcpm-chairs@tools.ietf.org, gurtov@ee.oulu.fi, draft-ietf-tcpm-rfc3782-bis@tools.ietf.org, floyd@acm.org, "gen-art@ietf.org Review Team" <gen-art@ietf.org>, The IESG <iesg@ietf.org>, David Harrington <ietfdbh@comcast.net>, Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Subject: Re: [Gen-art] new version of draft-ietf-tcpm-rfc3782-bis posted
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Jan 2012 21:58:50 -0000

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