Re: [Roll] AD Review of draft-ietf-roll-mpl-parameter-configuration

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

Yusuke:

Hi!  

I didn’t see a follow up from you, but I’m assuming that we’re on the same
page.

This draft is on the agenda for discussion in the IESG next week (July/9).
 The IETF Last Call has ended, and there are outstanding comments (minor
and nits) from IANA, SecDir and GenART.

Please take a look at the comments and post an update before next week.
The sooner the better to give the IESG a good chance to review the latest
text.

Thanks!

Alvaro.



On 6/18/15, 1:49 PM, "Roll on behalf of Alvaro Retana (aretana)"
<[e-mail] on behalf of [e-mail]> wrote:

>On 6/17/15, 1:43 PM, "Yusuke DOI" <[e-mail]> wrote:
>
>Yusuke:
>
>Hi!
>
>. . .
>>> Minor:
>>>
>>>  1. Section 1 (Introduction): "Some managed wireless mesh networks may
>>>     have a DHCP server to configure network parameters.²  How common is
>>>     the use of DHCP?  ³Some..may² doesn¹t sound like this extension
>>>will
>>>     be used a lot.  How do other networks configure their parameters?
>>>       I¹m assuming manually..
>>
>>I have no other experience, but I assume the configuration will be done
>>manually...
>. . .
>>
>>>  3. Section 2.3 (MPL Forwarder Behavior)  Joining and leaving the
>>>     domain.  I must be missing something..
>>>       * "the node MAY join the MPL domain given by the option²  Why
>>>         would the client request the Option and then not join the
>>>domain?
>>
>>One reason is resource constraint. As joining to a MPL domain requires
>>certain amount of buffers allocated, a node may fail to join all of the
>>domains given by the option.
>
>The use of ³MAY² above gives the impression that joining is optional.  But
>you¹re saying that even if the node wants to join it may not be able to,
>which is different.
>
>Suggestion:
>
>OLD>
>
>   If a DHCPv6 client requests and receives MPL Parameter Configuration
>   Option, the node MAY join the MPL domain given by the option and act
>   as an MPL forwarder.
>
>
>NEW>
>
>   If a DHCPv6 client requests and receives MPL Parameter Configuration
>   Option, the node SHOULD join the MPL domain given by the option and act
>   as an MPL forwarder.  Note that there may be cases in which a node may
>   fail is to join a domain (or domains) due to local resource
>constraints.
>
>I¹m not sure if you/the WG want to add something else to that paragraph..
>
>
>
>>>       * "A node MAY leave from an MPL domain..²  The conditions seem to
>>>         say that the domain in the Option changed, is that true?  If
>>>the
>>>         domain in the option changed, why would the node not leave the
>>>         domain?
>>
>>There's no reason except the domain is configured manually at the same
>>time (the first condition is not met). If there are a manual
>>configuration, implementation may consider it's overriding the DHCPv6
>>Option.
>>
>>Is this clear?:
>>
>>"""
>>A node SHOULD leave from a MPL domain if the node received a new option
>>without configuration for the MPL domain, unless it has overriding
>>external configuration on the MPL domain.
>>"""
>
>How about this instead:
>
>NEW>
>
>   A node SHOULD leave an MPL domain if it receives an updated
>   MPL Parameter Configuration Option without a configuration for the
>   MPL domain, unless it has overriding external configuration.
>
>
>I¹m not sure if ³external² is the right word..or if ³manual² might be
>better.  Look at the point #1 above about how other nodes may be
>configured.
>
>In this section (2.3) there¹s a priority of configuration shown:
>
>   The priority of MPL Parameter Configuration applied for an MPL Domain
>   is as follows (high to low).
>
>   o  Specific MPL Parameter Configuration to the MPL Domain (optlen=34)
>
>   o  Wildcard MPL Parameter Configuration (optlen=18)
>
>   o  Default configuration given in the MPL specification.
>
>
>But there is no mention anywhere in the document to external/manual
>configuration.  Where in that priority list should it fit?
>
>Thanks!
>
>Alvaro.
>
>_______________________________________________
>Roll mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/roll