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
>