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

Alvaro Retana <> Fri, 15 March 2019 15:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F33B112008F; Fri, 15 Mar 2019 08:47:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6bmxBh2ks3fi; Fri, 15 Mar 2019 08:47:11 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DA38812D4F0; Fri, 15 Mar 2019 08:47:10 -0700 (PDT)
Received: by with SMTP id j132so4669484oib.2; Fri, 15 Mar 2019 08:47:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=tTaIh6A9JKmyJSOtN/cvP1xEGfTt/7r81kU8n5eXGQo=; b=MP+8ZvmXUzbes82EMVbQfroBQPIX7n2RMK/XqBVT9t6YwWNDVqpwR1ZuQ4NX9gzkwQ WktZhXgfp2aWu9im4nuTC5ZKUte+VGOSjdZVXN7MBw1US4xayovRIgBzwKB1zw1efRzg rMPcQ72RIRmDVOujbQjcZWH78XkCIBLPFUVEZustHZ6s8bDv63Sc397qA7IB3gwVWxGo TOwg0+TyV3gBwAoyqZ65VW4LWYL/4OKyYMOJ4ElRFyWb9fuPz3xi7GkrIfmSkwxUa4CV elc3oDqo/XkPFkTPiEZboSBvvlrnRRZqODJMNAvFWQUqHHbeQ2U8X0llRv2m3I4XTTUS H+gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=tTaIh6A9JKmyJSOtN/cvP1xEGfTt/7r81kU8n5eXGQo=; b=C7/GsGl3m7gasuR7OUxQPBbqYt6tC8HlLGjHxsTrD3l6IlTOFg8UZPME7/mi5rsLrK GgKnEtWUnxOYl9EDxJ5GUASM9P5hbfQUbwaho/KJzvqz6cZ8Ath6iwcZvdKPzWqweZxL TdB+gOvbgM8qKk80Vv1ivzorij5fZVf3QfsscbG2/XB26JNM7XbuhtwervzraOxaBfRG pCfyzGnc4lG95rBxZs8Tfv/BaJkYqU8n9CIOeHbfFgufjfdfX5ozgmuyfKux50dtlbag 0PoAZwRyL3is0EEMQRudG9h87efrvws5c0wZuTIb23dq63z8XCqZVtLR0Ef05HZ31Mrr LHVA==
X-Gm-Message-State: APjAAAVhCQAE3uWEQw1m5PRQbgrOR4g3vFVOGd8RSxQkV1wrQld6C8om 18l6huUVnOZn2bx6l71MRTz9FovXVl08afI9qrY=
X-Google-Smtp-Source: APXvYqxwOm9bma4/Y9EiV9tabCYXspUa+m7yf5o6skiwF8cx++2LyihRgILmsat6YW8VXNspz4i+bukCmdzF8uPnjPc=
X-Received: by 2002:aca:4c10:: with SMTP id z16mr1891820oia.53.1552664830020; Fri, 15 Mar 2019 08:47:10 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Fri, 15 Mar 2019 16:47:09 +0100
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Date: Fri, 15 Mar 2019 16:47:09 +0100
Message-ID: <>
To: Lou Berger <>,
Cc: "Ratliff, Stanley" <>,, Mobile Ad-hoc Networks Working Group <>
Content-Type: multipart/alternative; boundary="000000000000a61291058423f347"
Archived-At: <>
Subject: Re: [manet] AD Review of draft-ietf-manet-dlep-multi-hop-extension-05
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mobile Ad-hoc Networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 15 Mar 2019 15:47:13 -0000

On March 8, 2019 at 9:54:24 AM, Lou Berger ( wrote:



Thanks for getting this done.

I have a couple of nits below — and will also send a reply to your exchange
with Justin.   I’ll start the IETF LC in a couple of minutes.



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

Yes, I think that’s fine.  Just a nit: there’s some orphaned text (“example
using”) left in the new text.


>> 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 ;-)

…but you still didn’t define the registry. :-(

Seriously:  it’s ok.  I trust that the next user will do the right thing.