[Roll] Brian Haberman's Discuss on draft-ietf-roll-mpl-parameter-configuration-06: (with DISCUSS and COMMENT)

["Brian Haberman" <[e-mail]>]

Brian Haberman has entered the following ballot position for
draft-ietf-roll-mpl-parameter-configuration-06: Discuss

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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Some of these points come from Bernie Volz's INT-Dir review...

1. This is one of the few options that is not a singleton, as defined in
section 16 of RFC 7227. While the use of multiple options seems
appropriate here, it would be best to clarify that clients (section 2.2)
and servers (section 2.4) must be able to support multiple instances of
this option. Given the discussion around supporting multiple MPL domains
in draft-ietf-roll-trickle-mcast, I would expect there to be situations
where the option appears multiple times.

2. In section 2.3 (MPL Forwarder Behavior), there should be a brief
discussion of the role of the MPL Domain Address and include a reference
to [I-D.ietf-roll-trickle-mcast].

3. In section 2.6 (Operational Considerations), the text is a bit odd.
Why should a parameter set not be updated more often than twice the
Information Refresh Time? How does the failure to refresh the option play
with text in section 2.3 that indicates a missing option means the node
should leave the MPL domain? Perhaps defining what "failure to refresh"
means (i.e., I think it refers to lack of a DHCPv6 server response to a
Renew or Information Request). Note also that Information Refresh Time is
only applicable to Information-Request messages (see RFC 4242) so work
may be needed as to how this this sections relate to Renew/Rebind
operations? I am also not sure why 2.6 is a standalone section when it
appears to be only applicable to clients and should be in either section
2.2 or 2.3.


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

1. I support Barry's DISCUSS on the lack of an option potentially forcing
a node to leave an MPL domain.

2. Why is the text in Appendix B not in the Operational Considerations
section?

3. Please be consistent with the use of MUSTs and SHALLs.  Pick one.

4. In section 2.2 (DHCPv6 Client Behavior), 2nd paragraph - why would a
client discard the option if the reserved bits are set? I would think
you'd want to use a new option if you're changing things drastically? But
it certainly is your choice as to whether you want to do that. Perhaps a
better reason is if one of the not-permitted values is used (such as 0
and 'all-bits-set') where are clearly reserved? 0 in many of these case
could be bad since that would yield 0 time values? This really is up to
you, but do think about what you might want to do any maintain backwards
compatibility. Adding a new flag bit to the reserved field is probably
not going to break things if existing implementations ignore the bit(s).