[dhcwg] John Scudder's No Objection on draft-ietf-dhc-addr-n otification-12: (with COMMENT)

John Scudder has entered the following ballot position for
draft-ietf-dhc-addr-notification-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-notification/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this very readable document. I have a few comments I hope may be
helpful.

### Section 4.2.1, Otherwise

```
If the message is not discarded, the address registration server SHOULD verify
that the address being registered is "appropriate to the link" as defined by
[RFC8415] or within a prefix delegated to the client via DHCPv6-PD (see Section
6.3 of [RFC8415]). Otherwise, it MUST drop the message, and SHOULD log this
fact. ```

Because the first sentence is SHOULD, the “otherwise” is ambiguous – it could
mean that the address registration server disregarded the SHOULD and didn’t do
the verification, or it could mean what I expect you intended, which is that
the address being registered is not appropriate to the link.

The easiest fix I see is to replace “otherwise” with “if the address being
registered fails this verification”, as in,

NEW:
If the message is not discarded, the address registration server SHOULD verify
that the address being registered is "appropriate to the link" as defined by
[RFC8415] or within a prefix delegated to the client via DHCPv6-PD (see Section
6.3 of [RFC8415]). If the address being registered fails this verification, it
MUST drop the message, and SHOULD log this fact.

This change would also have the felicitous side effect of not having two
consecutive sentences begin with “otherwise“. (I didn't quote the second one,
but it comes next.)

### Section 4.6.1, needs forward reference

“AddrRegRefreshCoalesce allows battery-powered hosts to wake up less often.”

I suggest adding a forward reference as in, “AddrRegRefreshCoalesce (Section
4.6.3) allows battery-powered hosts to wake up less often.”

### Acknowledgements

I thought it was weird that the document both credits a previous document
("borrows heavily”), listing the authors of that document, AND also adds the
authors of that document as front-page authors/contributors of the present
document. So, you are acknowledging... yourselves. ("Good job, me!" ;-)

I mean, it's not a big deal, whatever. But given that the justification for six
authors is "because the previous document", isn't being listed on the front
page acknowledgment enough? On the other hand, if the goal is to retain the
information that draft-ietf-dhc-addr-registration is a predecessor document,
why not put that in the replaces/replaced-by metadata instead? It's arguably
both more visible and more useful that way. It *is* possible, I'm pretty sure,
to have multiple documents in the replaced-by.



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