[manet] Martin Vigoureux's No Objection on draft-ietf-manet-dlep-multi-hop-extension-06: (with COMMENT)

Martin Vigoureux via Datatracker <noreply@ietf.org> Mon, 29 April 2019 16:46 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: manet@ietf.org
Delivered-To: manet@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 66FB0120491; Mon, 29 Apr 2019 09:46:52 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Martin Vigoureux via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-manet-dlep-multi-hop-extension@ietf.org, Stan Ratliff <sratliff@idirect.net>, aretana.ietf@gmail.com, manet-chairs@ietf.org, sratliff@idirect.net, manet@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.95.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Martin Vigoureux <martin.vigoureux@nokia.com>
Message-ID: <155655641240.15821.2941396884107276101.idtracker@ietfa.amsl.com>
Date: Mon, 29 Apr 2019 09:46:52 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/1j6h60mRD4DXw87tcG7xqvkTxsY>
Subject: [manet] Martin Vigoureux's No Objection on draft-ietf-manet-dlep-multi-hop-extension-06: (with COMMENT)
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 29 Apr 2019 16:47:01 -0000

Martin Vigoureux has entered the following ballot position for
draft-ietf-manet-dlep-multi-hop-extension-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:



thank you for this Document. I have a couple of questions

   The absence of the Hop Count Data Item MUST be interpreted by the router as
   a Hop Count value of one (1).
I know it is a bit nit-picking but would it be worth explicitly saying that
this applies only in the case where the Multi-Hop Forwarding capability has
been successfully negotiated?

   Once the change is made, or fails or is rejected, the modem MUST respond
   with a Session Update Response Message with an appropriate Status Code.
I think you should specify which status code to use depending on the situation.

In sections 3.2.2 and .3 you have a requirement that says: "... MUST NOT be
sent in a Session Update Message message" but in 3.2 you have some generic
piece of text which says:
   A modem that receives the Hop Control Data Item in a Session Update
   Message SHOULD take whatever actions are needed to make the change
   indicated by the data item for all known destinations.
So if a router does not respect the MUST NOT then a modem might try to take
some actions based on something it should have received. Maybe it would be
worth completing the "MUST NOT send" requirement with a "MUST discard/return
error/log" type of requirement.

By the way, I'm not sure that the should in "... SHOULD take whatever actions
..." should be in caps. The actions that to be taken are described in detail in
3.2.1 to 3.2.4 and are not all SHOULDs (MUST clear, SHOULD attempt to
establish, MUST suppress).