Subject: [dhcwg] DHC WG Re-Charter Proposal

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 25 Jun 2013 19:47:23 +0000

Hello:

The text below is a proposed update of the DHC WG charter that the co-chairs developed with input and review from Ted Lemon (AD). It assumes a DHCP Directorate is created as well (see separate email). Feedback on the charter text is appreciated and will also be discussed in Berlin as we hope to finalize it shortly thereafter.

While the DHC re-charter and DHCP directorate are connected, we'd like to try to separate the discussion (hence the directorate is in a separate email).

The current charter, which is rather old, can be viewed at http://datatracker.ietf.org/wg/dhc/charter/.

Proposed DHC WG Charter:

  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 Standard and is documented in RFC 2131 and RFC 2132. DHCPv6
  is currently a Proposed Standard and is documented in RFC 3315.
  Subsequent RFCs document additional options and other enhancements to
  the specifications.

  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 outside of scope for DHC WG. Such options should
  be defined within their respective WGs and reviewed by the DHCP
  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:

  * Develop extensions to the DHCPv6 infrastructure as required to meet
  new applications and deployments of DHCP. The topics currently
  in development are:

  - DHCPv6 Failover, High Availability and Load Balancing
  - DNS Update strategies for delegated prefixes (draft-ietf-dhc-dns-pd)
  - Extend DHCPv6 to work with multiple provisioning domains
  - DHCP provisioning of IPv4 clients over IPv6 networks
  - SOLMAXRT counter update
  - Container option
  - Address Network Identifier (draft-ietf-dhc-access-network-identifier)
  - New NTP option to replace OPTION_NTP_SERVER (RFC 5908)
  - Prefix coloring (draft-bhandari-dhc-class-based-prefix)

    Additional topics may only be added with approval from the responsible
    Area Director or by re-chartering.

  * Specify guidelines for creating new DHCPv6 options.

  * Develop documents that help explain operational considerations for
    the wider community.

  * Advance DHCPv6 (RFC 3315) along the IETF Standards Track. This will
  include writing analyses, corrections, and clarifications of the DHCPv6
  specifications, including RFC 3315, RFC3633, RFC3736 and other RFCs
  defining additional options, which identifies and resolves ambiguities,
  contradictory specifications and other obstacles to development of
  interoperable implementations.

END

-          Tomek & Bernie

---

From: Kim Kinnear <[email-masked]>
Date: Thu, 27 Jun 2013 16:48:47 -0400

I have a major problem with this charter.  As I read it, the DHC
WG cannot create drafts for new options the are not "protocol
options".  This is a *huge* change from the past.

There is clearly a desire to disconnect the DHC WG from becoming
involved in the options proposed by folks from other working
groups.  Thus, the DHCP Directorate is the place where those
options will be reviewed (according to this charter).  I can see
why this is being done, and while I'm a bit uncomfortable with
it, I can understand some of the reasons for this change, and I
can live with it.

However, that is very different from the constraint in this
charter that says that the DHC WG cannot create options that are
not protocol options.  This places the DHC WG in a *more*
restrictive position than other WGs -- *they* can try to create
options that are reviewed by the DHCP directorate.  But the DHC
WG is explicitly chartered to create only protocol options.
Period.

I think this is wrong.  When I raised this at the last IETF, I
was told that "consensus isn't necessary for charter approval".

I understand, but the fact that I was told that my opinion really
isn't interesting doesn't change my opinion.  

I *still* think that this is a major mistake.

I believe that the DHC WG should be able to take on the creation
of DHCP options if the WG chairs believe that it is a good idea.

I would strongly recommend that we amend this charter to include
this statement as the third paragraph:

  The DHC WG may, at the discretion of any of the chairs of the
  WG, be considered to be chartered to develop non-protocol DHCP
  options on a case by case basis.  The normal consensus approach
  to adoption as a WG work item would be used in this case, but
  would require explicit WG chair approval that the non-protocol
  option fit within the charter of the working group.  These
  options would undergo the same review as protocol extensions.

Absent something like this, if you need a simple non-protocol
option, you will have to shop it around to some other working
group to get it adopted.  Is this going to help the situation?

Regards -- Kim

