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

Hi Dominique,

Many thanks for your review. Updates were done in github. Please find
comments in line.

On Thu, Oct 22, 2020 at 8:45 AM <dominique.barthel@orange.com> wrote:

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

[ines] We deleted: "leaving the flags reserved for MOP value seven (7)" to
avoid confusion.
The goal is to rename the registry not to affect the flags for 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?
>

[ines] thank you, yes  we fixed as you suggested.

> - 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."?
>
[ines]  we fixed added specific values.

> - 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.
>
[ines]  we fixed to "Having the RAL information about the RPL domain, the
packet may be encapsulated to the root when the destination is not in the
RPL domain of the RAL."

Many thanks again,

Ines.

>
> Best regards
>
> Dominique
>
>
> Le 21/09/20 21:58, « Roll on behalf of Pascal Thubert (pthubert) »
> <roll-bounces@ietf.org on behalf of pthubert=40cisco.com@dmarc.ietf.org> 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 <mcr@sandelman.ca> a écrit
> >>:
> >>
> >>
> >> internet-drafts@ietf.org 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  [
> >> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on
> >>rails    [
> >>
> >> _______________________________________________
> >> Roll mailing list
> >> Roll@ietf.org
> >> https://www.ietf.org/mailman/listinfo/roll
> >_______________________________________________
> >Roll mailing list
> >Roll@ietf.org
> >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.
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>