Re: [dhcwg] Draft for Re-chartering

["Bernie Volz (volz)" <[e-mail]>]

Hi:

OK, that leaves us saying nothing about this particular issue and it will still be up to Suresh (or the then current AD) to deal with new options work that wasn’t done elsewhere. But I guess that isn’t “in our charter” to resolve. Though we could work in the following minor change if we wanted to attempt to at least capture the spirit - “within their respective WGs or sponsored by an appropriate AD”.

Looking at the charter again, I do wonder if bullet 3 should not be a bullet and just be a separate paragraph at very end (since it really isn’t an objective of the WG)? In the current charter, it was under the list of tasks we had which we removed in this round. Another option would be to change #3 to be “Finish up documents adopted by the WG. Additional topics …”?

And, I like your replacement text for bullet #1 … so I think that leaves us at (without the change proposed above):

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. Informational documents providing operational or implementation advice
about DHCPv6, as well as documents specifying standard mechanisms for
operating, administering and managing DHCPv6 servers, clients, and relay
agents.

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:[e-mail]]
Sent: Wednesday, January 10, 2018 2:14 PM
To: Bernie Volz (volz) <[e-mail]>
Cc: Tomek Mrugalski <[e-mail]>; [e-mail]
Subject: Re: [dhcwg] Draft for Re-chartering

On Jan 10, 2018, at 2:06 PM, Bernie Volz (volz) <[e-mail]<mailto:[e-mail]>> wrote:
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).

Right, my point is that the responsible AD for DHC is likely not the right AD to sponsor the kind of work that's being talked about.   IOW, this is simply not the right approach.

When we originally put the text in the charter, it hadn't sunk in that we weren't really solving the problem that we intended to solve when we required AD approval—the problem of people shopping their ideas to the DHC working group when they didn't get buy-in from the area where the work should have been done. Instead, we'd simply moved the burden for saying no from the working group to the AD.

Turning it around—requiring that an AD sponsor the work, actually solves the problem we were originally trying to solve.   It means that Suresh can now say "that's not in my area, so it doesn't make sense for me to sponsor it," instead of having to come up with a reason not to approve it.


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.

Yes, I know it does, but I think the current text is still problematic, hence the comment.


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?

I would make it more broad and detailed: "Informational documents providing operational or implementation advice about DHCPv6, as well as documents specifying standard mechanisms for operating, administering and managing DHCPv6 servers, clients and relay agents."