Re: [dhcwg] Draft for Re-chartering

Tomek Mrugalski <> Wed, 03 January 2018 21:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9C1E9129C6C for <>; Wed, 3 Jan 2018 13:38:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S3S1hE-V_F6v for <>; Wed, 3 Jan 2018 13:38:50 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C2E88120726 for <>; Wed, 3 Jan 2018 13:38:49 -0800 (PST)
Received: by with SMTP id g63so2830288lfl.11 for <>; Wed, 03 Jan 2018 13:38:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=nYuJisM+QmZ8w/nXnp9R9fJCYhidlRjFVGBrT0Ab+Wk=; b=Tj6Cbmq2IaOOIebNM6WIseA7s7IodWAkJFngOSFBDdjaVn8v13/Nahnc5L4SYIjVXi hfusjUqBVW7Fem+DigDQ0/5+Ltc/Grln8KVmquJBCAT3iYmFw2qJomqPZqAe2xybqXRG 2WB2PDetfjA2bQDzMnvyiwPvgEPPM79e7luq6wY7m2Hjdy4MEn60cTWF76D0BxktwAZ3 96bZgBae+AgoqAkWNJzefeB7tHyY2LkHaYfTwRLg+VAZjMZvh2EGOUUe5abJCn1W0bCh tgomg0Vn3qpvuFiY3mB2JZJRMeMuYl9R3tezrcrbsKNiuatAETltumAd9Fu9/QoujJhs U+mA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=nYuJisM+QmZ8w/nXnp9R9fJCYhidlRjFVGBrT0Ab+Wk=; b=i4xETt9yLkG4X+2OAKW1PYBlu61NHm+yEt0R/2P7N83Yd3474Xs8xGE/IYjhZ/DVIO c3+J7vfyRKGnSEuPT71mR7MkJjBfsZFn+LWPJ8goOKg9/36vsP2LlZf+Y3HHOAZnfJKS Pn27sutS6b4RSaPkBAlrAhgoaTrAd08sI700KNgoFYFfd/9Z22/hYB2PSuatqADSojju 5sFKSKxm8ysb8DeQJsBvvpoljX3X3RkM3ZJpn+1f4qkrsaDmgC7ZSQ8MtzBIe581UizR TsSvTAesjFP8Via+jsKM7/HVAVch9Gc8BHoKQc0t4KN5cdO7QPZv9DzfTFJIgXgrN5bP phQg==
X-Gm-Message-State: AKGB3mKPmtzTvfmlh86IS4HRJlmM1hPI8IN7RkAf6+byqFJJfmfCECSK C553P3OngfWFczaDUCIuyAAPpgoY
X-Google-Smtp-Source: ACJfBoswv3YBNjfFjVorKXl/uRZNMHd3c8OmcAfLuFO49bvGYjG2PGp90N5KU0CXGmD+L0fZV41RuA==
X-Received: by with SMTP id 27mr1539111lfx.26.1515015527588; Wed, 03 Jan 2018 13:38:47 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id f73sm356105lfk.23.2018. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jan 2018 13:38:46 -0800 (PST)
References: <>
From: Tomek Mrugalski <>
Message-ID: <>
Date: Wed, 3 Jan 2018 22:38:43 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------803AB5A92D1107191655AAA0"
Content-Language: en-GB
Archived-At: <>
Subject: Re: [dhcwg] Draft for Re-chartering
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 03 Jan 2018 21:38:53 -0000

W dniu 27.11.2017 o 03:36, Bernie Volz (volz) pisze:
> Hi:
> At IETF-100 in Singapore we discussed re-chartering the WG (see
> There were a few minor comments regarding that proposed text and a
> revised text based on those comments is below.
> Please comment on suggested changes/improvements.
> Begin Re-charter Text -->
> The Dynamic Host Configuration Working Group (DHC WG) has developed DHCP
> for automated allocation, configuration and management of IP addresses
> and TCP/IP protocol stack parameters. DHCPv4 is currently a Draft
I would rephrase the first sentence as:

The Dynamic Host Configuration Working Group (DHC WG) has developed DHCP
for automated allocation, configuration and management of IP addresses,
IPv6 prefixes, IP protocol stack parameters and other parameters.

Saying that everything being configurable by DHCP is a TCP procotol
stack parameter is misleading. We also configure services and parameters
that have nothing to do with TCP/IP stack.
Also, referring to the stack as TCP/IP sounds very 80s. IP protocol
stack sounds better. There are documented cases of DHCP users who used UDP.

> Standard and is documented in RFC 2131 and RFC 2132. DHCPv6 is currently
> a Proposed Standard and is being updated and the WG plans to advance the
> protocol to full standard.
> The DHC WG is responsible for defining DHCP protocol extensions.
> Definitions of new DHCP options that are delivered using standard
> mechanisms with documented semantics are not considered a protocol
> extension and thus are generally outside of scope for the DHC WG. Such
> options should be defined within their respective WGs and reviewed by
> DHCP experts in the Internet Area Directorate. However, if such options
> require protocol extensions or new semantics, the protocol extension
> work must be done in the DHC WG. Or, when no respective WG exists, the
> DHC WG may take on the option definitions work with approval from the
> responsible Area Director.
> The DHC WG has the following main objectives:
> 1. Develop documents that help explain operational considerations for
> the wider community if and as needed.
I would reword this item slightly:
Develop documents that are related to operational considerations of DHCP
for the wider community if and as needed.

There are two changes here. First, "explain" is removed as we may do
more than just explain. We could recommend some practices or discourage
people from doing certain things. Also, defining configuration
mechanisms, such as YANG models, is part of the operational
considerations. Second, without DHCP added, some may take it out of
context and say that DHC can make any operational consideration
regarding things other than DHCP. This is particularly likely with the
"wider community".

> 2. Assist other WGs and independent submissions in defining options
> (that follow RFC 7227 guidelines) and to assure DHCP operational
> considerations are properly documented.
During Singapore meeting we had a discussion about defining IOT options.
The general suggestion was that some external organization (IIRC OASIS
was mentioned) is better suited for such work. This approach would be
similar to what DOCSIS did for cable modems. Do we want to explicitly
mention "external organizations" in here?

The remaining text looks good to me.