Re: [dhcwg] Draft for Re-chartering

"Bernie Volz (volz)" <volz@cisco.com> Wed, 10 January 2018 19:06 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 B87B5126CB6 for <dhcwg@ietfa.amsl.com>; Wed, 10 Jan 2018 11:06:47 -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 r2vb0cltn0sa for <dhcwg@ietfa.amsl.com>; Wed, 10 Jan 2018 11:06:44 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80DED12D84E for <dhcwg@ietf.org>; Wed, 10 Jan 2018 11:06:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28978; q=dns/txt; s=iport; t=1515611202; x=1516820802; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CDJf+T3Vs5dLtl70BcHQ97YUT4RtHKBxEv+pavoHXx4=; b=XPgIvIGXPNgaOr1UqAlfDiVY+SafK4X30v76PdU19nQWzWpA30O9OPl+ c8Cw9cqZF24N8SOHG/rHdKzkR2KCjFAp+yoOTxxSRwy/QS6rAhF2bHfpW t8eAv9TzhLaPnyrw4/Z1otlL+LRM038oaB84cNs9njjh3fWDIOl0R4y96 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BwAQCOY1Za/4UNJK1eGQEBAQEBAQEBAQEBAQcBAQEBAYJKRzBmdCcHhACKJI5fggKJC44kghYKhTsCGoQsPxgBAQEBAQEBAQFrKIUjAQEBAQMjCj4OEAIBCA4DBAEBIQcDAgICHxEUCQgBAQQOBQgMiTtMAxWvU4Inhz4NgnABAQEBAQEBAQEBAQEBAQEBAQEBAQEdhCCCFYVggQ6Ca0QEggYfgmGCZQWZcok1PQKLf4RDhHiCIZF2imWDFoh5AhEZAYE7AR85gVBvFYJnhFd4ikkBgRYBAQE
X-IronPort-AV: E=Sophos;i="5.46,341,1511827200"; d="scan'208,217";a="123736645"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jan 2018 19:06:41 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id w0AJ6fnO031391 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 10 Jan 2018 19:06:41 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; Wed, 10 Jan 2018 13:06:40 -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; Wed, 10 Jan 2018 13:06:40 -0600
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Ted Lemon <mellon@fugue.com>
CC: Tomek Mrugalski <tomasz.mrugalski@gmail.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Thread-Topic: [dhcwg] Draft for Re-chartering
Thread-Index: AdNnKHnFDJ0pfbDmQeqJKheqkwE8GAd5QraAAMW1QJAAkn7VAAAKvFjw
Date: Wed, 10 Jan 2018 19:06:40 +0000
Message-ID: <ffa2ac46b00b4f12a89c8e14656502c8@XCH-ALN-003.cisco.com>
References: <c75fcb03185b49bab003dfa5e6a8f795@XCH-ALN-003.cisco.com> <0fd9d640-55d0-d7a2-eb06-a6de681b5491@gmail.com> <76942a0f18d24473a8fe54be29f4b4b8@XCH-ALN-003.cisco.com> <C804CF0C-1826-41BC-8BAA-4B57F63834B9@fugue.com>
In-Reply-To: <C804CF0C-1826-41BC-8BAA-4B57F63834B9@fugue.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: [161.44.67.125]
Content-Type: multipart/alternative; boundary="_000_ffa2ac46b00b4f12a89c8e14656502c8XCHALN003ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/v6XnhkTGF4PHdd4fzzzHqx9YxnQ>
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: Wed, 10 Jan 2018 19:06:48 -0000

Hi Ted:

Thanks for the review and comments.

I think to add any work not on our charter, we need approval from the WG’s responsible AD (not just any AD). And, the point of this was to say that if the option definition work wasn’t being done elsewhere, we would be the last resort place to do it (pending AD approval).

I’m OK with deleting “Or, when no respective WG exists, the“ since it would be covered in bullet point 3 – whether we remove the “and any option definition work” text from there or not. Perhaps fewer works are better, so do both? And, this basically matches the text in the current charter.

Bullet point 1 is pretty vague.  What are "operational considerations?"

That text comes from the current charter (it was adjusted slightly by recent comments from Tomek). I think this is what RFC 7969 (Customizing DHCP Configuration on the Basis of Network Topology) was done “under” in the current charter. And, probably RFC 7844 (Anonymity Profiles for DHCP Clients). Do you think that we need to clarify this to say something like “operational considerations (such as those covered by RFC 7969 and 7844)”? Or?

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.

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 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.


-          Bernie

From: Ted Lemon [mailto:mellon@fugue.com]
Sent: Wednesday, January 10, 2018 12:54 PM
To: Bernie Volz (volz) <volz@cisco.com>
Cc: Tomek Mrugalski <tomasz.mrugalski@gmail.com>; dhcwg@ietf.org
Subject: Re: [dhcwg] Draft for Re-chartering

On Jan 7, 2018, at 9:04 PM, Bernie Volz (volz) <volz@cisco.com<mailto:volz@cisco.com>> wrote:
Or, when no respective WG exists, the
DHC WG may take on the option definitions work with approval from the
responsible Area Director.

I would suggest that you just delete this.   If there is work of this type to do, the working group is already chartered to review it, and that's what's important.   There has to be some proponent or set of proponents who want to do the work in order for the work to happen; these are the people who should be doing the work.   If an AD approves of the work, that AD can sponsor the work.

I mention this because in many cases it may be the case that the AD who would sponsor the work would not be an INT AD, and so the current text is actually a bit restrictive—it places all the burden for deciding whether not to approve this type of work on the responsible AD for DHC (currently Suresh).   If the work is related to something that would be in Suresh's purview, then that makes perfect sense, but e.g. if it's a DHCP option to support some routing function, or something like that, I'd expect that the AD who would sponsor the work would be from the routing area.

If you do delete this, you should also update bullet point 3.

Bullet point 1 is pretty vague.  What are "operational considerations?"