On Jun 25, 2013, at 3:47 PM, Bernie Volz (volz) wrote:

> While the DHC re-charter and DHCP directorate are connected, we’d like to try to separate the discussion (hence the directorate is in a separate email).
>  
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 27 Jun 2013 21:13:08 +0000

Kim:

If we instead leave it too open, it would be too easy to adopt work that is either better handled by another WG or that should be worked through the DHCP Directorate (perhaps as an individual submission). Nothing here says you can't mention it on the DHC WG mailing list - it just wouldn't be a DHC WG work item.

I (and I think Tomek too) do agree with you that this is a potential concern because there are cases where new "simple" options may best be done by the WG.

But also note that the WG CAN take on new work:

We can go to the AD(s) and say we'd like to work on option foo because ... and if the arguments are reasonable, I don't think the AD(s) would say no. I believe experience has shown that the AD(s) are reasonable (yes, I know ... past performance is not necessarily indicative of future performance).

We'd like to try setting the bar a bit higher just now so it is easier to tell people to try elsewhere.

Also, note that there are already two on the list that fall into the category of generally not being DHC WG items (under the "new" charter):

The first was added because there really wasn't another place to do this work within the IETF (we tried to move it away, but Ted felt we were best to handle it). The second doesn't yet have a draft (on my plate when time permits unless someone else takes it on) and was in discussions with Ted because the current RFC is not something we want people to follow -- so it is a cleanup.

- Bernie

-----Original Message-----
From: Kim Kinnear (kkinnear) 
Sent: Thursday, June 27, 2013 4:49 PM
To: Bernie Volz (volz)
Cc: Kim Kinnear (kkinnear); [email-masked]; Ted Lemon ([email-masked])
Subject: Re: [dhcwg] DHC WG Re-Charter Proposal

I have a major problem with this charter.  As I read it, the DHC WG cannot create drafts for new options the are not "protocol options".  This is a *huge* change from the past.

There is clearly a desire to disconnect the DHC WG from becoming involved in the options proposed by folks from other working groups.  Thus, the DHCP Directorate is the place where those options will be reviewed (according to this charter).  I can see why this is being done, and while I'm a bit uncomfortable with it, I can understand some of the reasons for this change, and I can live with it.

However, that is very different from the constraint in this charter that says that the DHC WG cannot create options that are not protocol options.  This places the DHC WG in a *more* restrictive position than other WGs -- *they* can try to create options that are reviewed by the DHCP directorate.  But the DHC WG is explicitly chartered to create only protocol options.
Period.

I think this is wrong.  When I raised this at the last IETF, I was told that "consensus isn't necessary for charter approval".

I understand, but the fact that I was told that my opinion really isn't interesting doesn't change my opinion.  

I believe that the DHC WG should be able to take on the creation of DHCP options if the WG chairs believe that it is a good idea.

I would strongly recommend that we amend this charter to include this statement as the third paragraph:

Absent something like this, if you need a simple non-protocol option, you will have to shop it around to some other working group to get it adopted.  Is this going to help the situation?

Regards -- Kim

---

From: Ted Lemon <[email-masked]>
Date: Fri, 28 Jun 2013 01:25:13 +0000

I won't reiterate what Bernie said, which was correct, but a few points of my own:

> options".  This is a *huge* change from the past.

Bernie covered this; let me know if you don't buy his answer.

> WG is explicitly chartered to create only protocol options.

This is actually incorrect.   Random working groups can't just go off and do DHCP options.   The work has to appear in their charter.   The point of this is to raise the visibility of such proposals to the level of the IESG, so that we can avoid having working groups go off and extend DHCP without ever talking to us.   Part of what I hope to do to raise awareness of this at the IESG level is the text I asked the authors of the option guidelines draft to add to the document on the topic of chartering working groups to add options.   I don't see that in the current version of the document, but I'm hoping the authors will add that text, because it would make clear to you what we are trying to do.

> When I raised this at the last IETF, I

What was said was that consensus does not require that everybody agree.   Consensus _is_ required in order to propose a new charter, but that's not the whole story (see below).

> isn't interesting doesn't change my opinion.  

Your opinion is certainly interesting.   The question is whether it can be accommodated.   I _hope_ that what's been clarified here makes this change more palatable to you, but please be assured that if it still isn't palatable to you, this is not a desired outcome, nor one that anyone will feel pleasantly comfortable with.

