Re: [Roll] Part 1: comment resolutions for AD Review of draft-ietf-roll-aodv-rpl-07

[Alvaro Retana <[e-mail]>]

On May 7, 2020 at 3:47:35 PM, Charlie Perkins wrote:


Charlie:

Hi!


> Today we have submitted a revised version 8 for our
> draft-ietf-roll-aodv-rpl. Here is part 1 showing some resolutions for
> comments made by our AD for the improvement of draft-ietf-roll-aodv-rpl-07.

Thanks for the update!

I have some comments to your answers (see below) -- I'm only leaving
the comments where more discussion/changes may be needed.

In some cases I decided to put comments on the document (-08) itself.
I'll send out a separate message with those comments in a minute.
I'll also send out replied to part 2 of your answers.


Take care!

Alvaro.


...
> > 298 4.1. AODV-RPL DIO RREQ Option
> >
> > 300 OrigNode sets its IPv6 address in the DODAGID field of the RREQ-DIO
> > 301 message. A RREQ-DIO message MUST carry exactly one RREQ option.
> >
> > [major] What should a receiver do if more than one RREQ options are
> > received?
>
> I specified that it SHOULD be dropped. I don't think this is too harsh,
> even though other solutions are possible.

[major] When would the receiver not drop the RREQ-DIO?  IOW, why
wouldn't it always drop it (MUST)?  If it is not
dropped...then...should all the options be processed?

These questions go back to the reason only one RREQ option is
expected.  From §6.1, it seems like one is enough...specially given
that multiple ART options can be present.

Are there cases where more than one RREQ option could be "normal"?



...
> > 363 L is independent from the route lifetime, which is defined in the
> > 364 DODAG configuration option. The route entries in hop-by-hop
> > 365 routing and states of source routing can still be maintained even
> > 366 after the DAG expires.
> >
> > [??] I don't understand what the last sentence is trying to say. It
> > sounds as if the information learned through the DAG can still be used
> > after the DAG expires...up until the route lifetime expires...is that it?
> > Please clarify.
>
> How about this:
>
>
> The route entries in hop-by-hop routing
> and states of source routing can still be maintained
> even after the node no longer maintains DAG connectivity or
> messaging.

Why would the node want to maintain the information after it is disconnected?

Put another way, I understand why L is independent of the route
lifetime.  I don't understand why the information would be kept.  The
text says that it "can still be maintained", not that it has to be
maintained -- is there a value in keeping it?

Maybe simply remove the last sentence...??



...
> > 389 4.2. AODV-RPL DIO RREP Option
> >
> > 391 TargNode sets its IPv6 address in the DODAGID field of the RREP-DIO
> > 392 message. A RREP-DIO message MUST carry exactly one RREP option.
> > 393 TargNode supplies the following information in the RREP option:
> >
> > [major] What should the receiver do if more than one RREP option is
> > received?
>
> How about:
>
> A RREP-DIO message MUST carry exactly one RREP option,
> otherwise the message SHOULD be dropped.

[major] When would the receiver not drop the RREQ-DIO?  IOW, why
wouldn't it always drop it (MUST)?  If it is not
dropped...then...should all the options be processed?

These questions go back to the reason only one RREP option is
expected.  From §6.3, it seems like one is all that is needed.

Are there cases where more than one RREP option could be "normal"?



>
>
> >
> >
> > ...
> > 441 Shift
> > 442 6-bit unsigned integer. This field is used to recover the
> > 443 original InstanceID (see Section 6.3.3); 0 indicates that the
> > 444 original InstanceID is used.
> >
> > [major] s/InstanceID/RPLInstanceID/g
>
> Done.
>
>
>
>
>
> >
> > 446 Rsv
> > 447 MUST be initialized to zero and ignored upon reception.
> >
> > [major] Do you expect these bits to be assigned by IANA in the future?
>
> No, but a future specification could modify the operation. Do we need to say that?



...
> > 456 4.3. AODV-RPL DIO Target Option
...
> > 464 A RREQ-DIO message MUST carry at least one ART Option. A RREP-DIO
> > 465 message MUST carry exactly one ART Option.
> >
> > [major] What should a node do if more than one ART Option is received in
> > a RREP-DIO message?
>
> How about:
>
> A RREQ-DIO message MUST carry at least one ART Option. A RREP-DIO
> message MUST carry exactly one ART Option. Otherwise, the message
> SHOULD be dropped.


[major] When would the receiver not drop the RREP-DIO?  IOW, why
wouldn't it always drop it (MUST)?  If it is not
dropped...then...should all the options be processed?  From §6.3, it
seems like one is all that is needed.

Are there cases where more than one ART option could be "normal"?  The
RREQ can include multiple, but the RREP only one -- I didn't find a
place where it was clear that processing these ART options should
result in one reply, but I may have missed it.