Re: [dhcwg] WGLC on draft-ietf-dhc-rfc3315bis-05 - respond by August 8th

"Bernie Volz (volz)" <> Tue, 02 August 2016 01:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DA5D712D5E8 for <>; Mon, 1 Aug 2016 18:49:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.808
X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QUIYfcXNHZCw for <>; Mon, 1 Aug 2016 18:49:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D369612D0C6 for <>; Mon, 1 Aug 2016 18:49:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5206; q=dns/txt; s=iport; t=1470102545; x=1471312145; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=E099e105AHs7OC8RsvXIJwZKsOAIewqribyRzLf6TG4=; b=BuWR2ozfl2+xIqUM+C2fc6ZGSgfIlnSwMfS3L4pFz0kCvrKdVUooj4cC psieM7H+Ox6X5P/YWuTdyh9dBuVYv3MfROwgUf8omzE/0WhHiGBNaeh7P tIjQf3TNJnkofovNL6wDDBtpQbp6necu4m2kny0lyGgDHYd42YQPTk86O U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.28,458,1464652800"; d="scan'208";a="135771474"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Aug 2016 01:49:04 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u721n4f9008770 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <>; Tue, 2 Aug 2016 01:49:04 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 1 Aug 2016 20:49:04 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Mon, 1 Aug 2016 20:49:03 -0500
From: "Bernie Volz (volz)" <>
To: dhcwg <>
Thread-Topic: WGLC on draft-ietf-dhc-rfc3315bis-05 - respond by August 8th
Thread-Index: AdHsJSCnyTP8u/DPQz+xmZf7KItvLw==
Date: Tue, 02 Aug 2016 01:49:03 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-rfc3315bis-05 - respond by August 8th
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Aug 2016 01:49:08 -0000


With WG co-chair hat off, but as a document co-author, I do support this document moving forward after a thorough read through it.

I do have a lot of minor edits, such as:
- replacing "address" with "address or delegated prefix" or most likely "lease" in places we missed (though this is not just a search and replace).
- addressing ticket #167 ( by replacing requesting router with client and delegated router with server (or at least making it clear that these "router" terms don't preclude non-router devices from requesting delegated prefixes if the server is configured to delegate).
- unused terminology ("DHCP realm" is no longer used; was previously used for Delayed Auth Protocol which has been deprecated).
- remove use of "site-scoped" addresses in sections related to the link-address field (i.e., section 8.1, 18.1.1, 18.1.2).
- in a few cases, there is redundant text that can be removed (one example is in section 14, page 36, 3rd paragraph - last sentence duplicates first and is likely unnecessary).
- fix figure 8 as outer link-address should not be 0 but address from link to which relay A was attached.
- text in last paragraph of section 20 missed vendor-class and vendor-specific information options as being allowed to appear more than once (with different enterprise-ids).
- text in last paragraph of section 20.7 (ORO) missed Vendor Class option MUST NOT be in ORO (as this is a client to server option).
- some references were updated from RFC 2462 to 4862, but in some cases that was incorrect (as 4862 has no explicit mention of M- and O-bits processing).

I think it best to just apply many of these minor edits to the github document (likely in a branch or just on the main) rather than reporting the list of changes here.

There are a few other changes that deserve a bit more attention (and may best be handled by opening tickets):
- In 3315 we referenced RFC 2136 for DNS Updates, but perhaps referencing RFC 4704 (The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option) would be better?
- In many of the section 17.1.x (Creation and Transmission of <name> Messages), a forward reference to the corresponding Reply processing section would probably be useful.
- I think something about prefix hints should be added to 17.1.1 and 17.1.2 (such as what is in 17.1.4); alternatively we might want to just add something about that a client may do that and rely on the text already in 20.22 (IAPREFIX option).
- I'm not sure that the text in section 17.2.11 and 17.1.4 are fully aligned for Reconfigures. 17.2.11's text is a bit unclear in that it says "The server MAY include an ORO" (and then says if it includes IA options in the ORO, it must include the IA options themselves); section 17.1.4 assumes that this is always the case. I'm not sure if a "plain" Reconfigure without any ORO is valid from this as 17.1.4's text doesn't work well then? So, I think we need to clarify this a bit more. (The server I work on just sends a Reconfigure without ORO since we don't provide an administrator any way to say what the client should reconfigure and while I think this was intended to be acceptable behavior, but 17.1.4 needs a tweak to make it work?)
- Section 17.1.6 - minor issue but I don't think there's any need to delay sending Information-Request when being sent because of a Reconfigure?
- Section 17.1.10 looks like it is missing text (like in 17.1.9) about processing SOL_MAX_RT/INF_MAX_RT options if present? The earlier section (17.1.x) all said that a client adds the SOL_MAX_RT (or INF_MAX_RT for Information-Request)?
- Section 21 could use a rework as it is a bit scattered and jumps between topics. So, moving around some paragraphs to keep the IPSec and Reconfigure topics together as well as discussing "leases" to combine some of the address assigned/prefix delegation issues should be done.
- We should review section 22 as it first says focus will be on server considerations but then enumerates sections of RFC 7824 that are client related. Then remainder focuses on server allocation strategies (after referencing RFC 7284 section 4.3) and then duplicates some of that material. I think we should just refer readers to RFC 7824 for both client and server privacy considerations and leave it at that?
- In section 23 (IANA Considerations) there is a request to IANA to add a new column; should we perhaps provide IANA that data in a more easily used format? And, there is a "Note to IANA" that we need to clarify and remove. And straighten out the links (as some are .xhtml and others .xml).

There's also the question for the WG and co-authors about whether incorporating RFC 4242 (Information Refresh Time Option) into the bis document makes sense as it is  a MUST and there is text already in 17.1.6 about it and also in 20.25. This probably is a core piece of the base protocol (for assisting in stateless configuration of clients).

- Bernie