> group to get it adopted.  Is this going to help the situation?

The above text is specifically what the IESG would like taken out of the charter.   As Bernie said, the working group can take on a new work item either by agreement with the AD, or by adding that work to the charter.   Which path to take really depends on what work is proposed—if you want to add a new option to configure impress servers, that probably doesn't merit a recharter, but if you want to add a new option to carry SDP configuration information, that probably does.

The effect that this has is that if someone comes to the chairs and says "we want to do a new DHCP option in the DHC working group that effectively modifies the IPv6 routing architecture," there are now three levels of notice that can occur before the working group starts working on something it probably shouldn't.   First, the chairs might notice, and either say no themselves, or ask their AD to say no, so that they don't have to be the bad guys.   Second, if they don't notice the problem, the responsible AD might notice, and again say "no, sorry, that's not a good idea."   Third, if a charter change is done, other ADs on the IESG will likely notice the conflict, since it impacts their area.

So the point of this is to get cross-area recognition of new, potentially conflicting work _before_ the working group spends a year working on the document and sends it up to the IESG.

At the moment, the IESG does not like the DHC working group charter, because the way it's written, it's got a wildcard in it that's big enough to drive a truck through, and trucks have been driven through it in the past, sometimes with painful consequences.   This change is not intended to prevent the DHC working group ever working on new options.   The purpose of the change is very specifically to close this loophole.

The IESG has some limited influence in making this sort of thing happen, because working groups work for area directors, and consequently for the IESG.   If the IESG is not happy with the charter of a working group, they can't make the working group recharter if the working group doesn't want to, but they do have the ultimate nuclear option, which is to simply shut down the working group.   This doesn't happen very often, but it has been done.

Needless to say, this is not a desirable outcome, so this is my motivation for working with the chairs to try to close this loophole.   Certainly nobody on the IESG has proposed shutting down the working group, perhaps due to the beam-in-the-eye principle, but these sorts of cleanups are something the IESG as a whole is keen on right now, and that's where this push is coming from.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 28 Jun 2013 10:23:11 +0200

Two points:

On 6/28/13 3:25 AM, Ted Lemon wrote:
> This is actually incorrect. Random working groups can't just go off
> and do DHCP options. The work has to appear in their charter.

It is possible to hide a DHCP option in a draft without actually
mentioning it in the charter, if the option is in support of whatever
additional functionality is being offered. 

Also, as I read the changes and the intent in your message, Ted, this
will have the effect of slowing down new options work.  Maybe that's a
good thing, but it will happen because right now it's a matter of a call
for adoption for a WG draft and then off we go.  With the charter change
you'd need to first either gain approval of the AD or of the IESG for a
charter change, and then proceed to adoption.

Moreover, right now all expertise for DHCP has a well known rendezvous
point that has authority.  Directorates have shown themselves to be a
mixed bag.  One clear result is that it will shift load to the IESG,
because IESG members (probably you) will have to review the output of
the directorate.

In short I see this as a tradeoff between managing overlap and these
other issues.

Eliot

---

From: Alper Yegin <[email-masked]>
Date: Fri, 28 Jun 2013 12:34:24 +0300

>   - DHCP provisioning of IPv4 clients over IPv6 networks

I think we better stick with the "configuration/configuring" term instead of introducing the "provisioning" term.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 28 Jun 2013 14:50:16 +0000

Kim:

