Subject: Re: [Roll] I-D Action: draft-ietf-roll-useofrplinfo-41.txt

From: <[email-masked]>
Date: Thu, 22 Oct 2020 05:45:22 +0000

Hello all,

I just looked at draft-ietf-roll-useofrplinfo-41.txt and specifically the
diff.

I have the following comments:
- Section 4.3: "leaving the flags reserved for MOP value seven (7)".
Actually, there is no normative text later in the document (e.g., Section
11) that implements this. MOP 7 is indeed reserved (see following comment,
though), but not the flags for the MOP 7. I think this would not be a good
idea anyway, since it would be starting designing the protocol that uses
MOP 7.
- Section 11.3: "this document changes the allocation status of the Mode
of Operation
     (MOP) [ianamop] from Unassigned to Reserved.". I guess you mean "his
document changes the allocation status of the Mode of Operation (MOP)
[ianamop] value 7 from Unassigned to Reserved.", correct?
- Section 4.3 "to be limited to Mode-of-Operation (MOP) specific.". I
can't quite parse this sentence. Do you mean "to be limited to
Mode-of-Operation (MOP) specific values."? Or "to be Mode-of-Operation
(MOP) specific."?
- Section 8.2.1: "Having the RAL information about the RPL domain, it may
encapsulate". "It" does not refer to anything identifiable. Grammatically,
it would refer to "the flow", which does not quite make sense.

Best regards

Dominique

Le 21/09/20 21:58, « Roll on behalf of Pascal Thubert (pthubert) »
<[email-masked] on behalf of pthubert=[email-masked]> a
écrit :

>Hello Michael 
>
>Many thanks for this; I agree with those diffs and will change the other
>2 drafts to refer to this.
>
>
>Take care,
>
>Pascal
>
>> Le 21 sept. 2020 à 21:01, Michael Richardson <[email-masked]> a écrit
>>:
>> 
>> 
>> [email-masked] wrote:
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-41
>> 
>> Hi, based upon a conversation this morning among the authors and
>>useofrplinfo
>> and turnon-rfc8138, we arrived at the diffs above.
>> 
>> The point is that the changes to MOP and the rename of the
>> DODAG Configuration Options Flags registry would get done in the first
>> document that uses them, which is useofrplinfo.
>> 
>> I agreed to make the diffs required, and I hope that I got it right.
>> 
>> Some bits of the diff:
>> 
>> 4.3.  Updates to RFC6550: Configuration Options and Mode of Operation
>> 
>>     RFC6550 section 6.7.6 describes the DODAG Configuration Option.  In
>>     this option are a series of Flags in the first octet of the
>>payload. 
>>     These flags are described by the DODAG Configuration Option Flags
>>     registry [dodagcfg], in section 20.14 of RFC6550.
>> 
>>     Anticipating future work to revise RPL relating to how the LLN and
>>     DODAG is configured, this document changes the interpretation of
>>the 
>>     [dodagcfg] Registry to be limited to Mode-of-Operation (MOP)
>>     specific.  The MOP is described in [RFC6550] section 6.3.1.  The
>>     Options Flags Registry is renamed, and applies to MOP values zero
>>(0) 
>>     to six (6) only, leaving the flags reserved for MOP value seven
>>(7). 
>> 
>>     In addition, this document reserves MOP value 7 for future
>>expansion.
>> 
>> ...
>> 
>> 11.2.  Changes to DODAG Configuration Options Flags
>> 
>>     This document changes the name of the "DODAG Configuration Option
>>     Flags" [dodagcfg] to "DODAG Configuration Option Flags for MOP
>>0..6". 
>> 
>> 11.3.  Change MOP value 7 to Reserved
>> 
>>     This document changes the allocation status of the Mode of
>>Operation 
>>     (MOP) [ianamop] from Unassigned to Reserved.  This change is in
>>     support of future work related to capabilities.
>> 
>> 
>> The MOPEX document would then allocate the value, but nobody else can
>>use it
>> before then.
>> 
>> 
>> -- 
>> ]               Never tell me the odds!                 | ipv6 mesh
>>networks [ 
>> ]   Michael Richardson, Sandelman Software Works        | network
>>architect  [ 
>> ]     [email-masked]  http://www.sandelman.ca/        |   ruby on
>>rails    [ 
>>    
>> _______________________________________________
>> Roll mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/roll
>_______________________________________________
>Roll mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/roll

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.