Re: [dhcwg] advancing RFC8415

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

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 <[e-mail]> On Behalf Of Michael Richardson
Sent: Saturday, January 16, 2021 4:48 PM
To: [e-mail]
Subject: [dhcwg] advancing RFC8415


Bernie Volz \(volz\) <volz=[e-mail]> 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 [e-mail].
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 <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide