Re: [manet] AD Review of draft-ietf-manet-dlep-multi-hop-extension-05

[Alvaro Retana <[e-mail]>]

On March 9, 2019 at 5:10:57 AM, Lou Berger ([e-mail]) wrote:

Hi!

...

>>>>> 186 3.2.  Hop Control
>>>>> ...
>>>>> 200   A modem that receives the Hop Control Data Item in a Link
>>>>> 201   Characteristics Request Message SHOULD attempt to make
>>>>> the change
>>>>> 202   indicated by the data item for the associated
>>>>> destination MAC
>>>>> 203   address.  Once the change is made, fails or is rejected,
>>>>> the modem
>>>>> 204   MUST respond with a Link Characteristics Response
>>>>> Message containing
>>>>> 205   an updated Hop Count Data Item.  Note that other
>>>>> destinations can be
>>>>> 206   impacted as a result of the change and such changes are
>>>>> reported in
>>>>> 207   Destination Down and Destination Update Messages.  The
>>>>> modem MUST
>>>>> 208   notify the router of each destination that is not
>>>>> identified in the
>>>>> 209   Link Characteristics Response Message and is no longer
>>>>> reachable via
>>>>> 210   a Destination Down Message.  The modem MUST also notify
>>>>> the router of
>>>>> 211   each destination that is not identified in the Link
>>>>> Characteristics
>>>>> 212   Response Message and has a changed Hop Count impacted via a
>>>>> 213   Destination Update Message.
>>>>>
>>>>> [major] s/SHOULD attempt to make the change/SHOULD make the
>>>>> change  The Normative action is to make the change, not to try
>>>>> to make it.  There are 2 more instances of the same phrase in
>>>>> the text.
> well there is the "fails or rejected" outcomes -- I don't think
> it's right to call these anything but an attempt.  Perhaps there's
> another way to address your concern and the possibility that the
> change can fail.  What do you think?
>
>
> JWD This is actually because there is a hidden transient state: The
> modem is attempting to make the change but it hasn't yet succeeded or
> failed.  The amount of time this takes is fully dependent on the
> modem/radio characteristics so it would be inappropriate to put a
> fixed timeout value here.  This may be more cleanly stated by defining
> what the "attempt" state is.  The modem SHOULD enter the
> "attempt/resolving" state and once the change is made, fails or is
> rejected, the modem MUST respond.

given that these states are not defined anywhere in the context of DLEP,
I'm reluctant to add it here -- unless there is a solid reference
defining such.  Do you have a good reference?

alternatively, how about s/SHOULD attempt/SHOULD take whatever actions
are needed

I don’t like that either because it is not specific: what are the needed
actions??

I do like the explanation you added (below) about why it is really only an
attempt (why there may be failure/rejection).

So…I think that we could go back to “SHOULD attempt” given that there is an
explanation in the text.

BTW, there’s another “SHOULD attempt” in §3.2.3.

...

>   Failures may occur for multiple reasons, for example, the
> transmission
>   characteristics of the link don't support the one-hop connection at
>   the time of the request. Requests may be rejected by local policy.


Thanks!

Alvaro.