[dhcwg] Re: AD review of Dynamic Host Configuration Protocol for IPv6 (DHCPv6) draft-ietf-dhc-rfc8415bis-06

Hello Bernie and others,

While I was wondering why this effort appears to be stalled for 2+ weeks, I realized that I wrong used twice EVY2> in two different email messages... I took the liberty to rename the most recent EVY2> in EVY3>

Beside this EVY2 / EVY3, is there any remaining issue before submitting a revised I-D ?

Suresh, there is a call for you to update the shepherd’s write-up with the existing implementation and their lack of support/use of the features removed in 8415bis

Regards

-éric

From: Eric Vyncke (evyncke) <[email protected]>
Date: Thursday, 28 November 2024 at 14:44
To: Bernie Volz <[email protected]>
Cc: [email protected] <[email protected]>, Tomek Mrugalski <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, Timothy Winters <[email protected]>, Suresh Krishnan (sureshk) <[email protected]>
Subject: Re: AD review of Dynamic Host Configuration Protocol for IPv6 (DHCPv6) draft-ietf-dhc-rfc8415bis-06
Hello Bernie,

The shepherd’s write-up could indeed be updated about deployments/implementations using IA_TA, but your suggestion of added text is also OK (see EVY3> below).

Let’s submit a revised I-D and on we go for the publication process with the IETF Last Call

Regards and enjoy the family time of Thanksgiving (to whom it applies)

-éric


From: Bernie Volz <[email protected]>
Date: Tuesday, 26 November 2024 at 12:29
To: Eric Vyncke (evyncke) <[email protected]>
Cc: [email protected] <[email protected]>, Tomek Mrugalski <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, Timothy Winters <[email protected]>, Suresh Krishnan (sureshk) <[email protected]>, Suresh Krishnan (sureshk) <[email protected]>
Subject: Re: AD review of Dynamic Host Configuration Protocol for IPv6 (DHCPv6) draft-ietf-dhc-rfc8415bis-06
Hi:

Some more discussion on a few items (BV2) - see below.

- Bernie (from iPad)

On Nov 26, 2024, at 1:59 AM, Eric Vyncke (evyncke) <[email protected]> wrote:

Hello Bernie and Suresh (as there is possibly an action for the shepherd)

Thank you for your reply, I added some more comments prefixed by EVY2>, the absence of comments means ‘we agree’.

We are obviously converging, i.e., read my comments, decide, and upload a revised I-D so that I can request the IETF Last Call.

Regards

-éric

From: Bernie Volz <[email protected]>
Date: Wednesday, 20 November 2024 at 20:21
To: Eric Vyncke (evyncke) <[email protected]>
Cc: [email protected] <[email protected]>, Tomek Mrugalski <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, Timothy Winters <[email protected]>, Suresh Krishnan (sureshk) <[email protected]>, Suresh Krishnan (sureshk) <[email protected]>
Subject: Re: AD review of Dynamic Host Configuration Protocol for IPv6 (DHCPv6) draft-ietf-dhc-rfc8415bis-06
Thanks much for the review and findings - they are good! Comments below (BV>).

- Bernie (from iPad)

On Nov 15, 2024, at 4:46 PM, Eric Vyncke (evyncke) <[email protected]> wrote:

Dear authors, shepherd, and DHC WG,

Thank you for your efforts to elevate DHCPv6 to Internet Standard.

As usual for any IETF draft, I have done an AD review. Before proceeding with the publication process, I am requesting either a revised text or a reply to all points below.

Of course, I did the review on the diff and not on the base document, I am expecting that the IETF Last Call and the IESG evaluation will also be executed on the diffs. Please note that this is my first AD shepherding to an Internet Standard, so, feel free to educate me on wrong questions.

Regards,

-éric

# Metadata

Should the intended status clearly indicate “Internet Standard” ? Tbh I am not sure as draft-ietf-6man-rfc2460bis also indicated “Standards Track”.

BV> ok, will change to Internet Standard if possible. Looks like

Looks like this can be done by adding to

<seriesInfo name="Internet-Draft" value="draft-ietf-dhc-rfc8415bis-latest"/>

Perhaps adding status here could do this?

EVY2> I guess so, let’s have a try


2.47.4.  "status" Attribute



   The status of this document.  The currently known values are

   "standard", "informational", "experimental", "bcp", "fyi", and

   "full-standard".  The RFC Series Editor may change this list in the

   future.
# Generic

Should this document use “DHCP” or “DHCPv6” when referring to the protocol it specifies ? No hard feelings here but I would prefer to use “DHCP” everywhere (with perhaps a sentence about “In this document, DHCP is used to refer to the protocol specified in this document”.

Suggest using the aasvg tool to generate a nicer version of this long-lasting document... Trust me, this tool is impressive ;-) but this is a matter of taste. No need to reply to this comment.

BV> When working on RFC3315, Ralph had wanted to use “dhcp” except in cases where it wasn’t clear. We have hopefully tried to continue this practice. Note that section 4.2 says:


DHCP                      Dynamic Host Configuration Protocol for

                             IPv6.  The terms "DHCPv4" and "DHCPv6" are

                             used only in contexts where it is necessary

                             to avoid ambiguity.

There are about 88 uses of DHCPv6. Though looks like many were added in Implementation Status section which will be removed before publication. And many are for references or other uses where not using this might cause confusion.

Thus, I think we are ok - though maybe there are one or two that could be removed.

EVY2> ok

# Abstract

s/This document replaces RFC8415/This document obsoletes RFC8415/ (as also written at the end of section 1.1)
BV> Ok

# Section 1.1

Do the DHC WG have any information whether the features in  `obsoleting two features that have not been widely implemented` are deployed and used ?

