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

Lou Berger <lberger@labn.net> Fri, 08 March 2019 21:21 UTC

Return-Path: <lberger@labn.net>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB97D128B01 for <manet@ietfa.amsl.com>; Fri, 8 Mar 2019 13:21:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqytmPva-BPP for <manet@ietfa.amsl.com>; Fri, 8 Mar 2019 13:21:44 -0800 (PST)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F785131196 for <manet@ietf.org>; Fri, 8 Mar 2019 13:21:44 -0800 (PST)
Received: from cmgw12.unifiedlayer.com (unknown [10.9.0.12]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id 87B68177F15 for <manet@ietf.org>; Fri, 8 Mar 2019 14:10:57 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id 2MldhdhuGmds92MldhOav3; Fri, 08 Mar 2019 14:10:57 -0700
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=mts07ePx7P+tYgLHpE7QLs4Ss+DXBTitlaRmDoRYe4Y=; b=FWK3lC8EtYj6Wuki7N/6SluAkF /1c6AjK9+HFykb9Skq2W2ZCCnHuo+PAxDKfwS+MhABGguaWRCVizFfAtLCfD//GodoG0DRoPfo1CR yGPjnck8rvCNWrNyb3KHY+MbA;
Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:50700 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <lberger@labn.net>) id 1h2Mlc-002fsl-U3; Fri, 08 Mar 2019 14:10:57 -0700
To: Justin Dean <bebemaster@gmail.com>
Cc: Alvaro Retana <aretana.ietf@gmail.com>, draft-ietf-manet-dlep-multi-hop-extension@ietf.org, MANET IETF <manet@ietf.org>, Mobile Ad-hoc Networks Working Group <manet-chairs@ietf.org>
References: <CAMMESszKYXy_Oy-L+TgiJqqWBWOFTOxtnjuaX+O8Q+Jpg9iO3A@mail.gmail.com> <CAMMESsxztEYE3aDz0zmAsPwqpU9Q1szv0qiMcH8kUf=O9jhfgg@mail.gmail.com> <07cfd806-e3b1-3772-70a6-9db5af9662e7@labn.net> <CA+-pDCe_G+XGQfoU93_EdaHR_zLnGcA8G4nqsDYSCudS+qR9_w@mail.gmail.com>
From: Lou Berger <lberger@labn.net>
Message-ID: <842e7f1e-6231-c7cd-b968-93ae471619a9@labn.net>
Date: Fri, 8 Mar 2019 16:10:55 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: <CA+-pDCe_G+XGQfoU93_EdaHR_zLnGcA8G4nqsDYSCudS+qR9_w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 72.66.11.201
X-Source-L: No
X-Exim-ID: 1h2Mlc-002fsl-U3
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([IPv6:::1]) [72.66.11.201]:50700
X-Source-Auth: lberger@labn.net
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/dH_8SUwHagWVyE8oJiGPM7rp7xs>
Subject: Re: [manet] AD Review of draft-ietf-manet-dlep-multi-hop-extension-05
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Mar 2019 21:21:51 -0000

Hi,

     Thanks for the comments -- see below for responses

