Re: [dhcwg] WGLC on draft-ietf-dhc-rfc3315bis-05 - respond by August 8th
Ted Lemon <mellon@fugue.com> Wed, 31 August 2016 20:29 UTC
Return-Path: <mellon@fugue.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078B612D772 for <dhcwg@ietfa.amsl.com>; Wed, 31 Aug 2016 13:29:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 aYWEDDDxygHR for <dhcwg@ietfa.amsl.com>; Wed, 31 Aug 2016 13:29:04 -0700 (PDT)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (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 BB4D012D5BC for <dhcwg@ietf.org>; Wed, 31 Aug 2016 13:29:03 -0700 (PDT)
Received: by mail-lf0-x232.google.com with SMTP id e198so11926709lfb.2 for <dhcwg@ietf.org>; Wed, 31 Aug 2016 13:29:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lmaRTYCBypA6pN3FyqfNXIzD72W43uR1UGFByZXhSvY=; b=BBw/QIVL8lKWnsQJsyko2S+JC/LFsnugrUdGSgRReMWb/38i3bJjDq0o6lI/zkWhfu +v1/5iiwQZT1f+vf2rGtuvjyuqKPcF3VZqR3Nbc9siupPmjoLlRLdkuwTCLtGwgxr6jw B0/uK1k/s1Rj6wAY2eDzycvC8S9YiANmQSref9Ulu43JCNsaCfmH6uizrPFjuvBBH3rK 4LIVrylVTmv8hN+B+uB7aJo7P7Ap0G+bTJVs+OsGSzTkJT1KtA5Ez3ffQD4Qb783Y3Wx SfHLrMSTExWqZBG6X5bboXmcMPJNjnZDInrKWEvlXIodydNysm9ifIp5hb65Ld3VET3f bu8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lmaRTYCBypA6pN3FyqfNXIzD72W43uR1UGFByZXhSvY=; b=DAkMCRK3Uxj9CBTZIOO/PAA0B9+7lAuoFnIUFPB6x/1Q2FkCYJ5ET1WPtu4B6alT3F n4PEJKKEQdMso5DZQw0ZQZt36U6tLY1kdJ+kNbrE4CAwtYG1mIKmmEu0SnwA5TnPs0Ei vaIjpyZH1mIYdWNqVrHXA29xHfveXOz45GfkQJw4zoM17chcm+SxJfxWB0LstP3t4v1W BDJANevzaiMJ3TzAubO0By/qSiT1NSz2Q2Okmem4dT0d9tGUFXRfBpVh5PZPQb9CV/Wh TkSHiyrKDhBp7e7aj4/7yuiqzCu9ClbdQiwpVT9nNNYDYmcS+2M4BaSkT+mN8HH3Ob+U Rvsw==
X-Gm-Message-State: AE9vXwPBCAiguuvFJz6HWJLx7BV/ovKsVpnlYG9tY9llYt1GL8USFyRjfoCHVkgcWseSBEHTCqjI+iMcquZTlA==
X-Received: by 10.25.91.133 with SMTP id p127mr3406575lfb.39.1472675341714; Wed, 31 Aug 2016 13:29:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.217.93 with HTTP; Wed, 31 Aug 2016 13:28:21 -0700 (PDT)
In-Reply-To: <91D6F120-FCAF-4B07-AF26-80E38843C037@gmx.com>
References: <577FDCCE.5090107@gmail.com> <91D6F120-FCAF-4B07-AF26-80E38843C037@gmx.com>
From: Ted Lemon <mellon@fugue.com>
Date: Wed, 31 Aug 2016 16:28:21 -0400
Message-ID: <CAPt1N1nkxWkk+em_tCn5i6JkDN+cKS8PY4KAfqjcvWQNNZDThQ@mail.gmail.com>
To: Ian Farrer <ianfarrer@gmx.com>
Content-Type: multipart/alternative; boundary="001a1141209c9cedad053b63f226"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/ix6A-g9qnsj1ajsR761Sqq7fMdw>
Cc: dhcwg <dhcwg@ietf.org>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-rfc3315bis-05 - respond by August 8th
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Aug 2016 20:29:07 -0000
Ian, this goes back a while, so you may not remember, but your comment about 1.4 mentions a paragraph 12. There aren't that many paragraphs in 1.4. What did you actually mean? On Thu, Aug 4, 2016 at 1:40 PM, Ian Farrer <ianfarrer@gmx.com> wrote: > Hi, > > Here is my comments on rfc3315-bis-05. > > Cheers, > Ian > > Section 1.4 > Paragraph 2 is a repetition of the beginning of paragraph 12 > > 13.2 > T1/T2 times and how they are selected are discussed in this section, but > the > purpose of the T1/T2 timers is not described until section 17.1.4. A brief > overview > of their purpose would help readers. > > 16.1 Para 1 > The sentence: > "However, the client MAY send the message through another interface if the > interface is a logical > interface without direct link attachment" > is ambiguous, suggested reword: > However, the client MAY send the message through another interface if the > interface which > configuration is being requested for is a logical interface without direct > link attachment > > 17.1 DISCUSSION > Is this really a discussion point? The provided text for considerations > regarding > the use of unicast with relays seems straightforward enough and the > discussion doesn’t pose any questions. > > 17.1.2 > The client includes a Reconfigure Accept option indicating whether or > not... > The text here is not accurate (the option is only included if it is > supported) - Suggested reword: > The client includes a Reconfigure Accept option (see Section 20.20) if the > client is willing to accept Reconfigure messages from the server. > > > 17.1.10.1 Para beginning ‘When a client had received...' > There are a number of grammatical errors in this paragraph. Suggested > re-word: > > When a client receives a configuration option in an earlier Reply, > then sends a Renew, Rebind or Information-Request and the requested > option is not present in the Reply, the client MUST stop using > the previously received configuration information. In other words, the > client > should behave as if it never received this configuration option and return > to the relevant default state. If there is no viable way to stop using > the received configuration > information, the values received/configured from the option MAY persist > if there are no other sources for that data and they have no external > impact. > For example, a client that previously received a Client FQDN option and > used it to set up its hostname is allowed to continue using it if > there is no reasonable way for a host to unset its hostname and it > has no external impact. As a counter example, a client that previously > received an NTP server address from the DHCP server and does not > receive it any more, MUST stop using the configured NTP server IPv6 > address. The client SHOULD be open to other sources of the same > configuration information. This behavior does not apply to any IA > containers, as their processing is described in detail in other parts > of this document. > > * Suggest also that the 'MUST stop using' is replaced with SHOULD, as the > next paragraph describes an exception to the MUST requirement. > * Also, it would be worth extending this to say that if a requested option > is received that has an updated value, then use of the previous value > should be > discontinued and replaced with the new value. > > 17.2 Para 2 > s/server sends Advertise message/server sends an Advertise message/ > > 17.2.1 Para 6 > "Sending this option back to the client may useful using the server > selection > process." > Current text is unclear, propose: > Sending this option back to the client may be useful for the server > selection > process. > > 17.2.2 Para 6 > The term 'prefixes on included addresses' is used (twice). Suggest > 'prefixes of' > is used instead. > > 17.2.9 Para 6 > "IA_IA" is listed here. Assume IA_TA was meant. > > 17.2.11 Para 2 > Describes the server including an ORO option to say what is changed/added, > but > there is no corresponding text in 17.1.11 saying how the client should use > a received ORO in a reconf. message. (I see Bernie got this one as well) > > 18.1.1 > s/If not addresses/if no addresses/ > > 19 & 19.2 > Both sections describe that RFC3315 delayed authentication is obsolete. Is > the > repetition necessary? > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg >
- [dhcwg] WGLC on draft-ietf-dhc-rfc3315bis-05 - re… Tomek Mrugalski
- Re: [dhcwg] WGLC on draft-ietf-dhc-rfc3315bis-05 … 神明達哉
- Re: [dhcwg] WGLC on draft-ietf-dhc-rfc3315bis-05 … 神明達哉
- Re: [dhcwg] WGLC on draft-ietf-dhc-rfc3315bis-05 … Marcin Siodelski
- Re: [dhcwg] WGLC on draft-ietf-dhc-rfc3315bis-05 … Bernie Volz (volz)
- Re: [dhcwg] WGLC on draft-ietf-dhc-rfc3315bis-05 … Ian Farrer
- Re: [dhcwg] DHCP Relay and Prefix Delegation Ian Farrer
- Re: [dhcwg] WGLC on draft-ietf-dhc-rfc3315bis-05 … Bernie Volz (volz)
- Re: [dhcwg] YANG model for DHCPv6 - draft-ietf-dh… ian.farrer
- [dhcwg] DHCP Relay and Prefix Delegation Alexandre Petrescu
- [dhcwg] YANG model for DHCPv6 - draft-ietf-dhc-dh… Alexandre Petrescu
- Re: [dhcwg] WGLC on draft-ietf-dhc-rfc3315bis-05 … Lorenzo Colitti
- Re: [dhcwg] WGLC on draft-ietf-dhc-rfc3315bis-05 … Marcin Siodelski
- Re: [dhcwg] WGLC on draft-ietf-dhc-rfc3315bis-05 … Lorenzo Colitti
- Re: [dhcwg] WGLC on draft-ietf-dhc-rfc3315bis-05 … tianxiang li
- Re: [dhcwg] WGLC on draft-ietf-dhc-rfc3315bis-05 … 神明達哉
- Re: [dhcwg] DHCP Relay and Prefix Delegation Bernie Volz (volz)
- Re: [dhcwg] DHCP Relay and Prefix Delegation Alexandre Petrescu
- Re: [dhcwg] WGLC on draft-ietf-dhc-rfc3315bis-05 … Ted Lemon