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

[Yusuke DOI <[e-mail]>]

Hi Brian,

Thank you very much for your kind review.
I updated the document. Sorry for late response.

On 2015-07-08 23:15, Brian Haberman wrote:
> ----------------------------------------------------------------------
> 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].

Thank you for suggestion. I added some notes on multiple options and 
reference.

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

I modified text with reference to RFC6206, with clarification on 'failure'

<draft>
If a DHCPv6 client with an MPL forwarder configured by the MPL Parameter 
Configuration Option is unable to receive a valid response from a server 
within T2 of the las\
t valid DHCPv6 message sent from the server (if stateful) or twice the 
Information Refresh Time (if stateless), it MUST suspend the MPL 
forwarders of the MPL domains \
configured by the option. MPL forwarders configured by other methods 
such as static configuration file MUST NOT be suspended.

Clients MUST ignore all MPL Parameter Configuration Options if the 
options in a DHCPv6 message contains any invalid value (e.g., it uses 
reserved all-0 or all-1 value\
s in parameters). In this case, the message is considered not received 
in MPL context and the condition described in the previous paragraph 
applies.
</draft>

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

I hope answer to Barry's DISCUSS can make this resolved.

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

No reason to have separate section so I merged it on local copy (will be 
submitted as -08). Thanks for suggestion.

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

Agreed and fixed.

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

Thanks. As I stated on Alia's DISCUSS, I changed the definitions of 
reserved bits as you suggested.


Best Regards,

Yusuke