Re: [dhcwg] WGLC for draft-ietf-dhc-topo-conf-05.txt - Respond by July 29, 2015

"Bernie Volz (volz)" <> Mon, 27 July 2015 14:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BBECF1A8774 for <>; Mon, 27 Jul 2015 07:23:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aiPu9CwJsSsd for <>; Mon, 27 Jul 2015 07:23:00 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0D5E51B2E26 for <>; Mon, 27 Jul 2015 07:23:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=20089; q=dns/txt; s=iport; t=1438006980; x=1439216580; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4OIfl6peAvEHV8A7vgfCqz36byAr79EbouETMw5zQqY=; b=moPGgLawB5EUuOhBobYiSNJJy6UrByQTMywFV49PE4nAuDwp2LogLSW6 30sCW58jSZ6sK9saKfuRaJJqJhgEj17tdgJvORWlPADx5q3F4+M117cva lvnHy/5NNQtCvWq48lzLTNyS/ZMS6MxoHJFEFospWpQa9HQGSoYPW5B6C A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.15,554,1432598400"; d="scan'208,217"; a="15370936"
Received: from ([]) by with ESMTP; 27 Jul 2015 14:22:58 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t6REMwQG025610 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Jul 2015 14:22:58 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Mon, 27 Jul 2015 09:22:58 -0500
From: "Bernie Volz (volz)" <>
To: "" <>
Thread-Topic: [dhcwg] WGLC for draft-ietf-dhc-topo-conf-05.txt - Respond by July 29, 2015
Thread-Index: AQHQyHe84OSlYc+hbE6QZp0ATzv9Pw==
Date: Mon, 27 Jul 2015 14:22:58 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1CB8BF2Bxmbrcdx04ciscoc_"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-topo-conf-05.txt - Respond by July 29, 2015
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Jul 2015 14:23:03 -0000

As document shepherd and in response to the WGLC, below are my personal comments:

First, thanks to Marcin for his review and comments as he wrote up many of the issues I had (and also caught a few more).

Second, my view is that the document is almost ready and I support it moving forward after hopefully one more edit (I do not expect any of those changes requiring another WGLC).

The corrections are to clean up wording to improve clarity of the text (see Martin's comments). Also:

In section 9, I think there are two use cases missing. The 4 use cases for "multiple subnets on a link" are:

1.       Renumbering. This is probably more applicable to DHCPv6, but could also be used in DHCPv4 (though renumbering there is not graceful as clients only support a single 'lease').

2.       Expanding the allocation space. In DHCPv4 and for DHCPv6 Prefix Delegation, there could be cases where multiple subnets are needed because a single subnet may be too small to accommodate the client population.

3.       Allocating addresses (or delegation prefixes) that are not the same as topological information. For example, the link-address is on prefix X and the addresses to be delegated is on prefix Y. This could be based on differentiating information (i.e., whether device is CPE or CM in DOCSIS) or just because the link-address/giaddr is different from the actual allocation space.

4.       Differentiated services. Multiple allocation spaces exist for different types of clients (i.e., CPE vs CM in DOCSIS).

I also question whether section 8 (Dynamic Lookup) is really necessary and appropriate to this document. There already is text in that discusses this and do we really need it in multiple places? Perhaps adding a reference to this in section 7 (in first paragraph on page 14) would be sufficient?

There are also minor wording changes (adding "a" or "the", rewording several sentences to improve readability, and eliminating contractions (aren't, won't, ...)). And, there are a bunch of typos in the document:

-          "aquired" -> "acquired"

-          "indentifier" -> "identifier" (2 times)

-          "inserted" -> "inserted"

-          "identifers" -> "identifiers"
I will work directly with the authors on these issues.


As WG Co-chair, I would appreciate others reading the document and providing their input as to the status of the document.

-          Bernie

From: dhcwg [] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, July 08, 2015 5:15 PM
Subject: [dhcwg] WGLC for draft-ietf-dhc-topo-conf-05.txt - Respond by July 29, 2015

Hi all,

This message starts the DHC working group last call to advance "Customizing DHCP Configuration on the Basis of Network Topology", draft-ietf-dhc-topo-conf-05, document as an Informational RFC. The authors believe that this version is ready. We did a WGLC for the 03 draft in October 2014, which raised some issues and resulted in the updates. At that time, we felt the document did not pass WGLC.

The draft is available here:

Please send your comments by July 29th, 2015. If you do not feel this document should advance, please state your reasons why.

There are no IPR claims reported at this time.

Bernie Volz is the assigned shepherd for this document.

- Tomek & Bernie