Re: [Add] WGLC for draft-ietf-add-dnr

[Ben Schwartz <[e-mail]>]

On Fri, Mar 4, 2022 at 2:56 AM <[e-mail]> wrote:

> Hi Ben,
>
>
>
> That was considered in the past, but we need also to listen to the
> guidelines that are specific to each of these protocols. For example, a
> reco from DHC is to start with fixed length fields, this is why we have
> SvcPriority first not the order you propose.
>

I don't think we should attempt to apply these guidelines on our own.  If
they are indeed applicable in this case, I'd like to get that confirmed
from some relevant subject matter experts.

Likewise, SvcPriority is not present in RA because this can be inferred
> from the order appearance while this is not possible for DHCP as already
> recorded in the doc:
>
>
>
>    The DHCP options defined in Sections 4
> <https://datatracker.ietf.org/doc/html/draft-ietf-add-dnr#section-4> and 5
> <https://datatracker.ietf.org/doc/html/draft-ietf-add-dnr#section-5>
> follow the option
>
>    ordering guidelines in Section 17 of [RFC7227]
> <https://datatracker.ietf.org/doc/html/rfc7227#section-17>.
>
>
>
>    “Option order, either the order among many DHCPv6 options or the order
>
>    of multiple instances of the same option, SHOULD NOT be significant.
>
>    New documents MUST NOT assume any specific option processing order.”
>
>
Thanks for noting this.  A similar rule applies to to IPv6 RA (
https://www.rfc-editor.org/rfc/rfc4861#section-9):

   Options in Neighbor Discovery packets can appear in any order;
   receivers MUST be prepared to process them independently of their
   order.

Evidently we'll need to change that format in the draft.

Likewise, we don’t want to create a precedent for self-delimiting variable
> length fields but followed the guidelines from these groups to have an
> explicit length field for each variable length.
>

Where is that guidance written?

Here are some examples of concatenated self-delimiting variable-length
fields being used:
* IPv6 NDP Options
  - DNSSL domains (https://www.rfc-editor.org/rfc/rfc8106.html#section-5.2)
  - PvD domains (
https://www.rfc-editor.org/rfc/rfc8801.html#name-pvd-option-for-router-adver
)
  - CARD Sub-Options (https://www.rfc-editor.org/rfc/rfc4066#section-5.1.2.2
)
* DHCP
  - DNS Search List (https://www.rfc-editor.org/rfc/rfc3397.html#section-2)
  - SIP Domain List (https://www.rfc-editor.org/rfc/rfc6011.html#section-4.1
)
  - RDNSS (https://www.rfc-editor.org/rfc/rfc6731.html#section-4.2)
  - Mobility Service (https://www.rfc-editor.org/rfc/rfc5678.html#section-3)


> We need to be careful here because we are in an area where we need to take
> into account what the owners of these protocols maintain the protocol, not
> only what would be perfect for a specific application.
>

I agree.  If we're in doubt about their expectations, let's get more input
from them.