You might take a look at the 6man charter as an example (https://datatracker.ietf.org/wg/6man/charter/), part of which is below:

  The working group's work items are as follows:

  o Complete work on RA Flags Option
  o Complete work on RH0 Deprecation
  o Complete work on IPv6 over PPP Compression Negotiation
  o Complete work on Centrally Allocated Unique Local Addresses (ULA-C)

  All new work items not listed above require the approval
  of the working group and the sponsoring Area Director before
  they will be taken on by the working group.

The DHC wg has apparently had a very loose leash. Ted is just trying to get us to the IETF 'norm'.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Thursday, June 27, 2013 9:25 PM
To: Kim Kinnear (kkinnear)
Cc: Bernie Volz (volz); [email-masked]
Subject: Re: [dhcwg] DHC WG Re-Charter Proposal

On Jun 27, 2013, at 4:48 PM, Kim Kinnear <[email-masked]> wrote:
> I have a major problem with this charter.  As I read it, the DHC WG 
> cannot create drafts for new options the are not "protocol options".  
> This is a *huge* change from the past.

> However, that is very different from the constraint in this charter 
> that says that the DHC WG cannot create options that are not protocol 
> options.  This places the DHC WG in a *more* restrictive position than 
> other WGs -- *they* can try to create options that are reviewed by the 
> DHCP directorate.  But the DHC WG is explicitly chartered to create 
> only protocol options.
> Period.

> When I raised this at the last IETF, I was told that "consensus isn't 
> necessary for charter approval".

> I believe that the DHC WG should be able to take on the creation of 
> DHCP options if the WG chairs believe that it is a good idea.
> 
>  The DHC WG may, at the discretion of any of the chairs of the  WG, be 
> considered to be chartered to develop non-protocol DHCP  options on a 
> case by case basis.  The normal consensus approach  to adoption as a 
> WG work item would be used in this case, but  would require explicit 
> WG chair approval that the non-protocol  option fit within the charter 
> of the working group.  These  options would undergo the same review as 
> protocol extensions.
> 
> Absent something like this, if you need a simple non-protocol option, 
> you will have to shop it around to some other working group to get it 
> adopted.  Is this going to help the situation?

The above text is specifically what the IESG would like taken out of the charter.   As Bernie said, the working group can take on a new work item either by agreement with the AD, or by adding that work to the charter.   Which path to take really depends on what work is proposed-if you want to add a new option to configure impress servers, that probably doesn't merit a recharter, but if you want to add a new option to carry SDP configuration information, that probably does.

---

From: Kim Kinnear <[email-masked]>
Date: Fri, 28 Jun 2013 11:24:38 -0400

Ted,

I was aware that this change was designed to solve problems that
have occurred in the past.   The sometimes painful consequences
that you refer to have not directly impacted me, so this solution
seemed (and still seems, to some degree) out of proportion to the
severity of the problems it is designed to solve.  But I can see
the way the wind is blowing, and that this change is going to
happen.

It does help that you pointed out that there is a way to
still do a necessary non-protocol changing option should the need
arise.  As I believe the need will arise, I would be more
comforted if there were a specific mention of non-protocol
options in the "escape clause" (that new work can be taken on
with AD approval).  However, I am assuming that you don't want to
highlight that idea (that being the activity that you want to
reduce), so I suppose that idea isn't going to make much progress
either.

Thank you for explaining the "escape clause" -- I did miss it the
first time around. 

I can live with this as it stands, for what that is worth.

Regards -- Kim

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 28 Jun 2013 15:36:03 +0000

Well, one of the drafts is titled:

        Provisioning IPv4 Configuration Over IPv6 Only Networks
                   draft-ietf-dhc-v4configuration-01

And another draft has:

   By conveying DHCPv4 messages over DHCPv6 transport, this mechanism

   can achieve dynamic provisioning of IPv4 address and other

   configuration parameters.  In addition, it is able to leverage

   existing infrastructure for DHCPv4, e.g.  failover, DNS updates,

   leasequery, etc.  This mechanism is suitable for stateful allocation

   and management of IPv4 addresses and configuration parameters across

   IPv6 networks.

   Several approaches for provisioning such information have already

   been proposed.  This document describes alternative approach.

So this isn't really introducing new terminology.

But, if we have better words to describe this (and it may well extend to one or more drafts), I have no issues with using them.

-          Bernie

From: Alper Yegin [mailto:[email-masked]]
Sent: Friday, June 28, 2013 5:34 AM
To: Bernie Volz (volz)
Cc: [email-masked]; Ted Lemon ([email-masked])
Subject: Re: [dhcwg] DHC WG Re-Charter Proposal

---

From: Ted Lemon <[email-masked]>
Date: Fri, 28 Jun 2013 17:58:34 +0000

> additional functionality is being offered. 

I suppose that's true, but it's okay—if a working group decides to do this, then they may just face a late surprise during IETF review.   The point of this effort is to make late surprises less likely, but there's no way to prevent them entirely.

> charter change, and then proceed to adoption.

Yes, this is indeed the intention.   There's no need to rush, and the goal is to provide early feedback and clarity on exactly what it means to develop a new DHCP option, when working groups decide to do so.

> because IESG members (probably you) will have to review the output of

That's the exact goal.   We've had several cases where working groups got DHCP protocol extensions past the IESG without proper review, because there was no formal process for reviewing them.  The new charter we are discussing has a work item to replace a broken draft produced by a working group that bypassed the intended review process.  In another case I spent a huge amount of personal time essentially rewriting a document that a working group had done where they had failed to get proper review, and I only noticed it when the document was on the verge of publication, years after the working group had closed.   The document had been stalled waiting on a reference for a long time, or it would have become an RFC before the problem got fixed.   The goal of this is to do a better job of review in this situation, and hopefully avoid repeats of this kind of pain.

> In short I see this as a tradeoff between managing overlap and these

Yup, I think everything you've said here is correct.   :)

---

From: Ted Lemon <[email-masked]>
Date: Fri, 28 Jun 2013 18:03:48 +0000

> I can live with this as it stands, for what that is worth.

Thanks.   I will take what I can get on this.   Please continue to hold my feet to the fire if you feel that things aren't going the way they should be as a result of this.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 28 Jun 2013 19:29:54 +0000

FYI - The proposed re-charter text can be found at https://datatracker.ietf.org/doc/charter-ietf-dhc/ (thanks to Ted for uploading it).

There was also one minor issue fixed that Kim found:

Address should be Access:

- Access Network Identifier (draft-ietf-dhc-access-network-identifier)

---

From: Tomek Mrugalski <[email-masked]>
Date: Sat, 29 Jun 2013 14:12:58 +0200

On 28.06.2013 03:25, Ted Lemon wrote:
> Part of what I hope to do to raise awareness of this at the IESG
> level is the text I asked the authors of the option guidelines draft
> to add to the document on the topic of chartering working groups to
> add options.   I don't see that in the current version of the
> document, but I'm hoping the authors will add that text, because it
> would make clear to you what we are trying to do.
We did add it in after 11, which was kept unpublished for a while.
Option-guidelines-12 is now uploaded. Please check if the text (whole
section 13:
http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-12#section-13)
is complete and meets your goal.

Tomek

---

From: Ted Lemon <[email-masked]>
Date: Sat, 29 Jun 2013 14:43:15 +0000

> is complete and meets your goal.

Ah yes, there it is.   Thank you!

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 29 Jun 2013 17:13:46 +0000

Tomek:

You might want to clean up use of "Area Directors", "area directors", and "AD". Also, AD isn't necessarily defined (not sure it would need to be) in Section 13. There are just nits and may also be dealt with by the RFC-Editor.

This section does seem to be rather long winded, but I didn't identify any easy changes to shorten it.

Note: I haven't done a full pass through the document; just looked at this Section 13.

There is also the question of whether the RFC 3315, 24. IANA Considerations (which really is more than just IANA), might be 'updated' by this text. But that may best be left to the 3315-bis work.

Unless an issue is raised by Monday that might cause me to reconsider, I will start the WG Last Call then. I think given the US holiday week and greater chance that others in Europe and elsewhere are on vacation, I think it best to have it be the regular 2 week Last Call (I think we were originally planning for a shorter 1-week call).

- Bernie

-----Original Message-----
From: Tomek Mrugalski [mailto:[email-masked]] 
Sent: Saturday, June 29, 2013 8:13 AM
To: Ted Lemon
Cc: Kim Kinnear (kkinnear); [email-masked]; Bernie Volz (volz)
Subject: Re: [dhcwg] DHC WG Re-Charter Proposal and option-guidelines

On 28.06.2013 03:25, Ted Lemon wrote:
> Part of what I hope to do to raise awareness of this at the IESG level 
> is the text I asked the authors of the option guidelines draft to add 
> to the document on the topic of chartering working groups to
We did add it in after 11, which was kept unpublished for a while.
Option-guidelines-12 is now uploaded. Please check if the text (whole section 13:
http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-12#section-13)
is complete and meets your goal.

Tomek