BV> ISC Kea server doesn’t support IA_TA and so I think that might serve as a reference? The use of server-unicast is optional in servers and rarely used (for example, cable deployments always want dhcp traffic to go through relays). So, even if requested, it is not honored.

EVY2> good to know, should the shepherd write-up include this ?

BV2>We can have Suresh add to shepherd writeup-up.

But also, for unicast, appendix A has:


       UNICAST option.  The Server Unicast option has been obsoleted.

          Use of this was rarely practical as typically relay agents

          between the client and server need to glean information from

          the communication and cannot be bypassed.

Perhaps we can expand IA_TA text in Appendix A which is currently:


       IA_TA option.  The Identity Association for Temporary Addresses

          option has been obsoleted.  A client that needs a short-term /

          special purpose address can use a new IA_NA binding to request

          an address and release it when finished with it.

To add something like to end of the text:

There are some popular server and many client implementations that have not supported the IA_TA option and this has not created any known issues to date.

EVY3> sounds good to me
# Section 4.2

`At the time of writing` does not age very well, suggest using “At the time of writing (2024)” or something less vague. This issue occurs several times in the document.

More important ` One other IA type was defined (see [RFC8947<https://www.rfc-editor.org/info/rfc8947>])` please add this type to the previous enumeration and remove this sentence.

Should IA_LL options be listed in “IA option(s)” ? I guess yes.

I only found this “time of writing” in the IA types (IA and IA_options) issue?


IA option(s)              At the time of writing this document, one

                             or more IA_NA, IA_TA (obsoleted), and/or

                             IA_PD options.  New IA types may be defined

                             in the future.

We can fix these issues (time of writing and adding IA_LL). Note that there’s also https://www.iana.org/go/draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-02 which adds more. I wonder if we rework this to maybe just discuss the ones we’re defining in this document and reference folks to IANA page for full set. Anyway, something to think about.

EVY2> thanks fort he ‘time of writing’
EVY2> about IA_LL this one is approved and published while srv6-locator is not approved yet, hence perhaps worth making a difference

BV2>  I’m just concerned that the world could change by time RFC is published. But if you don’t see that as an issue, perhaps we can use (bolded text is changed text, sorry about formatting as iPad doesn’t make it easy).


IA                        Identity Association: a collection of

                             leases assigned to a client.  Each IA has

                             an associated IAID (see below).  A client

                             may have more than one IA assigned to it --

                             for example, one for each of its

                             interfaces.  Each IA holds one type of

                             lease; for example, an identity association

                             for non-temporary addresses (IA_NA) holds

                             addresses, and an identity association for

                             prefix delegation (IA_PD) holds delegated

                             prefixes.  Throughout this document, "IA"

                             is used to refer to an identity association

                             without identifying the type of a lease in

                             the IA.  This document defines three

                             IA types:

                             IA_NA, IA_TA (obsoleted), and IA_PD.

                             Another IA type was defined (see [RFC8947])

                             and more may be defined.



   IA option(s)      In this document, one

                             or more IA_NA, IA_TA (obsoleted), and/or

                             IA_PD options.  Another IA type was defined (see [RFC8947])

                             and more may be defined.



But perhaps others have suggestions.


EVY3> this sounds good to me, perhaps using “Another IA type, IA_LL, was defined”

s/ See [RFC8415] for details on the now obsoleted IA_TA option./ This option is obsolete, see [RFC8415] for details./

Should IA_LL (RFC 8947) be also listed in the terminology ?

# Section 6.3

What is ‘normal DHCP’ in ` That includes addressed leased out by normal DHCPv6 (IA_NA), prefixes via DHCPv6-PD (IA_PD), and addresses autoconfigured by IPv6 Router Advertisements.` ?

EVY2> this point was not replied to

BV2> Sorry I missed it. We should just remove the word “normal” here.

EVY2> thank you

# Section 7.2

What is “designated destination port” in their designated destination ports`?
BV> these are specified in first paragraph of section 7.2. Perhaps we can just add “- see above”?

EVY2> rather suggest modifying the first paragraph in something similar to “The designated UDP ports for ...” ?

BV2> how about we use:


   Nevertheless, regardless of the source port used,

   DHCP messages MUST be sent to clients at destination port 546 and

   servers and relays at destination port 547.

This is more explicit and requires less thinking on readers behalf?

EVY3> better indeed 😊


# Section 14.2

There are now only “two” use cases and not ` there are three such cases:` ;-) (perhaps worth checking whether there are other occurrences of this mistake)
BV> good catch.

# Section 18.4

Suggest using upper case BCP14 terms in this section for “may continue”
BV> this was just stating the behavoir, not a directive to client or server. But if you feel MAY is better, or maybe we look at another way to word this?
EVY2> after re-re-reading this section, you are correct, leave it like it is

# Section 21.5

Many of my fellow ADs will not be happy with “SHOULD” without any specific use case or consequences of bypassing the SHOULD.
BV> Older servers may still support IA_TA - but maybe they can just say they are RFC8415 compatible and not RFC-tobe compatible. So, maybe you are saying we should change this to MUST ignore.
EVY2> indeed the use of MUST NOT is better, of course old 8415 clients/servers will be there for years, but RFC-tobe clients/servers MUST not send this option + MUST ignore (and perhaps SHOULD log this invalid message ?).

# Section 21.12

As in section 21.5, strict normative BCP14 text should appear on when to send and what to do on receiving unicast traffic.

BV> Based on previous issue, we should say MUST ignore.

EVY2> indeed
# Section 22

Thanks for this detailed summary ;-)

# Errata

I have indeed verified that all errata (only 3 of them – a good sign of RFC 8415 quality) were processed or are no more relevant as IA_TA is obsoleted, thank you.

_______________________________________________
dhcwg mailing list -- [email protected]
To unsubscribe send an email to [email protected]