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

Michael Richardson <[email protected]> Wed, 04 Dec 2024 22:05:20 -0500
Newsgroups	gmane.ietf.dhc
Message-ID	<[email protected]>
Tomek Mrugalski <[email protected]> wrote:
    > As Bernie suggested, I played with the status attribute of the
    > <seriesInfo> tag. It didn't work with the latest xml2rfc 3.25.0. I don't
    > know why, but I do have a theory. The status field is documented in
    > RFC7991, Section 2.47.1. However, the docs for xml2rfc
    > (https://ietf-tools.github.io/xml2rfc/#name-seriesinfo) have the section
    > for status attribute empty. Perhaps it's being deprecated?

    > Is this something the RFC editor could fix once we reach that stage?

I think the RPC can/will fix this.

    > technologies). Yes, it's 2 extra chars to type, but it avoids confusion.
    > Finally, DHCPv4 and DHCPv6 are similar, but different protocols.

:-)
I preferred using two terms, but I didn't feel very strongly.

    >> 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.

    > Will try. Haven't used it, but looks easy enough.

It's very much fun to get really neat SVG out.

I read the rest of your suggested text, and they all look good to me.

    > How about we keep the SHOULD as it, but add an explanation what happens
    > if it's bypassed:

    > As this option was never popular among server or client
    > implementations before being deprecated, any implementations that
    > still attempt to send it are unlikely to have the option being
    > processed.

That's exactly what people want, when using SHOULD, explain the exception.

    >> # 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.
    > How about this:

    > The client SHOULD NOT request this option in ORO.  The server SHOULD
    > NOT send this option, even when requested by clients.  When any entity
    > receives server unicast option, the option SHOULD be ignored and the
    > message processing should continue as usual.

    > As this option was not very popular and it typically required special
    > configuration by those server implementations that did support it,
    > clients still requesting this option in ORO are increasingly unlikely
    > to get it.

SHOULD clients seeing this option (from older servers, I guess) ignore the option?
(vs drop the packet as illformed...)

Is there an exception here for compliant clients?
It is understood that old clients and servers might include it.

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

_______________________________________________
dhcwg mailing list -- [email protected]
To unsubscribe send an email to [email protected]
signature.asc (application/pgp-signature, 515 B)