Re: [dhcwg] Draft for Re-chartering

"Bernie Volz (volz)" <volz@cisco.com> Mon, 08 January 2018 02:04 UTC

Return-Path: <volz@cisco.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 87317126B6E for <dhcwg@ietfa.amsl.com>; Sun, 7 Jan 2018 18:04:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level:
X-Spam-Status: No, score=-14.52 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 MVyWQg1QevMq for <dhcwg@ietfa.amsl.com>; Sun, 7 Jan 2018 18:04:04 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B11E0126D3F for <dhcwg@ietf.org>; Sun, 7 Jan 2018 18:04:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25234; q=dns/txt; s=iport; t=1515377044; x=1516586644; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=6MnDyKzsHSMRshRIAy8I32fppDQWnHGv9O0Bd4ewcm0=; b=kY6uDmDKWivaqpGrC7/bC3tRjP4fSvcdcWQfwlTc3D+1WyNTUBhjkhJU SqqUXzDIIOAtVZv9dMD0wnE+piwXAQ+wFq6kID4i6lN0Cny+aoiWr2zHq PCNP9FuJP5I01U7GVbGAfbWe3+/lfpSl3eln/R5VGHXCgcRK7U8CspQR8 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BRAQDp0FJa/51dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKRTBmdCcHjiSOWIIClyoUggEKJYUWAoQyPxgBAQEBAQEBAQF?= =?us-ascii?q?rKIUjAQEBAQMnBj4eAgEIDgMEAQEhBwcyFAkIAQEEARIIDIk5ZBCzZTomigoBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEYBYQgghWGbYMvAYFWToVGBZlviW8CiAWNLoI?= =?us-ascii?q?ghhmLWY0ziTcCERkBgTsBHzmBUG8VglcBAQ6CVByBZ3iJDYEXAQEB?=
X-IronPort-AV: E=Sophos;i="5.46,328,1511827200"; d="scan'208,217";a="329885116"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2018 02:04:02 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id w082429Z023835 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Jan 2018 02:04:02 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sun, 7 Jan 2018 20:04:01 -0600
Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1320.000; Sun, 7 Jan 2018 20:04:01 -0600
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Tomek Mrugalski <tomasz.mrugalski@gmail.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Thread-Topic: [dhcwg] Draft for Re-chartering
Thread-Index: AdNnKHnFDJ0pfbDmQeqJKheqkwE8GAd5QraAAMW1QJA=
Date: Mon, 8 Jan 2018 02:04:01 +0000
Message-ID: <76942a0f18d24473a8fe54be29f4b4b8@XCH-ALN-003.cisco.com>
References: <c75fcb03185b49bab003dfa5e6a8f795@XCH-ALN-003.cisco.com> <0fd9d640-55d0-d7a2-eb06-a6de681b5491@gmail.com>
In-Reply-To: <0fd9d640-55d0-d7a2-eb06-a6de681b5491@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.98.1.197]
Content-Type: multipart/alternative; boundary="_000_76942a0f18d24473a8fe54be29f4b4b8XCHALN003ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/fvUfPuYQ7AxEKXj9OpYtxmaDLJo>
Subject: Re: [dhcwg] Draft for Re-chartering
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 08 Jan 2018 02:04:07 -0000

So, how about we go with:

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 and other parameters. DHCPv4 is
currently a Draft 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 are related to operational considerations of
DHCP for the wider community if and as needed.

2. Assist other WGs and independent submissions in defining options
(that follow RFC 7227 guidelines) and to assure DHCP operational
considerations are properly documented.

3. Additional topics and any option definition work may only be added
with approval from the responsible Area Director or by re-chartering.

4. Issue an updated version of the DHCPv6 base specification, and after
an appropriate interval following publication, advance to full standard.

This includes all of Tomek's proposed changes EXCEPT for adding anything to (2) for "external organizations". I think if asked we would (either personally or as a WG) help out. But I think that this needs to be formalized and will likely end up confusing people as to what it means.


-          Bernie

From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski
Sent: Wednesday, January 03, 2018 4:39 PM
To: dhcwg@ietf.org
Subject: Re: [dhcwg] Draft for Re-chartering

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 https://datatracker.ietf.org/meeting/100/materials/slides-100-dhc-dhc-recharter/). 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.

Tomek