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

["Alvaro Retana (aretana)" <[e-mail]>]

[Explicitly adding Brian.]

On 9/2/15, 3:32 AM, "Yusuke DOI" <[e-mail]> wrote:

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