Re: [tsvwg] Ben Campbell's Yes on draft-ietf-tsvwg-rfc5405bis-18: (with COMMENT)

"Ben Campbell" <ben@nostrum.com> Fri, 14 October 2016 15:15 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33702129523; Fri, 14 Oct 2016 08:15:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.896
X-Spam-Level:
X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HOzn-Z0hC2m; Fri, 14 Oct 2016 08:15:03 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CE09129527; Fri, 14 Oct 2016 08:15:00 -0700 (PDT)
Received: from [10.0.1.21] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u9EFEuVh013443 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 14 Oct 2016 10:14:57 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.21]
From: Ben Campbell <ben@nostrum.com>
To: "Eggert, Lars" <lars@netapp.com>
Date: Fri, 14 Oct 2016 10:14:56 -0500
Message-ID: <2A34BBF9-BB0C-4C4C-84FC-E9C9891D93E2@nostrum.com>
In-Reply-To: <9BA86A9A-81EE-4050-B46A-724670C0B03E@netapp.com>
References: <147629267441.6361.14616709969508339292.idtracker@ietfa.amsl.com> <9BA86A9A-81EE-4050-B46A-724670C0B03E@netapp.com>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.5r5263)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/PpxgUTS94ZEoo7uO663J5es3bhM>
Cc: "draft-ietf-tsvwg-rfc5405bis@ietf.org" <draft-ietf-tsvwg-rfc5405bis@ietf.org>, "David L. Black" <david.black@emc.com>, The IESG <iesg@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>
Subject: Re: [tsvwg] Ben Campbell's Yes on draft-ietf-tsvwg-rfc5405bis-18: (with COMMENT)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Oct 2016 15:15:08 -0000

Thanks for the response. All your comments are fine with me.

Thanks!

Ben.

On 14 Oct 2016, at 8:37, Eggert, Lars wrote:

> On 2016-10-12, at 19:17, Ben Campbell <ben@nostrum.com> wrote:
>> - I agree with Benoit that a more detailed "changes since 5405" 
>> section
>> would be helpful (separate from the inter-version change section.)
>
> I tried to come up with a short section, but gave up. There are just 
> too many changes since 5405.
>
>> - IDNits points out that RFC  896 is obsoleted RFC 7805. Is the 
>> reference
>> to 896 intentional? (The shepherd writeup mentions a different 
>> obsolete
>> reference, but not this one.)
>
> Good catch. This should be 1122.
>
>> - 3, 2nd paragraph:
>> Is it reasonable to avoid the negation in "not rare" and just say
>> "common"?
>
> That would be overstating things. But I changed it to "sometimes 
> present".
>
>> -3.1.1, 3rd paragraph: Please expand TFRC on first mention. (I think 
>> the
>> original 5405 text that expanded it got moved to later in the 
>> document.)
>
> Fixed
>
>>
>> -3.4, paragraph 3: "An application MAY optionally discard UDP 
>> datagrams
>>   with a zero checksum [RFC1122]"
>> Does this MAY give permission to discard, or state the fact that 1122
>> gives permission to discard? (If the second, please consider non-2119
>> language to avoid the ambiguity.)
>
> The latter; fixed
>
>>
>> -3.4.1, last bullet in list: I think there may be an editing or
>> copy/paste error here.  (Limit the usage of what? Is that section 3.6
>> _of_ RFC7510?)
>
> Good catch, fixed
>
>>
>> -3.6: Yay!
>>
>> - section 6, third paragraph: "Applications MAY also want to offer 
>> ways
>> to limit the
>>   number of requests they respond to in a time interval, in order to
>>   cap the bandwidth they consume."
>>
>> Is that MAY intentionally capitalized? Seems like a statement of 
>> fact.
>
> Yes it is
>
>>
>> -section 6, paragraph 5:  I concur with Kathleen's comment to 
>> reference
>> 7525 in the DTLS discussion.
>>
> Done
>>
>