On 3/8/2019 3:11 PM, Justin Dean wrote:
> Only a few inline comments. Marked with JWD
>
> On Thu, Mar 7, 2019 at 9:12 PM Lou Berger <lberger@labn.net 
> <mailto:lberger@labn.net>> wrote:
>
>     Hi,
>
>     I'm totally embarrassed to have missed both your initial comments
>     and this ping.  You have my complete apologies!
>
>     See below for responses in-line.
>
>     Also changes described in this message are posted at:
>
>     https://github.com/louberger/dlep-extensions/commit/69a401553437037958c4502aaea58a21c1a84688
>
>     and a formatted version at:
>
>     https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?url=https://raw.githubusercontent.com/louberger/dlep-extensions/master/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml
>
>
>     ------------------------------------------------------------------------
>
>     On February 12, 2019 4:12:15 PM Alvaro Retana
>     <aretana.ietf@gmail.com> <mailto:aretana.ietf@gmail.com> wrote:
>
>>     Ping!
>>
>>     Just wondering where we are with this document.
>>
>>     Alvaro.
>>
>>     On November 20, 2018 at 3:50:17 PM, Alvaro Retana
>>     (aretana.ietf@gmail.com <mailto:aretana.ietf@gmail.com>) wrote:
>>
>>>     Dear authors:
>>>
>>>     I just finished reading this document.  Please see my comments
>>>     below.
>>>
>>>     The actions of the router may result in (unintended) unreachable
>>>     destinations. But there is no way (that I know of through DLEP)
>>>     for the router to know the result of any of its actions
>>>     beforehand.  It is important for this information to be clear in
>>>     the document (either in a dedicated Deployment Considerations
>>>     sections or somewhere prominent in the text). Whether and how a
>>>     router uses the Hop Count information or not (already mentioned
>>>     in §3.1), and whether and how it reacts to any unreachable
>>>     destinations as a result of its actions are out of scope of this
>>>     document...this fact should also be prominently mentioned.
>>>
>     How about in the introduction, adding:
>       It is important to note that the use of the hop control mechanism
>       defined in this can result in connectivity changes and even loss of
>       the ability to reach one or more destinations.  The defined
>     mechanism
>       will report such connectivity changes, but the details of what a
>       router does or how it reacts to such are out scope of this document.
>
>>>     Along similar lines, I think that the Security Considerations
>>>     section should also include (at least) a mention of the risks.
>
>     Sure.  How about adding:
>
>     <t>
>       This extension does define one mechanism that is worth particular
>       note.  This extension includes a Hop Control mechanism, see <xref
>       target="sec-di-hcontrol"/>, that is similar to the Link
>       Characteristics Request Message in that it can impact the set of
>       destinations reported as reachable.  With the Link Characteristics
>       Request Message, this risk is implicit.  With the Hop Control
>       mechanism defined in this document it is more likely.  From a
>     security
>       perspective, implementations should be aware of this increased risk
>       and may choose to implement additional configuration control
>       mechanisms to ensure that the Hop Control mechanism is only used
>     under
>       conditions intended by the network operator.
>
>>>>>
>>>>>     I'll wait for these points to be addressed before starting the
>>>>>     IETF Last Call.
>>>>>
>>>>>     Thanks!
>>>>>
>>>>>     Alvaro.
>>>>>
>>>>>
>>>>>     [Line numbers come from idnits.]
>>>>>
>>>>>     ...
>>>>>     72 1.  Introduction
>>>>>     ...
>>>>>     80 Some modem technologies support connectivity to
>>>>>     destinations via
>>>>>     81 multi-hop forwarding. DLEP Destination messages can be used to
>>>>>     82 report such connectivity, see [RFC8175], but do not provide any
>>>>>     83 information related to the number or capacity of the hops.  The
>>>>>     84 extension defined in this document enables modems to inform
>>>>>     routers
>>>>>     85 when multi-hop forwarding is being used, and routers to
>>>>>     request that
>>>>>     86 modems change multi-hop forwarding behavior.  The extension
>>>>>     defined
>>>>>     87 in this document is referred to as "Multi-Hop Forwarding".
>>>>>
>>>>>     [major] Please define "multi-hop forwarding" in the context of
>>>>>     the modems.
>
>     Done, please see the changes at the repo posted above and let me
>     know if the changes are sufficient.
>
>>>>>
>>>>>     [minor] "Some modem technologies support connectivity to
>>>>>     destinations via multi-hop forwarding.  DLEP Destination
>>>>>     messages can be used to report such connectivity, see
>>>>>     [RFC8175]..."  Where does rfc8175 talk about that?
>     does the following help? s/connectivity/reachable destinations
>
>>>>>
>>>>>
>>>>>     ...
>>>>>     101 2.  Extension Usage and Identification
>>>>>
>>>>>     103   The use of the Multi-Hop Forwarding Extension SHOULD be
>>>>>     configurable.
>>>>>
>>>>>     [major] Is there a default recommended setting?
>>>>>
>     I think this is implementation specific.  For example if a modem
>     or product usage is unlikely to show multiple hops default off
>     seems reasonable, but the opposite is also possible.
>
>
>>>>>
>>>>>     ...
>>>>>     111 3.  Extension Data Items
>>>>>
>>>>>     113   Three data items are defined by this extension.  The Hop
>>>>>     Count Data
>>>>>     114   Item is used by a modem to provide the number of network
>>>>>     hops
>>>>>     115   traversed to reach a particular destination. The Hop
>>>>>     Control Data
>>>>>     116   Item is used by a router to request that a modem alter
>>>>>     connectivity
>>>>>     117   to a particular destination.  The Suppress Forwarding
>>>>>     Data Item is
>>>>>     118   used by a router to request that a modem disable
>>>>>     multi-hop forwarding
>>>>>     119   on either a device or destination basis.
>>>>>
>>>>>     121 3.1.  Hop Count
>>>>>
>>>>>     123   The Hop Count Data Item is used by a modem to indicate
>>>>>     the number of
>>>>>     124   physical hops between the modem and a specific
>>>>>     destination.  In other
>>>>>     125   words, each hop represents a transmission and the number
>>>>>     of hops is
>>>>>     126   equal to the number of transmissions required to go from
>>>>>     a router
>>>>>     127   connected modem to the destination's connected modem. 
>>>>>     The minimum
>>>>>     128   number of hops is 1, which represents transmission to
>>>>>     destinations
>>>>>     129   that are directly reachable via the router's locally
>>>>>     connected modem.
>>>>>
>>>>>     [minor] This section describes the hop count in terms of
>>>>>     physical hops, but §3 talks about "network hops".  Are these
>>>>>     the same thing? Please clarify.
>>>>>
>     Agreed.
>     -  physical hops between the modem and a specific destination.  In
>     other
>     +  modem that transmits/sends data to reach a particular destination,
>     +  i.e., hops, between the modem and a specific destination.  In other
>
>>>>>     131   The data item also contains an indication of when a
>>>>>     destination which
>>>>>     132   currently has a hop count of greater than one (1) could
>>>>>     be made
>>>>>     133   direcly reachable by a modem, e.g., by re-aiming an antenna.
>>>>>
>>>>>     [nit] s/direcly/directly
>     Thanks!
>
>>>>>
>>>>>     ...
>>>>>     140   A router receiving a Hop Count Data Item MAY use this
>>>>>     information in
>>>>>     141   its forwarding and routing decisions, and specific use
>>>>>     is out of
>>>>>     142   scope of this document. The absence of the Hop Count
>>>>>     Data Item MUST
>>>>>     143   be interpreted by the router as a Hop Count value of one
>>>>>     (1).
>>>>>
>>>>>     [major] s/MAY/may  The rest of the sentence says that the use
>>>>>     is out of scope, so there's nothing normative here.
>     okay
>>>>>
>>>>>     145   The format of the Hop Count Data Item is:
>>>>>
>>>>>     147        0 1                   2               3
>>>>>     148        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>>>>>     6 7 8 9 0 1
>>>>>     149
>>>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>     150       | Data Item Type            | Length                  |
>>>>>     151
>>>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>     152       |P|  Reserved   | Hop Count   |
>>>>>     153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>
>>>>>     155   Data Item Type:  TBA2
>>>>>
>>>>>     157   Length:  4
>>>>>
>>>>>     159   P:
>>>>>
>>>>>     161      The P-bit indicates that a destination is potentially
>>>>>     directly
>>>>>     162      reachable.  When the P-bit is set, the router MAY
>>>>>     request a direct
>>>>>     163      link to the associated destination using the Hop
>>>>>     Control Data Item
>>>>>     164      described below.
>>>>>
>>>>>     [major] Should it only be set if the Hop Count is > 1? I
>>>>>     interpret the definition ("potentially directly reachable") as
>>>>>     saying that this bit should not be set if Hop Count = 1, but I
>>>>>     think it could be interpreted in a different way.  Please clarify.
>     okay.
>     -      described below.
>     +      described below. This field MUST be ignored when the value
>     +      contained in the Hop Count field is one (1).
>
>>>>>
>>>>>     166   Reserved:
>>>>>
>>>>>     168      MUST be set to zero by the sender (a modem) and
>>>>>     ignored by the
>>>>>     169      receiver (a router).
>>>>>
>>>>>     [major] I think that a registry for these bits is needed.
>>>>>     Otherwise anyone can use them...
>
>     My inclination would be to establish a registry on the second
>     usage of the reserved field.  Right now I don't see additional
>     uses and it seems like a lot of unneeded overhead at this point. 
>     Of course, you're the AD so your view counts for more ;-)
>
>>>>>
>>>>>     171   Hop Count:
>>>>>
>>>>>     173      An unsigned 8-bit integer indicating the number of
>>>>>     network hops
>>>>>     174      required (i.e., number of times a packet will be
>>>>>     transmitted) to
>>>>>     175      reach the destination indicated in the message. The
>>>>>     special value
>>>>>     176      of 255 (0xFF) is used to indicate that the number of
>>>>>     hops is an
>>>>>     177      unknown number greater than one (1). This field MUST
>>>>>     contain a
>>>>>     178      value of at least one (1) if the associated
>>>>>     destination is
>>>>>     179      reachable.
>>>>>
>>>>>     181      A value of zero (0) is used to indicated that
>>>>>     processing of a Hop
>>>>>     182      Control action, see Section 3.2, has resulted in a
>>>>>     destination no
>>>>>     183      longer being reachable.  A zero value MUST NOT be
>>>>>     used in any
>>>>>     184      message other then a Link Characteristics Response
>>>>>     Message.
>>>>>
>>>>>     [nit] s/indicated/indicate
>     Thank you!
>
>>>>>
>>>>>     [minor] s/has resulted in a destination no longer being
>>>>>     reachable/has resulted in the destination no longer being
>>>>>     reachable  According to §3.2 the Hop Control message is about
>>>>>     "a particular destination", so the result can only be about it
>>>>>     (the destination), and not about any destination ("a
>>>>>     destination").  Yes, this is really a nit...but it took me
>>>>>     while to go check rfc8175 to get that detail right.
>     done.
>>>>>
>>>>>     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


>
>>>>>
>>>>>     215   A modem that receives the Hop Control Data Item in a
>>>>>     Session Update
>>>>>     216   Message SHOULD attempt to make the change indicated by
>>>>>     the data item
>>>>>     217   for all known destinations.  Once the change is made, or
>>>>>     fails or is
>>>>>     218   rejected, the modem MUST respond with a Session Update
>>>>>     Response
>>>>>     219   Message with an appropriate Status Code. Destination
>>>>>     specific impact
>>>>>     220   resulting from the processing of a Hop Control Data Item
>>>>>     in a Session
>>>>>     221   Update Message is provided via Destination Down and
>>>>>     Destination
>>>>>     222   Update Messages.  The modem MUST notify the router of each
>>>>>     223   destination that is no longer reachable via a
>>>>>     Destination Down
>>>>>     224   Message.  The modem MUST notify the router of any
>>>>>     changes in Hop
>>>>>     225   Counts via Destination Update Messages.
>>>>>
>>>>>     [minor] "Once the change is made, or fails or is rejected..."
>>>>>      Why could the change fail?
>     That the transmission characteristics of the channel don't support
>     the one-hop connection, even though the control plane though it might.
>
>>>>>     Why would it be rejected?
>     The far end modem rejects making the requested change, perhaps due
>     to policy.
>
>>>>>     I understand that the change may fail if, for example, the
>>>>>     destination is not directly reachable anymore (and a Direct
>>>>>     Connection was requested)...and I guess that there may be
>>>>>     "external" policy applied to the modem that could cause a
>>>>>     failure/rejection.  It might be worth clarifying that
>>>>>     (specially the rejection case) somewhere.
>>>>>
>>>>>
>     Okay how about:
>
>       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.
>>>>>     227   The format of the Hop Control Data Item is:
>>>>>
>>>>>     229        0 1                   2               3
>>>>>     230        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>>>>>     6 7 8 9 0 1
>>>>>     231
>>>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>     232       | Data Item Type            | Length                  |
>>>>>     233
>>>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>     234       |       Hop Control Actions     |
>>>>>     235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>
>>>>>     237   Data Item Type:  TBA3
>>>>>
>>>>>     239   Length:  4
>>>>>
>>>>>     [major] The Length should be 2.
>     yikes - you are right! Great catch.
>>>>>
>>>>>     241   Hop Control Actions:
>>>>>
>>>>>     243      An unsigned 16-bit value with the following meaning:
>>>>>
>>>>>     245  +-------+---------------------+
>>>>>     246                      | Value | Action  |
>>>>>     247  +-------+---------------------+
>>>>>     248                      | 0   | Reset               |
>>>>>     249                      |   |                     |
>>>>>     250                      | 1   | Terminate           |
>>>>>     251                      |   |                     |
>>>>>     252                      | 2   | Direct Connection   |
>>>>>     253                      |   |                     |
>>>>>     254                      | 3   | Suppress Forwarding |
>>>>>     255  +-------+---------------------+
>>>>>
>>>>>     257                    Table 1: Hop Control Actions Values
>>>>>
>>>>>     259 3.2.1.  Reset
>>>>>
>>>>>     261   The Reset Action requests that the default behavior be
>>>>>     restored.
>>>>>     262   When received in a Session Update Message message, a
>>>>>     modem SHOULD
>>>>>     263   clear all control actions that have previously been
>>>>>     processed on a
>>>>>     264   device wide basis, and revert to its configured
>>>>>     behavior.  When
>>>>>     265   received in a Link Characteristics Request Message, a
>>>>>     modem SHOULD
>>>>>     266   clear all control actions that have previously been
>>>>>     processed for the
>>>>>     267   destination indicated in the message.
>>>>>
>>>>>     [major] When would a modem not clear all control actions? 
>>>>>     IOW, why use SHOULD and not MUST?  I'm assuming that it may
>>>>>     not be possible (simply because of the nature of a manet), but
>>>>>     I'm asking in case there are other reasons.
>     I don't see a reason for not doing a MUST, I've made the change
>     but others should speak up if this is a mistake...
>
> JWD I think it may be a mistake to change this to a MUST.  There may 
> exist chained requests or delayed requests which are not yet fully 
> resolved and in those cases the modem should keep some state on those 
> pending actions so the results of those actions don't cause errant 
> behaviors.

I think the text covers this in "that have previously been processed" -- 
is this not sufficient?  If not, I'll change it back to SHOULD?

Thanks!

Lou


>>>>>
>>>>>     269 3.2.2.  Terminate
>>>>>
>>>>>     271   The Terminate Action is only valid on a per destination
>>>>>     basis and
>>>>>     272   MUST NOT be sent in a Session Update Message message. 
>>>>>     It indicates
>>>>>     273   that a direct connection is no longer needed with the
>>>>>     destination
>>>>>     274   identified in the message.  This request has no impact
>>>>>     for multi-hop
>>>>>     275   destinations and may fail even in a single hop case,
>>>>>     i.e. MAY result
>>>>>     276   in the Hop Count to the destination not being impacted
>>>>>     by the
>>>>>     277   processing of the request.
>>>>>
>>>>>     [major] s/MAY/may  That is a non-Normative statement.
>     s/MAY/can
>>>>>
>>>>>     [minor] What is the difference between Reset and Terminate
>>>>>     (for a particular destination)?
>     Terminate (possibly) undoes a direct connection
>     Reset undoes direct connection and suppress forwarding
>>>>>
>>>>>     279 3.2.3.  Direct Connection
>>>>>
>>>>>     281   The Direct Connection is only valid on a per destination
>>>>>     basis and
>>>>>     282   MUST NOT be sent in a Session Update Message message. 
>>>>>     It indicates
>>>>>     283   that the modem SHOULD attempt to establish a direct
>>>>>     connection with
>>>>>     284   the destination identified in the message.  This action
>>>>>     SHOULD only
>>>>>     285   be sent for destinations for which the Hop Count is
>>>>>     greater than 1
>>>>>     286   and has the P-Bit set in the previously received Hop
>>>>>     Count Data Item.
>>>>>     287   Results of the request for the destination identified in
>>>>>     the message
>>>>>     288   are provided as described above.  If any other
>>>>>     destination is
>>>>>     289   impacted in the processing of this action, the modem
>>>>>     MUST send a
>>>>>     290   Destination Update Message for each impacted destination.
>>>>>
>>>>>     [minor] ...or send a Destination Down...   If pointing at the
>>>>>     text above, I think that the last sentence (and any other
>>>>>     details) are not needed and redundant.
>     agreed and dropped
>>>>>
>>>>>     292 3.2.4.  Suppress Forwarding
>>>>>     ...
>>>>>     308   A modem which receives the Suppress Forwarding Data Item
>>>>>     in a Link
>>>>>     309   Characteristics Request Message MUST suppress multi-hop
>>>>>     forwarding
>>>>>     310   for only the destination indicated in the message. This
>>>>>     means that
>>>>>     311   data traffic originating from the modem's peer router
>>>>>     SHALL be sent
>>>>>     312   by the modem to the destination indicated in the Link
>>>>>     Characteristics
>>>>>     313   Request Message only when it is one modem hop away. 
>>>>>     Notably, data
>>>>>     314   traffic received by the modem from another modem MAY be
>>>>>     forwarded by
>>>>>     315   the modem per its normal processing.  Results are
>>>>>     provided as
>>>>>     316   described above.
>>>>>
>>>>>     [major] s/MAY/may  There's nothing about the change that would
>>>>>     make forwarding optional.
>     s/MAY/can
>
>>>>>
>>>>>     318 4.  Security Considerations
>>>>>
>>>>>     320   The extension enables the reporting and control of
>>>>>     forwarding
>>>>>     321   information by DLEP capable modems.  The extension does not
>>>>>     322   inherently introduce any additional threats above those
>>>>>     documented in
>>>>>
>>>>>     324   [RFC8175].  The approach taken to Security in that
>>>>>     document applies
>>>>>     325   equally when running the extension defined in this document.
>>>>>
>>>>>     [major] The use of this extension can result in unreachable
>>>>>     destinations -- maybe an unintended consequence of, for
>>>>>     example, re-aiming an antenna.  A rogue (or compromised)
>>>>>     router can take advantage of this.  A rogue (or compromised)
>>>>>     modem could indicate an incorrect hop count or P-bit setting
>>>>>     that may result in unreachable destinations (after the router
>>>>>     acts on that information).
>>>>>
>     I'm not sure either of these are really new.  Please see if the
>     text quoted above is adequate.
>>>>>     rfc8175 already mentions some related risks.  However, I think
>>>>>     that the point still needs to be called out specifically
>>>>>     because of the new functionality introduced.
>>>>>
>     sure.
>
>>>>>
>>>>>     ...
>>>>>     364 5.3.  Hop Control Actions Registry
>>>>>
>>>>>     366   Upon approval of this document, IANA is requested to
>>>>>     create a new
>>>>>     367   DLEP registry, named "Hop Control Actions Values".  The
>>>>>     following
>>>>>     368   table provides initial registry values and the
>>>>>     [RFC8126]. defined
>>>>>     369   policies that should apply to the registry:
>>>>>
>>>>>     [nit] s/[RFC8126]./[RFC8126]
>>>>>
>     thanks.
>
>>>>>
>>>>>     ...
>>>>>     409 6.2.  Informative References
>>>>>
>>>>>     411   [RFC8126]  Cotton, M., Leiba, B., and T. Narten,
>>>>>     "Guidelines for
>>>>>     412              Writing an IANA Considerations Section in
>>>>>     RFCs", BCP 26,
>>>>>     413              RFC 8126, DOI 10.17487/RFC8126, June 2017,
>>>>>     414              <https://www.rfc-editor.org/info/rfc8126>.
>>>>>
>>>>>     [major] This reference should be Normative.
>>>>>
>>>>>
>     Okay.
>
>     Thanks again for the comments -- once we resolve these I'll push a
>     new version. (I'll also push one before the monday cutoff no
>     matter what.)
>
>     Lou
>
>     _______________________________________________
>     manet mailing list
>     manet@ietf.org <mailto:manet@ietf.org>
>     https://www.ietf.org/mailman/listinfo/manet
>