Subject: [dhcwg] dhc - Not having a session at IETF 110

From: IETF Meeting Session Request Tool <[email-masked]>
Date: Fri, 15 Jan 2021 08:43:05 -0800

Bernie Volz, a chair of the dhc working group, indicated that the dhc working group does not plan to hold a session at IETF 110.

This message was generated and sent by the IETF Meeting Session Request Tool.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 15 Jan 2021 17:17:09 +0000

Hi:

Tim and I concluded that the DHC WG will not meet (virtually) at IETF 110. We decided a bit earlier than originally planned but we do not see anything on the horizon that requires a session.

As of this writing, there was only one request for time regarding the recently published individual-submission draft, https://datatracker.ietf.org/doc/draft-templin-duid-ipv6/, and this can be and is being discussed on the WG mailing list and does not warrant a session at this time.

If someone does need us to reconsider requesting a DHC WG session for IETF 110, please contact the chairs promptly (the IETF deadline to request a session is January 22nd). In general, new potential work should be initiated by submitting an individual-submission draft and sending details to the DHC WG mailing list.

The WG document status at this time is:
-	1 WG document (DHCPv6 Prefix Delegating Relay Requirements) is in the RFC-Editor queue.
-	1 WG document (YANG Data Model for DHCPv6 Configuration) needs comments on recent changes before potential WG last call. Please review as model was significantly updated.

And, we plan to advance the base DHCPv6 protocol specification (RFC8415) to full standard. As USGv6 DHCPv6 Standards Profiles were updated recently (based on RFC8415), we will monitor the development and results of testing suites related to these to determine when we feel there is sufficient support for RFC8415 in implementations to move forward.

Thanks much!

-	Bernie

---

From: Michael Richardson <[email-masked]>
Date: Sat, 16 Jan 2021 16:48:01 -0500

Bernie Volz \(volz\) <volz=[email-masked]> wrote:
    > Tim and I concluded that the DHC WG will not meet (virtually) at IETF
    > 110. We decided a bit earlier than originally planned but we do not see
    > anything on the horizon that requires a session.

Good.  When I replied I found myself replying to [email-masked].
Was that intended?  I guess it was in the To:, and the WG was in some BCC?
Or maybe just some artifact of replying to the DT.

    > And, we plan to advance the base DHCPv6 protocol specification
    > (RFC8415) to full standard. As USGv6 DHCPv6 Standards Profiles were
    > updated recently (based on RFC8415), we will monitor the development
    > and results of testing suites related to these to determine when we
    > feel there is sufficient support for RFC8415 in implementations to move
    > forward.

Are you saying that you propose to advance RFC8415 via RFC6410 section 2.2
second last-paragraph process? i.e. an IESG four week Last Call?

Or are you saying that a 8415bis process will start, and we'll have to have
another round of excising anything that hasn't been tested?

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 26 Jan 2021 17:31:19 +0000

Hi:

Per RFC6410 section 2.2, we need to:

   The IESG, in an IETF-wide Last Call of at least four weeks, confirms
   that a document advances from Proposed Standard to Internet Standard.
   The request for reclassification is sent to the IESG along with an
   explanation of how the criteria have been met.  The criteria are:

   (1) There are at least two independent interoperating implementations
       with widespread deployment and successful operational experience.

   (2) There are no errata against the specification that would cause a
       new implementation to fail to interoperate with deployed ones.

   (3) There are no unused features in the specification that greatly
       increase implementation complexity.

   (4) If the technology required to implement the specification
       requires patented or otherwise controlled technology, then the
       set of implementations must demonstrate at least two independent,
       separate and successful uses of the licensing process.

For (1), while it may be possible we can find sufficient implementations that adhere to RFC8415, we feel that once the USGv6 DHCPv6 testing is done (which is now based on RFC8415), it will be far easier to document this. Currently, most implementations are probably somewhere between RFC3315 and RFC8415 (some may not honor RFC7550, which is part of RFC8415).

I think there is no debate that RFC3315 (and many of its friends) meet (1) but it is less clear that hurdle can be met by RFC8415 (and some of the "more recent" RFCs that were incorporated into it).

For (2), while there are currently 3 errata, these all seem to be minor errors in the text. So, I think we are OK there. I don't think we need a RFC8415-bis.

For (3), there could be a debate whether IA_TA's are "unused". But as IA_TAs are optional and the deltas from IA_NA are "small", I would argue that it doesn't greatly increase the complexity of the implementations?

For (4), I don't think we have any "known" issues in this regard.

Thus, I see no need for a RFC8415-bis at this time.

In recent discussions, Tim and I feel that waiting a bit for the new USGv6 DHCPv6 testing suites to be developed and run will provide the data that we need to be more confident about (1).

I can speak for the Cisco Prime Network Registrar DHCP server - to the best of my knowledge it fully supports RFC8415 (I did start a re-review of RFC8415 to confirm about a year ago, but put it aside when Covid-19 disrupted our earlier plans for a DHCPv6 plugfest). If others have implementations of clients, servers, relays that they believe support RFC8415, please let us know as we can start to collect these details and, if appropriate, perhaps move on this sooner.

BTW: I think the email you replied to was the request for agenda items and those just needed to go to the chairs as we'd communicate the agenda (if we were meeting).

- Bernie

-----Original Message-----
From: dhcwg <[email-masked]> On Behalf Of Michael Richardson
Sent: Saturday, January 16, 2021 4:48 PM
To: [email-masked]
Subject: [dhcwg] advancing RFC8415

    > feel there is sufficient support for RFC8415 in implementations to move

Are you saying that you propose to advance RFC8415 via RFC6410 section 2.2 second last-paragraph process? i.e. an IESG four week Last Call?

Or are you saying that a 8415bis process will start, and we'll have to have another round of excising anything that hasn't been tested?

---

From: Michael Richardson <[email-masked]>
Date: Tue, 26 Jan 2021 13:37:02 -0500

> Per RFC6410 section 2.2, we need to:

...

    > increase implementation complexity.

...

Thanks for the reply and clarification to the group.

    > For (2), while there are currently 3 errata, these all seem to be minor
    > errors in the text. So, I think we are OK there. I don't think we need
    > a RFC8415-bis.

    > For (3), there could be a debate whether IA_TA's are "unused". But as
    > IA_TAs are optional and the deltas from IA_NA are "small", I would
    > argue that it doesn't greatly increase the complexity of the
    > implementations?

Yeah, this is where I think we'll need to clear.
Note that it says, "greatly increase", and I would certainly agree that IA_TA
does not fall into that category.

The DHCPv6 (mostly PD) client that is in OpenWRT probably gets the most
excerise out there.

It seems to interoperate well.  Perhaps Broadband Forum and CableLabs would
also be able to provide some data and/or contacts for ISPs that are
successfully doing IPv6-PD to home networks.  That might reveal a nice
interop matrix.  Maybe they won't go public with the data, but perhaps could
still attest to it.

---

From: Roy Marples <[email-masked]>
Date: Fri, 29 Jan 2021 17:26:15 +0000

> I think there is no debate that RFC3315 (and many of its friends) meet (1) but it is less clear that hurdle can be met by RFC8415 (and some of the "more recent" RFCs that were incorporated into it).

I believe dhcpcd-9.4 conforms with the all the above RFC's and sees a lot of use 
for Prefix Delegation.

Roy