From nobody Fri Feb 2 08:46:05 2018 Return-Path: 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 D014612DA28 for ; Fri, 2 Feb 2018 08:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 jA-5YPzXXX6x for ; Fri, 2 Feb 2018 08:46:00 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2BF512D9FF for ; Fri, 2 Feb 2018 08:45:59 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id 143so13849705wma.5 for ; Fri, 02 Feb 2018 08:45:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:mime-version:to:cc:from:subject:date:in-reply-to :references; bh=mPiL+jC1WRKLyoorgZxUCEM8K1E6QnAT5cDg/mU/c7g=; b=QKEgtEBPRLKa5pGNvj+d+IYxKVY73XiUbj7nI3MKsIAxAkNStMFUnpU8uNO8nngtLc QMaPc0sGDq6GQglrDsJzbEp98WTp1LNafopa0b4iM5XJqQB9Dk3oaE3jD9Mb4ZqhivS7 dW54E08bP7ntkOfirvZWcpiRKkjk9q4YqXBj5yZf9+j/+JD68uXBNp0M0q4VRy3K67Zs iXMJDPRAtjIWI6d31AGfOp+k7GVvfuZB48J0SAmnV+hv7WAs37hH9yvkj4PwfuFYW4+a QztpSkH2mzxk4SQ5yv0b1QUUzOIcXPCek4XKpLi/fd9feNwyXpLuC9ibMx3XWtTEfdVS zJlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:cc:from:subject:date :in-reply-to:references; bh=mPiL+jC1WRKLyoorgZxUCEM8K1E6QnAT5cDg/mU/c7g=; b=Yn0SuSpFL+c/ZevLh+WA3FrecPCbpwnV70/dWmVG11wWlWMCC5Njl6TvrIzgt9wHUa K/eUtAuB1cQGMg3G9AZycpqy284zGunt5ndP6NRjlRWggdXJLB2fBH44kycCMjfmcUf4 RwtrVzxVRuRA9RhxFkjjLa62JGvF53Kx3YUv9Ntw4s6jPqmzGKSDcevXEkha6N8gZxCY t5yil/yvbIKfy/Unh0Noa8BKdZeeVm0DGt/S0TIYPEtyXdWKBSRpb0F7iPqqSZ+r5d+m 6IvA+/cHftQa92ToVoey3TfxNiKyl/qL977gWuqT7VOptPLDGrfgdMrAfoU6qhBVRhUs SWuw== X-Gm-Message-State: AKwxytej4ysNNph1TWmmhEwTeMN5Z6ZW+9loMrPG/wuTtcB9hlhgQVAT WyELRHv52U+ZeaMdp4+4QHM= X-Google-Smtp-Source: AH8x226Od+yTjeJU4BNzbmy7iLRfKQyr52w2q2Yi9w578LabL++A3dyw2HTm2A8mi32TzSpm3kf1Fg== X-Received: by 10.80.173.45 with SMTP id y42mr15196512edc.247.1517589958326; Fri, 02 Feb 2018 08:45:58 -0800 (PST) Received: from [100.91.218.4] (ip-109-42-0-164.web.vodafone.de. [109.42.0.164]) by smtp.gmail.com with ESMTPSA id u17sm2390946edm.6.2018.02.02.08.45.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 02 Feb 2018 08:45:57 -0800 (PST) Message-ID: <5a7495c5.91f5500a.80291.24b5@mx.google.com> MIME-Version: 1.0 To: Victoria Pritchard , Rick Taylor Cc: "manet@ietf.org" From: HvFK Date: Fri, 2 Feb 2018 17:45:37 +0100 In-Reply-To: References: <38A5475DE83986499AEACD2CFAFC3F9801D32E95D5@tss-server1.home.tropicalstormsoftware.com> Content-Type: multipart/alternative; boundary="_8634C4EA-D63E-4560-9AFB-246845A09E99_" Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-lid-extension-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 16:46:03 -0000 --_8634C4EA-D63E-4560-9AFB-246845A09E99_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hello Rick, I find the draft very good. Especially section 2 -operations- i= s much better now. I'd love to see that draft ready to become a standard as= soon as possible, Cheers Georg ----- Urspr=C3=BCngliche Nachricht ----- Von: "Victoria Pritchard" Gesendet: =E2=80=8E31.=E2=80=8E01.=E2=80=8E2018 23:03 An: "Rick Taylor" Cc: "manet@ietf.org" Betreff: Re: [manet] I-D Action: draft-ietf-manet-dlep-lid-extension-01.txt Hi Rick, The new text is good, this is a well written draft, clear and easy to read. Only issue I can see is "it does not with to use" in section 3.1 - do you m= ean "it does not wish to use"? Regards, Vicky. On 30 January 2018 at 20:52, Rick Taylor w= rote: Hi All I have pushed out a new version of the link is draft. This version has some= minor text improvements hopefully clarifying some behavior.=20 Any reviews gratefully received, as I'd like to push for last call as I kno= w people are looking to implement Cheers Rick (Sent from my phone) ----- Reply message ----- From: "internet-drafts@ietf.org" To: "i-d-announce@ietf.org" Cc: "manet@ietf.org" Subject: [manet] I-D Action: draft-ietf-manet-dlep-lid-extension-01.txt Date: Tue, Jan 30, 2018 14:07 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks WG of the IETF. Title : Link Identifier Extension to DLEP Authors : Rick Taylor Stan Ratliff Filename : draft-ietf-manet-dlep-lid-extension-01.txt Pages : 8 Date : 2018-01-30 Abstract: There exists a class of modems that wish to support the Dynamic Link Exchange Protocol (DLEP) [RFC8175] but do not present a single Layer 2 network domain as required by DLEP. Such devices may be: o Modems that maintain a varying link to some upstream backbone network infrastructure, where the ability to announce link state and DLEP metrics is desired, but the concept of a DLEP destination router for the backbone does not apply. Examples of such devices can include LTE modems, IEEE 802.11 stations not in ad-hoc mode, and some satellite terminals. o Modems that provide Layer 3 wide area network connectivity between devices, where individual DLEP destinations do exist, but are not directly reachable by MAC address. This document introduces an optional extension to the core DLEP specification, allowing DLEP to be used between routers and modems that operate in this way. Note: o This document is intended as an extension to the core DLEP specification, and readers are expected to be fully conversant with the operation of core DLEP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-lid-extension/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-manet-dlep-lid-extension-01 https://datatracker.ietf.org/doc/html/draft-ietf-manet-dlep-lid-extension-0= 1 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-dlep-lid-extension-01 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet= --_8634C4EA-D63E-4560-9AFB-246845A09E99_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Hello Rick, I find the draft very good. Especially sectio= n 2 -operations- is much better now. I'd love to see that draft ready to be= come a standard as soon as possible, Cheers Georg
Von: Victoria Pritc= hard
Gesendet: =E2=80=8E31.=E2=80=8E01.=E2=80=8E2018 = 23:03
An: Rick Taylor
Cc: = manet@ietf.org
Betreff: Re: [manet] I-D Action: draft= -ietf-manet-dlep-lid-extension-01.txt

= Hi Rick,

The new text is good, this is a well written draft, clear a= nd easy to read.

Only issue I can see is "it does not with to use" i= n section 3.1 - do you mean "it does not wish to use"?

Regards,
V= icky.


On 30 January 2018 at 20:52, Rick Taylor <rick@tropi= calstormsoftware.com> wrote:
= =0A= =0A= =0A= =0A=
=0A=
<= div dir=3D"ltr">Hi All

I h= ave pushed out a new version of the link is draft. This version has some mi= nor text improvements hopefully clarifying some behavior. 

Any reviews gratefully received, as I= 'd like to push for last call as I know people are looking to implement

Cheers
=
Rick

(Sent from my phone)

----- Reply mess= age -----
From: "internet-drafts@ietf.org" <internet-drafts@ietf.org>
To: "i-d-announce@ietf.org<= /a>" <i-d-ann= ounce@ietf.org>
Cc: "manet@ietf.org" <manet@ietf.org>
Subject: [manet] I-D Action: draft-ietf-= manet-dlep-lid-extension-01.txt
Date: Tue, Jan 30, 2018 14:07
=

=0A=

=0A= A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=0A= This draft is a work item of the Mobile Ad-hoc Networks WG of the IETF.
= =0A=
=0A=         Title    &nb= sp;      : Link Identifier Extension to DLEP
= =0A=         Authors    &= nbsp;    : Rick Taylor
=0A=             &nb= sp;            = Stan Ratliff
=0A=         Filename    =     : draft-ietf-manet-dlep-lid-extension-01.txt
=0A=         Pages    &nb= sp;      : 8
=0A=         Date    &nbs= p;       : 2018-01-30
=0A=
=0A= Abstract:
=0A=    There exists a class of modems that wish to support the Dynami= c Link
=0A=    Exchange Protocol (DLEP) [RFC8175] but do not present a single= Layer
=0A=    2 network domain as required by DLEP.  Such devices may b= e:
=0A=
=0A=    o  Modems that maintain a varying link to some upstream b= ackbone
=0A=       network infrastructure, where the ability to= announce link state
=0A=       and DLEP metrics is desired, but the concept= of a DLEP destination
=0A=       router for the backbone does not apply. = ; Examples of such devices
=0A=       can include LTE modems, IEEE 802.11 stations= not in ad-hoc mode,
=0A=       and some satellite terminals.
=0A=
=0A=    o  Modems that provide Layer 3 wide area network connecti= vity between
=0A=       devices, where individual DLEP destinations = do exist, but are not
=0A=       directly reachable by MAC address.
=0A=
=0A=    This document introduces an optional extension to the core DLE= P
=0A=    specification, allowing DLEP to be used between routers and mo= dems
=0A=    that operate in this way.
=0A=
=0A=    Note:
=0A=
=0A=    o  This document is intended as an extension to the core = DLEP
=0A=       specification, and readers are expected to b= e fully conversant
=0A=       with the operation of core DLEP.
=0A=
=0A=
=0A= The IETF datatracker status page for this draft is:
=0A= https://datatracker.ietf.org/doc/draft-ietf-m= anet-dlep-lid-extension/
=0A=
=0A= There are also htmlized versions available at:
=0A= https://tools.ietf.org/html/draft-ietf-manet-dle= p-lid-extension-01
=0A= https://datatracker.ietf.org/doc/html/= draft-ietf-manet-dlep-lid-extension-01
=0A=
=0A= A diff from the previous version is available at:
=0A= https://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-manet-dlep-lid-extension-01
=0A=
=0A=
=0A= Please note that it may take a couple of minutes from the time of submissio= n
=0A= until the htmlized version and diff are available at tools.ietf.org.
=0A=
=0A= Internet-Drafts are also available by anonymous FTP at:
=0A= ftp://ftp= .ietf.org/internet-drafts/
=0A=
=0A= _______________________________________________
=0A= manet mailing list
=0A= manet@ietf.org
= =0A= h= ttps://www.ietf.org/mailman/listinfo/manet
=0A=
=0A=
=0A= =0A=
_______________________________________________
=0A= manet mailing list
=0A= manet@ietf.org
=0A= https://www.ietf.org/mailman/listinfo/manet
= =0A=

=0A= = --_8634C4EA-D63E-4560-9AFB-246845A09E99_-- From nobody Mon Feb 5 02:02:05 2018 Return-Path: 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 4922112AAB6 for ; Mon, 5 Feb 2018 02:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 T5PmPPQklQel for ; Mon, 5 Feb 2018 02:02:02 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A9E1129C59 for ; Mon, 5 Feb 2018 02:02:02 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id n188so20430851qkn.11 for ; Mon, 05 Feb 2018 02:02:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UAkvBCSoW8FXzcckh4gSRdwmgD7vrQqAij56XOv+MJk=; b=fTDqDDXTFiOPLctgPNpNcAi7lIFcMkR448AG8Q3HNn5iZotOrn116w2D/M/ViqMtj5 JlicPHsXNIIJwIE88ImUII3s5TennwCW0GRUpsejlJCfMPSRlkpEil0sdBdTF9cpoQeE m5V/czUaaCbsqJawmgQhFZX3CXKyEH4VtFZse/I2sWksffAWoUHIhQ93tfrkIUoHlQPE jVKtomgOf1WIJGDwRJb985uwCN/rzgiRPE5mF1egqQGBfU9hx9q2oL5XRUdB9Yugp7jR sHUI/doX2FMJ2Ci17JJAKPNf813JdSml2H/Ph1YwkaYW59WFHw5TQjKpqEVKap/XrwYI ZBfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UAkvBCSoW8FXzcckh4gSRdwmgD7vrQqAij56XOv+MJk=; b=lQGoYy52YgkJMSGjVuMCvORWv4Zbwl5dMapkHyzCgGy8QoVOgsEKWZuhkdCDHmrG2T 2AqJMzzPPiNjjj2xFHy6QahR8iDSyo9owEtArZb4hx2pJjxX76A7btuWQMfbVWAu0REl fqxxHE0jYmIraRaaMv3d1pJI9LyR7v308YsoRDslpKTBsVjA47bd8mZHlaI/SEbaoWgu 0+uB8nPxbUXS4gTXdUHU8Jbcm19mpK7tRozSYuzaOqL64cVSMERxJM74pgZGxhFgMG3w pL22ym4qAS3s8g4vfZN9NRCncf/NpUBKTbeQUMz+PKmTXvZS84rd50k1wG4lMjNxTyjH EWJg== X-Gm-Message-State: APf1xPCTOvcG8swuvpMAtP1vbE+o+vpTdkqcabGu+umT4JfnCJ7i9P7i c0OHQ/aEcYBh74aiNbrUCerv89NGJLLjxlHUMcLzhw== X-Google-Smtp-Source: AH8x2251un/u6/nqMq0N1k6lB9hmJZJsVVYu5fVXpu1RqSBt0jp/Yl7lEXtPsXK0nVFBcOFp+f70VDbxQXCRUGbPJGk= X-Received: by 10.55.22.67 with SMTP id g64mr20112836qkh.343.1517824921399; Mon, 05 Feb 2018 02:02:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.64.138 with HTTP; Mon, 5 Feb 2018 02:01:30 -0800 (PST) In-Reply-To: <151732120050.27516.9349844420176741896@ietfa.amsl.com> References: <151732120050.27516.9349844420176741896@ietfa.amsl.com> From: Henning Rogge Date: Mon, 5 Feb 2018 11:01:30 +0100 Message-ID: To: MANET IETF Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-lid-extension-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 10:02:04 -0000 Hi, I think I like the new text two, its easy to read and introduce the new concept quickly. The only thing I am concerned about is the "empty" flags field... do we already have an usecase for this? If not, we could remove it and introduce it (if necessary) in an extension... we could discover the existence of an (optional) flags field by comparing the length of the link-id TLV with the (known) value of the link-id-length TLV. Henning Rogge From nobody Mon Feb 5 03:56:36 2018 Return-Path: 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 B30971201F2 for ; Mon, 5 Feb 2018 03:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 KMWHIfdb26os for ; Mon, 5 Feb 2018 03:56:33 -0800 (PST) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE6941200FC for ; Mon, 5 Feb 2018 03:56:32 -0800 (PST) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Mon, 5 Feb 2018 11:56:29 +0000 From: Rick Taylor To: "hrogge@gmail.com" , "manet@ietf.org" Thread-Topic: [manet] I-D Action: draft-ietf-manet-dlep-lid-extension-01.txt Thread-Index: AQHTmdOgPD5qpa5rD0Sntsrb0M70f6OVnO8AgAAgG4A= Date: Mon, 5 Feb 2018 11:56:25 +0000 Message-ID: <1517831785.8344.5.camel@tropicalstormsoftware.com> References: <151732120050.27516.9349844420176741896@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: <76db35d3-8c7a-44eb-aa90-95a67554ec86> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-lid-extension-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 11:56:35 -0000 SGkgQWxsLA0KDQpDb21tZW50cyBpbmxpbmUNCg0KT24gTW9uLCAyMDE4LTAyLTA1IGF0IDExOjAx ICswMTAwLCBIZW5uaW5nIFJvZ2dlIHdyb3RlOg0KPiBIaSwNCj4gDQo+IEkgdGhpbmsgSSBsaWtl IHRoZSBuZXcgdGV4dCB0d28sIGl0cyBlYXN5IHRvIHJlYWQgYW5kIGludHJvZHVjZSB0aGUNCj4g bmV3IGNvbmNlcHQgcXVpY2tseS4NCg0KVGhhbmsgeW91IChhbmQgR2VvcmcgYXMgd2VsbCkgdmVy eSBtdWNoIQ0KDQo+IA0KPiBUaGUgb25seSB0aGluZyBJIGFtIGNvbmNlcm5lZCBhYm91dCBpcyB0 aGUgImVtcHR5IiBmbGFncyBmaWVsZC4uLiBkbw0KPiB3ZSBhbHJlYWR5IGhhdmUgYW4gdXNlY2Fz ZSBmb3IgdGhpcz8NCg0KSSBtdXN0IGFkbWl0LCBJIGNvcHkgYW5kIHBhc3RlZCB0aGUgdGV4dCBm cm9tIGVsc2V3aGVyZSwgYW5kIHRoZW4NCnJlYWxpemVkIEkgaGFkIG5vIGZsYWdzLg0KDQpIb3dl dmVyLCBvbmUgcG9zc2libGUgZmxhZyBjb3VsZCB1c2VkIHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4g TGlua3MgdG8NCkRlc3RpbmF0aW9ucyB3aXRoIGFuIElQIGFkZHJlc3MgKGFkZHJlc3NhYmxlIGRl c3RpbmF0aW9ucy8gTGF5ZXIgMw0KcmFkaW8gbmV0KSBhbmQgTGlua3MgdG8gIEluZnJhc3RydWN0 dXJlIChubyBJUCBhZGRyZXNzLCBqdXN0IGEgc3VibmV0KS4NCiBBbHRob3VnaCB0aGlzIGV4dGVu c2lvbiBkb2Vzbid0IG5lZWQgdG8gZGlmZmVyZW50aWF0ZSwgaXQgbWlnaHQgYmUNCnVzZWZ1bCBm b3IgdGhlIHJvdXRlciB0byBrbm93IHRoZSBkaWZmZXJlbmNlIHdoZW4gdXNlZCB3aXRoIG90aGVy DQpleHRlbnNpb25zIChob3AgY29udHJvbCBwZXJoYXBzKS4NCg0KPiANCj4gSWYgbm90LCB3ZSBj b3VsZCByZW1vdmUgaXQgYW5kIGludHJvZHVjZSBpdCAoaWYgbmVjZXNzYXJ5KSBpbiBhbg0KPiBl eHRlbnNpb24uLi4gd2UgY291bGQgZGlzY292ZXIgdGhlIGV4aXN0ZW5jZSBvZiBhbiAob3B0aW9u YWwpIGZsYWdzDQo+IGZpZWxkIGJ5IGNvbXBhcmluZyB0aGUgbGVuZ3RoIG9mIHRoZSBsaW5rLWlk IFRMViB3aXRoIHRoZSAoa25vd24pDQo+IHZhbHVlIG9mIHRoZSBsaW5rLWlkLWxlbmd0aCBUTFYu DQoNClllcywgaWYgYSBmbGFncyBmaWVsZCB3YXMgbmVlZGVkIGxhdGVyLCBhICdMaW5rIElkZW50 aWZpZXJzIEZsYWdzJw0KZXh0ZW5zaW9uIGNvdWxkIGludHJvZHVjZSBpdCBsZWdpdGltYXRlbHku DQoNCg== From nobody Mon Feb 5 04:01:12 2018 Return-Path: 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 8FCF91201F2 for ; Mon, 5 Feb 2018 04:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Bz2ghrjREOD8 for ; Mon, 5 Feb 2018 04:01:09 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 491251200FC for ; Mon, 5 Feb 2018 04:01:09 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id w128so9812768qkb.5 for ; Mon, 05 Feb 2018 04:01:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YNf17xH/lx4UiFIwem6Mvb9JD7ySc5NrMgYndNxb1Xs=; b=mtAay41ocmhe4Jy0/9W+xFYTlGz+WDp8l/I66Rq95ID7hOe3dzKMwgWJUkR4Cidn1t 1p9nep+zfpiJZAVc5e3gIBiWCQasK3bIyFYqIUjbflQuwTIO92Zh1yecl9QlPxfF1aa1 cBOraesUP1ALSmo01/j8si4wwEm1ctQrVHMPMXZn2R3omXW5FVR3EgZv1tbXpR688eF7 vzIKeGXT1g5qnoYhteGr0u93eA7pEhgwL2HbpL5bPDBN9OBUghrA+rfquX47n4p4jWcw sFWxuUgKxJhe7xu5Kvvxi6D54TaD7D93YHyjDLyLuYc/3WHqVs4a6RgpQKmc3FhlOSsa YnUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YNf17xH/lx4UiFIwem6Mvb9JD7ySc5NrMgYndNxb1Xs=; b=sLoQqKAYydbG9CQsiDEKxdVrIJL1u2tMWivBuBm7tLzOQJE1qdADL6JhSUYmg/IiaJ UenphWhb+0WHQMTDI+thGm5asj7nxYfPWP0fc/rm3WcVSJh+ZeosUnz4xxPCdacNel6B uk7pGxbjB3D87S2bzv1kHMRZWSyYuGub4TXJPlcDKz1Cq/+hkukZ7on8ssnTCQEo/HkV 1KpKfA6NEuUYADFq8SFu40omuhGBYz/+uSMoj0WxbeDxZ0NfLyYRvtEaCsTRod3PdRIF P24qicUUYqwtzkzKn9Yd0NPGPDlFYbicGoniYojJP+n8RpYWRrnRzSnw1SWzCl717WK3 eXbQ== X-Gm-Message-State: APf1xPCWmHFp8lgxRkcI7fxs+j5JWKAdcQzsQVwsJV6ES1GebKIUL4iY EXAxu0w1p4g9IyyoMlShMTCORQBoxRGPvt4n3X8= X-Google-Smtp-Source: AH8x2276t3CWZTkQs5auCNoSaSq9syELflijuRLyJyNnm/LIYTlHivOa6DEH1sxtTvIFxwaNeZINnoZYBMiM9r9/0BY= X-Received: by 10.55.149.199 with SMTP id x190mr22045385qkd.176.1517832068212; Mon, 05 Feb 2018 04:01:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.64.138 with HTTP; Mon, 5 Feb 2018 04:00:37 -0800 (PST) In-Reply-To: <1517831785.8344.5.camel@tropicalstormsoftware.com> References: <151732120050.27516.9349844420176741896@ietfa.amsl.com> <1517831785.8344.5.camel@tropicalstormsoftware.com> From: Henning Rogge Date: Mon, 5 Feb 2018 13:00:37 +0100 Message-ID: To: Rick Taylor Cc: "manet@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-lid-extension-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 12:01:12 -0000 On Mon, Feb 5, 2018 at 12:56 PM, Rick Taylor wrote: > Hi All, > > On Mon, 2018-02-05 at 11:01 +0100, Henning Rogge wrote: >> Hi, >> >> I think I like the new text two, its easy to read and introduce the >> new concept quickly. > > Thank you (and Georg as well) very much! > >> >> The only thing I am concerned about is the "empty" flags field... do >> we already have an usecase for this? > > I must admit, I copy and pasted the text from elsewhere, and then > realized I had no flags. > > However, one possible flag could used to distinguish between Links to > Destinations with an IP address (addressable destinations/ Layer 3 > radio net) and Links to Infrastructure (no IP address, just a subnet). > Although this extension doesn't need to differentiate, it might be > useful for the router to know the difference when used with other > extensions (hop control perhaps). Wouldn't it be easier to look at the prefix length of the IP? >> If not, we could remove it and introduce it (if necessary) in an >> extension... we could discover the existence of an (optional) flags >> field by comparing the length of the link-id TLV with the (known) >> value of the link-id-length TLV. > > Yes, if a flags field was needed later, a 'Link Identifiers Flags' > extension could introduce it legitimately. So what do you think, just drop the flags field? Henning From nobody Mon Feb 5 05:14:36 2018 Return-Path: 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 B15DF126BF3 for ; Mon, 5 Feb 2018 05:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 RmRVYkYB_G4U for ; Mon, 5 Feb 2018 05:14:32 -0800 (PST) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4262124B17 for ; Mon, 5 Feb 2018 05:14:31 -0800 (PST) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Mon, 5 Feb 2018 13:14:24 +0000 From: Rick Taylor To: "hrogge@gmail.com" CC: "manet@ietf.org" Thread-Topic: [manet] I-D Action: draft-ietf-manet-dlep-lid-extension-01.txt Thread-Index: AQHTmdOgPD5qpa5rD0Sntsrb0M70f6OVnO8AgAAgG4CAAAEtgIAAFJgA Date: Mon, 5 Feb 2018 13:14:20 +0000 Message-ID: <1517836460.8344.6.camel@tropicalstormsoftware.com> References: <151732120050.27516.9349844420176741896@ietfa.amsl.com> <1517831785.8344.5.camel@tropicalstormsoftware.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: <803c7493-dc50-4478-8bf5-c8fae5eee654> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-lid-extension-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 13:14:34 -0000 T24gTW9uLCAyMDE4LTAyLTA1IGF0IDEzOjAwICswMTAwLCBIZW5uaW5nIFJvZ2dlIHdyb3RlOg0K PiBPbiBNb24sIEZlYiA1LCAyMDE4IGF0IDEyOjU2IFBNLCBSaWNrIFRheWxvcg0KPiA8cmlja0B0 cm9waWNhbHN0b3Jtc29mdHdhcmUuY29tPiB3cm90ZToNCj4gPiBIaSBBbGwsDQo+ID4gDQo+ID4g T24gTW9uLCAyMDE4LTAyLTA1IGF0IDExOjAxICswMTAwLCBIZW5uaW5nIFJvZ2dlIHdyb3RlOg0K PiA+ID4gSGksDQo+ID4gPiANCj4gPiA+IEkgdGhpbmsgSSBsaWtlIHRoZSBuZXcgdGV4dCB0d28s IGl0cyBlYXN5IHRvIHJlYWQgYW5kIGludHJvZHVjZQ0KPiA+ID4gdGhlDQo+ID4gPiBuZXcgY29u Y2VwdCBxdWlja2x5Lg0KPiA+IA0KPiA+IFRoYW5rIHlvdSAoYW5kIEdlb3JnIGFzIHdlbGwpIHZl cnkgbXVjaCENCj4gPiANCj4gPiA+IA0KPiA+ID4gVGhlIG9ubHkgdGhpbmcgSSBhbSBjb25jZXJu ZWQgYWJvdXQgaXMgdGhlICJlbXB0eSIgZmxhZ3MgZmllbGQuLi4NCj4gPiA+IGRvDQo+ID4gPiB3 ZSBhbHJlYWR5IGhhdmUgYW4gdXNlY2FzZSBmb3IgdGhpcz8NCj4gPiANCj4gPiBJIG11c3QgYWRt aXQsIEkgY29weSBhbmQgcGFzdGVkIHRoZSB0ZXh0IGZyb20gZWxzZXdoZXJlLCBhbmQgdGhlbg0K PiA+IHJlYWxpemVkIEkgaGFkIG5vIGZsYWdzLg0KPiA+IA0KPiA+IEhvd2V2ZXIsIG9uZSBwb3Nz aWJsZSBmbGFnIGNvdWxkIHVzZWQgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiBMaW5rcw0KPiA+IHRv DQo+ID4gRGVzdGluYXRpb25zIHdpdGggYW4gSVAgYWRkcmVzcyAoYWRkcmVzc2FibGUgZGVzdGlu YXRpb25zLyBMYXllciAzDQo+ID4gcmFkaW8gbmV0KSBhbmQgTGlua3MgdG8gIEluZnJhc3RydWN0 dXJlIChubyBJUCBhZGRyZXNzLCBqdXN0IGENCj4gPiBzdWJuZXQpLg0KPiA+ICBBbHRob3VnaCB0 aGlzIGV4dGVuc2lvbiBkb2Vzbid0IG5lZWQgdG8gZGlmZmVyZW50aWF0ZSwgaXQgbWlnaHQgYmUN Cj4gPiB1c2VmdWwgZm9yIHRoZSByb3V0ZXIgdG8ga25vdyB0aGUgZGlmZmVyZW5jZSB3aGVuIHVz ZWQgd2l0aCBvdGhlcg0KPiA+IGV4dGVuc2lvbnMgKGhvcCBjb250cm9sIHBlcmhhcHMpLg0KPiAN Cj4gV291bGRuJ3QgaXQgYmUgZWFzaWVyIHRvIGxvb2sgYXQgdGhlIHByZWZpeCBsZW5ndGggb2Yg dGhlIElQPw0KPiANCj4gPiA+IElmIG5vdCwgd2UgY291bGQgcmVtb3ZlIGl0IGFuZCBpbnRyb2R1 Y2UgaXQgKGlmIG5lY2Vzc2FyeSkgaW4gYW4NCj4gPiA+IGV4dGVuc2lvbi4uLiB3ZSBjb3VsZCBk aXNjb3ZlciB0aGUgZXhpc3RlbmNlIG9mIGFuIChvcHRpb25hbCkNCj4gPiA+IGZsYWdzDQo+ID4g PiBmaWVsZCBieSBjb21wYXJpbmcgdGhlIGxlbmd0aCBvZiB0aGUgbGluay1pZCBUTFYgd2l0aCB0 aGUgKGtub3duKQ0KPiA+ID4gdmFsdWUgb2YgdGhlIGxpbmstaWQtbGVuZ3RoIFRMVi4NCj4gPiAN Cj4gPiBZZXMsIGlmIGEgZmxhZ3MgZmllbGQgd2FzIG5lZWRlZCBsYXRlciwgYSAnTGluayBJZGVu dGlmaWVycyBGbGFncycNCj4gPiBleHRlbnNpb24gY291bGQgaW50cm9kdWNlIGl0IGxlZ2l0aW1h dGVseS4NCj4gDQo+IFNvIHdoYXQgZG8geW91IHRoaW5rLCBqdXN0IGRyb3AgdGhlIGZsYWdzIGZp ZWxkPw0KDQpJJ20gaGFwcHkgdG8gZHJvcCB0aGVtIGlmIG5vLW9uZSBjYW4gdGhpbmsgb2YgYSB1 c2UgZm9yIHRoZW0uDQoNClJpY2sNCg== From nobody Mon Feb 5 08:31:38 2018 Return-Path: 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 BE4FF1270AE for ; Mon, 5 Feb 2018 08:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 UeRc6yIUjYP1 for ; Mon, 5 Feb 2018 08:31:35 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7694712702E for ; Mon, 5 Feb 2018 08:31:35 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id 141so26963589wme.3 for ; Mon, 05 Feb 2018 08:31:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:mime-version:to:cc:from:subject:date:in-reply-to :references; bh=Iio62F277aRSYoYdrDZ7Mfl0JUz5PcXTQhrfe2fxrFk=; b=sUd/k1HH8Swj2IholMPjFBEdqxUKmb2/w4VcrUu2pxDVpNRWzf3VU9cyRdcRsdzU/f VtPLl2n2lg9gIg82X5UHLMQLQKTv5cCW3aRZuhotlfKImy7OOjhcN8OPckK1spABs7cS MDvBiwRRg8UxcczFT+JSx2x+CvQu6OgK/08rTFk9EKrKk1Yq30eQFzqsdBH3GluyRJLz zerfIktgLX3tfXF/7dWiYE9v0w/DAiOAzaG5yZj0JGdQwi+5OSB/izGLgEsYdAEmo8Ne 0+d5Jq90ELEF9tSusPpZNd0oBbt2lTXf+uf5CPwurJ7KubDudSdE++eYSH1a68mPc/F8 SFHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:cc:from:subject:date :in-reply-to:references; bh=Iio62F277aRSYoYdrDZ7Mfl0JUz5PcXTQhrfe2fxrFk=; b=kfX6Spd/fnPd+2fy3Zf3t7tYj7QLzcs3onXPpjfAd+/QCU4gpGBKjqoCye4grf008D QZN+LBtY8zOF/aTESlYHxnNCU9mMC4t+4EHProm+JDnH15vuHovZAUAGy8MJxNKi8o5X jUTw42rj5OLX5No7Hz7EON9CueAuE/t51GScUxwQmhK+wRX3gS3+284G2ySdnT4on+3o Yiq5EuPrkNdQniaI1gL1lltSmKiUSM2ewLuYVAuTPIhwz881GW5qjSOHLZy/CWSlmlUT iQslF8FA9ZL3xQ61GnpgOXul5pO8CmhvzbFnpZMu2ltssK0/YTP1I+gbRXdTrqmsvykF nxBA== X-Gm-Message-State: AKwxytfZk4gV9t90bucjg4PB3aW4pVSvvKijaVSYondEmZaJlximF0HF TLc3xph6cCoX9p7xwMV7IKE= X-Google-Smtp-Source: AH8x224rvJ8tVeku5M6tB2F/Impc4CGYXOzmGDrwsaNcN8Ri/8OS1lKJ0st+ARK2EzzY5KSSpowrXg== X-Received: by 10.80.174.227 with SMTP id f32mr81480526edd.155.1517848294057; Mon, 05 Feb 2018 08:31:34 -0800 (PST) Received: from [192.168.2.100] (dslb-088-068-202-193.088.068.pools.vodafone-ip.de. [88.68.202.193]) by smtp.gmail.com with ESMTPSA id p32sm8000369eda.69.2018.02.05.08.31.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 05 Feb 2018 08:31:32 -0800 (PST) Message-ID: <5a7886e4.2394500a.3b85e.bf5f@mx.google.com> MIME-Version: 1.0 To: Rick Taylor , "hrogge@gmail.com" Cc: "manet@ietf.org" From: HvFK Date: Mon, 5 Feb 2018 17:31:33 +0100 In-Reply-To: <1517836460.8344.6.camel@tropicalstormsoftware.com> References: <151732120050.27516.9349844420176741896@ietfa.amsl.com> <1517831785.8344.5.camel@tropicalstormsoftware.com> <1517836460.8344.6.camel@tropicalstormsoftware.com> Content-Type: multipart/alternative; boundary="_FBE0539D-B9AF-4A0F-A9C0-346182E425BC_" Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-lid-extension-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 16:31:38 -0000 --_FBE0539D-B9AF-4A0F-A9C0-346182E425BC_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi Rick, Henning, all I think with both the Link-Identifier-Data-Item and Link-Identifier-Length-= Data-Item we have some good flexibility. I personally do not see a need for= the flags. I am also happy to remove it. Best Regards, Georg ----- Urspr=C3=BCngliche Nachricht ----- Von: "Rick Taylor" Gesendet: =E2=80=8E05.=E2=80=8E02.=E2=80=8E2018 14:14 An: "hrogge@gmail.com" Cc: "manet@ietf.org" Betreff: Re: [manet] I-D Action: draft-ietf-manet-dlep-lid-extension-01.txt On Mon, 2018-02-05 at 13:00 +0100, Henning Rogge wrote: > On Mon, Feb 5, 2018 at 12:56 PM, Rick Taylor > wrote: > > Hi All, > >=20 > > On Mon, 2018-02-05 at 11:01 +0100, Henning Rogge wrote: > > > Hi, > > >=20 > > > I think I like the new text two, its easy to read and introduce > > > the > > > new concept quickly. > >=20 > > Thank you (and Georg as well) very much! > >=20 > > >=20 > > > The only thing I am concerned about is the "empty" flags field... > > > do > > > we already have an usecase for this? > >=20 > > I must admit, I copy and pasted the text from elsewhere, and then > > realized I had no flags. > >=20 > > However, one possible flag could used to distinguish between Links > > to > > Destinations with an IP address (addressable destinations/ Layer 3 > > radio net) and Links to Infrastructure (no IP address, just a > > subnet). > > Although this extension doesn't need to differentiate, it might be > > useful for the router to know the difference when used with other > > extensions (hop control perhaps). >=20 > Wouldn't it be easier to look at the prefix length of the IP? >=20 > > > If not, we could remove it and introduce it (if necessary) in an > > > extension... we could discover the existence of an (optional) > > > flags > > > field by comparing the length of the link-id TLV with the (known) > > > value of the link-id-length TLV. > >=20 > > Yes, if a flags field was needed later, a 'Link Identifiers Flags' > > extension could introduce it legitimately. >=20 > So what do you think, just drop the flags field? I'm happy to drop them if no-one can think of a use for them. Rick _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_FBE0539D-B9AF-4A0F-A9C0-346182E425BC_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Hi Rick, Henning, all

I think with both the Link-I= dentifier-Data-Item and Link-Identifier-Length-Data-Item we have some good = flexibility. I personally do not see a need for the flags. I am also happy = to remove it.
Best Regards,  Georg
= Von: Rick Taylor<= /a>
Gesendet: =E2=80=8E05.=E2=80=8E02.=E2=80=8E2018 14:14=
An: hrogge@gmail.com=
Cc: manet@ietf.org=
Betreff: Re: [manet] I-D Action: draft-ietf-manet-dl= ep-lid-extension-01.txt

On Mon, 2018-02-05 at 13:00 +01= 00, Henning Rogge wrote:
> On Mon, Feb 5, 2018 at 12:56 PM, Rick Tayl= or
> <rick@tropicalstormsoftware.com> wrote:
> > Hi Al= l,
> >
> > On Mon, 2018-02-05 at 11:01 +0100, Henning Ro= gge wrote:
> > > Hi,
> > >
> > > I thi= nk I like the new text two, its easy to read and introduce
> > >= ; the
> > > new concept quickly.
> >
> > Tha= nk you (and Georg as well) very much!
> >
> > >
&= gt; > > The only thing I am concerned about is the "empty" flags fiel= d...
> > > do
> > > we already have an usecase for = this?
> >
> > I must admit, I copy and pasted the text f= rom elsewhere, and then
> > realized I had no flags.
> > =
> > However, one possible flag could used to distinguish between = Links
> > to
> > Destinations with an IP address (address= able destinations/ Layer 3
> > radio net) and Links to  Infra= structure (no IP address, just a
> > subnet).
> >  A= lthough this extension doesn't need to differentiate, it might be
> &= gt; useful for the router to know the difference when used with other
&g= t; > extensions (hop control perhaps).
>
> Wouldn't it be e= asier to look at the prefix length of the IP?
>
> > > If= not, we could remove it and introduce it (if necessary) in an
> >= > extension... we could discover the existence of an (optional)
>= > > flags
> > > field by comparing the length of the lin= k-id TLV with the (known)
> > > value of the link-id-length TLV= .
> >
> > Yes, if a flags field was needed later, a 'Lin= k Identifiers Flags'
> > extension could introduce it legitimately= .
>
> So what do you think, just drop the flags field?

= I'm happy to drop them if no-one can think of a use for them.

Rick_______________________________________________
manet mailing list
= manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
= --_FBE0539D-B9AF-4A0F-A9C0-346182E425BC_-- From nobody Tue Feb 6 00:51:42 2018 Return-Path: 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 C0793126DD9 for ; Tue, 6 Feb 2018 00:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 HfRX0niXdAHQ for ; Tue, 6 Feb 2018 00:51:38 -0800 (PST) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 384AC126BF6 for ; Tue, 6 Feb 2018 00:51:37 -0800 (PST) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Tue, 6 Feb 2018 08:51:35 +0000 From: Rick Taylor To: HvFK , "hrogge@gmail.com" CC: "manet@ietf.org" Thread-Topic: [manet] I-D Action: draft-ietf-manet-dlep-lid-extension-01.txt Thread-Index: AQHTmdOgPD5qpa5rD0Sntsrb0M70f6OVnO8AgAAgG4CAAAEtgIAAFJgAgAA3GoCAARC7wA== Date: Tue, 6 Feb 2018 08:51:33 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801D32F4793@tss-server1.home.tropicalstormsoftware.com> References: <151732120050.27516.9349844420176741896@ietfa.amsl.com> <1517831785.8344.5.camel@tropicalstormsoftware.com> <1517836460.8344.6.camel@tropicalstormsoftware.com> <5a7886e4.2394500a.3b85e.bf5f@mx.google.com> In-Reply-To: <5a7886e4.2394500a.3b85e.bf5f@mx.google.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_38A5475DE83986499AEACD2CFAFC3F9801D32F4793tssserver1hom_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-lid-extension-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 08:51:41 -0000 --_000_38A5475DE83986499AEACD2CFAFC3F9801D32F4793tssserver1hom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29ycnkgZm9yIHRoZSB0b3AtcG9zdCwgZGFtbiBPdXRsb29rLg0KDQpPbmUgdGhpbmcgSSBoYXZl IGNvbnNpZGVyZWQgaXMgd2hldGhlciBhZGRpbmcgc29tZSB3b3JrZWQgZXhhbXBsZXMgdG8gdGhl IHRleHQgaGFzIHZhbHVlLiAgSSBoYXZlIGhhZCB0byBleHBsYWluIExJRHMgYSBjb3VwbGUgb2Yg dGltZXMgdG8gcGVvcGxlIHdobyBoYXZlbuKAmXQgaW1tZWRpYXRlbHkgcmVhbGl6ZWQgdGhhdCB0 aGUgZXh0ZW5zaW9uIHNvbHZlcyB0aGVpciBwcm9ibGVtLiAgSXTigJlzIGFsd2F5cyBhbiBpc3N1 ZSB3aXRoIElFVEYgZHJhZnRzIHRoYXQgdGhleSBkcmlsbCBkb3duIHRvIHRoZSByYXcgcHJvdG9j b2xzLCBvZnRlbiBub3QgZXhwbGFpbmluZyB0aGUgcHJvYmxlbSBzcGFjZSB3ZWxsIChvciBwZXJo YXBzIGl04oCZcyBqdXN0IG15IHdyaXRpbmcgc3R5bGUpLg0KDQpNeSB0aG91Z2h0cyBhcmUsIHBl cmhhcHMgYSBzZWN0aW9uIGNvdmVyaW5nOiDigJxTbyB5b3UgaGF2ZSBhIExheWVyIDMgbW9kZW3i gJ0sIGFuZCDigJxTbyB5b3UgaGF2ZSBhIExURS9XaUZpIEFQ4oCdIGFuZCB5b3Ugd2FudCBETEVQ LiAgT2J2aW91c2x5IEkgaGF0ZSB3cml0aW5nIHRleHQsIEnigJltIGFuIGVuZ2luZWVyLCBidXQg aWYgcGVvcGxlIHRoaW5rIGl0IGhhcyB2YWx1ZSwgSSBjb3VsZCBmaW5kIHRoZSB0aW1lLg0KDQpP cGluaW9ucz8NCg0KUmljaw0KDQpGcm9tOiBIdkZLIFttYWlsdG86aHZmazYyQGdtYWlsLmNvbV0N ClNlbnQ6IDA1IEZlYnJ1YXJ5IDIwMTggMTY6MzINClRvOiBSaWNrIFRheWxvcjsgaHJvZ2dlQGdt YWlsLmNvbQ0KQ2M6IG1hbmV0QGlldGYub3JnDQpTdWJqZWN0OiBBVzogW21hbmV0XSBJLUQgQWN0 aW9uOiBkcmFmdC1pZXRmLW1hbmV0LWRsZXAtbGlkLWV4dGVuc2lvbi0wMS50eHQNCg0KSGkgUmlj aywgSGVubmluZywgYWxsDQoNCkkgdGhpbmsgd2l0aCBib3RoIHRoZSBMaW5rLUlkZW50aWZpZXIt RGF0YS1JdGVtIGFuZCBMaW5rLUlkZW50aWZpZXItTGVuZ3RoLURhdGEtSXRlbSB3ZSBoYXZlIHNv bWUgZ29vZCBmbGV4aWJpbGl0eS4gSSBwZXJzb25hbGx5IGRvIG5vdCBzZWUgYSBuZWVkIGZvciB0 aGUgZmxhZ3MuIEkgYW0gYWxzbyBoYXBweSB0byByZW1vdmUgaXQuDQpCZXN0IFJlZ2FyZHMsICBH ZW9yZw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClZvbjogUmljayBUYXlsb3I8 bWFpbHRvOnJpY2tAdHJvcGljYWxzdG9ybXNvZnR3YXJlLmNvbT4NCkdlc2VuZGV0OiDigI4wNS7i gI4wMi7igI4yMDE4IDE0OjE0DQpBbjogaHJvZ2dlQGdtYWlsLmNvbTxtYWlsdG86aHJvZ2dlQGdt YWlsLmNvbT4NCkNjOiBtYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpCZXRy ZWZmOiBSZTogW21hbmV0XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW1hbmV0LWRsZXAtbGlkLWV4 dGVuc2lvbi0wMS50eHQNCk9uIE1vbiwgMjAxOC0wMi0wNSBhdCAxMzowMCArMDEwMCwgSGVubmlu ZyBSb2dnZSB3cm90ZToNCj4gT24gTW9uLCBGZWIgNSwgMjAxOCBhdCAxMjo1NiBQTSwgUmljayBU YXlsb3INCj4gPHJpY2tAdHJvcGljYWxzdG9ybXNvZnR3YXJlLmNvbTxtYWlsdG86cmlja0B0cm9w aWNhbHN0b3Jtc29mdHdhcmUuY29tPj4gd3JvdGU6DQo+ID4gSGkgQWxsLA0KPiA+DQo+ID4gT24g TW9uLCAyMDE4LTAyLTA1IGF0IDExOjAxICswMTAwLCBIZW5uaW5nIFJvZ2dlIHdyb3RlOg0KPiA+ ID4gSGksDQo+ID4gPg0KPiA+ID4gSSB0aGluayBJIGxpa2UgdGhlIG5ldyB0ZXh0IHR3bywgaXRz IGVhc3kgdG8gcmVhZCBhbmQgaW50cm9kdWNlDQo+ID4gPiB0aGUNCj4gPiA+IG5ldyBjb25jZXB0 IHF1aWNrbHkuDQo+ID4NCj4gPiBUaGFuayB5b3UgKGFuZCBHZW9yZyBhcyB3ZWxsKSB2ZXJ5IG11 Y2ghDQo+ID4NCj4gPiA+DQo+ID4gPiBUaGUgb25seSB0aGluZyBJIGFtIGNvbmNlcm5lZCBhYm91 dCBpcyB0aGUgImVtcHR5IiBmbGFncyBmaWVsZC4uLg0KPiA+ID4gZG8NCj4gPiA+IHdlIGFscmVh ZHkgaGF2ZSBhbiB1c2VjYXNlIGZvciB0aGlzPw0KPiA+DQo+ID4gSSBtdXN0IGFkbWl0LCBJIGNv cHkgYW5kIHBhc3RlZCB0aGUgdGV4dCBmcm9tIGVsc2V3aGVyZSwgYW5kIHRoZW4NCj4gPiByZWFs aXplZCBJIGhhZCBubyBmbGFncy4NCj4gPg0KPiA+IEhvd2V2ZXIsIG9uZSBwb3NzaWJsZSBmbGFn IGNvdWxkIHVzZWQgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiBMaW5rcw0KPiA+IHRvDQo+ID4gRGVz dGluYXRpb25zIHdpdGggYW4gSVAgYWRkcmVzcyAoYWRkcmVzc2FibGUgZGVzdGluYXRpb25zLyBM YXllciAzDQo+ID4gcmFkaW8gbmV0KSBhbmQgTGlua3MgdG8gIEluZnJhc3RydWN0dXJlIChubyBJ UCBhZGRyZXNzLCBqdXN0IGENCj4gPiBzdWJuZXQpLg0KPiA+ICBBbHRob3VnaCB0aGlzIGV4dGVu c2lvbiBkb2Vzbid0IG5lZWQgdG8gZGlmZmVyZW50aWF0ZSwgaXQgbWlnaHQgYmUNCj4gPiB1c2Vm dWwgZm9yIHRoZSByb3V0ZXIgdG8ga25vdyB0aGUgZGlmZmVyZW5jZSB3aGVuIHVzZWQgd2l0aCBv dGhlcg0KPiA+IGV4dGVuc2lvbnMgKGhvcCBjb250cm9sIHBlcmhhcHMpLg0KPg0KPiBXb3VsZG4n dCBpdCBiZSBlYXNpZXIgdG8gbG9vayBhdCB0aGUgcHJlZml4IGxlbmd0aCBvZiB0aGUgSVA/DQo+ DQo+ID4gPiBJZiBub3QsIHdlIGNvdWxkIHJlbW92ZSBpdCBhbmQgaW50cm9kdWNlIGl0IChpZiBu ZWNlc3NhcnkpIGluIGFuDQo+ID4gPiBleHRlbnNpb24uLi4gd2UgY291bGQgZGlzY292ZXIgdGhl IGV4aXN0ZW5jZSBvZiBhbiAob3B0aW9uYWwpDQo+ID4gPiBmbGFncw0KPiA+ID4gZmllbGQgYnkg Y29tcGFyaW5nIHRoZSBsZW5ndGggb2YgdGhlIGxpbmstaWQgVExWIHdpdGggdGhlIChrbm93bikN Cj4gPiA+IHZhbHVlIG9mIHRoZSBsaW5rLWlkLWxlbmd0aCBUTFYuDQo+ID4NCj4gPiBZZXMsIGlm IGEgZmxhZ3MgZmllbGQgd2FzIG5lZWRlZCBsYXRlciwgYSAnTGluayBJZGVudGlmaWVycyBGbGFn cycNCj4gPiBleHRlbnNpb24gY291bGQgaW50cm9kdWNlIGl0IGxlZ2l0aW1hdGVseS4NCj4NCj4g U28gd2hhdCBkbyB5b3UgdGhpbmssIGp1c3QgZHJvcCB0aGUgZmxhZ3MgZmllbGQ/DQoNCkknbSBo YXBweSB0byBkcm9wIHRoZW0gaWYgbm8tb25lIGNhbiB0aGluayBvZiBhIHVzZSBmb3IgdGhlbS4N Cg0KUmljaw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cm1hbmV0IG1haWxpbmcgbGlzdA0KbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0K --_000_38A5475DE83986499AEACD2CFAFC3F9801D32F4793tssserver1hom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdp bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVO LUdCIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+U29ycnkgZm9yIHRoZSB0b3AtcG9z dCwgZGFtbiBPdXRsb29rLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+T25lIHRoaW5nIEkgaGF2ZSBjb25z aWRlcmVkIGlzIHdoZXRoZXIgYWRkaW5nIHNvbWUgd29ya2VkIGV4YW1wbGVzIHRvIHRoZSB0ZXh0 IGhhcyB2YWx1ZS7CoCBJIGhhdmUgaGFkIHRvIGV4cGxhaW4gTElEcyBhIGNvdXBsZSBvZiB0aW1l cyB0byBwZW9wbGUgd2hvIGhhdmVu4oCZdCBpbW1lZGlhdGVseSByZWFsaXplZCB0aGF0IHRoZSBl eHRlbnNpb24gc29sdmVzIHRoZWlyIHByb2JsZW0uwqAgSXTigJlzIGFsd2F5cyBhbiBpc3N1ZSB3 aXRoIElFVEYgZHJhZnRzIHRoYXQgdGhleSBkcmlsbCBkb3duIHRvIHRoZSByYXcgcHJvdG9jb2xz LCBvZnRlbiBub3QgZXhwbGFpbmluZyB0aGUgcHJvYmxlbSBzcGFjZSB3ZWxsIChvciBwZXJoYXBz IGl04oCZcyBqdXN0IG15IHdyaXRpbmcgc3R5bGUpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+TXkgdGhv dWdodHMgYXJlLCBwZXJoYXBzIGEgc2VjdGlvbiBjb3ZlcmluZzog4oCcU28geW91IGhhdmUgYSBM YXllciAzIG1vZGVt4oCdLCBhbmQg4oCcU28geW91IGhhdmUgYSBMVEUvV2lGaSBBUOKAnSBhbmQg eW91IHdhbnQgRExFUC7CoCBPYnZpb3VzbHkgSSBoYXRlIHdyaXRpbmcgdGV4dCwgSeKAmW0gYW4g ZW5naW5lZXIsIGJ1dCBpZiBwZW9wbGUgdGhpbmsgaXQgaGFzIHZhbHVlLCBJIGNvdWxkIGZpbmQg dGhlIHRpbWUuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5PcGluaW9ucz88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PlJpY2s8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0 LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsPjxi PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1VUyBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBI dkZLIFttYWlsdG86aHZmazYyQGdtYWlsLmNvbV0gPGJyPjxiPlNlbnQ6PC9iPiAwNSBGZWJydWFy eSAyMDE4IDE2OjMyPGJyPjxiPlRvOjwvYj4gUmljayBUYXlsb3I7IGhyb2dnZUBnbWFpbC5jb208 YnI+PGI+Q2M6PC9iPiBtYW5ldEBpZXRmLm9yZzxicj48Yj5TdWJqZWN0OjwvYj4gQVc6IFttYW5l dF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1tYW5ldC1kbGVwLWxpZC1leHRlbnNpb24tMDEudHh0 PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpw PiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPkhp IFJpY2ssIEhlbm5pbmcsIGFsbDxicj48YnI+SSB0aGluayB3aXRoIGJvdGggdGhlIExpbmstSWRl bnRpZmllci1EYXRhLUl0ZW0gYW5kIExpbmstSWRlbnRpZmllci1MZW5ndGgtRGF0YS1JdGVtIHdl IGhhdmUgc29tZSBnb29kIGZsZXhpYmlsaXR5LiBJIHBlcnNvbmFsbHkgZG8gbm90IHNlZSBhIG5l ZWQgZm9yIHRoZSBmbGFncy4gSSBhbSBhbHNvIGhhcHB5IHRvIHJlbW92ZSBpdC48YnI+QmVzdCBS ZWdhcmRzLCZuYnNwOyBHZW9yZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2 PjxkaXYgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50 ZXInPjxociBzaXplPTIgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlcj48L2Rpdj48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48Yj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5Wb246IDwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIic+PGEgaHJlZj0ibWFpbHRvOnJpY2tAdHJvcGljYWxzdG9ybXNvZnR3 YXJlLmNvbSI+UmljayBUYXlsb3I8L2E+PC9zcGFuPjxicj48Yj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5HZXNlbmRldDog PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiJz7igI4wNS7igI4wMi7igI4yMDE4IDE0OjE0PC9zcGFuPjxicj48 Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiJz5BbjogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48YSBocmVmPSJtYWlsdG86aHJvZ2dl QGdtYWlsLmNvbSI+aHJvZ2dlQGdtYWlsLmNvbTwvYT48L3NwYW4+PGJyPjxiPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPkNj OiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiInPjxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyI+bWFu ZXRAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5CZXRyZWZmOiA8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiInPlJlOiBbbWFuZXRdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbWFuZXQtZGxlcC1s aWQtZXh0ZW5zaW9uLTAxLnR4dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1N c29Ob3JtYWw+T24gTW9uLCAyMDE4LTAyLTA1IGF0IDEzOjAwICswMTAwLCBIZW5uaW5nIFJvZ2dl IHdyb3RlOjxicj4mZ3Q7IE9uIE1vbiwgRmViIDUsIDIwMTggYXQgMTI6NTYgUE0sIFJpY2sgVGF5 bG9yPGJyPiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNrQHRyb3BpY2Fsc3Rvcm1zb2Z0d2Fy ZS5jb20iPnJpY2tAdHJvcGljYWxzdG9ybXNvZnR3YXJlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4m Z3Q7ICZndDsgSGkgQWxsLDxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyBPbiBNb24sIDIwMTgt MDItMDUgYXQgMTE6MDEgKzAxMDAsIEhlbm5pbmcgUm9nZ2Ugd3JvdGU6PGJyPiZndDsgJmd0OyAm Z3Q7IEhpLDxicj4mZ3Q7ICZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7ICZndDsgSSB0aGluayBJIGxp a2UgdGhlIG5ldyB0ZXh0IHR3bywgaXRzIGVhc3kgdG8gcmVhZCBhbmQgaW50cm9kdWNlPGJyPiZn dDsgJmd0OyAmZ3Q7IHRoZTxicj4mZ3Q7ICZndDsgJmd0OyBuZXcgY29uY2VwdCBxdWlja2x5Ljxi cj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyBUaGFuayB5b3UgKGFuZCBHZW9yZyBhcyB3ZWxsKSB2 ZXJ5IG11Y2ghPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAm Z3Q7IFRoZSBvbmx5IHRoaW5nIEkgYW0gY29uY2VybmVkIGFib3V0IGlzIHRoZSAmcXVvdDtlbXB0 eSZxdW90OyBmbGFncyBmaWVsZC4uLjxicj4mZ3Q7ICZndDsgJmd0OyBkbzxicj4mZ3Q7ICZndDsg Jmd0OyB3ZSBhbHJlYWR5IGhhdmUgYW4gdXNlY2FzZSBmb3IgdGhpcz88YnI+Jmd0OyAmZ3Q7IDxi cj4mZ3Q7ICZndDsgSSBtdXN0IGFkbWl0LCBJIGNvcHkgYW5kIHBhc3RlZCB0aGUgdGV4dCBmcm9t IGVsc2V3aGVyZSwgYW5kIHRoZW48YnI+Jmd0OyAmZ3Q7IHJlYWxpemVkIEkgaGFkIG5vIGZsYWdz Ljxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyBIb3dldmVyLCBvbmUgcG9zc2libGUgZmxhZyBj b3VsZCB1c2VkIHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gTGlua3M8YnI+Jmd0OyAmZ3Q7IHRvPGJy PiZndDsgJmd0OyBEZXN0aW5hdGlvbnMgd2l0aCBhbiBJUCBhZGRyZXNzIChhZGRyZXNzYWJsZSBk ZXN0aW5hdGlvbnMvIExheWVyIDM8YnI+Jmd0OyAmZ3Q7IHJhZGlvIG5ldCkgYW5kIExpbmtzIHRv Jm5ic3A7IEluZnJhc3RydWN0dXJlIChubyBJUCBhZGRyZXNzLCBqdXN0IGE8YnI+Jmd0OyAmZ3Q7 IHN1Ym5ldCkuPGJyPiZndDsgJmd0OyZuYnNwOyBBbHRob3VnaCB0aGlzIGV4dGVuc2lvbiBkb2Vz bid0IG5lZWQgdG8gZGlmZmVyZW50aWF0ZSwgaXQgbWlnaHQgYmU8YnI+Jmd0OyAmZ3Q7IHVzZWZ1 bCBmb3IgdGhlIHJvdXRlciB0byBrbm93IHRoZSBkaWZmZXJlbmNlIHdoZW4gdXNlZCB3aXRoIG90 aGVyPGJyPiZndDsgJmd0OyBleHRlbnNpb25zIChob3AgY29udHJvbCBwZXJoYXBzKS48YnI+Jmd0 OyA8YnI+Jmd0OyBXb3VsZG4ndCBpdCBiZSBlYXNpZXIgdG8gbG9vayBhdCB0aGUgcHJlZml4IGxl bmd0aCBvZiB0aGUgSVA/PGJyPiZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7IElmIG5vdCwgd2UgY291 bGQgcmVtb3ZlIGl0IGFuZCBpbnRyb2R1Y2UgaXQgKGlmIG5lY2Vzc2FyeSkgaW4gYW48YnI+Jmd0 OyAmZ3Q7ICZndDsgZXh0ZW5zaW9uLi4uIHdlIGNvdWxkIGRpc2NvdmVyIHRoZSBleGlzdGVuY2Ug b2YgYW4gKG9wdGlvbmFsKTxicj4mZ3Q7ICZndDsgJmd0OyBmbGFnczxicj4mZ3Q7ICZndDsgJmd0 OyBmaWVsZCBieSBjb21wYXJpbmcgdGhlIGxlbmd0aCBvZiB0aGUgbGluay1pZCBUTFYgd2l0aCB0 aGUgKGtub3duKTxicj4mZ3Q7ICZndDsgJmd0OyB2YWx1ZSBvZiB0aGUgbGluay1pZC1sZW5ndGgg VExWLjxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyBZZXMsIGlmIGEgZmxhZ3MgZmllbGQgd2Fz IG5lZWRlZCBsYXRlciwgYSAnTGluayBJZGVudGlmaWVycyBGbGFncyc8YnI+Jmd0OyAmZ3Q7IGV4 dGVuc2lvbiBjb3VsZCBpbnRyb2R1Y2UgaXQgbGVnaXRpbWF0ZWx5Ljxicj4mZ3Q7IDxicj4mZ3Q7 IFNvIHdoYXQgZG8geW91IHRoaW5rLCBqdXN0IGRyb3AgdGhlIGZsYWdzIGZpZWxkPzxicj48YnI+ SSdtIGhhcHB5IHRvIGRyb3AgdGhlbSBpZiBuby1vbmUgY2FuIHRoaW5rIG9mIGEgdXNlIGZvciB0 aGVtLjxicj48YnI+Umljazxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj5tYW5ldCBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOm1hbmV0 QGlldGYub3JnIj5tYW5ldEBpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tYW5ldDwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2JvZHk+PC9o dG1sPg== --_000_38A5475DE83986499AEACD2CFAFC3F9801D32F4793tssserver1hom_-- From nobody Tue Feb 6 01:05:42 2018 Return-Path: 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 4D2EE126DD9 for ; Tue, 6 Feb 2018 01:05:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 e1MuWRtyInQ3 for ; Tue, 6 Feb 2018 01:05:29 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0525F120727 for ; Tue, 6 Feb 2018 01:05:29 -0800 (PST) Received: by mail-oi0-x234.google.com with SMTP id x21so798795oie.13 for ; Tue, 06 Feb 2018 01:05:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LhKQnzQeuMXDMluczGpFZHrbVLx2WYLvTMo88cQpM3c=; b=q3HwHCFWT+Mp5zS3P32C6PBVeEGM99ONyXvyA3Jua2R+ixx8sLZ2EQ0WuFI0tSJD/m prALWeUvg9rYzNd8tTLu/mSi4Pnph3c+uYhd4c1BbRwPTvWm1zz3mrMcNn8/DmE90aYs GRj7SyoJKU5mnehOaO10z2dieIL/+miwb7z1vp/8uK2bHjN6wUHTqVfbK9u9IWsldFI1 SNUvSgAhg0YhyjlhYkg9bDYc1S2Su5aU6jeyE/azUzOKldmqC0FBtUTPk9XvJfRC1RN3 dVDMQHbDdjDURNWtBe28RJhW7wlcjtMUO/zGywSywVX+RVCB/gRFdkDw6m0GNgu1COq/ CDDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LhKQnzQeuMXDMluczGpFZHrbVLx2WYLvTMo88cQpM3c=; b=nD/ojF6Bu+fCiwfhf8T9zfOIT68z/eoCHO2RjOVD/nWX7NlBpEJJlRTg9GxoBUmliU FN5g01IVvhU6aOlLcGHdl/S8HHSZZNVcCNNTVjVn/zncw5nEoN2zoq9wsUlD/tpjzUwj 0Vv6tSf/6efw2Zz1PnKF72RgZmfslbO8VNsN26ydXu2gwDZmNyqPd2OkLwV72eBq3jcZ C8iibxeCRa7FNDFkMf8PrLAA5OMqyKg4BTxsi+G0czDStOUYjOg24j8s9AAi4lec+4Dj xaSGZ1pmmC5Cj50FmYKo7OM9nMlF4RuLwB36O4kP3w8aFC007hzPq0MZcdgF95mH6GSg l3uA== X-Gm-Message-State: APf1xPAlF+o7gGsHLJlVxL8h3zKoTN+UdofVJU6Vm+gkLIWivIhRKgFl ReHJJctjcLX7wa9zeNH3fJqtsoYTLtexNYzA/0Y= X-Google-Smtp-Source: AH8x227fqiLErlouMGUGebXWzzXiAdkinaUvAZhexjZSuhLaz1/fJ4raTJtRBRSMVMRkWePXVsskHy974h8dXt1GvZw= X-Received: by 10.202.68.213 with SMTP id r204mr1090801oia.80.1517907928363; Tue, 06 Feb 2018 01:05:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.9.153 with HTTP; Tue, 6 Feb 2018 01:05:27 -0800 (PST) In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801D32F4793@tss-server1.home.tropicalstormsoftware.com> References: <151732120050.27516.9349844420176741896@ietfa.amsl.com> <1517831785.8344.5.camel@tropicalstormsoftware.com> <1517836460.8344.6.camel@tropicalstormsoftware.com> <5a7886e4.2394500a.3b85e.bf5f@mx.google.com> <38A5475DE83986499AEACD2CFAFC3F9801D32F4793@tss-server1.home.tropicalstormsoftware.com> From: Abdussalam Baryun Date: Tue, 6 Feb 2018 11:05:27 +0200 Message-ID: To: Rick Taylor Cc: HvFK , "hrogge@gmail.com" , "manet@ietf.org" Content-Type: multipart/alternative; boundary="001a113d74eadf3e8f0564877a1e" Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-lid-extension-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 09:05:41 -0000 --001a113d74eadf3e8f0564877a1e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Rick, On Tue, Feb 6, 2018 at 10:51 AM, Rick Taylor wrote: > Sorry for the top-post, damn Outlook. > > > > One thing I have considered is whether adding some worked examples to the > text has value. I have had to explain LIDs a couple of times to people w= ho > haven=E2=80=99t immediately realized that the extension solves their prob= lem. It=E2=80=99s > always an issue with IETF drafts that they drill down to the raw protocol= s, > often not explaining the problem space well (or perhaps it=E2=80=99s just= my > writing style). > > > > My thoughts are, perhaps a section covering: =E2=80=9CSo you have a Layer= 3 > modem=E2=80=9D, and =E2=80=9CSo you have a LTE/WiFi AP=E2=80=9D and you w= ant DLEP. Obviously I > hate writing text, I=E2=80=99m an engineer, but if people think it has va= lue, I > could find the time. > > > > Opinions? > I think the applicability statement section is helpful to mention solutions or use cases. However, users always can contact authors of RFCs, or IETF WGs, AB --001a113d74eadf3e8f0564877a1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Rick,

On Tue, Feb 6, 2018 at 10:51 AM, Rick Taylor = <ric= k@tropicalstormsoftware.com> wrote:

= Sorry for the top-post, damn Outlook.

=C2=A0

One thing I have consi= dered is whether adding some worked examples to the text has value.=C2=A0 I= have had to explain LIDs a couple of times to people who haven=E2=80=99t i= mmediately realized that the extension solves their problem.=C2=A0 It=E2=80= =99s always an issue with IETF drafts that they drill down to the raw proto= cols, often not explaining the problem space well (or perhaps it=E2=80=99s = just my writing style).

=C2=A0

My thoughts are, perhaps a section c= overing: =E2=80=9CSo you have a Layer 3 modem=E2=80=9D, and =E2=80=9CSo you= have a LTE/WiFi AP=E2=80=9D and you want DLEP.=C2=A0 Obviously I hate writ= ing text, I=E2=80=99m an engineer, but if people think it has value, I coul= d find the time.

=C2=A0

= Opinions?


I think the applicability statement section=C2=A0is h= elpful to=C2=A0mention solutions or use cases. However, users always can co= ntact authors of RFCs, or IETF WGs,

AB
=
--001a113d74eadf3e8f0564877a1e-- From nobody Tue Feb 6 23:43:27 2018 Return-Path: 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 0434E1201FA for ; Tue, 6 Feb 2018 23:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 qJcTRfNzAVWd for ; Tue, 6 Feb 2018 23:43:24 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF9091200C1 for ; Tue, 6 Feb 2018 23:43:23 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id x4-v6so21223848wmc.0 for ; Tue, 06 Feb 2018 23:43:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:mime-version:to:cc:from:subject:date:in-reply-to :references; bh=eFEqLK2gcacrkDL8+fD2ZWUIXu3vLVciSzESXrr6uB0=; b=Us9CRo4LdcN2WsLf/e452emMunqRZCDjgZHfOqrslvdUNLN9EgDmkN0spRI0EuWmF9 2HvlFTGAe3TQ3IvCM0BmGMeLXDcDE1bNKANxjoEjHS+gF/kHHYeigLmEbOTC3y2HL+Yd Q1h2dJ6T9mCNuIhg91nW4vZVNTKohakTKxv1PoynFQhFs18zcizXPdWcRssSVhdnDIaG +Mh27znfcqz3Yk1J7dSlIaFjVS3p2/7ZZRLupYDRHwPE98AS7JBPpQJIlZebsewZuzHX pCCOtNp56yzl3rhlEgbUZzM5QPFipZQ+6HEPRzFKBbKhyyfFpvVdTCZjcAy7MJTX3RM8 Gjug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:cc:from:subject:date :in-reply-to:references; bh=eFEqLK2gcacrkDL8+fD2ZWUIXu3vLVciSzESXrr6uB0=; b=kntuY13Rt37L9w+rADvci/aR904I+2NDodzzPesDQ3E8ssiu77aiRu3stDKR5TvYAl YsPNKa6Zqw7rV69nHmyRpApMZ6H3qYNqAqAtIGYBLLIFAWThK7iCf0jQ8Fg+JtsmTJZC 8q28/teuc+XpPsyVBkh9Vx8ol4rDAfkS5eqUuqirJ4XCRE8TwC+YLa3jqEVf7QWGP0p3 c4TVFF8qBEgpQaicRwK9+gUvcqQehRVFYRfW0hsVk8Pl2hGgGn2x5IzavsmHb07HiwFq LPJK4xC9ZCCtqR7XPZSkyftn4zd5rTaxBJQ7tnVE+hdSe8ihacjKWv0SWTarzb0AB0+o K8lA== X-Gm-Message-State: APf1xPA3fpFBT7ppNBe79B/d1ZveaVrfxxzcp08QZkI/S/XScWGECKvx pbLOZq+S/eCw1DBQtZtltNY= X-Google-Smtp-Source: AH8x226kLfaksMy202OU8W2huP/58A44Wgi4JwglWVKlWK0NsSsk7FUEmfM/MuRKLViAEgNucsJueQ== X-Received: by 10.80.194.146 with SMTP id o18mr7384197edf.67.1517989402317; Tue, 06 Feb 2018 23:43:22 -0800 (PST) Received: from [100.73.138.137] (ip-109-41-194-185.web.vodafone.de. [109.41.194.185]) by smtp.gmail.com with ESMTPSA id s23sm724624edm.15.2018.02.06.23.43.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 06 Feb 2018 23:43:21 -0800 (PST) Message-ID: <5a7aae19.97f4500a.3f698.4774@mx.google.com> MIME-Version: 1.0 To: Abdussalam Baryun , Rick Taylor Cc: "hrogge@gmail.com" , "manet@ietf.org" From: HvFK Date: Wed, 7 Feb 2018 08:43:21 +0100 In-Reply-To: References: <151732120050.27516.9349844420176741896@ietfa.amsl.com> <1517831785.8344.5.camel@tropicalstormsoftware.com> <1517836460.8344.6.camel@tropicalstormsoftware.com> <5a7886e4.2394500a.3b85e.bf5f@mx.google.com> <38A5475DE83986499AEACD2CFAFC3F9801D32F4793@tss-server1.home.tropicalstormsoftware.com> Content-Type: multipart/alternative; boundary="_CD53923B-9311-40B3-AF1E-1F9797615152_" Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-lid-extension-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 07:43:26 -0000 --_CD53923B-9311-40B3-AF1E-1F9797615152_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Good Morning everybody, usually a picture says more than a thousand words, but pictures do not real= ly fit into RFCs.... Let me try a brief use case: a IP Router is connected to an LTE infrastruct= ure via the EPC. The connection is supported by DLEP and called local. Seve= ral LTE modems are connected to this infrastructure over the air interface = (LTE RAN). Attached to the LTE modems are again IP Router supported again w= ith DLEP and called remote. In that case and with core DLEP the MAC data it= em would be the local one and the optionally IP data item the remote one. T= his Situation is a violation of core DLEP and won't work correctly. With LI= D this is turned valid as each remote side is represented by one unique LID= , the respective remote IP, but all of them with the same local MAC. This is my understanding and a real use case I've to deal with. Please reph= rase or comment if necessary. Regards, Georg=20 ----- Urspr=C3=BCngliche Nachricht ----- Von: "Abdussalam Baryun" Gesendet: =E2=80=8E06.=E2=80=8E02.=E2=80=8E2018 10:05 An: "Rick Taylor" Cc: "HvFK" ; "hrogge@gmail.com" ; "mane= t@ietf.org" Betreff: Re: [manet] I-D Action: draft-ietf-manet-dlep-lid-extension-01.txt Thanks Rick, On Tue, Feb 6, 2018 at 10:51 AM, Rick Taylor wrote: Sorry for the top-post, damn Outlook. =20 One thing I have considered is whether adding some worked examples to the t= ext has value. I have had to explain LIDs a couple of times to people who = haven=E2=80=99t immediately realized that the extension solves their proble= m. It=E2=80=99s always an issue with IETF drafts that they drill down to t= he raw protocols, often not explaining the problem space well (or perhaps i= t=E2=80=99s just my writing style). =20 My thoughts are, perhaps a section covering: =E2=80=9CSo you have a Layer 3= modem=E2=80=9D, and =E2=80=9CSo you have a LTE/WiFi AP=E2=80=9D and you wa= nt DLEP. Obviously I hate writing text, I=E2=80=99m an engineer, but if pe= ople think it has value, I could find the time. =20 Opinions? I think the applicability statement section is helpful to mention solutions= or use cases. However, users always can contact authors of RFCs, or IETF W= Gs, AB= --_CD53923B-9311-40B3-AF1E-1F9797615152_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Good Morning everybody,
usually a picture says more th= an a thousand words, but pictures do not really fit into RFCs....
Let me= try a brief use case: a IP Router is connected to an LTE infrastructure vi= a the EPC. The connection is supported by DLEP and called local. Several LT= E modems are connected to this infrastructure over the air interface (LTE R= AN). Attached to the LTE modems are again IP Router supported again with DL= EP and called remote. In that case and with core DLEP the MAC data item wou= ld be the local one and the optionally IP data item the remote one. This Si= tuation is a violation of core DLEP and won't work correctly. With LID this= is turned valid as each remote side is represented by one unique LID, the = respective remote IP, but all of them with the same local MAC.

This = is my understanding and a real use case I've to deal with. Please rephrase = or comment if necessary.
Regards, Georg
Von: Abdussalam Bary= un
Gesendet: =E2=80=8E06.=E2=80=8E02.=E2=80=8E2018 10= :05
An: Rick Taylor
Cc: = HvFK; hrogge@gmail.com; manet@ietf.org
Betreff: = Re= : [manet] I-D Action: draft-ietf-manet-dlep-lid-extension-01.txt
=
Thanks Rick,

On Tue, Feb 6, 2018 at 10:51 AM, Rick Taylor <rick@tropicalstormsoftware.com> wrote:

Sorry for the top-post, damn Outlook.

 

One thing I have considered is wheth= er adding some worked examples to the text has value.  I have had to e= xplain LIDs a couple of times to people who haven=E2=80=99t immediately rea= lized that the extension solves their problem.  It=E2=80=99s always an= issue with IETF drafts that they drill down to the raw protocols, often no= t explaining the problem space well (or perhaps it=E2=80=99s just my writin= g style).

My thoughts are, perhaps a section covering: =E2=80=9CSo you have a Layer = 3 modem=E2=80=9D, and =E2=80=9CSo you have a LTE/WiFi AP=E2=80=9D and you w= ant DLEP.  Obviously I hate writing text, I=E2=80=99m an engineer, but= if people think it has value, I could find the time.<= /p>

 

Opinions?


I think the applicability statement sect= ion is helpful to mention solutions or use cases. However, users = always can contact authors of RFCs, or IETF WGs,

A= B

=0A= = --_CD53923B-9311-40B3-AF1E-1F9797615152_-- From nobody Wed Feb 7 00:50:37 2018 Return-Path: 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 B3E461200C1 for ; Wed, 7 Feb 2018 00:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6BCtgYZoG7ux for ; Wed, 7 Feb 2018 00:50:28 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C0EA1250B8 for ; Wed, 7 Feb 2018 00:50:28 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id f4so126936qtj.6 for ; Wed, 07 Feb 2018 00:50:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=oD5kuFjCBmrINmTZ0lrQlp7suJV7/oFJzMNEOQEmZr4=; b=RE85+i92h6NZ6rr949dGqlvea3Cu/mBjzwN+JZZ3qm9BEjvyFk3BxBZFoIbyA3QMc2 FMITO1ITRpDi6FlDwUsya2JhcOBgDkI7FoYEGPUmNWf2RgxQNnZn8SVrtQEeEr5Aa2Ky dwmZCUyipQG0j1D0h/V2v8MN/YDG1/wYXxbuEeSwGc6lAY4IiISB0GCGdyCy1SxqxaJ+ Umh8EY9MDijOON74VhkK2ze6mjFc+zyaS8LCF6bTqZYK450uXjDsrswePjiUwU0W9bMD WeSXL4HMIwSD0XCiY03oefBZi5U+IXkyn7gFQ++2ENcKwbSZhb65JjnDVcCms1EsWl+E qUpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=oD5kuFjCBmrINmTZ0lrQlp7suJV7/oFJzMNEOQEmZr4=; b=nJXym8mL8ZBLMXv9s+WATzYvL2VOwe4Kh0IXbUYIRtoi23330n9AEpMV37ByPLHAph S6j9O954hDtdHDbilVzrG+ofMO54F59hRUXOAdruosJTtkDsHnhgprVJxH1Avvayuy+J GiVfpHGSwcR0dDyG/MvIsumDTY4lUoxiiSVzGH+GZ6Hv2vWjaVwnbK2TUpGXiLNbvNVR P1YxPRvQQ933RzmQ4I5dT9ri/9qXW9X6EdoWIvow14cM/Mqyue8OGi6GQirvx4rgRWfZ 6bclYM5WjRqDHRwa0oPEYvhfa72T4nKKds9GaaIWw/zTF8nRUg+Ap68QyYTzxUoyoPpw SGuQ== X-Gm-Message-State: APf1xPACFOTgTmzqVLAac3Rro0/lC5cf5jiyErJvQXk2uFm+Kkc5diN/ GKvp84RvyRFAl3THq4fqnoGbPkp4SQJC1M5/O+M= X-Google-Smtp-Source: AH8x226l9KPoQozYZURSFdgCJ8ebBHcCaiSkvEuPFx0DiGbvqLSLvrnvxS242j1HwGDpbB7rSEaNIal31gCuZuuOqBQ= X-Received: by 10.200.67.30 with SMTP id z30mr8502549qtm.197.1517993427333; Wed, 07 Feb 2018 00:50:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.64.138 with HTTP; Wed, 7 Feb 2018 00:49:56 -0800 (PST) In-Reply-To: <5a7aae19.97f4500a.3f698.4774@mx.google.com> References: <151732120050.27516.9349844420176741896@ietfa.amsl.com> <1517831785.8344.5.camel@tropicalstormsoftware.com> <1517836460.8344.6.camel@tropicalstormsoftware.com> <5a7886e4.2394500a.3b85e.bf5f@mx.google.com> <38A5475DE83986499AEACD2CFAFC3F9801D32F4793@tss-server1.home.tropicalstormsoftware.com> <5a7aae19.97f4500a.3f698.4774@mx.google.com> From: Henning Rogge Date: Wed, 7 Feb 2018 09:49:56 +0100 Message-ID: To: HvFK Cc: Abdussalam Baryun , Rick Taylor , "manet@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-lid-extension-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 08:50:34 -0000 Hi, the major use case I see for this draft is the support of multiple classes of service on the radio, e.g. prioritization on the link layer. (with the help of some other TLVs) this draft will allow the radio to announce multiple options to reach a direct neighbor and announce how the router can select them. Henning Rogge On Wed, Feb 7, 2018 at 8:43 AM, HvFK wrote: > Good Morning everybody, > usually a picture says more than a thousand words, but pictures do not > really fit into RFCs.... > Let me try a brief use case: a IP Router is connected to an LTE > infrastructure via the EPC. The connection is supported by DLEP and calle= d > local. Several LTE modems are connected to this infrastructure over the a= ir > interface (LTE RAN). Attached to the LTE modems are again IP Router > supported again with DLEP and called remote. In that case and with core D= LEP > the MAC data item would be the local one and the optionally IP data item = the > remote one. This Situation is a violation of core DLEP and won't work > correctly. With LID this is turned valid as each remote side is represent= ed > by one unique LID, the respective remote IP, but all of them with the sam= e > local MAC. > > This is my understanding and a real use case I've to deal with. Please > rephrase or comment if necessary. > Regards, Georg > ________________________________ > Von: Abdussalam Baryun > Gesendet: =E2=80=8E06.=E2=80=8E02.=E2=80=8E2018 10:05 > An: Rick Taylor > Cc: HvFK; hrogge@gmail.com; manet@ietf.org > Betreff: Re: [manet] I-D Action: draft-ietf-manet-dlep-lid-extension-01.t= xt > > Thanks Rick, > > On Tue, Feb 6, 2018 at 10:51 AM, Rick Taylor > wrote: >> >> Sorry for the top-post, damn Outlook. >> >> >> >> One thing I have considered is whether adding some worked examples to th= e >> text has value. I have had to explain LIDs a couple of times to people = who >> haven=E2=80=99t immediately realized that the extension solves their pro= blem. It=E2=80=99s >> always an issue with IETF drafts that they drill down to the raw protoco= ls, >> often not explaining the problem space well (or perhaps it=E2=80=99s jus= t my writing >> style). >> >> >> >> My thoughts are, perhaps a section covering: =E2=80=9CSo you have a Laye= r 3 >> modem=E2=80=9D, and =E2=80=9CSo you have a LTE/WiFi AP=E2=80=9D and you = want DLEP. Obviously I hate >> writing text, I=E2=80=99m an engineer, but if people think it has value,= I could >> find the time. >> >> >> >> Opinions? > > > I think the applicability statement section is helpful to mention solutio= ns > or use cases. However, users always can contact authors of RFCs, or IETF > WGs, > > AB > From nobody Wed Feb 14 15:06:21 2018 Return-Path: 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 934D11270AB for ; Wed, 14 Feb 2018 15:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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] autolearn=ham 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 EGREDm44kX79 for ; Wed, 14 Feb 2018 15:06:17 -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 2EEE912700F for ; Wed, 14 Feb 2018 15:06:17 -0800 (PST) Received: from cmgw4 (unknown [10.0.90.85]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id F308A175B30 for ; Wed, 14 Feb 2018 16:06:15 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id An6B1x00U2SSUrH01n6E6C; Wed, 14 Feb 2018 16:06:15 -0700 X-Authority-Analysis: v=2.2 cv=G85sK5s5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=Op4juWPpsa0A:10 a=wU2YTnxGAAAA:8 a=NEAV23lmAAAA:8 a=u6Ws2X-LPAWlhauOg-wA:9 a=B6VXFI4T1fAXX2pY:21 a=F-iwtYgl_G9oUzBP:21 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 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:To:Subject:Sender:Reply-To:Cc: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=eerwVHdjRLrUmPnYPWS+dYarA6HL/Ktu+nFJoqoaGjk=; b=TaJtqSosQj9vwk++a2/fSShDtj sDUY0JVb2sFEylVD0xm0t9pTeq+dmO68nTa8/qve5gmuaPeT/w/wQpK0quiMZLSR0MfiZAcfbXvvD qWitbhe+Wd75QlFSK+StcPOOw; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:57870 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1em67v-002T5m-Pz; Wed, 14 Feb 2018 16:06:11 -0700 To: "Wiggins, David - 0665 - MITLL" , Justin Dean , MANET IETF References: <020E5EA0-7A6B-46D1-9363-640E3FBBA0ED@ll.mit.edu> <16134a38478.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> From: Lou Berger Message-ID: <68a6abc9-8305-1bf7-da99-37e7015da68c@labn.net> Date: Wed, 14 Feb 2018 18:06:09 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: 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: 100.15.86.101 X-Exim-ID: 1em67v-002T5m-Pz X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:57870 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [manet] Last call ending X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 23:06:20 -0000 Sorry for the delayed response. see bewlo On 1/29/2018 5:26 PM, Wiggins, David - 0665 - MITLL wrote: > I tried to clarify Suppress Forwarding: > > The Suppress Forwarding Action is used by a router to indicate to its > peer that multi-hop forwarding performed by the modem is to be > suppressed. A router may request that multi-hop forwarding may be > suppressed on a device wide or destination specific basis. yes. > A modem which receives the Suppress Forwarding Data Item in a Session > Update Message MUST suppress multi-hop forwarding on a device wide > basis. For data traffic originating from the modem's peer router, the > modem MUST only send such traffic to destinations that are one hop > away. Any data traffic received from the modem MUST NOT be resent to > another modem. Impact to destination hop counts are provided to the > router by the modem as described above. How about, slightly rephrased:   A modem which receives the Suppress Forwarding Data Item in a Session   Update Message MUST suppress multi-hop forwarding on a device wide   basis. This means that data traffic originating from the modem's peer   router SHALL only be sent by the modem to destinations that are one   modem hop away, and that any data traffic received by the modem from   another modem that is not destined to the peer router SHALL be   dropped. Impact to destination hop counts are provided to the   router by the modem as described above. > A modem which receives the Suppress Forwarding Data Item in a Link > Characteristics Request Message MUST suppress multi-hop forwarding for > only the destination indicated in the message. Sending of traffic by > the modem is modified as described in the previous paragraph, except > that the suppression only applies to the specific destination given in > the Link Characteristics Request Message. Results are provided as > described above. Actually there's a substantive difference in the following, i.e., transit traffic is *not* impacted:   A modem which receives the Suppress Forwarding Data Item in a Link   Characteristics Request Message MUST suppress multi-hop forwarding for   only the destination indicated in the message.  This means that data   traffic originating from the modem's peer router SHALL be sent by the   modem to the destination indicated in the Link Characteristics Request   Message only when it is one modem hop away.  Notably, data traffic   received by the modem from another modem MAY be forwarded by the modem   per its normal processing.  Results are provided as described above. Does this work for you/all? Lou > Does that fit what was meant? > > Thanks, > David > > > > On 1/29/18, 1:37 PM, "Lou Berger" wrote: > > ... > David, (all) > I think I've addressed all comments in the latest push to the repo. I'm > enclosing below a specific diff of the commit that addresses your > comments, please take a look and let me know if you see any issues > remaining. > > Note I have clarified processing when hop control is in a > characteristics change message and changed/simplified in the Session > request massage case - to improve processing consistency as you > requested. Please see the specific changes below and let me know what > you think. > > I also have one comment in response to your comment below. > > On 01/29/2018 09:36 AM, Wiggins, David - 0665 - MITLL wrote: > > > That’s why I was suggesting a radically different mechanism for the router > > > to express its wishes, e.g., by ordering the destinations in terms of > > > importance, and letting the modem work that information into its topology > > > control scheme however it can. The router’s most important destination may > > > be best reached over a 3-hop link. > > > > > > > To me this is a different extension with different objectives. I certainly > > would be interested in reading that extension. > > > > It has very similar objectives to the Direct Connection/Terminate part of this extension, but I agree that it doesn’t fit well in this extension. > > I think an extension that does this as well as let's a router understand > some of the resource impacts of a manet topology (with out exposing the > full topology ala ospf/isis-te) would be very interesting. I actually > had some related discussion on this in singapore. If you have a > proposal on this or are interested in collaborating on such, I'm very > interested in this! > > Thanks, > > Lou > > Changes from: > https://github.com/louberger/dlep-extensions/commit/100217f5a8a3e35c6608b4a88428b20b14854f8f > commit 100217f5a8a3e35c6608b4a88428b20b14854f8f > Author: Lou Berger > Date: Mon Jan 29 13:20:09 2018 -0500 > > Multi-hop: Address remainder of Dave W. comments > - Clean up Hop Behavior processing. > Send only one message when link characteristic change results in > a change/unreachable requested destination > Destination impact due to Hop Control Data Item in a Session > Update Message always provided via a Destination Down or > Destination Update Message. > > diff --git a/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml > b/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml > index 5fc2845..f81e3be 100644 > --- a/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml > +++ b/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml > @@ -110,7 +110,8 @@ > words, each hop represents a transmission and the number of hops is > equal to the number of transmissions required to go from a router > connected modem to the destination's connected modem. The minimum > - number of hops is 1, which represents the transmission by the router's > + number of hops is 1, which represents transmission to destinations > + that are directly reachable via the router's > locally connected > modem. > > @@ -176,7 +177,7 @@ > A value of zero (0) is used to indicated that processing of a Hop > Control action, see , has resulted > in a destination no longer being reachable. A zero value MUST NOT > - be used in any message other then a Destination Announce Response > + be used in any message other then a Link Characteristics Response > Message. > > > @@ -189,7 +190,8 @@ > connectivity to a particular destination, or in multi-hop processing > on a device wide basis. A router can request multi-hop reachable > destination be changed to a single hop. A router can also indicate > - that the modem terminate connectivity to a particular destination. > + that the modem terminates a previous direct connectivity request to a > + particular destination. > > > The Hop Control Data Item MAY be carried in a Session Update Message > @@ -218,20 +220,19 @@ > notify the router of each destination that is no longer reachable via > a Destination Down Message. The modem MUST notify the router of any > changes in Hop Counts via Destination Update Messages. Note that > - normal DLEP processing is not otherwise modified by this document, this > - includes the generation of Destination Down messages. > + neither Destination Down or Update Message SHOULD NOT be sent for the > + destination MAC address contained in the Link Characteristics > + Response Message. > > > A modem that receives the Hop Control Data Item in > a Session Update Message > SHOULD attempt to make the change indicated by the data item > - for the associated destination MAC address, when carried in a Link > - Characteristics Request Message, or all destinations, when carried in > - a Session Update Message. Once the change is made, > - or fails or is rejected, the modem MUST respond with a Link > Characteristics > - Request Message containing an updated Hop Count Data Item. Note that > - other destinations can be impacted as a result of the change and such > - changes are reported in > + for all known destinations. 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. Destination specific > + impact resulting from the processing of a Hop Control Data Item in a > + Session Update Message is provided via > Destination Down and Destination Update Messages. The modem MUST > notify the router of each destination that is no longer reachable via > a Destination Down Message. The modem MUST notify the router of any > > From nobody Wed Feb 14 15:10:42 2018 Return-Path: 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 8A4911272E1 for ; Wed, 14 Feb 2018 15:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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] autolearn=ham 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 4CdQqIvIYCQv for ; Wed, 14 Feb 2018 15:10:38 -0800 (PST) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 5880012700F for ; Wed, 14 Feb 2018 15:10:38 -0800 (PST) Received: from cmgw4 (unknown [10.0.90.85]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id F248A1E097D for ; Wed, 14 Feb 2018 16:10:37 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id AnAa1x01F2SSUrH01nAdM3; Wed, 14 Feb 2018 16:10:37 -0700 X-Authority-Analysis: v=2.2 cv=G85sK5s5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=Op4juWPpsa0A:10 a=wU2YTnxGAAAA:8 a=NEAV23lmAAAA:8 a=48vgC7mUAAAA:8 a=c0QgQHz4hgc6i3fSFhoA:9 a=ea2_Swc9FDCSOq9Z:21 a=yUcn17jzzK2aO4bX:21 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22 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=rqTvZZABgHKnSNQFpaxFi/+qgpoZsTaR3zvQmT0m9Os=; b=ssWKbmUoIAowunx7e93lXC6Ff7 x9NrozNrpRXBBGEHYjjqdNgMIGWGUX8iU/pUtUxz3InWGk27OfX4WTTeK+kjOcokjFeRLdgQShpQV oKwHZvpo0go/dJBiTGp4ZYV86; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:58220 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1em6CA-002Uuf-LZ; Wed, 14 Feb 2018 16:10:34 -0700 To: Stan Ratliff , "Wiggins, David - 0665 - MITLL" Cc: Justin Dean , MANET IETF References: <020E5EA0-7A6B-46D1-9363-640E3FBBA0ED@ll.mit.edu> <16134a38478.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> From: Lou Berger Message-ID: <097c3985-48d7-9584-da50-1ddf14524fa3@labn.net> Date: Wed, 14 Feb 2018 18:10:32 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: 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: 100.15.86.101 X-Exim-ID: 1em6CA-002Uuf-LZ X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:58220 X-Source-Auth: lberger@labn.net X-Email-Count: 7 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [manet] Last call ending X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 23:10:40 -0000 Hi Stan, On 1/29/2018 5:39 PM, Stan Ratliff wrote: > > Sent from my iPhone > >> On Jan 29, 2018, at 5:26 PM, Wiggins, David - 0665 - MITLL wrote: >> >> I tried to clarify Suppress Forwarding: >> >> The Suppress Forwarding Action is used by a router to indicate to its >> peer that multi-hop forwarding performed by the modem is to be >> suppressed. A router may request that multi-hop forwarding may be >> suppressed on a device wide or destination specific basis. >> >> A modem which receives the Suppress Forwarding Data Item in a Session >> Update Message MUST suppress multi-hop forwarding on a device wide >> basis. > This concerns me. Should the modem > a) silently drop traffic unless/until the multi-hop destination(s) become single-hop again? (Bad plan, IMO) Or, > b) issue Destination Down for multi-hop destination(s), and re-issue Destination Up If/when the dest is single-hop? Stand note that the reference paragraph concludes:   Impact to destination hop counts are provided to the   router by the modem as described above. and above it says:  ...  Destination specific impact resulting from the processing of a Hop  Control Data Item in a Session Update Message is provided via  Destination Down and Destination Update Messages.  The modem MUST  notify the router of each destination that is no longer reachable via a  Destination Down Message. The modem MUST notify the router of any  changes in Hop Counts via Destination Update Messages. Is this sufficient? Thanks, Lou > Regards, > Stan > >> For data traffic originating from the modem's peer router, the >> modem MUST only send such traffic to destinations that are one hop >> away. Any data traffic received from the modem MUST NOT be resent to >> another modem. Impact to destination hop counts are provided to the >> router by the modem as described above. >> >> A modem which receives the Suppress Forwarding Data Item in a Link >> Characteristics Request Message MUST suppress multi-hop forwarding for >> only the destination indicated in the message. Sending of traffic by >> the modem is modified as described in the previous paragraph, except >> that the suppression only applies to the specific destination given in >> the Link Characteristics Request Message. Results are provided as >> described above. >> >> Does that fit what was meant? >> >> Thanks, >> David >> >> >> >> On 1/29/18, 1:37 PM, "Lou Berger" wrote: >> >> ... >> David, (all) >> I think I've addressed all comments in the latest push to the repo. I'm >> enclosing below a specific diff of the commit that addresses your >> comments, please take a look and let me know if you see any issues >> remaining. >> >> Note I have clarified processing when hop control is in a >> characteristics change message and changed/simplified in the Session >> request massage case - to improve processing consistency as you >> requested. Please see the specific changes below and let me know what >> you think. >> >> I also have one comment in response to your comment below. >> >> On 01/29/2018 09:36 AM, Wiggins, David - 0665 - MITLL wrote: >>>> That’s why I was suggesting a radically different mechanism for the router >>>> to express its wishes, e.g., by ordering the destinations in terms of >>>> importance, and letting the modem work that information into its topology >>>> control scheme however it can. The router’s most important destination may >>>> be best reached over a 3-hop link. >>>> >>> To me this is a different extension with different objectives. I certainly >>> would be interested in reading that extension. >>> >>> It has very similar objectives to the Direct Connection/Terminate part of this extension, but I agree that it doesn’t fit well in this extension. >> I think an extension that does this as well as let's a router understand >> some of the resource impacts of a manet topology (with out exposing the >> full topology ala ospf/isis-te) would be very interesting. I actually >> had some related discussion on this in singapore. If you have a >> proposal on this or are interested in collaborating on such, I'm very >> interested in this! >> >> Thanks, >> >> Lou >> >> Changes from: >> https://github.com/louberger/dlep-extensions/commit/100217f5a8a3e35c6608b4a88428b20b14854f8f >> commit 100217f5a8a3e35c6608b4a88428b20b14854f8f >> Author: Lou Berger >> Date: Mon Jan 29 13:20:09 2018 -0500 >> >> Multi-hop: Address remainder of Dave W. comments >> - Clean up Hop Behavior processing. >> Send only one message when link characteristic change results in >> a change/unreachable requested destination >> Destination impact due to Hop Control Data Item in a Session >> Update Message always provided via a Destination Down or >> Destination Update Message. >> >> diff --git a/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml >> b/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml >> index 5fc2845..f81e3be 100644 >> --- a/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml >> +++ b/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml >> @@ -110,7 +110,8 @@ >> words, each hop represents a transmission and the number of hops is >> equal to the number of transmissions required to go from a router >> connected modem to the destination's connected modem. The minimum >> - number of hops is 1, which represents the transmission by the router's >> + number of hops is 1, which represents transmission to destinations >> + that are directly reachable via the router's >> locally connected >> modem. >> >> @@ -176,7 +177,7 @@ >> A value of zero (0) is used to indicated that processing of a Hop >> Control action, see , has resulted >> in a destination no longer being reachable. A zero value MUST NOT >> - be used in any message other then a Destination Announce Response >> + be used in any message other then a Link Characteristics Response >> Message. >> >> >> @@ -189,7 +190,8 @@ >> connectivity to a particular destination, or in multi-hop processing >> on a device wide basis. A router can request multi-hop reachable >> destination be changed to a single hop. A router can also indicate >> - that the modem terminate connectivity to a particular destination. >> + that the modem terminates a previous direct connectivity request to a >> + particular destination. >> >> >> The Hop Control Data Item MAY be carried in a Session Update Message >> @@ -218,20 +220,19 @@ >> notify the router of each destination that is no longer reachable via >> a Destination Down Message. The modem MUST notify the router of any >> changes in Hop Counts via Destination Update Messages. Note that >> - normal DLEP processing is not otherwise modified by this document, this >> - includes the generation of Destination Down messages. >> + neither Destination Down or Update Message SHOULD NOT be sent for the >> + destination MAC address contained in the Link Characteristics >> + Response Message. >> >> >> A modem that receives the Hop Control Data Item in >> a Session Update Message >> SHOULD attempt to make the change indicated by the data item >> - for the associated destination MAC address, when carried in a Link >> - Characteristics Request Message, or all destinations, when carried in >> - a Session Update Message. Once the change is made, >> - or fails or is rejected, the modem MUST respond with a Link >> Characteristics >> - Request Message containing an updated Hop Count Data Item. Note that >> - other destinations can be impacted as a result of the change and such >> - changes are reported in >> + for all known destinations. 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. Destination specific >> + impact resulting from the processing of a Hop Control Data Item in a >> + Session Update Message is provided via >> Destination Down and Destination Update Messages. The modem MUST >> notify the router of each destination that is no longer reachable via >> a Destination Down Message. The modem MUST notify the router of any >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet From nobody Wed Feb 14 15:27:55 2018 Return-Path: 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 2DC60126CD8; Wed, 14 Feb 2018 15:27:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151865086912.7521.1302513672018061966@ietfa.amsl.com> Date: Wed, 14 Feb 2018 15:27:49 -0800 Archived-At: Subject: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 23:27:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks WG of the IETF. Title : DLEP Latency Range Extension Authors : Bow-Nan Cheng Lou Berger Filename : draft-ietf-manet-dlep-latency-extension-02.txt Pages : 5 Date : 2018-02-14 Abstract: This document defines an extension to the DLEP protocol to provide the range of latency that may be experienced on a link. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-latency-extension/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-manet-dlep-latency-extension-02 https://datatracker.ietf.org/doc/html/draft-ietf-manet-dlep-latency-extension-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-latency-extension-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 14 15:37:01 2018 Return-Path: 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 04A761272E1 for ; Wed, 14 Feb 2018 15:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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] autolearn=ham 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 E5MnBOAbCRvh for ; Wed, 14 Feb 2018 15:36:57 -0800 (PST) Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) (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 51CE9126DFB for ; Wed, 14 Feb 2018 15:36:55 -0800 (PST) Received: from cmgw4 (unknown [10.0.90.85]) by gproxy3.mail.unifiedlayer.com (Postfix) with ESMTP id EAD1D400AD for ; Wed, 14 Feb 2018 16:36:54 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id Ancr1x00F2SSUrH01ncupL; Wed, 14 Feb 2018 16:36:54 -0700 X-Authority-Analysis: v=2.2 cv=G85sK5s5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=Op4juWPpsa0A:10 a=48vgC7mUAAAA:8 a=0ZgzDHaQzhVBHrr1te0A:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 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:Cc:References: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=ZqikaLIhCjtTBDErQ3lGGF99hK3j4JVjEGQEtpEDNVU=; b=Knhh5O3h1xqzgEaF8ggbMYyoNM UGsPUbkgpkzoFvte/0Z2+Q9jlFCsqOIvwjXCUQxkvDCnDQQJ5wMZ5j/xWr5+c/bHpc9a+1K9HkP/T soVlRfh0pn+rHH/HK6CgsF/Up; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:60464 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1em6ba-002h4J-8R; Wed, 14 Feb 2018 16:36:51 -0700 To: manet@ietf.org References: <151865086912.7521.1302513672018061966@ietfa.amsl.com> Cc: draft-ietf-manet-dlep-latency-extension@ietf.org From: Lou Berger Message-ID: Date: Wed, 14 Feb 2018 18:36:47 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <151865086912.7521.1302513672018061966@ietfa.amsl.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: 100.15.86.101 X-Exim-ID: 1em6ba-002h4J-8R X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:60464 X-Source-Auth: lberger@labn.net X-Email-Count: 8 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 23:36:59 -0000 Hi, This version addresses all comments received (to date) during WG LC with one exception.  The one exception was a private question/comment on how to handle latency that may be queue specific.  As this extension is independent of queue definition (which introduced in pause and credit extensions) and the same question applies to other link metrics, it was my opinion that queue specific metrics are beyond the scope of this draft and really warrants a new extension in its own rights.  Given this was raised privately during LC and not specifically addressed in this version, I thought it important to mention  on list. All other comments were discussed on list. See below for a link to see these diffs. Lou On 2/14/2018 6:27 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Mobile Ad-hoc Networks WG of the IETF. > > Title : DLEP Latency Range Extension > Authors : Bow-Nan Cheng > Lou Berger > Filename : draft-ietf-manet-dlep-latency-extension-02.txt > Pages : 5 > Date : 2018-02-14 > > Abstract: > This document defines an extension to the DLEP protocol to provide > the range of latency that may be experienced on a link. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-latency-extension/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-manet-dlep-latency-extension-02 > https://datatracker.ietf.org/doc/html/draft-ietf-manet-dlep-latency-extension-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-latency-extension-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Fri Feb 16 07:09:37 2018 Return-Path: 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 DDE0012D88F; Fri, 16 Feb 2018 07:09:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151879377285.5017.233118525184173608@ietfa.amsl.com> Date: Fri, 16 Feb 2018 07:09:32 -0800 Archived-At: Subject: [manet] I-D Action: draft-ietf-manet-dlep-multi-hop-extension-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 15:09:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks WG of the IETF. Title : DLEP Multi-Hop Forwarding Extension Authors : Bow-Nan Cheng Lou Berger Filename : draft-ietf-manet-dlep-multi-hop-extension-04.txt Pages : 10 Date : 2018-02-16 Abstract: This document defines an extension to the DLEP protocol that enables the reporting and control of Multi-Hop Forwarding by DLEP capable modems. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-multi-hop-extension/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-manet-dlep-multi-hop-extension-04 https://datatracker.ietf.org/doc/html/draft-ietf-manet-dlep-multi-hop-extension-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-multi-hop-extension-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 16 07:14:42 2018 Return-Path: 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 6CB661273B1 for ; Fri, 16 Feb 2018 07:14:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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] autolearn=ham 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 esO_l2Rx-aoz for ; Fri, 16 Feb 2018 07:14:39 -0800 (PST) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (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 053E2120454 for ; Fri, 16 Feb 2018 07:14:38 -0800 (PST) Received: from cmgw3 (unknown [10.0.90.84]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id B2ACC1E06AB for ; Fri, 16 Feb 2018 08:14:38 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id BTEb1x00A2SSUrH01TEesS; Fri, 16 Feb 2018 08:14:38 -0700 X-Authority-Analysis: v=2.2 cv=XM9AcUpE c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=Op4juWPpsa0A:10 a=48vgC7mUAAAA:8 a=RehFWjLUiUovX4E7yc0A:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 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:To:Subject:Sender:Reply-To:Cc: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=+zZ5+RwMnUrSAh7EEH3zH6tLUxdX7/J3XgOG/8Nzfps=; b=DYpFem6Ab/vtrm9GaNfsVGnL2l zTHyxRbhR34g9tVE344zMYMwmc6l6JbgskI8uikW8H7NZLJULQfGnm2NQ2FWZkrY2GX4iDTWOHrxA hNHWaaqI0ngbyVorTgYN8oRLa; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:52548 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1emhic-003xDD-UR; Fri, 16 Feb 2018 08:14:35 -0700 To: "manet-chairs@ietf.org" , manet@ietf.org References: <151879377285.5017.233118525184173608@ietfa.amsl.com> From: Lou Berger Message-ID: <15cbeb3f-aaab-1d40-4ace-75f1326ff63a@labn.net> Date: Fri, 16 Feb 2018 10:14:31 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <151879377285.5017.233118525184173608@ietfa.amsl.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: 100.15.86.101 X-Exim-ID: 1emhic-003xDD-UR X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:52548 X-Source-Auth: lberger@labn.net X-Email-Count: 7 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-multi-hop-extension-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 15:14:40 -0000 Hi,     I thought it would be good to publish this version which captures all LC comments and discussion to date.  Please review (diffs) and let us know if we missed anything or if you still would like to see any additional language changes? Chairs,     What's the next step?  Is LC now closed?  What else would you like to see happen before publication request? Thanks, Lou On 2/16/2018 10:09 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Mobile Ad-hoc Networks WG of the IETF. > > Title : DLEP Multi-Hop Forwarding Extension > Authors : Bow-Nan Cheng > Lou Berger > Filename : draft-ietf-manet-dlep-multi-hop-extension-04.txt > Pages : 10 > Date : 2018-02-16 > > Abstract: > This document defines an extension to the DLEP protocol that enables > the reporting and control of Multi-Hop Forwarding by DLEP capable > modems. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-multi-hop-extension/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-manet-dlep-multi-hop-extension-04 > https://datatracker.ietf.org/doc/html/draft-ietf-manet-dlep-multi-hop-extension-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-multi-hop-extension-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Fri Feb 16 12:28:43 2018 Return-Path: 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 679F912421A; Fri, 16 Feb 2018 12:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no 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 DX53Tc74KHUw; Fri, 16 Feb 2018 12:28:40 -0800 (PST) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA6F1200C1; Fri, 16 Feb 2018 12:28:40 -0800 (PST) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id w1GKSdjW015061; Fri, 16 Feb 2018 15:28:39 -0500 From: "Wiggins, David - 0665 - MITLL" To: Lou Berger , "manet-chairs@ietf.org" , "manet@ietf.org" Thread-Topic: [manet] I-D Action: draft-ietf-manet-dlep-multi-hop-extension-04.txt Thread-Index: AQHTpzhBBHDz7z21eUSkqZjVoXqb3KOndxGAgAAD8IA= Date: Fri, 16 Feb 2018 20:28:38 +0000 Message-ID: <088A520C-39BC-4463-9C43-88B71F7A1DF7@ll.mit.edu> References: <151879377285.5017.233118525184173608@ietfa.amsl.com> <15cbeb3f-aaab-1d40-4ace-75f1326ff63a@labn.net> In-Reply-To: <15cbeb3f-aaab-1d40-4ace-75f1326ff63a@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.118] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3601639717_328010772" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-16_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802160238 Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-multi-hop-extension-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 20:28:42 -0000 --B_3601639717_328010772 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Thanks for updating this, Lou. I had a bit of trouble parsing this: "Note that neither Destination Down or Update Message SHOULD NOT be sent for the destination MAC address contained in the Link Characteristi= cs Response Message." The double negative threw me... maybe just omit "neither"? Otherwise, looks good! David =EF=BB=BFOn 2/16/18, 10:15 AM, "manet on behalf of Lou Berger" wrote: Hi, =20 I thought it would be good to publish this version which captures=20 all LC comments and discussion to date. Please review (diffs) and let=20 us know if we missed anything or if you still would like to see any=20 additional language changes? =20 Chairs, =20 What's the next step? Is LC now closed? What else would you like= =20 to see happen before publication request? =20 Thanks, =20 Lou =20 =20 On 2/16/2018 10:09 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts di= rectories. > This draft is a work item of the Mobile Ad-hoc Networks WG of the IET= F. > > Title : DLEP Multi-Hop Forwarding Extension > Authors : Bow-Nan Cheng > Lou Berger > Filename : draft-ietf-manet-dlep-multi-hop-extension-04.txt > Pages : 10 > Date : 2018-02-16 > > Abstract: > This document defines an extension to the DLEP protocol that enab= les > the reporting and control of Multi-Hop Forwarding by DLEP capable > modems. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-multi-hop-exte= nsion/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-manet-dlep-multi-hop-extension= -04 > https://datatracker.ietf.org/doc/html/draft-ietf-manet-dlep-multi-hop= -extension-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-dlep-multi-hop-ext= ension-04 > > > Please note that it may take a couple of minutes from the time of sub= mission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > =20 _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet =20 --B_3601639717_328010772 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUWQYJKoZIhvcNAQcCoIIUSjCCFEYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EjwwggT1MIID3aADAgECAgplPFVEAAAAAH4VMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTMwHhcNMTYwNDA0MTI0ODMyWhcNMTkwNDA0MTI0ODMyWjBiMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSEwHwYDVQQDExhXaWdnaW5zLkRhdmlkLlAuNTAwMTUyMDcwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDJAb/lYMuBBR+S5pd/D61TZUVFI0iUnE1lDC0JOx9zyPDH inu2X2wN8x3uIO6/2xV9RjnuoORnzTv95Se/rhE7D4AfVZaj/i6oreCoLItIGph0E6Sl3SuA ALy9vHS0G9fCUm72xdOTkc2PqzIHHg8A9uN/pB8OTbktXgQMN/0TLarDF6u2LAswTQ2CxBWJ Hr9u78KA3QOkLWzQeua5aqINaHzYVrih5LTmAxI0B+h6Ug40hEViLRBfjN8jAJg4GF3dr42b GL4oDIS5eKFwSpbUR/jUKWNwoF1eG+jhAWdnUfHo7akVYxajXii9vqLmrsactqPZGu29HnO+ A6aoMM8PAgMBAAGjggG8MIIBuDAdBgNVHQ4EFgQU0xCKedODZWIHRzv1PlQPu4wdGwUwDgYD VR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUH AQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcE MDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAiBgNV HSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMCMGA1UdEQQcMBqBGERhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIE Gh4YAEwATABVAHMAZQByAFMAaQBnAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQB8VMg24SrD vmqbj2l36MyBV02CV/ItcmUxfR8p+oGEGnm1veofenM7m9l3ZR3PHcM8lMQgCUmJrbNvF07G tRkehlflC8nujwv5szRG1lUv8UjYdYr9dFCBnEHGVY/FwQSV7Bz6tVyibQFlqZOnbyTKNmSm phroRbIulo971T4L3a9+2FX8n7PvjqG5Rn4yXNuPqVerQTcZN4pFbbo1lpuOK4wTVKlIvVoW NTfZPTxjbtNwfJYThlFyijTEur3XA1UL6+UoA9230Oz3+qL856RzJKOOBFoxZapor6nzjPDX 1ubAmBcwAlrXWNSzN0euX8wbPiOLSJvQ1LRpZsmJMxtfMIIEvDCCA6SgAwIBAgIBKTANBgkq hkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3Jh dG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRMTCBSb290IENBMB4XDTEzMTIxNzAw MDAwMFoXDTIwMTIzMTIzNTk1OVowUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5j b2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0EtMzCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANowUnVtfLbltbTcRuofAdJKnJBWUAALaBwp L1KVBF+oxbwXfJkCOdxsi2EbgKOB1iaXu/4sxVzn0iQ7OlDOaL7wjn14NmyYA2JQQvSQ3CwR SJ9J6aTrvUb6Y1kosbQuenK8CeVLOUD3bcbSnXpOSyV5dqCsN8PJYoVIsXj28VmndZu2TCim oL5vc08mz+hbpikcXmCY0qQdvnAGI6BhhG0lR8sfLsx5usQKATB8WvG8vsg8/Cc5OrD/YopY D94l0hqAgJocgc75UEOUDTVj/hJqPY8/7pCoWFQf1cHcbaKrjwKp+InwwCGjPXbW9OXMtYFw BUj92f4lJMcgWWVDkX8CAwEAAaOCAZowggGWMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0O BBYEFNdgZg57SY11TA39z0beyMcSh8q/MB8GA1UdIwQYMBaAFGeqes/0Cqa5crWKoNKd8hDD Q+0pMA4GA1UdDwEB/wQEAwIBhjBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6 Ly9jcmwubGwubWl0LmVkdS9nZXR0bz9MTFJDQTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Au bGwubWl0LmVkdS9vY3NwMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVk dS9nZXRjcmw/TExSQ0EwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsqhkiG9xIC AQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMBCjANBgsq hkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG9xICAQMB EDANBgkqhkiG9w0BAQUFAAOCAQEALH/RwZ+9qlO1E4JMWq4wHO4sp4XAxIFsHs2CrXf0ixkk NA4bcyFfy0wsalC4znfh/h06jCVwfPpx584cqkON0bJxmThU+UX8z4feHW/2Sd6pduOA8JSS O8lwQNg5GXBBIDlgvWx3KxJc1OjZ4oGoUluaHVSa4Zh/14UAHDEu+xOR+tsssStVjz4HAYqR lZ7tcUh204h3uw6n1kNrVTC1H9t12ISLmveJCbEHeI0oe9TVQ9HuxeLJwKKkDCPfDMw2Hizp I5cykbO+6/2jLDwCsepzGjr0S+wstD46edYtqhZGxpl/KH54dpHq40070Sf4Ntq9TFfEUdT5 LYzLDTrD3zCCA4MwggJroAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMx HzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNTUlUTEwgUm9vdCBDQTAeFw0wODA5MjMxMjAwMDBaFw0yOTEyMzEyMzU5NTlaMFQxCzAJ BgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQ S0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDFTikXWLImsvmtir9cEAqD3eQJMBMbsHDQ0YWkQnUDdeyvpQgir3/VUkE6ALAOqtWw ArWVHDL+WSsfM+ShuIyvXDONDbxJH/2yDmQByasyoFhtzfTaq3AIYpnF012ECHadQ4I7XQAy lSwI12mKQ9j26RPyWwD56iszhDWtz8vQnoAdGm05Tsi4MF1mP6101vuC/4YqSevrCP2baxUZ rChobsACqGxa9BQz+riH8fkWliXCdUASHYDOGqIb1vCXq4kkjMn/y5RaV02RXDPUjl9H+8Jr GItchbihTJ0G5EpMb56QSjEca4PvfLHkm2xJyJLwdAvagQzy2/5UAL5qVuqDAgMBAAGjYDBe MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFGeqes/0Cqa5crWKoNKd8hDDQ+0pMB8GA1Ud IwQYMBaAFGeqes/0Cqa5crWKoNKd8hDDQ+0pMAsGA1UdDwQEAwIBhjANBgkqhkiG9w0BAQUF AAOCAQEAPhttBWDQeHjYSlhfj8k+Q1Lc5QARZH9iDNlRjVAaL2tBnil9yNTX9Nqg1Pxjth/R E75702Ib34EOFAf+RCJk5Cj2u/01RvzEO0oJgJp3vMRC1Wxixa68rZcvD8mLWbZ4G+g4HhFL /ksBZ83Cztb4Na3ZrLN5MLKstKvHtlWAGPM06bRM8iRt+ml3CDG6jsVkvy2z4zbj3YCXzt3d Vqx69RLWmmtEES6kKGY9O3WGO1qORA6lPgFADM/WVURitbOW/47+Vs/2K6MqlhZx9ipDcUZ/ ftgK+4N656zjGb6eqbKto2w14jwaHdcMjCp/MecuHLhjzRXKo38mPx1/dIr0ADCCBPgwggPg oAMCAQICCmVBPb8AAAAAfhkwDQYJKoZIhvcNAQELBQAwUTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlU TEwgQ0EtMzAeFw0xNjA0MDQxMjUzNTdaFw0xOTA0MDQxMjUzNTdaMGIxCzAJBgNVBAYTAlVT MR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQZW9wbGUxITAf BgNVBAMTGFdpZ2dpbnMuRGF2aWQuUC41MDAxNTIwNzCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALxLr6lj3p6xTBv4hIMClz+oodyhI36yILLxw3lpNWMLMRgicN0xp5qE/TYq eA9JovmLQKXi5zy2NoOHo5I4xT7rgctVStlMoub/Cu+yU4AbQFY/TPUoeTcnPE8sSIdaZ8ya ZrRpzRMbZe4U6tbqhRMfoIZ8wwVoddo13wFhTd3tuKnBN/3KSowHy5rlBNmPz4rl6kjbr+l+ bLwqwnDu0LkgLXIe0s+pS+VhMpAegi4Glt7VBblvpk8gkZ2WLLb6F2V5Osdrk5auCLOwziIe TkysfpH/OJ8fwXw9spgHH8xvSzxv09mcLe+c6RyAcfCclemgVAwm5BioBvEdyFImbK8CAwEA AaOCAb8wggG7MB0GA1UdDgQWBBTK35v8BBqQXPD5Ewd/My8jOgtQ1TAOBgNVHQ8BAf8EBAMC BSAwHwYDVR0jBBgwFoAU12BmDntJjXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYi aHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYI KwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcw AYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQB gjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD6+0gAgFkAgEFMCUGA1UdJQQeMBwGBFUd JQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwIwYD VR0RBBwwGoEYRGF2aWQuV2lnZ2luc0BsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAE0UyFocglrX8UuUfV+S 6s4dgmpdkLuTDkrcdrhVY2X0jQZpqoL0sS6HrgFMto92VizlP0TRlmkcuONlX7KhJaP9/HCr yrylnV/fJ+ZbCGIaT6DOiQZNCYrjTpPgolXfNYjLwOwOev8l3ORSU7Oj7/R4RTVPDlUg+2KS RyVh/AumAw1dHwffTMtuAYXo5GtDKWzO9i1Q/QDRksiBhUtf1LoXLDskwf5hatrLav1AVIR2 BtD0pIi2NWsT2+zWFO5qkzqh81aVhHxRAs2Fry80eiH/pMkLvo6rR/4OdqsGFyvPxOgq33c0 wKHMaERy/bxTVLUD166IUvJIfE55/PwFTYIxggHlMIIB4QIBATBfMFExCzAJBgNVBAYTAlVT MR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMCCmU8VUQAAAAAfhUwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEW BBTLCFQCz62X5M33p4QEHyAiLbZR3zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xODAyMTYyMDI4MzdaMA0GCSqGSIb3DQEBAQUABIIBAC6/3ZQa/D4sgovs w1iD0y3DYso1LP6+5TR2mkdfSwV38hmBICL/RsslxI0TLB489TK+GTEo0hMKo8NrDfOww6KR TN/QxTEqe4ZBB+WakDwZZbeHnmrn+MefG0zckHYfWQxqlrqWX0xEF3D+YB49kVJGMRUWlXNA cCVpP2y+ym8J8M0VYp7xgcFu87wwUCN+nF2onJ70AWIixR7eJmdvA/VgnBpOlSvKU1nzhxrI MyoELqArHc6x6NPVfvoO4oL7jJif3OyEi6Zs47W8ZFYYUa07DsQEUqD6JnCT9W5FBmuZA9Z+ IsXsOEL0CgGohsBWB3dkEL2A/EL6A/a9UCXZBJs= --B_3601639717_328010772-- From nobody Fri Feb 16 13:25:30 2018 Return-Path: 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 75AD712D7F4 for ; Fri, 16 Feb 2018 13:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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] 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 BgI2BlwspXDO for ; Fri, 16 Feb 2018 13:25:26 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (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 386D912D7F2 for ; Fri, 16 Feb 2018 13:25:26 -0800 (PST) Received: from cmgw2 (unknown [10.0.90.83]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id BBC6E215C46 for ; Fri, 16 Feb 2018 14:25:25 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id BZRM1x0182SSUrH01ZRQyK; Fri, 16 Feb 2018 14:25:25 -0700 X-Authority-Analysis: v=2.2 cv=TIA1cxta c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=Op4juWPpsa0A:10 a=48vgC7mUAAAA:8 a=wU2YTnxGAAAA:8 a=VpDdPTD9l8iJGbbfA2QA:9 a=3a8Hwki-kzLe2jNo:21 a=KJ9oR16fEl-ZH3ez:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=Yz9wTY_ffGCQnEDHKrcv:22 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:To:Subject:Sender:Reply-To:Cc: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=LrUK2/wuUZuKSk3asXiIflf36+jc6QWEOGp8Pc2LOrk=; b=WAiMXfE/4F5uLHE2ME8Or9EDID yqTagN2BXLS3gxZgS2HfD4hxXZBxOhzcavvf5RQUfCVECLELsdxsS7beXWeY/2Qt33h+cpPpjCUtk hUgLDyJis60J1LRX+cuaJPaK9; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:52854 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1emnVR-001pMM-Pz; Fri, 16 Feb 2018 14:25:21 -0700 To: "Wiggins, David - 0665 - MITLL" , "manet-chairs@ietf.org" , "manet@ietf.org" References: <151879377285.5017.233118525184173608@ietfa.amsl.com> <15cbeb3f-aaab-1d40-4ace-75f1326ff63a@labn.net> <088A520C-39BC-4463-9C43-88B71F7A1DF7@ll.mit.edu> From: Lou Berger Message-ID: Date: Fri, 16 Feb 2018 16:25:19 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <088A520C-39BC-4463-9C43-88B71F7A1DF7@ll.mit.edu> 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: 100.15.86.101 X-Exim-ID: 1emnVR-001pMM-Pz X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:52854 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-multi-hop-extension-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 21:25:29 -0000 Hi David, On 2/16/2018 3:28 PM, Wiggins, David - 0665 - MITLL wrote: > Thanks for updating this, Lou. > > I had a bit of trouble parsing this: > "Note that neither Destination Down or Update Message SHOULD NOT > be sent for the destination MAC address contained in the Link Characteristics > Response Message." Fair enough - it is hard to parse. How about OLD:   ....  Note that other destinations can be   impacted as a result of the change and such changes are reported in   Destination Down and Destination Update Messages.  The modem MUST   notify the router of each destination that is no longer reachable via   a Destination Down Message. The modem MUST notify the router of any   changes in Hop Counts via Destination Update Messages.  Note that   neither Destination Down or Update Message SHOULD NOT be sent for the   destination MAC address contained in the Link Characteristics   Response Message. NEW:   ...Note that other destinations can be   impacted as a result of the change and such changes are reported in   Destination Down and Destination Update Messages.  The modem MUST   notify the router of each destination that is *not identified in the   Link Characteristics Response Message and* is no longer reachable via a   Destination Down Message.  The modem MUST *also* notify the router of   *each destination that is not identified in the Link Characteristics   Response Message and has a changed Hop Count impacted via a   Destination Update Message*. Changes are flagged with asterisks. Does this work? Lou > The double negative threw me... maybe just omit "neither"? > > Otherwise, looks good! > > David > > On 2/16/18, 10:15 AM, "manet on behalf of Lou Berger" wrote: > > Hi, > > I thought it would be good to publish this version which captures > all LC comments and discussion to date. Please review (diffs) and let > us know if we missed anything or if you still would like to see any > additional language changes? > > Chairs, > > What's the next step? Is LC now closed? What else would you like > to see happen before publication request? > > Thanks, > > Lou > > > On 2/16/2018 10:09 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Mobile Ad-hoc Networks WG of the IETF. > > > > Title : DLEP Multi-Hop Forwarding Extension > > Authors : Bow-Nan Cheng > > Lou Berger > > Filename : draft-ietf-manet-dlep-multi-hop-extension-04.txt > > Pages : 10 > > Date : 2018-02-16 > > > > Abstract: > > This document defines an extension to the DLEP protocol that enables > > the reporting and control of Multi-Hop Forwarding by DLEP capable > > modems. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-multi-hop-extension/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-manet-dlep-multi-hop-extension-04 > > https://datatracker.ietf.org/doc/html/draft-ietf-manet-dlep-multi-hop-extension-04 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-multi-hop-extension-04 > > > > > > Please note that it may take a couple of minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Fri Feb 16 13:34:55 2018 Return-Path: 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 09DD112D7F8; Fri, 16 Feb 2018 13:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no 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 rXJ5g1DuLemP; Fri, 16 Feb 2018 13:34:50 -0800 (PST) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id EB5D3124207; Fri, 16 Feb 2018 13:34:49 -0800 (PST) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id w1GLYmRj003404; Fri, 16 Feb 2018 16:34:48 -0500 From: "Wiggins, David - 0665 - MITLL" To: Lou Berger , "manet-chairs@ietf.org" , "manet@ietf.org" Thread-Topic: [manet] I-D Action: draft-ietf-manet-dlep-multi-hop-extension-04.txt Thread-Index: AQHTpzhBBHDz7z21eUSkqZjVoXqb3KOndxGAgAAD8ICAAGOqgP//rtOA Date: Fri, 16 Feb 2018 21:34:47 +0000 Message-ID: <8B2FB185-4DEC-4C28-81D9-DB05A5139B81@ll.mit.edu> References: <151879377285.5017.233118525184173608@ietfa.amsl.com> <15cbeb3f-aaab-1d40-4ace-75f1326ff63a@labn.net> <088A520C-39BC-4463-9C43-88B71F7A1DF7@ll.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.118] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3601643687_772145824" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-16_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802160252 Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-multi-hop-extension-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 21:34:53 -0000 --B_3601643687_772145824 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Yes, that's clearer to me. Thanks! David =EF=BB=BFOn 2/16/18, 4:26 PM, "Lou Berger" wrote: Hi David, =20 On 2/16/2018 3:28 PM, Wiggins, David - 0665 - MITLL wrote: > Thanks for updating this, Lou. > > I had a bit of trouble parsing this: > "Note that neither Destination Down or Update Message SHOULD NOT > be sent for the destination MAC address contained in the Link Charact= eristics > Response Message." Fair enough - it is hard to parse. How about OLD: .... Note that other destinations can be impacted as a result of the change and such changes are reported in Destination Down and Destination Update Messages. The modem MUST notify the router of each destination that is no longer reachable vi= a a Destination Down Message. The modem MUST notify the router of any changes in Hop Counts via Destination Update Messages. Note that neither Destination Down or Update Message SHOULD NOT be sent for th= e destination MAC address contained in the Link Characteristics Response Message. =20 NEW: ...Note that other destinations can be impacted as a result of the change and such changes are reported in Destination Down and Destination Update Messages. The modem MUST notify the router of each destination that is *not identified in the Link Characteristics Response Message and* is no longer reachable vi= a a Destination Down Message. The modem MUST *also* notify the router o= f *each destination that is not identified in the Link Characteristics Response Message and has a changed Hop Count impacted via a Destination Update Message*. =20 Changes are flagged with asterisks. =20 Does this work? Lou =20 =20 > The double negative threw me... maybe just omit "neither"? > > Otherwise, looks good! > > David > > On 2/16/18, 10:15 AM, "manet on behalf of Lou Berger" wrote: > > Hi, > =20 > I thought it would be good to publish this version which ca= ptures > all LC comments and discussion to date. Please review (diffs) a= nd let > us know if we missed anything or if you still would like to see = any > additional language changes? > =20 > Chairs, > =20 > What's the next step? Is LC now closed? What else would y= ou like > to see happen before publication request? > =20 > Thanks, > =20 > Lou > =20 > =20 > On 2/16/2018 10:09 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Dr= afts directories. > > This draft is a work item of the Mobile Ad-hoc Networks WG of = the IETF. > > > > Title : DLEP Multi-Hop Forwarding Extension > > Authors : Bow-Nan Cheng > > Lou Berger > > Filename : draft-ietf-manet-dlep-multi-hop-extension-0= 4.txt > > Pages : 10 > > Date : 2018-02-16 > > > > Abstract: > > This document defines an extension to the DLEP protocol th= at enables > > the reporting and control of Multi-Hop Forwarding by DLEP = capable > > modems. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-multi-h= op-extension/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-manet-dlep-multi-hop-ex= tension-04 > > https://datatracker.ietf.org/doc/html/draft-ietf-manet-dlep-mu= lti-hop-extension-04 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-dlep-multi-= hop-extension-04 > > > > > > Please note that it may take a couple of minutes from the time= of submission > > until the htmlized version and diff are available at tools.iet= f.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > =20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > =20 =20 =20 --B_3601643687_772145824 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUWQYJKoZIhvcNAQcCoIIUSjCCFEYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EjwwggT1MIID3aADAgECAgplPFVEAAAAAH4VMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTMwHhcNMTYwNDA0MTI0ODMyWhcNMTkwNDA0MTI0ODMyWjBiMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSEwHwYDVQQDExhXaWdnaW5zLkRhdmlkLlAuNTAwMTUyMDcwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDJAb/lYMuBBR+S5pd/D61TZUVFI0iUnE1lDC0JOx9zyPDH inu2X2wN8x3uIO6/2xV9RjnuoORnzTv95Se/rhE7D4AfVZaj/i6oreCoLItIGph0E6Sl3SuA ALy9vHS0G9fCUm72xdOTkc2PqzIHHg8A9uN/pB8OTbktXgQMN/0TLarDF6u2LAswTQ2CxBWJ Hr9u78KA3QOkLWzQeua5aqINaHzYVrih5LTmAxI0B+h6Ug40hEViLRBfjN8jAJg4GF3dr42b GL4oDIS5eKFwSpbUR/jUKWNwoF1eG+jhAWdnUfHo7akVYxajXii9vqLmrsactqPZGu29HnO+ A6aoMM8PAgMBAAGjggG8MIIBuDAdBgNVHQ4EFgQU0xCKedODZWIHRzv1PlQPu4wdGwUwDgYD VR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUH AQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcE MDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAiBgNV HSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMCMGA1UdEQQcMBqBGERhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIE Gh4YAEwATABVAHMAZQByAFMAaQBnAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQB8VMg24SrD vmqbj2l36MyBV02CV/ItcmUxfR8p+oGEGnm1veofenM7m9l3ZR3PHcM8lMQgCUmJrbNvF07G tRkehlflC8nujwv5szRG1lUv8UjYdYr9dFCBnEHGVY/FwQSV7Bz6tVyibQFlqZOnbyTKNmSm phroRbIulo971T4L3a9+2FX8n7PvjqG5Rn4yXNuPqVerQTcZN4pFbbo1lpuOK4wTVKlIvVoW NTfZPTxjbtNwfJYThlFyijTEur3XA1UL6+UoA9230Oz3+qL856RzJKOOBFoxZapor6nzjPDX 1ubAmBcwAlrXWNSzN0euX8wbPiOLSJvQ1LRpZsmJMxtfMIIEvDCCA6SgAwIBAgIBKTANBgkq hkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3Jh dG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRMTCBSb290IENBMB4XDTEzMTIxNzAw MDAwMFoXDTIwMTIzMTIzNTk1OVowUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5j b2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0EtMzCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANowUnVtfLbltbTcRuofAdJKnJBWUAALaBwp L1KVBF+oxbwXfJkCOdxsi2EbgKOB1iaXu/4sxVzn0iQ7OlDOaL7wjn14NmyYA2JQQvSQ3CwR SJ9J6aTrvUb6Y1kosbQuenK8CeVLOUD3bcbSnXpOSyV5dqCsN8PJYoVIsXj28VmndZu2TCim oL5vc08mz+hbpikcXmCY0qQdvnAGI6BhhG0lR8sfLsx5usQKATB8WvG8vsg8/Cc5OrD/YopY D94l0hqAgJocgc75UEOUDTVj/hJqPY8/7pCoWFQf1cHcbaKrjwKp+InwwCGjPXbW9OXMtYFw BUj92f4lJMcgWWVDkX8CAwEAAaOCAZowggGWMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0O BBYEFNdgZg57SY11TA39z0beyMcSh8q/MB8GA1UdIwQYMBaAFGeqes/0Cqa5crWKoNKd8hDD Q+0pMA4GA1UdDwEB/wQEAwIBhjBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6 Ly9jcmwubGwubWl0LmVkdS9nZXR0bz9MTFJDQTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Au bGwubWl0LmVkdS9vY3NwMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVk dS9nZXRjcmw/TExSQ0EwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsqhkiG9xIC AQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMBCjANBgsq hkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG9xICAQMB EDANBgkqhkiG9w0BAQUFAAOCAQEALH/RwZ+9qlO1E4JMWq4wHO4sp4XAxIFsHs2CrXf0ixkk NA4bcyFfy0wsalC4znfh/h06jCVwfPpx584cqkON0bJxmThU+UX8z4feHW/2Sd6pduOA8JSS O8lwQNg5GXBBIDlgvWx3KxJc1OjZ4oGoUluaHVSa4Zh/14UAHDEu+xOR+tsssStVjz4HAYqR lZ7tcUh204h3uw6n1kNrVTC1H9t12ISLmveJCbEHeI0oe9TVQ9HuxeLJwKKkDCPfDMw2Hizp I5cykbO+6/2jLDwCsepzGjr0S+wstD46edYtqhZGxpl/KH54dpHq40070Sf4Ntq9TFfEUdT5 LYzLDTrD3zCCA4MwggJroAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMx HzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNTUlUTEwgUm9vdCBDQTAeFw0wODA5MjMxMjAwMDBaFw0yOTEyMzEyMzU5NTlaMFQxCzAJ BgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQ S0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDFTikXWLImsvmtir9cEAqD3eQJMBMbsHDQ0YWkQnUDdeyvpQgir3/VUkE6ALAOqtWw ArWVHDL+WSsfM+ShuIyvXDONDbxJH/2yDmQByasyoFhtzfTaq3AIYpnF012ECHadQ4I7XQAy lSwI12mKQ9j26RPyWwD56iszhDWtz8vQnoAdGm05Tsi4MF1mP6101vuC/4YqSevrCP2baxUZ rChobsACqGxa9BQz+riH8fkWliXCdUASHYDOGqIb1vCXq4kkjMn/y5RaV02RXDPUjl9H+8Jr GItchbihTJ0G5EpMb56QSjEca4PvfLHkm2xJyJLwdAvagQzy2/5UAL5qVuqDAgMBAAGjYDBe MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFGeqes/0Cqa5crWKoNKd8hDDQ+0pMB8GA1Ud IwQYMBaAFGeqes/0Cqa5crWKoNKd8hDDQ+0pMAsGA1UdDwQEAwIBhjANBgkqhkiG9w0BAQUF AAOCAQEAPhttBWDQeHjYSlhfj8k+Q1Lc5QARZH9iDNlRjVAaL2tBnil9yNTX9Nqg1Pxjth/R E75702Ib34EOFAf+RCJk5Cj2u/01RvzEO0oJgJp3vMRC1Wxixa68rZcvD8mLWbZ4G+g4HhFL /ksBZ83Cztb4Na3ZrLN5MLKstKvHtlWAGPM06bRM8iRt+ml3CDG6jsVkvy2z4zbj3YCXzt3d Vqx69RLWmmtEES6kKGY9O3WGO1qORA6lPgFADM/WVURitbOW/47+Vs/2K6MqlhZx9ipDcUZ/ ftgK+4N656zjGb6eqbKto2w14jwaHdcMjCp/MecuHLhjzRXKo38mPx1/dIr0ADCCBPgwggPg oAMCAQICCmVBPb8AAAAAfhkwDQYJKoZIhvcNAQELBQAwUTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlU TEwgQ0EtMzAeFw0xNjA0MDQxMjUzNTdaFw0xOTA0MDQxMjUzNTdaMGIxCzAJBgNVBAYTAlVT MR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQZW9wbGUxITAf BgNVBAMTGFdpZ2dpbnMuRGF2aWQuUC41MDAxNTIwNzCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALxLr6lj3p6xTBv4hIMClz+oodyhI36yILLxw3lpNWMLMRgicN0xp5qE/TYq eA9JovmLQKXi5zy2NoOHo5I4xT7rgctVStlMoub/Cu+yU4AbQFY/TPUoeTcnPE8sSIdaZ8ya ZrRpzRMbZe4U6tbqhRMfoIZ8wwVoddo13wFhTd3tuKnBN/3KSowHy5rlBNmPz4rl6kjbr+l+ bLwqwnDu0LkgLXIe0s+pS+VhMpAegi4Glt7VBblvpk8gkZ2WLLb6F2V5Osdrk5auCLOwziIe TkysfpH/OJ8fwXw9spgHH8xvSzxv09mcLe+c6RyAcfCclemgVAwm5BioBvEdyFImbK8CAwEA AaOCAb8wggG7MB0GA1UdDgQWBBTK35v8BBqQXPD5Ewd/My8jOgtQ1TAOBgNVHQ8BAf8EBAMC BSAwHwYDVR0jBBgwFoAU12BmDntJjXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYi aHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYI KwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcw AYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQB gjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD6+0gAgFkAgEFMCUGA1UdJQQeMBwGBFUd JQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwIwYD VR0RBBwwGoEYRGF2aWQuV2lnZ2luc0BsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAE0UyFocglrX8UuUfV+S 6s4dgmpdkLuTDkrcdrhVY2X0jQZpqoL0sS6HrgFMto92VizlP0TRlmkcuONlX7KhJaP9/HCr yrylnV/fJ+ZbCGIaT6DOiQZNCYrjTpPgolXfNYjLwOwOev8l3ORSU7Oj7/R4RTVPDlUg+2KS RyVh/AumAw1dHwffTMtuAYXo5GtDKWzO9i1Q/QDRksiBhUtf1LoXLDskwf5hatrLav1AVIR2 BtD0pIi2NWsT2+zWFO5qkzqh81aVhHxRAs2Fry80eiH/pMkLvo6rR/4OdqsGFyvPxOgq33c0 wKHMaERy/bxTVLUD166IUvJIfE55/PwFTYIxggHlMIIB4QIBATBfMFExCzAJBgNVBAYTAlVT MR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMCCmU8VUQAAAAAfhUwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEW BBQqd84OvltLAA+B4xPwGYLRFRNUXTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xODAyMTYyMTM0NDdaMA0GCSqGSIb3DQEBAQUABIIBAHBBf+fl4osJ2etN sCN0AXY7gNOOmEoy7YlgoWauf1oa/MGzAshMzDNeaH+4uwEuBw9SVDzIAuQvv1t9b3IIwqQ5 WfOAVFFSPOFHkUDZSMppV1tCCc88uIgmKSLlGDHPQ1pFyicYP4rJTEKxIun5HKYm0p/GwOks /lewd2ZEhcd4d1swUZeeFKBxgBtt1s8zVZq71Xx6f3OXosDrCujLkqekFCFQKzyjIgDFW3vA upP5mMCR+guI+e7v/7heIy74RN8xfd0oXtFQxpUoj37EcKSu2JC5alLWo/jvU+/F2EqFG4Pk wm9nyup60ZXNMJdfbLrYkq+pWIeTRglP/N5Jb2A= --B_3601643687_772145824-- From nobody Sun Feb 18 15:23:54 2018 Return-Path: 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 06F4C126E64; Sun, 18 Feb 2018 15:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 SXDQc_Xpx6Tt; Sun, 18 Feb 2018 15:23:51 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94E56126BF7; Sun, 18 Feb 2018 15:23:51 -0800 (PST) Received: by mail-oi0-x22b.google.com with SMTP id l124so5984079oib.0; Sun, 18 Feb 2018 15:23:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8DqTAWMzu3D83Tsy7X/Lde4ELFTvZ4SwdUboOSAhK8w=; b=IjNrqMFPKfFGRQNfdUyoGpZYT0wYUCH6A3WDfCf2uuv0HW7V5PpHlsAJc/SnH7jPdC 6wLGTCqCzgoCOGYEXzlhdKNOMgxVOuZW1qWdSihCZwHLlWox9ANaZ/Jqw1LwtYE9+MWX THc1Gx36L3kNh+jogMZNxnbRj7QfwGsMWiuWGe9tLBqAd9ecL+XzZ1WCVCrteM05t7Nf V4QuX0TjZlzxm2PiXakWKXGhlh7HNE3u9ll/w6Yd5yxUKmEJY/5vxDmtrVKGza+65TCc A9iFoN0ttaU5GWLQTgxZzvrdlYS2CIBl0amNbgzZo7H7QfLpf78jeZlAhbSc2XbH4V7S X9OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8DqTAWMzu3D83Tsy7X/Lde4ELFTvZ4SwdUboOSAhK8w=; b=WUkjXhyLiDlJuSuSOxB3hHgpCNMVLr44S/Faslau2chzWlIX91gdWAiA3yXvm6S2y7 WebplAkS7T7y7VHKr8y53OL1U0jHXcCi0GvR7NMBnp2W0XVKik3fxpmDSIjrqrYPYuzW NDp8Kki/2uQlZ6aYCKtZ/595YxYhZwTrvK9p5qKGc2bxyVIJIVHKnTxGth3n6et7Yx+m f6X49D7HDsr//JEO27jnmre09uo4RWqYi3Hnm6msVQMqEj9Kf/8javcedZjYRYIu1nH+ vG8TcuDmX5h/gtY8Q7AomXFYLeWOuRD4PvmlZl7ozdTy7Vfv45cJNHtrbAdnbo8VWSsM 6QWw== X-Gm-Message-State: APf1xPBM+Z4gew2RuzKiHrjc8ZkdY273FoaQ6wRTA8NmOKNQ5RaIsbbB H/ebWywwQxVoRIzQcw7/xKSYzm1c6Biiet6rlZwgZg== X-Google-Smtp-Source: AH8x225lZL8L4ltgOn7rTxfOjsAAVz/kjJV17WTNSzSUfok710V/aWg7e4cBbcJQ4mMmC+Hj/2V3ylZ7LSYSd3H6GoU= X-Received: by 10.202.205.66 with SMTP id d63mr3944899oig.226.1518996230940; Sun, 18 Feb 2018 15:23:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.44 with HTTP; Sun, 18 Feb 2018 15:23:50 -0800 (PST) In-Reply-To: References: <151865086912.7521.1302513672018061966@ietfa.amsl.com> From: Abdussalam Baryun Date: Mon, 19 Feb 2018 01:23:50 +0200 Message-ID: To: Lou Berger Cc: manet , draft-ietf-manet-dlep-latency-extension@ietf.org Content-Type: multipart/alternative; boundary="001a1134f8eec2aede056584de6d" Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 23:23:54 -0000 --001a1134f8eec2aede056584de6d Content-Type: text/plain; charset="UTF-8" Hi Lou, Thanks for your updates. I am sorry that I did not comment on the draft before, however, this is my thought, in section 3: draft>The Latency Range Data Item serves much the same purpose as the Latency Data Item defined in [RFC8175 ] with the addition of being able to communicate the latency range that may be experienced by traffic on a link. AB> IMO, or understanding, latency range is not one value, but two values, so how can two values be same in the purpose of one value of latency? maybe the draft should discuss that for clarification, because I did not understand. AB> this draft does not say what will happen to the data item latency of RFC8175 (type code 16), because in RFC8175 says such messages MUST contain one value of .... and states the latency item, not the latency-range. Some sections after 12.6 does not mention the dlep support of such extension what will happen, so IMO this darft should say how the replacement of Latency item, AB> as this draft may need to say that if the extension is supported then latency range item replaces the latency item, or it may say that the maximum latency value is used into the latency item value. Not sure which approach is better. AB> My problem in understanding the draft, is that if this draft is supported as mentioned in section-12.6 in the RFC8175 then it MUST be contained in that message. So this needs to be said again I think in this draft (because the draft now says: MAY be carry). draft> The Latency Range Data Item MAY be carried in the same messages and MUST be processed according to the same rules as the Latency Data Item defined in [RFC8175 ]. AB> same rules, but we have two values, one max-latency and one min-latency, please clarify, AB> as mentioned above ''same rules as latency'' but what will happen to this latency item while it is a MUST in many messages, what will be the value, but Latency range is a MAY. AB> so I may suggest the value of the range for the draft's item and that the latecy iten in rfc8175 contains the max-latency, or any you suggest to clarify it. AB> furthermore, the RFC8175 mentions change in metrics what kind of reaction, so within this draft cases, if the latency was the metric what value will be used (max, avg, min,...) may need to be specified in the draft. Best Regards AB On Thu, Feb 15, 2018 at 1:36 AM, Lou Berger wrote: > Hi, > > This version addresses all comments received (to date) during WG LC with > one exception. The one exception was a private question/comment on how to > handle latency that may be queue specific. As this extension is > independent of queue definition (which introduced in pause and credit > extensions) and the same question applies to other link metrics, it was my > opinion that queue specific metrics are beyond the scope of this draft and > really warrants a new extension in its own rights. Given this was raised > privately during LC and not specifically addressed in this version, I > thought it important to mention on list. > > All other comments were discussed on list. See below for a link to see > these diffs. > > Lou > > > On 2/14/2018 6:27 PM, internet-drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Mobile Ad-hoc Networks WG of the IETF. >> >> Title : DLEP Latency Range Extension >> Authors : Bow-Nan Cheng >> Lou Berger >> Filename : draft-ietf-manet-dlep-latency-extension-02.txt >> Pages : 5 >> Date : 2018-02-14 >> >> Abstract: >> This document defines an extension to the DLEP protocol to provide >> the range of latency that may be experienced on a link. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-latency-extension/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-manet-dlep-latency-extension-02 >> https://datatracker.ietf.org/doc/html/draft-ietf-manet-dlep- >> latency-extension-02 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-late >> ncy-extension-02 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --001a1134f8eec2aede056584de6d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Lou,

Thanks for your upda= tes. I am sorry that I did not comment on the draft before, however, this i= s my thought,

in section 3:

=C2=A0draft>The Latency Range Data Item serves much the same purpose = as the
=C2=A0=C2=A0 Latency Data Item defined in [RFC8175] with the addition of= being
=C2=A0=C2=A0 able to communicate the latency range that may be ex= perienced by
=C2=A0=C2=A0 traffic on a link.=C2=A0

<= div>AB> IMO, or understanding, =C2=A0latency range is not one value, but= two values, so how can two values be same in the purpose of one value of l= atency? maybe the draft should discuss that for clarification, because I di= d not understand.


AB> this draft= does not say what will happen to the data item latency of RFC8175 (type co= de 16), because in RFC8175 says=C2=A0such messages=C2=A0MUST contain one va= lue of .... and states the latency item, not the latency-range. Some sectio= ns after 12.6 does not mention the dlep=C2=A0support of such extension what= will happen, so IMO this darft should say how the replacement of Latency i= tem,

AB> as this draft may need to say=C2=A0tha= t if the extension is supported then latency range item replaces the latenc= y item, or it may say that the maximum latency value is used into the laten= cy item value. Not sure which approach is better.

= AB> =C2=A0My problem in understanding the draft, is that if this draft i= s supported as mentioned in section-12.6 in the RFC8175 then it MUST be con= tained=C2=A0in that message. So this needs to be said again=C2=A0I think in= this draft (because the draft now says: MAY be carry).

draft> =C2=A0The Latency Range Data Item MAY be carried in the
= =C2=A0=C2=A0 same messages and MUST be processed according to the same rule= s as
=C2=A0=C2=A0 the Latency Data Item defined in [RFC8175].

AB> same rules, but we have two values, one max-latency and one = min-latency, please clarify,

AB> as mentioned a= bove ''same rules as latency'' but what will happen to this= latency item while it is a MUST in many messages, what will be the value, = but Latency range is a MAY.

AB> so=C2=A0I may s= uggest the value of the range for the draft's item and that the latecy = iten in rfc8175 contains the max-latency, or any you suggest to clarify it.=

AB> furthermore, the RFC8175 ment= ions change in metrics what kind of reaction, so within this draft cases, i= f the latency was the metric what value will be used (max, avg, min,...) ma= y need to be specified in the draft.


Best Regards
AB



On Thu, Feb 15, 2018 at 1:36 AM, Lou Berger <lberger@labn.net>= ; wrote:
Hi,

This version addresses all comments received (to date) during WG LC with on= e exception.=C2=A0 The one exception was a private question/comment on how = to handle latency that may be queue specific.=C2=A0 As this extension is in= dependent of queue definition (which introduced in pause and credit extensi= ons) and the same question applies to other link metrics, it was my opinion= that queue specific metrics are beyond the scope of this draft and really = warrants a new extension in its own rights.=C2=A0 Given this was raised pri= vately during LC and not specifically addressed in this version, I thought = it important to mention=C2=A0 on list.

All other comments were discussed on list. See below for a link to see thes= e diffs.

Lou


On 2/14/2018 6:27 PM, internet-drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Mobile Ad-hoc Networks WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: DLEP Latency Range Extension
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : Bow-Nan Cheng
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Lou Berger
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-manet-dlep-latency-extension-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 5
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-02-14

Abstract:
=C2=A0 =C2=A0 This document defines an extension to the DLEP protocol to pr= ovide
=C2=A0 =C2=A0 the range of latency that may be experienced on a link.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.or= g/doc/draft-ietf-manet-dlep-latency-extension/

There are also htmlized versions available at:
https://tools.ietf.org/html/dr= aft-ietf-manet-dlep-latency-extension-02
https://datatracker.= ietf.org/doc/html/draft-ietf-manet-dlep-latency-extension-02<= br>
A diff from the previous version is available at:
https://www.ietf.org/r= fcdiff?url2=3Ddraft-ietf-manet-dlep-latency-extension-02


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--001a1134f8eec2aede056584de6d-- From nobody Mon Feb 19 03:45:01 2018 Return-Path: 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 7D3AD126DEE; Mon, 19 Feb 2018 03:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 DlWA6Ie6hJjG; Mon, 19 Feb 2018 03:44:57 -0800 (PST) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 220D6127522; Mon, 19 Feb 2018 03:44:57 -0800 (PST) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Mon, 19 Feb 2018 11:44:50 +0000 From: Rick Taylor To: "abdussalambaryun@gmail.com" , "lberger@labn.net" CC: "manet@ietf.org" , "draft-ietf-manet-dlep-latency-extension@ietf.org" Thread-Topic: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt Thread-Index: AQHTpeuLyTOgGDggRE6oXD83soFJ16OkjYSAgAZFtQCAAM8CgA== Date: Mon, 19 Feb 2018 11:44:45 +0000 Message-ID: <1519040685.4538.10.camel@tropicalstormsoftware.com> References: <151865086912.7521.1302513672018061966@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: <9a5f2c39-86b1-4711-8e18-e4a1e83599ba> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 11:44:59 -0000 SGkgTG91LA0KDQpBQiByYWlzZXMgYSBnb29kIHBvaW50IGFib3V0IGJlaGF2aW91ciB3aGVuIG9u ZSBwZWVyIGRvZXMgbm90IHN1cHBvcnQNCnRoZSBleHRlbnNpb24uDQoNCkluIHRoZSBMSUQgZXh0 ZW5zaW9uIGRyYWZ0LCBJIGhhdmUgdHJpZWQgdG8gYWRkIG5vcm1hdGl2ZSB0ZXh0IHRoYXQNCmRl c2NyaWJlcyBob3cgYW4gaW1wbGVtZW50YXRpb24gc3VwcG9ydHMgY29yZSBETEVQIHdoZW4gaXQg ZG9lcyBsYXllci0zIA0Kcm91dGluZy4gIEkgdGhpbmsgYSBxdWljayBzZW50ZW5jZSBkZXNjcmli aW5nIGhvdyB0aGUgY29yZSBMYXRlbmN5DQptZXRyaWMgc2hvdWxkIGJlIHVzZWQgd2hlbiB0aGlz IGV4dGVuc2lvbiBpcyBpbiB1c2UsIGFuZCBub3QgaW4gdXNlDQptaWdodCBiZSBiZW5lZmljaWFs Lg0KDQpDaGVlcnMsDQoNClJpY2sNCg0KT24gTW9uLCAyMDE4LTAyLTE5IGF0IDAxOjIzICswMjAw LCBBYmR1c3NhbGFtIEJhcnl1biB3cm90ZToNCj4gSGkgTG91LA0KPiANCj4gVGhhbmtzIGZvciB5 b3VyIHVwZGF0ZXMuIEkgYW0gc29ycnkgdGhhdCBJIGRpZCBub3QgY29tbWVudCBvbiB0aGUNCj4g ZHJhZnQgYmVmb3JlLCBob3dldmVyLCB0aGlzIGlzIG15IHRob3VnaHQsDQo+IA0KPiBpbiBzZWN0 aW9uIDM6DQo+IA0KPiAgZHJhZnQ+VGhlIExhdGVuY3kgUmFuZ2UgRGF0YSBJdGVtIHNlcnZlcyBt dWNoIHRoZSBzYW1lIHB1cnBvc2UgYXMNCj4gdGhlDQo+ICAgIExhdGVuY3kgRGF0YSBJdGVtIGRl ZmluZWQgaW4gW1JGQzgxNzVdIHdpdGggdGhlIGFkZGl0aW9uIG9mIGJlaW5nDQo+ICAgIGFibGUg dG8gY29tbXVuaWNhdGUgdGhlIGxhdGVuY3kgcmFuZ2UgdGhhdCBtYXkgYmUgZXhwZXJpZW5jZWQg YnkNCj4gICAgdHJhZmZpYyBvbiBhIGxpbmsuIA0KPiANCj4gQUI+IElNTywgb3IgdW5kZXJzdGFu ZGluZywgIGxhdGVuY3kgcmFuZ2UgaXMgbm90IG9uZSB2YWx1ZSwgYnV0IHR3bw0KPiB2YWx1ZXMs IHNvIGhvdyBjYW4gdHdvIHZhbHVlcyBiZSBzYW1lIGluIHRoZSBwdXJwb3NlIG9mIG9uZSB2YWx1 ZSBvZg0KPiBsYXRlbmN5PyBtYXliZSB0aGUgZHJhZnQgc2hvdWxkIGRpc2N1c3MgdGhhdCBmb3Ig Y2xhcmlmaWNhdGlvbiwNCj4gYmVjYXVzZSBJIGRpZCBub3QgdW5kZXJzdGFuZC4NCj4gDQo+IA0K PiBBQj4gdGhpcyBkcmFmdCBkb2VzIG5vdCBzYXkgd2hhdCB3aWxsIGhhcHBlbiB0byB0aGUgZGF0 YSBpdGVtIGxhdGVuY3kNCj4gb2YgUkZDODE3NSAodHlwZSBjb2RlIDE2KSwgYmVjYXVzZSBpbiBS RkM4MTc1IHNheXMgc3VjaCBtZXNzYWdlcyBNVVNUDQo+IGNvbnRhaW4gb25lIHZhbHVlIG9mIC4u Li4gYW5kIHN0YXRlcyB0aGUgbGF0ZW5jeSBpdGVtLCBub3QgdGhlDQo+IGxhdGVuY3ktcmFuZ2Uu IFNvbWUgc2VjdGlvbnMgYWZ0ZXIgMTIuNiBkb2VzIG5vdCBtZW50aW9uIHRoZQ0KPiBkbGVwIHN1 cHBvcnQgb2Ygc3VjaCBleHRlbnNpb24gd2hhdCB3aWxsIGhhcHBlbiwgc28gSU1PIHRoaXMgZGFy ZnQNCj4gc2hvdWxkIHNheSBob3cgdGhlIHJlcGxhY2VtZW50IG9mIExhdGVuY3kgaXRlbSwNCj4g DQo+IEFCPiBhcyB0aGlzIGRyYWZ0IG1heSBuZWVkIHRvIHNheSB0aGF0IGlmIHRoZSBleHRlbnNp b24gaXMgc3VwcG9ydGVkDQo+IHRoZW4gbGF0ZW5jeSByYW5nZSBpdGVtIHJlcGxhY2VzIHRoZSBs YXRlbmN5IGl0ZW0sIG9yIGl0IG1heSBzYXkgdGhhdA0KPiB0aGUgbWF4aW11bSBsYXRlbmN5IHZh bHVlIGlzIHVzZWQgaW50byB0aGUgbGF0ZW5jeSBpdGVtIHZhbHVlLiBOb3QNCj4gc3VyZSB3aGlj aCBhcHByb2FjaCBpcyBiZXR0ZXIuDQo+IA0KPiBBQj4gIE15IHByb2JsZW0gaW4gdW5kZXJzdGFu ZGluZyB0aGUgZHJhZnQsIGlzIHRoYXQgaWYgdGhpcyBkcmFmdCBpcw0KPiBzdXBwb3J0ZWQgYXMg bWVudGlvbmVkIGluIHNlY3Rpb24tMTIuNiBpbiB0aGUgUkZDODE3NSB0aGVuIGl0IE1VU1QgYmUN Cj4gY29udGFpbmVkIGluIHRoYXQgbWVzc2FnZS4gU28gdGhpcyBuZWVkcyB0byBiZSBzYWlkIGFn YWluIEkgdGhpbmsgaW4NCj4gdGhpcyBkcmFmdCAoYmVjYXVzZSB0aGUgZHJhZnQgbm93IHNheXM6 IE1BWSBiZSBjYXJyeSkuDQo+IA0KPiBkcmFmdD4gIFRoZSBMYXRlbmN5IFJhbmdlIERhdGEgSXRl bSBNQVkgYmUgY2FycmllZCBpbiB0aGUNCj4gICAgc2FtZSBtZXNzYWdlcyBhbmQgTVVTVCBiZSBw cm9jZXNzZWQgYWNjb3JkaW5nIHRvIHRoZSBzYW1lIHJ1bGVzIGFzDQo+ICAgIHRoZSBMYXRlbmN5 IERhdGEgSXRlbSBkZWZpbmVkIGluIFtSRkM4MTc1XS4NCj4gDQo+IEFCPiBzYW1lIHJ1bGVzLCBi dXQgd2UgaGF2ZSB0d28gdmFsdWVzLCBvbmUgbWF4LWxhdGVuY3kgYW5kIG9uZSBtaW4tDQo+IGxh dGVuY3ksIHBsZWFzZSBjbGFyaWZ5LA0KPiANCj4gQUI+IGFzIG1lbnRpb25lZCBhYm92ZSAnJ3Nh bWUgcnVsZXMgYXMgbGF0ZW5jeScnIGJ1dCB3aGF0IHdpbGwgaGFwcGVuDQo+IHRvIHRoaXMgbGF0 ZW5jeSBpdGVtIHdoaWxlIGl0IGlzIGEgTVVTVCBpbiBtYW55IG1lc3NhZ2VzLCB3aGF0IHdpbGwN Cj4gYmUgdGhlIHZhbHVlLCBidXQgTGF0ZW5jeSByYW5nZSBpcyBhIE1BWS4NCj4gDQo+IEFCPiBz byBJIG1heSBzdWdnZXN0IHRoZSB2YWx1ZSBvZiB0aGUgcmFuZ2UgZm9yIHRoZSBkcmFmdCdzIGl0 ZW0gYW5kDQo+IHRoYXQgdGhlIGxhdGVjeSBpdGVuIGluIHJmYzgxNzUgY29udGFpbnMgdGhlIG1h eC1sYXRlbmN5LCBvciBhbnkgeW91DQo+IHN1Z2dlc3QgdG8gY2xhcmlmeSBpdC4NCj4gDQo+IEFC PiBmdXJ0aGVybW9yZSwgdGhlIFJGQzgxNzUgbWVudGlvbnMgY2hhbmdlIGluIG1ldHJpY3Mgd2hh dCBraW5kIG9mDQo+IHJlYWN0aW9uLCBzbyB3aXRoaW4gdGhpcyBkcmFmdCBjYXNlcywgaWYgdGhl IGxhdGVuY3kgd2FzIHRoZSBtZXRyaWMNCj4gd2hhdCB2YWx1ZSB3aWxsIGJlIHVzZWQgKG1heCwg YXZnLCBtaW4sLi4uKSBtYXkgbmVlZCB0byBiZSBzcGVjaWZpZWQNCj4gaW4gdGhlIGRyYWZ0Lg0K PiANCj4gDQo+IEJlc3QgUmVnYXJkcw0KPiBBQg0KPiANCj4gDQo+IA0KPiBPbiBUaHUsIEZlYiAx NSwgMjAxOCBhdCAxOjM2IEFNLCBMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0PiB3cm90ZToN Cj4gPiBIaSwNCj4gPiANCj4gPiBUaGlzIHZlcnNpb24gYWRkcmVzc2VzIGFsbCBjb21tZW50cyBy ZWNlaXZlZCAodG8gZGF0ZSkgZHVyaW5nIFdHIExDDQo+ID4gd2l0aCBvbmUgZXhjZXB0aW9uLiAg VGhlIG9uZSBleGNlcHRpb24gd2FzIGEgcHJpdmF0ZQ0KPiA+IHF1ZXN0aW9uL2NvbW1lbnQgb24g aG93IHRvIGhhbmRsZSBsYXRlbmN5IHRoYXQgbWF5IGJlIHF1ZXVlDQo+ID4gc3BlY2lmaWMuICBB cyB0aGlzIGV4dGVuc2lvbiBpcyBpbmRlcGVuZGVudCBvZiBxdWV1ZSBkZWZpbml0aW9uDQo+ID4g KHdoaWNoIGludHJvZHVjZWQgaW4gcGF1c2UgYW5kIGNyZWRpdCBleHRlbnNpb25zKSBhbmQgdGhl IHNhbWUNCj4gPiBxdWVzdGlvbiBhcHBsaWVzIHRvIG90aGVyIGxpbmsgbWV0cmljcywgaXQgd2Fz IG15IG9waW5pb24gdGhhdA0KPiA+IHF1ZXVlIHNwZWNpZmljIG1ldHJpY3MgYXJlIGJleW9uZCB0 aGUgc2NvcGUgb2YgdGhpcyBkcmFmdCBhbmQNCj4gPiByZWFsbHkgd2FycmFudHMgYSBuZXcgZXh0 ZW5zaW9uIGluIGl0cyBvd24gcmlnaHRzLiAgR2l2ZW4gdGhpcyB3YXMNCj4gPiByYWlzZWQgcHJp dmF0ZWx5IGR1cmluZyBMQyBhbmQgbm90IHNwZWNpZmljYWxseSBhZGRyZXNzZWQgaW4gdGhpcw0K PiA+IHZlcnNpb24sIEkgdGhvdWdodCBpdCBpbXBvcnRhbnQgdG8gbWVudGlvbiAgb24gbGlzdC4N Cj4gPiANCj4gPiBBbGwgb3RoZXIgY29tbWVudHMgd2VyZSBkaXNjdXNzZWQgb24gbGlzdC4gU2Vl IGJlbG93IGZvciBhIGxpbmsgdG8NCj4gPiBzZWUgdGhlc2UgZGlmZnMuDQo+ID4gDQo+ID4gTG91 DQo+ID4gDQo+ID4gDQo+ID4gT24gMi8xNC8yMDE4IDY6MjcgUE0sIGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZyB3cm90ZToNCj4gPiA+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBm cm9tIHRoZSBvbi1saW5lIEludGVybmV0LQ0KPiA+ID4gRHJhZnRzIGRpcmVjdG9yaWVzLg0KPiA+ ID4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgTW9iaWxlIEFkLWhvYyBOZXR3b3Jr cyBXRyBvZiB0aGUNCj4gPiA+IElFVEYuDQo+ID4gPiANCj4gPiA+ICAgICAgICAgIFRpdGxlICAg ICAgICAgICA6IERMRVAgTGF0ZW5jeSBSYW5nZSBFeHRlbnNpb24NCj4gPiA+ICAgICAgICAgIEF1 dGhvcnMgICAgICAgICA6IEJvdy1OYW4gQ2hlbmcNCj4gPiA+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgIExvdSBCZXJnZXINCj4gPiA+ICAgICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQt aWV0Zi1tYW5ldC1kbGVwLWxhdGVuY3ktDQo+ID4gPiBleHRlbnNpb24tMDIudHh0DQo+ID4gPiAg ICAgICAgIFBhZ2VzICAgICAgICAgICA6IDUNCj4gPiA+ICAgICAgICAgRGF0ZSAgICAgICAgICAg IDogMjAxOC0wMi0xNA0KPiA+ID4gDQo+ID4gPiBBYnN0cmFjdDoNCj4gPiA+ICAgICBUaGlzIGRv Y3VtZW50IGRlZmluZXMgYW4gZXh0ZW5zaW9uIHRvIHRoZSBETEVQIHByb3RvY29sIHRvDQo+ID4g PiBwcm92aWRlDQo+ID4gPiAgICAgdGhlIHJhbmdlIG9mIGxhdGVuY3kgdGhhdCBtYXkgYmUgZXhw ZXJpZW5jZWQgb24gYSBsaW5rLg0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IFRoZSBJRVRGIGRhdGF0 cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPiA+ID4gaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tYW5ldC1kbGVwLWxhdGVuY3ktZXgNCj4g PiA+IHRlbnNpb24vDQo+ID4gPiANCj4gPiA+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNp b25zIGF2YWlsYWJsZSBhdDoNCj4gPiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW1hbmV0LWRsZXAtbGF0ZW5jeS1leHRlbnNpDQo+ID4gPiBvbi0wMg0KPiA+ID4gaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLW1hbmV0LWRsZXAt bGF0ZW4NCj4gPiA+IGN5LWV4dGVuc2lvbi0wMg0KPiA+ID4gDQo+ID4gPiBBIGRpZmYgZnJvbSB0 aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+ID4gPiBodHRwczovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1tYW5ldC1kbGVwLWxhdGVuY3ktZQ0KPiA+ ID4geHRlbnNpb24tMDINCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiBQbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPiA+ID4gc3Vi bWlzc2lvbg0KPiA+ID4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2 YWlsYWJsZSBhdA0KPiA+ID4gdG9vbHMuaWV0Zi5vcmcuDQo+ID4gPiANCj4gPiA+IEludGVybmV0 LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gPiA+IGZ0 cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+ID4gPiANCj4gPiA+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBtYW5ldCBtYWls aW5nIGxpc3QNCj4gPiA+IG1hbmV0QGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQo+ID4gPiANCj4gPiA+IA0KPiA+ICANCj4gPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IG1hbmV0IG1h aWxpbmcgbGlzdA0KPiA+IG1hbmV0QGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tYW5ldA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gbWFuZXQgbWFpbGluZyBsaXN0DQo+IG1hbmV0QGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ= From nobody Mon Feb 19 08:40:24 2018 Return-Path: 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 42F2E126DED for ; Mon, 19 Feb 2018 08:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 cs1R-oRTgVpZ for ; Mon, 19 Feb 2018 08:40:19 -0800 (PST) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E83D1241F8 for ; Mon, 19 Feb 2018 08:40:19 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id n7so545369ita.5 for ; Mon, 19 Feb 2018 08:40:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wkw9AWXhblZNvcCwKeSOXF8QJMXD89DUWMzMHypeytE=; b=IjdD85LdRjm1fh9HJ5FO+wLCoAeMoMfyZWSQTs1a4/DwXZJjcgbUOgCwYeRW0s5yI4 eTbUvzcd1KcPaeherak9toWTmMEI8IHIatSVjfbGtb7Q6krDMYi0nlFvya3+dY3Emnyu bJJKKvo/bS/OpTTqklhxaJaVYAAYTSvjoTuI+v/2P4ktvLviURB6OiwlyoQVFwB5AdNV ywhXUUKisKpnjB5ES1XDG6egCCZQGPJ3c9+32xO0l8N/Y7Jjq0C3NVc2+uYoOIHdKLtP OFi5Ykf89hUfDgaPBKxgjxOjqJ7aYkhoe+4XbpbzgqkLvhjWTXz5mZBE4cVsL2O0l+zn SaKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wkw9AWXhblZNvcCwKeSOXF8QJMXD89DUWMzMHypeytE=; b=K3U6R1E5zUbCW3UYhlBlEG3sdfnuhlnyNdMHvvdFlcwGsjFnvGjjGnVD+/TvExU2dz E/9oRfG006SkE8zqE7+EV1jVgiAgQ9gHnbe1+tjl1UZMUordmp/lYwS/5eMywjsYsAoz hdEgTqyiV/BF475uL4KMgnWt0WhF8TymBJScyY9RxvSlk3+WSsdBSJKYaaI2F8MdLz13 4sQyGUXOR4E1Au27L78tcRabkoNWMR+W54s5UKaXOT0nx1daUMOL9efaXQBsvmzIf/6z LflEPxBTJLDMviYgQPNLWA8na2n+z8ude7IccS+Bi5tl5Lve/z0D4dkeQttGEYfxCSIs fZNw== X-Gm-Message-State: APf1xPBqyjNm7rLDwC21XDNVrZ0WJUUjRW0QD+byxv+MXeqbbq3iBjem 2hxMwJ0C7rGmJMvZvovFqPFM1eU+db0/vBcujOk= X-Google-Smtp-Source: AH8x227zBZ/GBfuMoZUe0prHvKPBEVRHchD/6EG7L56r+ax2NNvVJcEnzDXy51kJHVUclefydxrlwraxHnyQZdDO9OM= X-Received: by 10.36.8.69 with SMTP id 66mr19459314itc.132.1519058418555; Mon, 19 Feb 2018 08:40:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.162.79 with HTTP; Mon, 19 Feb 2018 08:40:17 -0800 (PST) In-Reply-To: <097c3985-48d7-9584-da50-1ddf14524fa3@labn.net> References: <020E5EA0-7A6B-46D1-9363-640E3FBBA0ED@ll.mit.edu> <16134a38478.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <097c3985-48d7-9584-da50-1ddf14524fa3@labn.net> From: Stan Ratliff Date: Mon, 19 Feb 2018 11:40:17 -0500 Message-ID: To: Lou Berger Cc: "Wiggins, David - 0665 - MITLL" , Justin Dean , MANET IETF Content-Type: multipart/alternative; boundary="001a1140acc26e606b0565935978" Archived-At: Subject: Re: [manet] Last call ending X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 16:40:22 -0000 --001a1140acc26e606b0565935978 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Lou, On Wed, Feb 14, 2018 at 6:10 PM, Lou Berger wrote: > Hi Stan, > > > On 1/29/2018 5:39 PM, Stan Ratliff wrote: > >> >> Sent from my iPhone >> >> On Jan 29, 2018, at 5:26 PM, Wiggins, David - 0665 - MITLL < >>> David.Wiggins@ll.mit.edu> wrote: >>> >>> I tried to clarify Suppress Forwarding: >>> >>> The Suppress Forwarding Action is used by a router to indicate to its >>> peer that multi-hop forwarding performed by the modem is to be >>> suppressed. A router may request that multi-hop forwarding may be >>> suppressed on a device wide or destination specific basis. >>> >>> A modem which receives the Suppress Forwarding Data Item in a Session >>> Update Message MUST suppress multi-hop forwarding on a device wide >>> basis. >>> >> This concerns me. Should the modem >> a) silently drop traffic unless/until the multi-hop destination(s) becom= e >> single-hop again? (Bad plan, IMO) Or, >> b) issue Destination Down for multi-hop destination(s), and re-issue >> Destination Up If/when the dest is single-hop? >> > > Stand note that the reference paragraph concludes: > Impact to destination hop counts are provided to the > router by the modem as described above. > > and above it says: > ... > Destination specific impact resulting from the processing of a Hop > Control Data Item in a Session Update Message is provided via > Destination Down and Destination Update Messages. The modem MUST > notify the router of each destination that is no longer reachable via a > Destination Down Message. The modem MUST notify the router of any > changes in Hop Counts via Destination Update Messages. > > Is this sufficient? > Yes, I'm good to go with that text. Apologies for any noise. Regards, Stan > Thanks, > Lou > >> Regards, >> Stan >> >> For data traffic originating from the modem's peer router, the >>> modem MUST only send such traffic to destinations that are one hop >>> away. Any data traffic received from the modem MUST NOT be resent to >>> another modem. Impact to destination hop counts are provided to the >>> router by the modem as described above. >>> >>> A modem which receives the Suppress Forwarding Data Item in a Link >>> Characteristics Request Message MUST suppress multi-hop forwarding fo= r >>> only the destination indicated in the message. Sending of traffic by >>> the modem is modified as described in the previous paragraph, except >>> that the suppression only applies to the specific destination given i= n >>> the Link Characteristics Request Message. Results are provided as >>> described above. >>> >>> Does that fit what was meant? >>> >>> Thanks, >>> David >>> >>> >>> >>> On 1/29/18, 1:37 PM, "Lou Berger" wrote: >>> >>> ... >>> David, (all) >>> I think I've addressed all comments in the latest push to the repo. >>> I'm >>> enclosing below a specific diff of the commit that addresses your >>> comments, please take a look and let me know if you see any issues >>> remaining. >>> >>> Note I have clarified processing when hop control is in a >>> characteristics change message and changed/simplified in the Sessio= n >>> request massage case - to improve processing consistency as you >>> requested. Please see the specific changes below and let me know >>> what >>> you think. >>> >>> I also have one comment in response to your comment below. >>> >>> On 01/29/2018 09:36 AM, Wiggins, David - 0665 - MITLL wrote: >>> >>>> That=E2=80=99s why I was suggesting a radically different mechanism fo= r the >>>>> router >>>>> to express its wishes, e.g., by ordering the destinations in terms of >>>>> importance, and letting the modem work that information into its >>>>> topology >>>>> control scheme however it can. The router=E2=80=99s most important >>>>> destination may >>>>> be best reached over a 3-hop link. >>>>> >>>>> To me this is a different extension with different objectives. I >>>> certainly >>>> would be interested in reading that extension. >>>> >>>> It has very similar objectives to the Direct Connection/Terminate part >>>> of this extension, but I agree that it doesn=E2=80=99t fit well in thi= s extension. >>>> >>> I think an extension that does this as well as let's a router >>> understand >>> some of the resource impacts of a manet topology (with out exposing >>> the >>> full topology ala ospf/isis-te) would be very interesting. I >>> actually >>> had some related discussion on this in singapore. If you have a >>> proposal on this or are interested in collaborating on such, I'm ve= ry >>> interested in this! >>> >>> Thanks, >>> >>> Lou >>> >>> Changes from: >>> https://github.com/louberger/dlep-extensions/commit/100217f5 >>> a8a3e35c6608b4a88428b20b14854f8f >>> commit 100217f5a8a3e35c6608b4a88428b20b14854f8f >>> Author: Lou Berger >>> Date: Mon Jan 29 13:20:09 2018 -0500 >>> >>> Multi-hop: Address remainder of Dave W. comments >>> - Clean up Hop Behavior processing. >>> Send only one message when link characteristic change >>> results in >>> a change/unreachable requested destination >>> Destination impact due to Hop Control Data Item in a >>> Session >>> Update Message always provided via a Destination >>> Down or >>> Destination Update Message. >>> >>> diff --git a/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xm= l >>> b/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml >>> index 5fc2845..f81e3be 100644 >>> --- a/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml >>> +++ b/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml >>> @@ -110,7 +110,8 @@ >>> words, each hop represents a transmission and the number of hop= s >>> is >>> equal to the number of transmissions required to go from a rout= er >>> connected modem to the destination's connected modem. The >>> minimum >>> - number of hops is 1, which represents the transmission by the >>> router's >>> + number of hops is 1, which represents transmission to destinatio= ns >>> + that are directly reachable via the router's >>> locally connected >>> modem. >>> >>> @@ -176,7 +177,7 @@ >>> A value of zero (0) is used to indicated that processing of >>> a Hop >>> Control action, see , has >>> resulted >>> in a destination no longer being reachable. A zero value >>> MUST NOT >>> - be used in any message other then a Destination Announce >>> Response >>> + be used in any message other then a Link Characteristics >>> Response >>> Message. >>> >>> >>> @@ -189,7 +190,8 @@ >>> connectivity to a particular destination, or in multi-hop >>> processing >>> on a device wide basis. A router can request multi-hop reachabl= e >>> destination be changed to a single hop. A router can also >>> indicate >>> - that the modem terminate connectivity to a particular destinatio= n. >>> + that the modem terminates a previous direct connectivity request >>> to a >>> + particular destination. >>> >>> >>> The Hop Control Data Item MAY be carried in a Session Update >>> Message >>> @@ -218,20 +220,19 @@ >>> notify the router of each destination that is no longer >>> reachable via >>> a Destination Down Message. The modem MUST notify the router of >>> any >>> changes in Hop Counts via Destination Update Messages. Note th= at >>> - normal DLEP processing is not otherwise modified by this >>> document, this >>> - includes the generation of Destination Down messages. >>> + neither Destination Down or Update Message SHOULD NOT be sent fo= r >>> the >>> + destination MAC address contained in the Link Characteristics >>> + Response Message. >>> >>> >>> A modem that receives the Hop Control Data Item in >>> a Session Update Message >>> SHOULD attempt to make the change indicated by the data item >>> - for the associated destination MAC address, when carried in a Li= nk >>> - Characteristics Request Message, or all destinations, when >>> carried in >>> - a Session Update Message. Once the change is made, >>> - or fails or is rejected, the modem MUST respond with a Link >>> Characteristics >>> - Request Message containing an updated Hop Count Data Item. Note >>> that >>> - other destinations can be impacted as a result of the change and >>> such >>> - changes are reported in >>> + for all known destinations. Once the change is made, or fails o= r >>> is >>> + rejected, the modem MUST respond with a Session Update Response >>> + Message with an appropriate Status Code. Destination specific >>> + impact resulting from the processing of a Hop Control Data Item >>> in a >>> + Session Update Message is provided via >>> Destination Down and Destination Update Messages. The modem MU= ST >>> notify the router of each destination that is no longer >>> reachable via >>> a Destination Down Message. The modem MUST notify the router of >>> any >>> >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >> > --001a1140acc26e606b0565935978 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Lou,

On Wed, Feb 14, 2018 at 6:10 PM, Lou Berger <lberger@labn.net> wrote:
Hi Stan,


On 1/29/2018 5:39 PM, Stan Ratliff wrote:

Sent from my iPhone

On Jan 29, 2018, at 5:26 PM, Wiggins, David - 0665 - MITLL <David.Wiggins@ll.mit.edu<= /a>> wrote:

I tried to clarify Suppress Forwarding:

=C2=A0 The Suppress Forwarding Action is used by a router to indicate to it= s
=C2=A0 peer that multi-hop forwarding performed by the modem is to be
=C2=A0 suppressed.=C2=A0 A router may request that multi-hop forwarding may= be
=C2=A0 suppressed on a device wide or destination specific basis.

=C2=A0 A modem which receives the Suppress Forwarding Data Item in a Sessio= n
=C2=A0 Update Message MUST suppress multi-hop forwarding on a device wide =C2=A0 basis.
This concerns me. Should the modem
a) silently drop traffic unless/until the multi-hop destination(s) become s= ingle-hop again? (Bad plan, IMO) Or,
b) issue Destination Down for multi-hop destination(s), and re-issue Destin= ation Up If/when the dest is single-hop?

Stand note that the reference paragraph concludes:
=C2=A0 Impact to destination hop counts are provided to the
=C2=A0 router by the modem as described above.

and above it says:
=C2=A0...
=C2=A0Destination specific impact resulting from the processing of a Hop =C2=A0Control Data Item in a Session Update Message is provided via
=C2=A0Destination Down and Destination Update Messages.=C2=A0 The modem MUS= T
=C2=A0notify the router of each destination that is no longer reachable via= a
=C2=A0Destination Down Message. The modem MUST notify the router of any
=C2=A0changes in Hop Counts via Destination Update Messages.

Is this sufficient?


Regards,


=C2=A0
Thanks,
Lou
Regards,
Stan

For data traffic originating from the modem's peer router, the
=C2=A0 modem MUST only send such traffic to destinations that are one hop =C2=A0 away.=C2=A0 Any data traffic received from the modem MUST NOT be res= ent to
=C2=A0 another modem.=C2=A0 Impact to destination hop counts are provided t= o the
=C2=A0 router by the modem as described above.

=C2=A0 A modem which receives the Suppress Forwarding Data Item in a Link =C2=A0 Characteristics Request Message MUST suppress multi-hop forwarding f= or
=C2=A0 only the destination indicated in the message.=C2=A0 Sending of traf= fic by
=C2=A0 the modem is modified as described in the previous paragraph, except=
=C2=A0 that the suppression only applies to the specific destination given = in
=C2=A0 the Link Characteristics Request Message.=C2=A0 Results are provided= as
=C2=A0 described above.

Does that fit what was meant?

Thanks,
David



On 1/29/18, 1:37 PM, "Lou Berger" <lberger@labn.net> wrote:

=C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 David, (all)
=C2=A0 =C2=A0 I think I've addressed all comments in the latest push to= the repo.=C2=A0 I'm
=C2=A0 =C2=A0 enclosing below a specific diff of the commit that addresses = your
=C2=A0 =C2=A0 comments, please take a look and let me know if you see any i= ssues
=C2=A0 =C2=A0 remaining.

=C2=A0 =C2=A0 Note I have clarified processing when hop control is in a
=C2=A0 =C2=A0 characteristics change message and changed/simplified in the = Session
=C2=A0 =C2=A0 request massage case - to improve processing consistency as y= ou
=C2=A0 =C2=A0 requested.=C2=A0 Please see the specific changes below and le= t me know what
=C2=A0 =C2=A0 you think.

=C2=A0 =C2=A0 I also have one comment in response to your comment below.
=C2=A0 =C2=A0 On 01/29/2018 09:36 AM, Wiggins, David - 0665 - MITLL wrote:<= br>
That=E2=80=99s why I was suggesting a radically different mechanism for the= router
to express its wishes, e.g., by ordering the destinations in terms of
importance, and letting the modem work that information into its topology control scheme however it can.=C2=A0 The router=E2=80=99s most important de= stination may
be best reached over a 3-hop link.

=C2=A0 =C2=A0 To me this is a different extension with different objectives= . I certainly
=C2=A0 =C2=A0 would be interested in reading that extension.

It has very similar objectives to the Direct Connection/Terminate part of t= his extension, but I agree that it doesn=E2=80=99t fit well in this extensi= on.
=C2=A0 =C2=A0 I think an extension that does this as well as let's a ro= uter understand
=C2=A0 =C2=A0 some of the resource impacts of a manet topology (with out ex= posing the
=C2=A0 =C2=A0 full topology ala ospf/isis-te) would be very interesting.=C2= =A0 I actually
=C2=A0 =C2=A0 had some related discussion on this in singapore.=C2=A0 If yo= u have a
=C2=A0 =C2=A0 proposal on this or are interested in collaborating on such, = I'm very
=C2=A0 =C2=A0 interested in this!

=C2=A0 =C2=A0 Thanks,

=C2=A0 =C2=A0 Lou

=C2=A0 =C2=A0 Changes from:
=C2=A0 =C2=A0 https://github.com/louberger/dlep-extensions/commit/100217f5a8a3e35c6608b4a88428b20b14854f8f
=C2=A0 =C2=A0 commit 100217f5a8a3e35c6608b4a88428b20b14854f8f
=C2=A0 =C2=A0 Author: Lou Berger <lberger@labn.net>
=C2=A0 =C2=A0 Date:=C2=A0 =C2=A0Mon Jan 29 13:20:09 2018 -0500

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Multi-hop: Address remainder of Dave W. c= omments
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Clean up Hop Behavior pro= cessing.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Send only one messag= e when link characteristic change results in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a cha= nge/unreachable requested destination
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination impact d= ue to Hop Control Data Item in a Session
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Updat= e Message always provided via a Destination Down or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Desti= nation Update Message.

=C2=A0 =C2=A0 diff --git a/multi-hop/draft-ietf-manet-dlep-multi-hop-e= xtension.xml
=C2=A0 =C2=A0 b/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xm= l
=C2=A0 =C2=A0 index 5fc2845..f81e3be 100644
=C2=A0 =C2=A0 --- a/multi-hop/draft-ietf-manet-dlep-multi-hop-extensio= n.xml
=C2=A0 =C2=A0 +++ b/multi-hop/draft-ietf-manet-dlep-multi-hop-extensio= n.xml
=C2=A0 =C2=A0 @@ -110,7 +110,8 @@
=C2=A0 =C2=A0 =C2=A0 =C2=A0 words, each hop represents a transmission and t= he number of hops is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 equal to the number of transmissions required t= o go from a router
=C2=A0 =C2=A0 =C2=A0 =C2=A0 connected modem to the destination's connec= ted modem.=C2=A0 The minimum
=C2=A0 =C2=A0 -=C2=A0 number of hops is 1, which represents the transmissio= n by the router's
=C2=A0 =C2=A0 +=C2=A0 number of hops is 1, which represents transmission to= destinations
=C2=A0 =C2=A0 +=C2=A0 that are directly reachable via the router's
=C2=A0 =C2=A0 =C2=A0 =C2=A0 locally connected
=C2=A0 =C2=A0 =C2=A0 =C2=A0 modem.
=C2=A0 =C2=A0 =C2=A0 </t>
=C2=A0 =C2=A0 @@ -176,7 +177,7 @@
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A value of zero (0) is used to in= dicated that processing of a Hop
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Control action, see <xref targ= et=3D"sec-di-hcontrol"/>, has resulted
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in a destination no longer being = reachable.=C2=A0 A zero value MUST NOT
=C2=A0 =C2=A0 -=C2=A0 =C2=A0 =C2=A0 be used in any message other then a Des= tination Announce Response
=C2=A0 =C2=A0 +=C2=A0 =C2=A0 =C2=A0 be used in any message other then a Lin= k Characteristics Response
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Message.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </t>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 </list>
=C2=A0 =C2=A0 @@ -189,7 +190,8 @@
=C2=A0 =C2=A0 =C2=A0 =C2=A0 connectivity to a particular destination, or in= multi-hop processing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 on a device wide basis. A router can request mu= lti-hop reachable
=C2=A0 =C2=A0 =C2=A0 =C2=A0 destination be changed to a single hop.=C2=A0 A= router can also indicate
=C2=A0 =C2=A0 -=C2=A0 that the modem terminate connectivity to a particular= destination.
=C2=A0 =C2=A0 +=C2=A0 that the modem terminates a previous direct connectiv= ity request to a
=C2=A0 =C2=A0 +=C2=A0 particular destination.
=C2=A0 =C2=A0 =C2=A0 </t>
=C2=A0 =C2=A0 =C2=A0 <t>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 The Hop Control Data Item MAY be carried in a S= ession Update Message
=C2=A0 =C2=A0 @@ -218,20 +220,19 @@
=C2=A0 =C2=A0 =C2=A0 =C2=A0 notify the router of each destination that is n= o longer reachable via
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a Destination Down Message. The modem MUST noti= fy the router of any
=C2=A0 =C2=A0 =C2=A0 =C2=A0 changes in Hop Counts via Destination Update Me= ssages.=C2=A0 Note that
=C2=A0 =C2=A0 -=C2=A0 normal DLEP processing is not otherwise modified by t= his document, this
=C2=A0 =C2=A0 -=C2=A0 includes the generation of Destination Down messages.=
=C2=A0 =C2=A0 +=C2=A0 neither Destination Down or Update Message SHOULD NOT= be sent for the
=C2=A0 =C2=A0 +=C2=A0 destination MAC address contained in the Link Charact= eristics
=C2=A0 =C2=A0 +=C2=A0 Response Message.
=C2=A0 =C2=A0 =C2=A0 </t>
=C2=A0 =C2=A0 =C2=A0 <t>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 A modem that receives the Hop Control Data Item= in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a Session Update Message
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SHOULD attempt to make the change indicated by = the data item
=C2=A0 =C2=A0 -=C2=A0 for the associated destination MAC address, when carr= ied in a Link
=C2=A0 =C2=A0 -=C2=A0 Characteristics Request Message, or all destinations,= when carried in
=C2=A0 =C2=A0 -=C2=A0 a Session Update Message. Once the change is made, =C2=A0 =C2=A0 -=C2=A0 or fails or is rejected, the modem MUST respond with = a Link
=C2=A0 =C2=A0 Characteristics
=C2=A0 =C2=A0 -=C2=A0 Request Message containing an updated Hop Count Data = Item.=C2=A0 Note that
=C2=A0 =C2=A0 -=C2=A0 other destinations can be impacted as a result of the= change and such
=C2=A0 =C2=A0 -=C2=A0 changes are reported in
=C2=A0 =C2=A0 +=C2=A0 for all known destinations.=C2=A0 Once the change is = made, or fails or is
=C2=A0 =C2=A0 +=C2=A0 rejected, the modem MUST respond with a Session Updat= e Response
=C2=A0 =C2=A0 +=C2=A0 Message with an appropriate Status Code.=C2=A0 Destin= ation specific
=C2=A0 =C2=A0 +=C2=A0 impact resulting from the processing of a Hop Control= Data Item in a
=C2=A0 =C2=A0 +=C2=A0 Session Update Message is provided via
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Destination Down and Destination Update Message= s.=C2=A0 The modem MUST
=C2=A0 =C2=A0 =C2=A0 =C2=A0 notify the router of each destination that is n= o longer reachable via
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a Destination Down Message. The modem MUST noti= fy the router of any


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


--001a1140acc26e606b0565935978-- From nobody Mon Feb 19 13:38:39 2018 Return-Path: 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 A5CCA1277BB for ; Mon, 19 Feb 2018 13:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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] autolearn=ham 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 ZS8j_9efUrxE for ; Mon, 19 Feb 2018 13:38:35 -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 C116212422F for ; Mon, 19 Feb 2018 13:38:28 -0800 (PST) Received: from cmgw4 (unknown [10.0.90.85]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id E5A42175DC8 for ; Mon, 19 Feb 2018 14:38:26 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id CleP1x0052SSUrH01leSdM; Mon, 19 Feb 2018 14:38:26 -0700 X-Authority-Analysis: v=2.2 cv=G85sK5s5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=Op4juWPpsa0A:10 a=wU2YTnxGAAAA:8 a=NEAV23lmAAAA:8 a=48vgC7mUAAAA:8 a=NdFI5I3zeenAOd4uZbgA:9 a=LbRk24-v1xpUbwDx:21 a=f87SK3c3R3nihrGw:21 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22 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=n4LK05Do3f6s9uNyExWO0tdUQsfJj9EuB1E0vdQKI2M=; b=XuoskdNLD2Pw78jsaUXJwF4Dnz 8s8W74ivGKhV3qZJQ8H6ShSvJE0FuNFtYgLt//UKgUtan4vY5JqLauDoofnW2ciChqTnS5VBQ9u4B 02mnzSfbZeayiw+KLrXmUHSsm; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:45390 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1ent8g-0036u9-Q2; Mon, 19 Feb 2018 14:38:22 -0700 To: Stan Ratliff Cc: "Wiggins, David - 0665 - MITLL" , Justin Dean , MANET IETF References: <020E5EA0-7A6B-46D1-9363-640E3FBBA0ED@ll.mit.edu> <16134a38478.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <097c3985-48d7-9584-da50-1ddf14524fa3@labn.net> From: Lou Berger Message-ID: <509a0d80-d60c-bd1b-1936-fe7a7c73214f@labn.net> Date: Mon, 19 Feb 2018 16:38:19 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: 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: 100.15.86.101 X-Exim-ID: 1ent8g-0036u9-Q2 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:45390 X-Source-Auth: lberger@labn.net X-Email-Count: 6 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [manet] Last call ending X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 21:38:38 -0000 Thanks Stan. On 2/19/2018 11:40 AM, Stan Ratliff wrote: > Lou, > > On Wed, Feb 14, 2018 at 6:10 PM, Lou Berger > wrote: > > Hi Stan, > > > On 1/29/2018 5:39 PM, Stan Ratliff wrote: > > > Sent from my iPhone > > On Jan 29, 2018, at 5:26 PM, Wiggins, David - 0665 - MITLL > > wrote: > > I tried to clarify Suppress Forwarding: > >   The Suppress Forwarding Action is used by a router to > indicate to its >   peer that multi-hop forwarding performed by the modem is > to be >   suppressed.  A router may request that multi-hop > forwarding may be >   suppressed on a device wide or destination specific basis. > >   A modem which receives the Suppress Forwarding Data Item > in a Session >   Update Message MUST suppress multi-hop forwarding on a > device wide >   basis. > > This concerns me. Should the modem > a) silently drop traffic unless/until the multi-hop > destination(s) become single-hop again? (Bad plan, IMO) Or, > b) issue Destination Down for multi-hop destination(s), and > re-issue Destination Up If/when the dest is single-hop? > > > Stand note that the reference paragraph concludes: >   Impact to destination hop counts are provided to the >   router by the modem as described above. > > and above it says: >  ... >  Destination specific impact resulting from the processing of a Hop >  Control Data Item in a Session Update Message is provided via >  Destination Down and Destination Update Messages.  The modem MUST >  notify the router of each destination that is no longer reachable > via a >  Destination Down Message. The modem MUST notify the router of any >  changes in Hop Counts via Destination Update Messages. > > Is this sufficient? > > > Yes, I'm good to go with that text. Apologies for any noise. > > Regards, > Stan > > > Thanks, > Lou > > Regards, > Stan > > For data traffic originating from the modem's peer router, the >   modem MUST only send such traffic to destinations that > are one hop >   away.  Any data traffic received from the modem MUST NOT > be resent to >   another modem.  Impact to destination hop counts are > provided to the >   router by the modem as described above. > >   A modem which receives the Suppress Forwarding Data Item > in a Link >   Characteristics Request Message MUST suppress multi-hop > forwarding for >   only the destination indicated in the message. Sending > of traffic by >   the modem is modified as described in the previous > paragraph, except >   that the suppression only applies to the specific > destination given in >   the Link Characteristics Request Message.  Results are > provided as >   described above. > > Does that fit what was meant? > > Thanks, > David > > > > On 1/29/18, 1:37 PM, "Lou Berger" > wrote: > >     ... >     David, (all) >     I think I've addressed all comments in the latest push > to the repo.  I'm >     enclosing below a specific diff of the commit that > addresses your >     comments, please take a look and let me know if you > see any issues >     remaining. > >     Note I have clarified processing when hop control is in a >     characteristics change message and changed/simplified > in the Session >     request massage case - to improve processing > consistency as you >     requested.  Please see the specific changes below and > let me know what >     you think. > >     I also have one comment in response to your comment below. > >     On 01/29/2018 09:36 AM, Wiggins, David - 0665 - MITLL > wrote: > > That’s why I was suggesting a radically different > mechanism for the router > to express its wishes, e.g., by ordering the > destinations in terms of > importance, and letting the modem work that > information into its topology > control scheme however it can.  The router’s most > important destination may > be best reached over a 3-hop link. > >     To me this is a different extension with different > objectives. I certainly >     would be interested in reading that extension. > > It has very similar objectives to the Direct > Connection/Terminate part of this extension, but I > agree that it doesn’t fit well in this extension. > >     I think an extension that does this as well as let's a > router understand >     some of the resource impacts of a manet topology (with > out exposing the >     full topology ala ospf/isis-te) would be very > interesting.  I actually >     had some related discussion on this in singapore. If > you have a >     proposal on this or are interested in collaborating on > such, I'm very >     interested in this! > >     Thanks, > >     Lou > >     Changes from: > https://github.com/louberger/dlep-extensions/commit/100217f5a8a3e35c6608b4a88428b20b14854f8f > >     commit 100217f5a8a3e35c6608b4a88428b20b14854f8f >     Author: Lou Berger > >     Date:   Mon Jan 29 13:20:09 2018 -0500 > >          Multi-hop: Address remainder of Dave W. comments >              - Clean up Hop Behavior processing. >                Send only one message when link > characteristic change results in >                     a change/unreachable requested destination >                Destination impact due to Hop Control Data > Item in a Session >                     Update Message always provided via a > Destination Down or >                     Destination Update Message. > >     diff --git > a/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml >     b/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml >     index 5fc2845..f81e3be 100644 >     --- > a/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml >     +++ > b/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml >     @@ -110,7 +110,8 @@ >         words, each hop represents a transmission and the > number of hops is >         equal to the number of transmissions required to > go from a router >         connected modem to the destination's connected > modem.  The minimum >     -  number of hops is 1, which represents the > transmission by the router's >     +  number of hops is 1, which represents transmission > to destinations >     +  that are directly reachable via the router's >         locally connected >         modem. >       >     @@ -176,7 +177,7 @@ >             A value of zero (0) is used to indicated that > processing of a Hop >             Control action, see target="sec-di-hcontrol"/>, has resulted >             in a destination no longer being reachable.  A > zero value MUST NOT >     -      be used in any message other then a Destination > Announce Response >     +      be used in any message other then a Link > Characteristics Response >             Message. >           >         >     @@ -189,7 +190,8 @@ >         connectivity to a particular destination, or in > multi-hop processing >         on a device wide basis. A router can request > multi-hop reachable >         destination be changed to a single hop.  A router > can also indicate >     -  that the modem terminate connectivity to a > particular destination. >     +  that the modem terminates a previous direct > connectivity request to a >     +  particular destination. >       >       >         The Hop Control Data Item MAY be carried in a > Session Update Message >     @@ -218,20 +220,19 @@ >         notify the router of each destination that is no > longer reachable via >         a Destination Down Message. The modem MUST notify > the router of any >         changes in Hop Counts via Destination Update > Messages.  Note that >     -  normal DLEP processing is not otherwise modified by > this document, this >     -  includes the generation of Destination Down messages. >     +  neither Destination Down or Update Message SHOULD > NOT be sent for the >     +  destination MAC address contained in the Link > Characteristics >     +  Response Message. >       >       >         A modem that receives the Hop Control Data Item in >         a Session Update Message >         SHOULD attempt to make the change indicated by the > data item >     -  for the associated destination MAC address, when > carried in a Link >     -  Characteristics Request Message, or all > destinations, when carried in >     -  a Session Update Message. Once the change is made, >     -  or fails or is rejected, the modem MUST respond > with a Link >     Characteristics >     -  Request Message containing an updated Hop Count > Data Item.  Note that >     -  other destinations can be impacted as a result of > the change and such >     -  changes are reported in >     +  for all known destinations.  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. > Destination specific >     +  impact resulting from the processing of a Hop > Control Data Item in a >     +  Session Update Message is provided via >         Destination Down and Destination Update Messages.  > The modem MUST >         notify the router of each destination that is no > longer reachable via >         a Destination Down Message. The modem MUST notify > the router of any > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > From nobody Mon Feb 19 14:04:19 2018 Return-Path: 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 346DB126BF6 for ; Mon, 19 Feb 2018 14:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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] 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 4gp5g_FYVj4C for ; Mon, 19 Feb 2018 14:04:14 -0800 (PST) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 743C9128D2E for ; Mon, 19 Feb 2018 14:04:14 -0800 (PST) Received: from cmgw4 (unknown [10.0.90.85]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id AF3D31E0D1E for ; Mon, 19 Feb 2018 15:04:09 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id Cm461x01F2SSUrH01m49i7; Mon, 19 Feb 2018 15:04:09 -0700 X-Authority-Analysis: v=2.2 cv=G85sK5s5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=Op4juWPpsa0A:10 a=48vgC7mUAAAA:8 a=wU2YTnxGAAAA:8 a=eGf5b6Z-puGTbbNaQNsA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=Yz9wTY_ffGCQnEDHKrcv:22 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=C6354VgQLGUzsjapbxLHFejhabi2cHPakgAX3qTZjE0=; b=ODv6JqT+ldDh4PZSQ+ouMoaP/+ dn4y/h6e6HhmelScBs5FbYodfMug3tkT9bhGVTlQXWJ801LiKkpQJA63b2EjALrO9K4xVVW+Tl5EL CeR3R9wxSMNGMbwT8Ge1q5BMc; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:47414 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1entXa-003G2B-GI; Mon, 19 Feb 2018 15:04:06 -0700 To: Abdussalam Baryun Cc: manet , draft-ietf-manet-dlep-latency-extension@ietf.org References: <151865086912.7521.1302513672018061966@ietfa.amsl.com> From: Lou Berger Message-ID: Date: Mon, 19 Feb 2018 17:04:03 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: 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: 100.15.86.101 X-Exim-ID: 1entXa-003G2B-GI X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:47414 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 22:04:16 -0000 Hi AB, See below. On 2/18/2018 6:23 PM, Abdussalam Baryun wrote: > Hi Lou, > > Thanks for your updates. I am sorry that I did not comment on the > draft before, however, this is my thought, > > in section 3: > >  draft>The Latency Range Data Item serves much the same purpose as the >    Latency Data Item defined in [RFC8175 > ] with the addition of being >    able to communicate the latency range that may be experienced by >    traffic on a link. > > AB> IMO, or understanding,  latency range is not one value, but two > values, so how can two values be same in the purpose of one value of > latency? maybe the draft should discuss that for clarification, > because I did not understand. > So per 8175: The Latency Data Item is used to indicate the amount of latency, in microseconds, on the link. so  8175 defines a single point definition of "the amount of latency ... on the link" while this draft defines a range for latency "that may be experienced by traffic on a link".  Nether say how this is to be used. I'm not sure what more is to be said on this.  Do you have an proposed language? > > AB> this draft does not say what will happen to the data item latency > of RFC8175 (type code 16), because in RFC8175 says such messages MUST > contain one value of .... and states the latency item, not the > latency-range. Some sections after 12.6 does not mention the > dlep support of such extension what will happen, so IMO this darft > should say how the replacement of Latency item, it's not a replacement.  It is sent in addition.  As is generally the case in extension RFCs, if a modification to an existing RFC is not stated explicitly, there is no such modification.  I do agree that if the new data item were to be sent in place of the old one (a) this should be made very explicit and (b) this document would be an update to RFC8175. see the next response > > AB> as this draft may need to say that if the extension is supported > then latency range item replaces the latency item, or it may say that > the maximum latency value is used into the latency item value. Not > sure which approach is better. The document doesn't modify the existing latency data item. Is it worth adding a sentence to the end of section 2 along the lines of: Note: the usage of the extension defined in this document does not impact processing associated with the Latency Data Item defined in Section 13.6 of [rfc8175]. Seems pretty obvious, but also a benign addition > > AB>  My problem in understanding the draft, is that if this draft is > supported as mentioned in section-12.6 in the RFC8175 then it MUST be > contained in that message. So this needs to be said again I think in > this draft (because the draft now says: MAY be carry). > > draft>  The Latency Range Data Item MAY be carried in the >    same messages and MUST be processed according to the same rules as >    the Latency Data Item defined in [RFC8175 > ]. > can you elaborate on what specific changes you'd like to see? > AB> same rules, but we have two values, one max-latency and one > min-latency, please clarify, > It's one data item.  RFC8179 defines when and how the data item is sent, not how the latency value is set or used.  This is the same for the extension. > AB> as mentioned above ''same rules as latency'' but what will happen > to this latency item while it is a MUST in many messages, what will be > the value, but Latency range is a MAY. > Correct.  An implementation MAY choose to include a Latency Range Data Item where it includes a Latency Data Item. > AB> so I may suggest the value of the range for the draft's item and > that the latecy iten in rfc8175 contains the max-latency, or any you > suggest to clarify it. > rfc8175 latency data item is intentionally not impacted by this document.  It remains (per 8179) The calculation of latency is implementation dependent. For example, the latency may be a running average calculated from the internal queuing. > AB> furthermore, the RFC8175 mentions change in metrics what kind of > reaction, so within this draft cases, if the latency was the metric > what value will be used (max, avg, min,...) may need to be specified > in the draft. the draft says:    Maximum Latency:       A 64-bit unsigned integer, representing the longest transmission       delay, in microseconds, that a packet encounters as it is       transmitted over the link.    Minimum Latency:       A 64-bit unsigned integer, representing the shortest transmission       delay, in microseconds, that a packet encounters as it is       transmitted over the link. What change/addition would you like to see? Thanks, Lou > > > Best Regards > AB > > > > On Thu, Feb 15, 2018 at 1:36 AM, Lou Berger > wrote: > > Hi, > > This version addresses all comments received (to date) during WG > LC with one exception.  The one exception was a private > question/comment on how to handle latency that may be queue > specific.  As this extension is independent of queue definition > (which introduced in pause and credit extensions) and the same > question applies to other link metrics, it was my opinion that > queue specific metrics are beyond the scope of this draft and > really warrants a new extension in its own rights.  Given this was > raised privately during LC and not specifically addressed in this > version, I thought it important to mention  on list. > > All other comments were discussed on list. See below for a link to > see these diffs. > > Lou > > > On 2/14/2018 6:27 PM, internet-drafts@ietf.org > wrote: > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Mobile Ad-hoc Networks WG of > the IETF. > >          Title           : DLEP Latency Range Extension >          Authors         : Bow-Nan Cheng >                            Lou Berger >         Filename        : > draft-ietf-manet-dlep-latency-extension-02.txt >         Pages           : 5 >         Date            : 2018-02-14 > > Abstract: >     This document defines an extension to the DLEP protocol to > provide >     the range of latency that may be experienced on a link. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-latency-extension/ > > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-manet-dlep-latency-extension-02 > > https://datatracker.ietf.org/doc/html/draft-ietf-manet-dlep-latency-extension-02 > > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-latency-extension-02 > > > > Please note that it may take a couple of minutes from the time > of submission > until the htmlized version and diff are available at > tools.ietf.org . > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > From nobody Mon Feb 19 14:07:15 2018 Return-Path: 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 5FDF7126DCA for ; Mon, 19 Feb 2018 14:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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] autolearn=ham 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 c-qkElwt13Uw for ; Mon, 19 Feb 2018 14:07:11 -0800 (PST) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 659331241FC for ; Mon, 19 Feb 2018 14:07:11 -0800 (PST) Received: from cmgw2 (unknown [10.0.90.83]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 219011E0C00 for ; Mon, 19 Feb 2018 15:07:11 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id Cm771x00X2SSUrH01m7Akr; Mon, 19 Feb 2018 15:07:11 -0700 X-Authority-Analysis: v=2.2 cv=TIA1cxta c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=Op4juWPpsa0A:10 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=3XOiZPIFiXaC_LTroNgA:9 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22 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=Cz+amYm4MbRbsAhJlkS+xCx9i8wVkhNuv78mphyD+uA=; b=hdQNIKlUpN8nTiXPKLPjNPEpa/ 76KIz3vTwkZGU4g3rXGJBkb3VCijQOGOy7dqlOCfvFEjnMdL4gJE4L/mY293v0EHiWwtvsE43MUkY oUtu7jtq68yKCs5bJs0ZVo/cy; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:47664 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1entaV-003Gvh-7l; Mon, 19 Feb 2018 15:07:07 -0700 To: Rick Taylor , "abdussalambaryun@gmail.com" Cc: "manet@ietf.org" , "draft-ietf-manet-dlep-latency-extension@ietf.org" References: <151865086912.7521.1302513672018061966@ietfa.amsl.com> <1519040685.4538.10.camel@tropicalstormsoftware.com> From: Lou Berger Message-ID: <2da288f6-4805-c4b2-870d-854964eb4d8f@labn.net> Date: Mon, 19 Feb 2018 17:07:03 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1519040685.4538.10.camel@tropicalstormsoftware.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: 100.15.86.101 X-Exim-ID: 1entaV-003Gvh-7l X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:47664 X-Source-Auth: lberger@labn.net X-Email-Count: 6 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 22:07:13 -0000 On 2/19/2018 6:44 AM, Rick Taylor wrote: > Hi Lou, > > AB raises a good point about behaviour when one peer does not support > the extension. I think I missed his point on this.  But there is no issue here, per standard 8179 processing, if one peer doesn't support the extension it isn't used.  What else needs to be said? > In the LID extension draft, I have tried to add normative text that > describes how an implementation supports core DLEP when it does layer-3 > routing. I think a quick sentence describing how the core Latency > metric should be used when this extension is in use, and not in use > might be beneficial. in this extension 8179 behavior continues even when the extension is used, so I'm not sure what the concern is for this draft. Cheers, Lou > > Cheers, > > Rick > > On Mon, 2018-02-19 at 01:23 +0200, Abdussalam Baryun wrote: >> Hi Lou, >> >> Thanks for your updates. I am sorry that I did not comment on the >> draft before, however, this is my thought, >> >> in section 3: >> >> draft>The Latency Range Data Item serves much the same purpose as >> the >> Latency Data Item defined in [RFC8175] with the addition of being >> able to communicate the latency range that may be experienced by >> traffic on a link. >> >> AB> IMO, or understanding, latency range is not one value, but two >> values, so how can two values be same in the purpose of one value of >> latency? maybe the draft should discuss that for clarification, >> because I did not understand. >> >> >> AB> this draft does not say what will happen to the data item latency >> of RFC8175 (type code 16), because in RFC8175 says such messages MUST >> contain one value of .... and states the latency item, not the >> latency-range. Some sections after 12.6 does not mention the >> dlep support of such extension what will happen, so IMO this darft >> should say how the replacement of Latency item, >> >> AB> as this draft may need to say that if the extension is supported >> then latency range item replaces the latency item, or it may say that >> the maximum latency value is used into the latency item value. Not >> sure which approach is better. >> >> AB> My problem in understanding the draft, is that if this draft is >> supported as mentioned in section-12.6 in the RFC8175 then it MUST be >> contained in that message. So this needs to be said again I think in >> this draft (because the draft now says: MAY be carry). >> >> draft> The Latency Range Data Item MAY be carried in the >> same messages and MUST be processed according to the same rules as >> the Latency Data Item defined in [RFC8175]. >> >> AB> same rules, but we have two values, one max-latency and one min- >> latency, please clarify, >> >> AB> as mentioned above ''same rules as latency'' but what will happen >> to this latency item while it is a MUST in many messages, what will >> be the value, but Latency range is a MAY. >> >> AB> so I may suggest the value of the range for the draft's item and >> that the latecy iten in rfc8175 contains the max-latency, or any you >> suggest to clarify it. >> >> AB> furthermore, the RFC8175 mentions change in metrics what kind of >> reaction, so within this draft cases, if the latency was the metric >> what value will be used (max, avg, min,...) may need to be specified >> in the draft. >> >> >> Best Regards >> AB >> >> >> >> On Thu, Feb 15, 2018 at 1:36 AM, Lou Berger wrote: >>> Hi, >>> >>> This version addresses all comments received (to date) during WG LC >>> with one exception. The one exception was a private >>> question/comment on how to handle latency that may be queue >>> specific. As this extension is independent of queue definition >>> (which introduced in pause and credit extensions) and the same >>> question applies to other link metrics, it was my opinion that >>> queue specific metrics are beyond the scope of this draft and >>> really warrants a new extension in its own rights. Given this was >>> raised privately during LC and not specifically addressed in this >>> version, I thought it important to mention on list. >>> >>> All other comments were discussed on list. See below for a link to >>> see these diffs. >>> >>> Lou >>> >>> >>> On 2/14/2018 6:27 PM, internet-drafts@ietf.org wrote: >>>> A New Internet-Draft is available from the on-line Internet- >>>> Drafts directories. >>>> This draft is a work item of the Mobile Ad-hoc Networks WG of the >>>> IETF. >>>> >>>> Title : DLEP Latency Range Extension >>>> Authors : Bow-Nan Cheng >>>> Lou Berger >>>> Filename : draft-ietf-manet-dlep-latency- >>>> extension-02.txt >>>> Pages : 5 >>>> Date : 2018-02-14 >>>> >>>> Abstract: >>>> This document defines an extension to the DLEP protocol to >>>> provide >>>> the range of latency that may be experienced on a link. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-latency-ex >>>> tension/ >>>> >>>> There are also htmlized versions available at: >>>> https://tools.ietf.org/html/draft-ietf-manet-dlep-latency-extensi >>>> on-02 >>>> https://datatracker.ietf.org/doc/html/draft-ietf-manet-dlep-laten >>>> cy-extension-02 >>>> >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-latency-e >>>> xtension-02 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at >>>> tools.ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>>> >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet From nobody Mon Feb 19 18:20:06 2018 Return-Path: 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 580AB126D73; Mon, 19 Feb 2018 18:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 B0yCx05lJmaB; Mon, 19 Feb 2018 18:20:01 -0800 (PST) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 037CB1243FE; Mon, 19 Feb 2018 18:20:01 -0800 (PST) Received: by mail-oi0-x231.google.com with SMTP id f186so1487214oig.4; Mon, 19 Feb 2018 18:20:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rIvkqRkq0wkOi96/syr+K1zSsbij5au3qlfiqwvHZec=; b=OjB1q1dkFhcn8igAWmv9TCUYj1Z5S2eccN4KsjdRxHJAn988HyJTUD2ScSBITzjUCa n2o2CA2ysMr4mrqhUTI4MIgTv04JYLZ7HJXOAeCNbRaeBuwelkJlbvAsEmbYXpZ/zbIe NpAeNLk1oyiLWw49a2oWzNsfFiazToN2rxuhrcC+W90Ohm7WmchokTWo4g6nS0U70JgK 2r7q1qXGYASXnf5VDR8UJuagEi2hPdYek7b0EUrXx2KDbNw7oM6t1d8jKrijmjkd9tny 5r0A3EyjCfIn8y+K59NXrAEUKOt/pdJQSBVlMFfvhXyPQAihoBMNNbvlXeZyRQ0wOXiU BPvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rIvkqRkq0wkOi96/syr+K1zSsbij5au3qlfiqwvHZec=; b=FaeF5xNp8Ku7SWm+OWaTDII3OJBSTe4GJ1RCE7W59GPgMdywy6jdofiapsQudukhCR r5/ygpsAyobLCGSL55DDD4WlfiiO2pHScmm3h3JKtXD5uz+qAgtCOMPdyn1TrEg7V79M 5Hc+I7+DQLWUAtVxQegJ4Xmi7BjzonbPu76/1EFrY7fN4Od0ea0Ravilve3FWV4/pM/K pQscWOQwJLrrKewdzNv3k25ci45isnHzzBqh5nS8WQA7isZfWNAeKezKMUTd9MckIQ9t eD7AkIyGZ2IMIEINvjpd8eoI+xX+zz9mJGZCpI9tduDFTV2HxmOR4hySoHmcpBGLHlGe kynA== X-Gm-Message-State: APf1xPBLfxRjLABR6pIawelcOIVtp6rQbQk6DrfWObXYTHcQg4+ZU4Qd C6L7tcWHcL6W3k85zM5yOps4KfOPi/7G7QHoTDpUHA== X-Google-Smtp-Source: AH8x226G7OiUlJ8N6aVVpZJBBbJbL3sYD7OsC0eQjCYMxFFACEb1kFYs4flMKkfLRmAtei5MlLrtk7cmszBpPcdScOg= X-Received: by 10.202.204.203 with SMTP id c194mr12222923oig.156.1519093200263; Mon, 19 Feb 2018 18:20:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.36 with HTTP; Mon, 19 Feb 2018 18:19:59 -0800 (PST) In-Reply-To: References: <151865086912.7521.1302513672018061966@ietfa.amsl.com> From: Abdussalam Baryun Date: Tue, 20 Feb 2018 04:19:59 +0200 Message-ID: To: Lou Berger Cc: manet , draft-ietf-manet-dlep-latency-extension@ietf.org Content-Type: multipart/alternative; boundary="001a1134f342951f7205659b722f" Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 02:20:04 -0000 --001a1134f342951f7205659b722f Content-Type: text/plain; charset="UTF-8" Hi Lou, I will try to clarify my concerns below, however, the main issue is the question: Does the Range Latency item Cannot appear in any message without Latency item? I prefer not, but please help me to know why if yes. On Tue, Feb 20, 2018 at 12:04 AM, Lou Berger wrote: > Hi AB, > > See below. > > > On 2/18/2018 6:23 PM, Abdussalam Baryun wrote: > >> Hi Lou, >> >> Thanks for your updates. I am sorry that I did not comment on the draft >> before, however, this is my thought, >> >> in section 3: >> >> draft>The Latency Range Data Item serves much the same purpose as the >> Latency Data Item defined in [RFC8175 > fc8175>] with the addition of being >> able to communicate the latency range that may be experienced by >> traffic on a link. >> >> AB> IMO, or understanding, latency range is not one value, but two >> values, so how can two values be same in the purpose of one value of >> latency? maybe the draft should discuss that for clarification, because I >> did not understand. >> >> > So per 8175: > > > The Latency Data Item is used to indicate the amount of latency, in > microseconds, on the link. > > > so 8175 defines a single point definition of "the amount of latency ... > on the link" while this draft defines a range for latency "that may be > experienced by traffic on a link". Nether say how this is to be used. > > I'm not sure what more is to be said on this. Do you have an proposed > language? AB> I think that Latency Range Data Item does not serve the same purpose as the Latency Data Item, because by requests of the router that data of Latency is used differently from Latency Range. If you agree, I may suggest deleting the words ''same purpose'', maybe replaced by '' additional related information''. It will be good to show/add/write about: the importance of range because the link may have same latency but different ranges which affects performance of routing (maybe one line to show that the range information is related to latency and give it more meaning in terms of performance). > > > >> AB> this draft does not say what will happen to the data item latency of >> RFC8175 (type code 16), because in RFC8175 says such messages MUST contain >> one value of .... and states the latency item, not the latency-range. Some >> sections after 12.6 does not mention the dlep support of such extension >> what will happen, so IMO this darft should say how the replacement of >> Latency item, >> > > it's not a replacement. It is sent in addition. As is generally the case > in extension RFCs, if a modification to an existing RFC is not stated > explicitly, there is no such modification. But IMO it is not clear where the Latency Range item operates within 8175, > I do agree that if the new data item were to be sent in place of the old > one (a) this should be made very explicit and (b) this document would be an > update to RFC8175. > Yes, ok, so I understand that both items can be independent, (my first read thought they are dependent some how). > > see the next response > >> >> AB> as this draft may need to say that if the extension is supported then >> latency range item replaces the latency item, or it may say that the >> maximum latency value is used into the latency item value. Not sure which >> approach is better. >> > > The document doesn't modify the existing latency data item. > ok, > > Is it worth adding a sentence to the end of section 2 along the lines of: > > Note: the usage of the extension defined in this document does not impact > processing associated with the Latency Data Item defined in Section 13.6 of > [rfc8175]. > I think it will be easier to understand, specially when we say in the draft they follow same rules in 8175, so maybe better without section number, new note> the usage of the extension defined in this document does not impact processing associated with the Latency Data Item. > > Seems pretty obvious, but also a benign addition > >> >> AB> My problem in understanding the draft, is that if this draft is >> supported as mentioned in section-12.6 in the RFC8175 then it MUST be >> contained in that message. So this needs to be said again I think in this >> draft (because the draft now says: MAY be carry). >> >> draft> The Latency Range Data Item MAY be carried in the >> same messages and MUST be processed according to the same rules as >> the Latency Data Item defined in [RFC8175 < >> https://tools.ietf.org/html/rfc8175>]. >> >> > can you elaborate on what specific changes you'd like to see? AB> I mean in the draft says MAY be carried in same messages that carry Latency item. I think this makes the Range item dependent some how. The question is do you allow one message to carry Range item but without Latency item. I think you don't mean that, but you mean MAY carry range item similar to the messages types that MAY carry latency item. AB> I prefer that this draft clarifies Range item independently in all possible messages as: *Session Initialization Response Message* (MUST carry) *Session Update Message *(MAY Carry) *Destination Up Message *(MAY Carry) *Destination Announce Response Message *(MAY Carry) *Destination Update Message *(MAY Carry) *Link Characteristics Response Message *(SHOULD carry) (.......may be others ,,,........) AB> also if the Latency Range is used as a metric, what is the > AB> same rules, but we have two values, one max-latency and one >> min-latency, please clarify, >> >> It's one data item. RFC8179 defines when and how the data item is sent, > not how the latency value is set or used. This is the same for the > extension. > > AB> as mentioned above ''same rules as latency'' but what will happen to >> this latency item while it is a MUST in many messages, what will be the >> value, but Latency range is a MAY. >> >> Correct. An implementation MAY choose to include a Latency Range Data > Item where it includes a Latency Data Item. ok > > > AB> so I may suggest the value of the range for the draft's item and that >> the latecy iten in rfc8175 contains the max-latency, or any you suggest to >> clarify it. >> >> rfc8175 latency data item is intentionally not impacted by this > document. It remains (per 8179) > > The calculation > of latency is implementation dependent. For example, the latency may > be a running average calculated from the internal queuing. ok > > > > AB> furthermore, the RFC8175 mentions change in metrics what kind of >> reaction, so within this draft cases, if the latency was the metric what >> value will be used (max, avg, min,...) may need to be specified in the >> draft. >> > > the draft says: > > Maximum Latency: > > A 64-bit unsigned integer, representing the longest transmission > delay, in microseconds, that a packet encounters as it is > transmitted over the link. > > Minimum Latency: > > A 64-bit unsigned integer, representing the shortest transmission > delay, in microseconds, that a packet encounters as it is > transmitted over the link. > > What change/addition would you like to see? > The addition maybe is what will happen when Range changes, we can say it will follow similar rules in 8175 of the latency item. thank for your explanation, Best Regards, AB > > --001a1134f342951f7205659b722f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Lou,

I will try to clarif= y my concerns below, however, the main issue is the question:=C2=A0Does the= Range Latency item Cannot appear in any message without Latency item? I pr= efer not, but please help me to know why if yes.

On Tue, Feb 20, 2018 at 12:04 AM, Lou= Berger <lberger@labn.net> wrote:
Hi AB,<= br>
See below.


On 2/18/2018 6:23 PM, Abdussalam Baryun wrote:
Hi Lou,

Thanks for your updates. I am sorry that I did not comment on the draft bef= ore, however, this is my thought,

in section 3:

=C2=A0draft>The Latency Range Data Item serves much the same purpose as = the
 =C2=A0=C2=A0 Latency Data Item defined in [RFC8175 <https://to= ols.ietf.org/html/rfc8175>] with the addition of being =C2=A0=C2=A0 able to communicate the latency range that may be experienced = by
=C2=A0=C2=A0 traffic on a link.

AB> IMO, or understanding, =C2=A0latency range is not one value, but two= values, so how can two values be same in the purpose of one value of laten= cy? maybe the draft should discuss that for clarification, because I did no= t understand.


So per 8175:


=C2=A0 =C2=A0The Latency Data Item is used to indicate the amount of latenc= y, in
=C2=A0 =C2=A0microseconds, on the link.


so=C2=A0 8175 defines a single point definition of "the amount of late= ncy ... on the link" while this draft defines a range for latency &quo= t;that may be experienced by traffic on a link".=C2=A0 Nether say how = this is to be used.

I'm not sure what more is to be said on this.=C2=A0 Do you have an prop= osed language?

AB> I think=C2=A0that Lat= ency Range Data Item does not serve the same purpose as the Latency Data It= em, because by=C2=A0requests of the router that data of Latency=C2=A0is use= d differently from Latency Range.=C2=A0If you agree, I may suggest deleting= the words ''same=C2=A0purpose'',=C2=A0maybe replaced by &#= 39;'=C2=A0additional related information''. It will be good to = show/add/write about:=C2=A0the importance of range because the link may hav= e same latency but different ranges which affects performance of routing (m= aybe one line to show that the range information is related to latency and = give it more meaning in terms of performance).
=


AB> this draft does not say what will happen to the data item latency of= RFC8175 (type code 16), because in RFC8175 says=C2=A0such messages=C2=A0MU= ST contain one value of .... and states the latency item, not the latency-r= ange. Some sections after 12.6 does not mention the dlep=C2=A0support of su= ch extension what will happen, so IMO this darft should say how the replace= ment of Latency item,

 it's not a replacement.=C2=A0 It is sent in addition.=C2=A0 As is gener= ally the case in extension RFCs, if a modification to an existing RFC is no= t stated explicitly, there is no such modification.=C2=A0
=
But IMO it is not clear where the Latency Range item operate= s within 8175,

=C2=A0
I do= agree that if the new data item were to be sent in place of the old one (a= ) this should be made very explicit and (b) this document would be an updat= e to RFC8175.

Yes, ok, so I understand = that both items can be independent, (my first read thought they are depende= nt some how).
=C2=A0=C2=A0

see the next response

AB> as this draft may need to say=C2=A0that if the extension is supporte= d then latency range item replaces the latency item, or it may say that the= maximum latency value is used into the latency item value. Not sure which = approach is better.

 The document doesn't modify the existing latency data item.

ok,
=C2=A0

Is it worth adding a sentence to the end of section 2 along the lines of:
Note: the usage of the extension defined in this document does not impact p= rocessing associated with the Latency Data Item defined in Section 13.6 of = [rfc8175].

I think it will be easier to= understand, specially when we say in the draft they follow same rules in 8= 175,=C2=A0

so maybe better without section number,=

new note> the usage of the extension defined i= n this document does not impact processing associated with the Latency Data= Item.

Seems pretty obvious, but also a benign addition

AB> =C2=A0My problem in understanding the draft, is that if this draft i= s supported as mentioned in section-12.6 in the RFC8175 then it MUST be con= tained=C2=A0in that message. So this needs to be said again=C2=A0I think in= this draft (because the draft now says: MAY be carry).

draft> =C2=A0The Latency Range Data Item MAY be carried in the
=C2=A0=C2=A0 same messages and MUST be processed according to the same rule= s as
 =C2=A0=C2=A0 the Latency Data Item defined in [RFC8175 <https:= //tools.ietf.org/html/rfc8175>].


can you elaborate on what specific changes you'd like to see?

AB> I mean in the draft says MAY be carried in sa= me messages that carry Latency item. I think this makes the Range item depe= ndent some how. The question is do you allow one message to carry Range ite= m but without Latency item. I think you don't mean that, but you mean M= AY carry range item similar to the messages types that MAY carry latency it= em.

=C2=A0AB> I prefer that this draft clarifie= s Range item independently in all possible =C2=A0messages as:
Session Initialization Response Message=C2=A0=C2=A0 (MUST carry)
Session Update Message=C2= =A0=C2=A0=C2=A0 (MAY Carry)
Destination Up Messa= ge=C2=A0=C2=A0=C2=A0 (MAY Carry)
De= stination Announce Response Message=C2=A0=C2=A0 (MAY Carry)<= /span>
Destination Update Message=C2=A0=C2=A0=C2=A0 (MAY Carry)
Link Characteristics Respons= e Message=C2=A0=C2=A0=C2=A0=C2=A0(SHOULD carry)
(.......= may be others ,,,........)


AB> a= lso if the Latency Range is used as a metric, what is the






=C2=A0
AB> same rules, but we have two values, one max-latency and one min-late= ncy, please clarify,

 It's one data item.=C2=A0 RFC8179 defines when and how the data item is= sent, not how the latency value is set or used.=C2=A0 This is the same for= the extension.

AB> as mentioned above ''same rules as latency'' but wha= t will happen to this latency item while it is a MUST in many messages, wha= t will be the value, but Latency range is a MAY.

 Correct.=C2=A0 An implementation MAY choose to include a Latency Range Data= Item where it includes a Latency Data Item.

ok=C2=A0


AB> so=C2=A0I may suggest the value of the range for the draft's ite= m and that the latecy iten in rfc8175 contains the max-latency, or any you = suggest to clarify it.

 rfc8175 latency data item is intentionally not impacted by this document.= =C2=A0 It remains (per 8179)

=C2=A0 =C2=A0The calculation
=C2=A0 =C2=A0of latency is implementation dependent.=C2=A0 For example, the= latency may
=C2=A0 =C2=A0be a running average calculated from the internal queuing.

ok=C2=A0



AB> furthermore, the RFC8175 mentions change in metrics what kind of rea= ction, so within this draft cases, if the latency was the metric what value= will be used (max, avg, min,...) may need to be specified in the draft.

the draft says:

=C2=A0=C2=A0 Maximum Latency:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A 64-bit unsigned integer, representing the = longest transmission
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 delay, in microseconds, that a packet encoun= ters as it is
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 transmitted over the link.

=C2=A0=C2=A0 Minimum Latency:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A 64-bit unsigned integer, representing the = shortest transmission
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 delay, in microseconds, that a packet encoun= ters as it is
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 transmitted over the link.

What change/addition would you like to see?

=
The addition maybe is=C2=A0what will happen when Range changes, we can= say it will follow similar rules in 8175=C2=A0of the latency item.

=C2=A0thank for your explanation,

Best Regards,

AB=C2=A0

--001a1134f342951f7205659b722f-- From nobody Tue Feb 20 01:44:21 2018 Return-Path: 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 41D9E127077; Tue, 20 Feb 2018 01:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 KCEvKFwj0kpS; Tue, 20 Feb 2018 01:44:18 -0800 (PST) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0999124239; Tue, 20 Feb 2018 01:44:17 -0800 (PST) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Tue, 20 Feb 2018 09:44:10 +0000 From: Rick Taylor To: "abdussalambaryun@gmail.com" , "lberger@labn.net" CC: "manet@ietf.org" , "draft-ietf-manet-dlep-latency-extension@ietf.org" Thread-Topic: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt Thread-Index: AQHTpeuLyTOgGDggRE6oXD83soFJ16OkjYSAgAZFtQCAAM8CgIAArd+AgADCwIA= Date: Tue, 20 Feb 2018 09:44:05 +0000 Message-ID: <1519119845.4538.13.camel@tropicalstormsoftware.com> References: <151865086912.7521.1302513672018061966@ietfa.amsl.com> <1519040685.4538.10.camel@tropicalstormsoftware.com> <2da288f6-4805-c4b2-870d-854964eb4d8f@labn.net> In-Reply-To: <2da288f6-4805-c4b2-870d-854964eb4d8f@labn.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: <108b54e5-005d-44d8-8d1a-59c9a0861d09> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 09:44:19 -0000 SGkgTG91LA0KDQpPbiBNb24sIDIwMTgtMDItMTkgYXQgMTc6MDcgLTA1MDAsIExvdSBCZXJnZXIg d3JvdGU6DQo+IA0KPiBPbiAyLzE5LzIwMTggNjo0NCBBTSwgUmljayBUYXlsb3Igd3JvdGU6DQo+ ID4gSGkgTG91LA0KPiA+IA0KPiA+IEFCIHJhaXNlcyBhIGdvb2QgcG9pbnQgYWJvdXQgYmVoYXZp b3VyIHdoZW4gb25lIHBlZXIgZG9lcyBub3QNCj4gPiBzdXBwb3J0DQo+ID4gdGhlIGV4dGVuc2lv bi4NCj4gDQo+IEkgdGhpbmsgSSBtaXNzZWQgaGlzIHBvaW50IG9uIHRoaXMuICBCdXQgdGhlcmUg aXMgbm8gaXNzdWUgaGVyZSwgcGVyIA0KPiBzdGFuZGFyZCA4MTc5IHByb2Nlc3NpbmcsIGlmIG9u ZSBwZWVyIGRvZXNuJ3Qgc3VwcG9ydCB0aGUgZXh0ZW5zaW9uDQo+IGl0IA0KPiBpc24ndCB1c2Vk LiAgV2hhdCBlbHNlIG5lZWRzIHRvIGJlIHNhaWQ/DQo+IA0KPiA+IEluIHRoZSBMSUQgZXh0ZW5z aW9uIGRyYWZ0LCBJIGhhdmUgdHJpZWQgdG8gYWRkIG5vcm1hdGl2ZSB0ZXh0IHRoYXQNCj4gPiBk ZXNjcmliZXMgaG93IGFuIGltcGxlbWVudGF0aW9uIHN1cHBvcnRzIGNvcmUgRExFUCB3aGVuIGl0 IGRvZXMNCj4gPiBsYXllci0zDQo+ID4gcm91dGluZy4gIEkgdGhpbmsgYSBxdWljayBzZW50ZW5j ZSBkZXNjcmliaW5nIGhvdyB0aGUgY29yZSBMYXRlbmN5DQo+ID4gbWV0cmljIHNob3VsZCBiZSB1 c2VkIHdoZW4gdGhpcyBleHRlbnNpb24gaXMgaW4gdXNlLCBhbmQgbm90IGluIHVzZQ0KPiA+IG1p Z2h0IGJlIGJlbmVmaWNpYWwuDQo+IA0KPiBpbiB0aGlzIGV4dGVuc2lvbiA4MTc5IGJlaGF2aW9y IGNvbnRpbnVlcyBldmVuIHdoZW4gdGhlIGV4dGVuc2lvbiBpcyANCj4gdXNlZCwgc28gSSdtIG5v dCBzdXJlIHdoYXQgdGhlIGNvbmNlcm4gaXMgZm9yIHRoaXMgZHJhZnQuDQoNCk9rYXksIG9uIHJl LXJlYWRpbmcsIEknbSBoYXBweSB3aXRoIHRoZSB0ZXh0IGFzIGlzLg0KDQpDaGVlcnMsDQoNClJp Y2sNCg== From nobody Tue Feb 20 08:54:00 2018 Return-Path: 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 E8F13129C59 for ; Tue, 20 Feb 2018 08:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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] 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 GHrvzKcUcCtO for ; Tue, 20 Feb 2018 08:53:58 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (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 9CDA01276AF for ; Tue, 20 Feb 2018 08:53:58 -0800 (PST) Received: from CMOut01 (unknown [10.0.90.82]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id 052B72166EB for ; Tue, 20 Feb 2018 09:53:10 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id D4t61x00D2SSUrH014t9Bm; Tue, 20 Feb 2018 09:53:09 -0700 X-Authority-Analysis: v=2.2 cv=Rf/gMxlv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=Op4juWPpsa0A:10 a=xq5j0dqVUvJziLuX3zcA:9 a=QEXdDO2ut3YA:10 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=Zx+1Q0B0QKEunRlrQWuyeILM5/3l5PszTSBWv26tmNY=; b=xRD1YIno/ZvuF+Kfhlw0Cr0T9S TnhL4XQJHYz1CeQzx2hLeSbXbvcotMwnDSfCbRYMOBpYfhfyXS47cOTnJMnCGXyuqJ+6fs0PTm+vE O2NerTRDN4y3XicyUVN8tKYxo; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:45432 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1eoBA9-000i4D-Ul; Tue, 20 Feb 2018 09:53:06 -0700 To: Rick Taylor , "abdussalambaryun@gmail.com" Cc: "manet@ietf.org" , "draft-ietf-manet-dlep-latency-extension@ietf.org" References: <151865086912.7521.1302513672018061966@ietfa.amsl.com> <1519040685.4538.10.camel@tropicalstormsoftware.com> <2da288f6-4805-c4b2-870d-854964eb4d8f@labn.net> <1519119845.4538.13.camel@tropicalstormsoftware.com> From: Lou Berger Message-ID: <17b61e40-3c67-d062-9447-fac38644aea8@labn.net> Date: Tue, 20 Feb 2018 11:53:04 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1519119845.4538.13.camel@tropicalstormsoftware.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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: 100.15.86.101 X-Exim-ID: 1eoBA9-000i4D-Ul X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:45432 X-Source-Auth: lberger@labn.net X-Email-Count: 8 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 16:54:00 -0000 On 2/20/2018 4:44 AM, Rick Taylor wrote: > Okay, on re-reading, I'm happy with the text as is. Thanks, Rick... Lou From nobody Tue Feb 20 09:42:24 2018 Return-Path: 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 90713126E01 for ; Tue, 20 Feb 2018 09:42:22 -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=ham 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 5OillGVKOiZG for ; Tue, 20 Feb 2018 09:42:20 -0800 (PST) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) (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 9645E126CC7 for ; Tue, 20 Feb 2018 09:42:20 -0800 (PST) Received: from cmgw2 (unknown [10.0.90.83]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id 743A5140642 for ; Tue, 20 Feb 2018 10:42:10 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id D5i61x00g2SSUrH015i9PF; Tue, 20 Feb 2018 10:42:10 -0700 X-Authority-Analysis: v=2.2 cv=TIA1cxta c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=Op4juWPpsa0A:10 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=IM51pB5UNAyc8fLHj7wA:9 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22 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=O5Rmc+x7seEVckpeEEHyU9unxVkY2myBGq2vvGcFwdM=; b=HWKfjqqE9h/r7fJ7BkF0mVjdNv VskEko/T4Q8Zxe1hfC/159zKsw8lbSqSnebVV1zp8P1KZyTb1+z12b0P97WEnwc20WK/9IFAlwX1S c9C4SG2DQjTxr6Lm+X76KFxKY; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:49692 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1eoBva-00101T-Id; Tue, 20 Feb 2018 10:42:06 -0700 To: Abdussalam Baryun Cc: manet , draft-ietf-manet-dlep-latency-extension@ietf.org References: <151865086912.7521.1302513672018061966@ietfa.amsl.com> From: Lou Berger Message-ID: <1b0c761b-9fda-49e0-8344-52750c232b74@labn.net> Date: Tue, 20 Feb 2018 12:42:04 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: 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: 100.15.86.101 X-Exim-ID: 1eoBva-00101T-Id X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:49692 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 17:42:23 -0000 Hi AB, see below. On 2/19/2018 9:19 PM, Abdussalam Baryun wrote: > Hi Lou, > > I will try to clarify my concerns below, however, the main issue is > the question: Does the Range Latency item Cannot appear in any message > without Latency item? This document doesn't make this requirement.  Per 8175, there are cases where the existing Latency Data Item is optional, so it is possible for an implementation to send the extension data item but not a latency data item.  This is up to the implementation. > I prefer not, but please help me to know why if yes. > > On Tue, Feb 20, 2018 at 12:04 AM, Lou Berger > wrote: > > Hi AB, > > See below. > > > On 2/18/2018 6:23 PM, Abdussalam Baryun wrote: > > Hi Lou, > > Thanks for your updates. I am sorry that I did not comment on > the draft before, however, this is my thought, > > in section 3: > >  draft>The Latency Range Data Item serves much the same > purpose as the >    Latency Data Item defined in [RFC8175 > >] with the addition of being >    able to communicate the latency range that may be > experienced by >    traffic on a link. > > AB> IMO, or understanding,  latency range is not one value, > but two values, so how can two values be same in the purpose > of one value of latency? maybe the draft should discuss that > for clarification, because I did not understand. > > > So per 8175: > > >    The Latency Data Item is used to indicate the amount of latency, in >    microseconds, on the link. > > > so  8175 defines a single point definition of "the amount of > latency ... on the link" while this draft defines a range for > latency "that may be experienced by traffic on a link".  Nether > say how this is to be used. > > I'm not sure what more is to be said on this.  Do you have an > proposed language? > > > AB> I think that Latency Range Data Item does not serve the same > purpose as the Latency Data Item, because by requests of the router > that data of Latency is used differently from Latency Range. The text is "much the same"  - if you prefer we can change this to "parallel" not that this informative text not normative so no specific processing is implied. >  If you agree, I don't.  I think you are reading to much into this informative text. > I may suggest deleting the words ''same purpose'', maybe replaced by > '' additional related information''. It will be good to show/add/write > about: the importance of range because the link may have same latency > but different ranges which affects performance of routing (maybe one > line to show that the range information is related to latency and give > it more meaning in terms of performance). > > There is no parallel text in 8175 specifically for the latency DI so I'm not sure why we'd add it here. > > > AB> this draft does not say what will happen to the data item > latency of RFC8175 (type code 16), because in RFC8175 > says such messages MUST contain one value of .... and states > the latency item, not the latency-range. Some sections after > 12.6 does not mention the dlep support of such extension what > will happen, so IMO this darft should say how the replacement > of Latency item, > > > it's not a replacement.  It is sent in addition.  As is generally > the case in extension RFCs, if a modification to an existing RFC > is not stated explicitly, there is no such modification. > > > But IMO it is not clear where the Latency Range item operates within > 8175, > The draft currently says:      The Latency Range Data Item MAY be carried in the same messages ... as  the Latency Data Item defined in [RFC8175]. Is this not sufficient? >  ... > Is it worth adding a sentence to the end of section 2 along the > lines of: > > Note: the usage of the extension defined in this document does not > impact processing associated with the Latency Data Item defined in > Section 13.6 of [rfc8175]. > > > I think it will be easier to understand, specially when we say in the > draft they follow same rules in 8175, > > so maybe better without section number, > sure... > new note> the usage of the extension defined in this document does not > impact processing associated with the Latency Data Item. > > Seems pretty obvious, but also a benign addition > > > AB>  My problem in understanding the draft, is that if this > draft is supported as mentioned in section-12.6 in the RFC8175 > then it MUST be contained in that message. So this needs to be > said again I think in this draft (because the draft now says: > MAY be carry). > > draft>  The Latency Range Data Item MAY be carried in the >    same messages and MUST be processed according to the same > rules as >    the Latency Data Item defined in [RFC8175 > >]. > > > can you elaborate on what specific changes you'd like to see? > > > AB> I mean in the draft says MAY be carried in same messages that > carry Latency item. I think this makes the Range item dependent some > how. The question is do you allow one message to carry Range item but > without Latency item. yes. for example latency is optional in Session Update Message, e.g., this covers the case where the range changes but the base latency does not.  I don't see any issue with this. > I think you don't mean that, but you mean MAY carry range item similar > to the messages types that MAY carry latency item. > >  AB> I prefer that this draft clarifies Range item independently in > all possible  messages as: > > *Session Initialization Response Message* (MUST carry) > *Session Update Message *(MAY Carry) > *Destination Up Message *(MAY Carry) > *Destination Announce Response Message *(MAY Carry) > *Destination Update Message *(MAY Carry) > *Link Characteristics Response Message *(SHOULD carry) > (.......may be others ,,,........) > > If we had BNF in the document, I agree that the BNF would need to be updated.  Since we don't I think this is a bit redundant but of course defer to the WG on this. > AB> also if the Latency Range is used as a metric, what is the > > ?? ... > AB> furthermore, the RFC8175 mentions change in metrics what > kind of reaction, so within this draft cases, if the latency > was the metric what value will be used (max, avg, min,...) may > need to be specified in the draft. > > > the draft says: > >    Maximum Latency: > >       A 64-bit unsigned integer, representing the longest transmission >       delay, in microseconds, that a packet encounters as it is >       transmitted over the link. > >    Minimum Latency: > >       A 64-bit unsigned integer, representing the shortest > transmission >       delay, in microseconds, that a packet encounters as it is >       transmitted over the link. > > What change/addition would you like to see? > > > The addition maybe is what will happen when Range changes, we can say > it will follow similar rules in 8175 of the latency item. >  it says:  The Latency Range Data Item ...  MUST be processed according to the   same rules as the Latency Data Item defined in . Is this not sufficient? Thanks, Lou >  thank for your explanation, > > Best Regards, > > AB > > From nobody Tue Feb 20 09:49:57 2018 Return-Path: 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 AE4CA127909; Tue, 20 Feb 2018 09:49:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151914899368.3895.9790169601653111569@ietfa.amsl.com> Date: Tue, 20 Feb 2018 09:49:53 -0800 Archived-At: Subject: [manet] I-D Action: draft-ietf-manet-dlep-multi-hop-extension-05.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 17:49:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks WG of the IETF. Title : DLEP Multi-Hop Forwarding Extension Authors : Bow-Nan Cheng Lou Berger Filename : draft-ietf-manet-dlep-multi-hop-extension-05.txt Pages : 10 Date : 2018-02-20 Abstract: This document defines an extension to the DLEP protocol that enables the reporting and control of Multi-Hop Forwarding by DLEP capable modems. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-multi-hop-extension/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-manet-dlep-multi-hop-extension-05 https://datatracker.ietf.org/doc/html/draft-ietf-manet-dlep-multi-hop-extension-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-multi-hop-extension-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 20 10:47:28 2018 Return-Path: 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 E1F9612DA09; Tue, 20 Feb 2018 10:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 kPVgK0MoPvEl; Tue, 20 Feb 2018 10:47:23 -0800 (PST) Received: from llmx3.ll.mit.edu (LLMX3.LL.MIT.EDU [129.55.12.49]) by ietfa.amsl.com (Postfix) with ESMTP id 50F1812D96A; Tue, 20 Feb 2018 10:47:22 -0800 (PST) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx3.ll.mit.edu (unknown) with ESMTP id w1KIlLXs036691; Tue, 20 Feb 2018 13:47:21 -0500 From: "Wiggins, David - 0665 - MITLL" To: Lou Berger , Abdussalam Baryun CC: manet , "draft-ietf-manet-dlep-latency-extension@ietf.org" Thread-Topic: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt Thread-Index: AQHTpeuCULBcw8lYE0O2vuJm4DzNVaOk4VaAgAZFtQCAAXwKgIAAR4KAgAEBoAD//75rAA== Date: Tue, 20 Feb 2018 18:47:20 +0000 Message-ID: <4FEB14CD-DE8D-4735-9FCA-8912EB49AB82@ll.mit.edu> References: <151865086912.7521.1302513672018061966@ietfa.amsl.com> <1b0c761b-9fda-49e0-8344-52750c232b74@labn.net> In-Reply-To: <1b0c761b-9fda-49e0-8344-52750c232b74@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.118] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3601979240_1141897982" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-20_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802200225 Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 18:47:26 -0000 --B_3601979240_1141897982 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit On 2/20/18, 12:42 PM, "manet on behalf of Lou Berger" wrote: On 2/19/2018 9:19 PM, Abdussalam Baryun wrote: > But IMO it is not clear where the Latency Range item operates within > 8175, > The draft currently says: The Latency Range Data Item MAY be carried in the same messages ... as the Latency Data Item defined in [RFC8175]. Is this not sufficient? Perhaps AB is reading this as "if a specific, on-the-wire message has a Latency Data Item in it, then that particular message is allowed to have a Latency Range Data Item. Otherwise, it cannot have a Latency Range Data Item. AB, is that your interpretation? If so, then maybe just saying "message types" instead of "messages" is enough clarification. David --B_3601979240_1141897982 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUWQYJKoZIhvcNAQcCoIIUSjCCFEYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EjwwggT1MIID3aADAgECAgplPFVEAAAAAH4VMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTMwHhcNMTYwNDA0MTI0ODMyWhcNMTkwNDA0MTI0ODMyWjBiMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSEwHwYDVQQDExhXaWdnaW5zLkRhdmlkLlAuNTAwMTUyMDcwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDJAb/lYMuBBR+S5pd/D61TZUVFI0iUnE1lDC0JOx9zyPDH inu2X2wN8x3uIO6/2xV9RjnuoORnzTv95Se/rhE7D4AfVZaj/i6oreCoLItIGph0E6Sl3SuA ALy9vHS0G9fCUm72xdOTkc2PqzIHHg8A9uN/pB8OTbktXgQMN/0TLarDF6u2LAswTQ2CxBWJ Hr9u78KA3QOkLWzQeua5aqINaHzYVrih5LTmAxI0B+h6Ug40hEViLRBfjN8jAJg4GF3dr42b GL4oDIS5eKFwSpbUR/jUKWNwoF1eG+jhAWdnUfHo7akVYxajXii9vqLmrsactqPZGu29HnO+ A6aoMM8PAgMBAAGjggG8MIIBuDAdBgNVHQ4EFgQU0xCKedODZWIHRzv1PlQPu4wdGwUwDgYD VR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUH AQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcE MDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAiBgNV HSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMCMGA1UdEQQcMBqBGERhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIE Gh4YAEwATABVAHMAZQByAFMAaQBnAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQB8VMg24SrD vmqbj2l36MyBV02CV/ItcmUxfR8p+oGEGnm1veofenM7m9l3ZR3PHcM8lMQgCUmJrbNvF07G tRkehlflC8nujwv5szRG1lUv8UjYdYr9dFCBnEHGVY/FwQSV7Bz6tVyibQFlqZOnbyTKNmSm phroRbIulo971T4L3a9+2FX8n7PvjqG5Rn4yXNuPqVerQTcZN4pFbbo1lpuOK4wTVKlIvVoW NTfZPTxjbtNwfJYThlFyijTEur3XA1UL6+UoA9230Oz3+qL856RzJKOOBFoxZapor6nzjPDX 1ubAmBcwAlrXWNSzN0euX8wbPiOLSJvQ1LRpZsmJMxtfMIIEvDCCA6SgAwIBAgIBKTANBgkq hkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3Jh dG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRMTCBSb290IENBMB4XDTEzMTIxNzAw MDAwMFoXDTIwMTIzMTIzNTk1OVowUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5j b2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0EtMzCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANowUnVtfLbltbTcRuofAdJKnJBWUAALaBwp L1KVBF+oxbwXfJkCOdxsi2EbgKOB1iaXu/4sxVzn0iQ7OlDOaL7wjn14NmyYA2JQQvSQ3CwR SJ9J6aTrvUb6Y1kosbQuenK8CeVLOUD3bcbSnXpOSyV5dqCsN8PJYoVIsXj28VmndZu2TCim oL5vc08mz+hbpikcXmCY0qQdvnAGI6BhhG0lR8sfLsx5usQKATB8WvG8vsg8/Cc5OrD/YopY D94l0hqAgJocgc75UEOUDTVj/hJqPY8/7pCoWFQf1cHcbaKrjwKp+InwwCGjPXbW9OXMtYFw BUj92f4lJMcgWWVDkX8CAwEAAaOCAZowggGWMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0O BBYEFNdgZg57SY11TA39z0beyMcSh8q/MB8GA1UdIwQYMBaAFGeqes/0Cqa5crWKoNKd8hDD Q+0pMA4GA1UdDwEB/wQEAwIBhjBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6 Ly9jcmwubGwubWl0LmVkdS9nZXR0bz9MTFJDQTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Au bGwubWl0LmVkdS9vY3NwMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVk dS9nZXRjcmw/TExSQ0EwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsqhkiG9xIC AQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMBCjANBgsq hkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG9xICAQMB EDANBgkqhkiG9w0BAQUFAAOCAQEALH/RwZ+9qlO1E4JMWq4wHO4sp4XAxIFsHs2CrXf0ixkk NA4bcyFfy0wsalC4znfh/h06jCVwfPpx584cqkON0bJxmThU+UX8z4feHW/2Sd6pduOA8JSS O8lwQNg5GXBBIDlgvWx3KxJc1OjZ4oGoUluaHVSa4Zh/14UAHDEu+xOR+tsssStVjz4HAYqR lZ7tcUh204h3uw6n1kNrVTC1H9t12ISLmveJCbEHeI0oe9TVQ9HuxeLJwKKkDCPfDMw2Hizp I5cykbO+6/2jLDwCsepzGjr0S+wstD46edYtqhZGxpl/KH54dpHq40070Sf4Ntq9TFfEUdT5 LYzLDTrD3zCCA4MwggJroAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMx HzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNTUlUTEwgUm9vdCBDQTAeFw0wODA5MjMxMjAwMDBaFw0yOTEyMzEyMzU5NTlaMFQxCzAJ BgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQ S0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDFTikXWLImsvmtir9cEAqD3eQJMBMbsHDQ0YWkQnUDdeyvpQgir3/VUkE6ALAOqtWw ArWVHDL+WSsfM+ShuIyvXDONDbxJH/2yDmQByasyoFhtzfTaq3AIYpnF012ECHadQ4I7XQAy lSwI12mKQ9j26RPyWwD56iszhDWtz8vQnoAdGm05Tsi4MF1mP6101vuC/4YqSevrCP2baxUZ rChobsACqGxa9BQz+riH8fkWliXCdUASHYDOGqIb1vCXq4kkjMn/y5RaV02RXDPUjl9H+8Jr GItchbihTJ0G5EpMb56QSjEca4PvfLHkm2xJyJLwdAvagQzy2/5UAL5qVuqDAgMBAAGjYDBe MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFGeqes/0Cqa5crWKoNKd8hDDQ+0pMB8GA1Ud IwQYMBaAFGeqes/0Cqa5crWKoNKd8hDDQ+0pMAsGA1UdDwQEAwIBhjANBgkqhkiG9w0BAQUF AAOCAQEAPhttBWDQeHjYSlhfj8k+Q1Lc5QARZH9iDNlRjVAaL2tBnil9yNTX9Nqg1Pxjth/R E75702Ib34EOFAf+RCJk5Cj2u/01RvzEO0oJgJp3vMRC1Wxixa68rZcvD8mLWbZ4G+g4HhFL /ksBZ83Cztb4Na3ZrLN5MLKstKvHtlWAGPM06bRM8iRt+ml3CDG6jsVkvy2z4zbj3YCXzt3d Vqx69RLWmmtEES6kKGY9O3WGO1qORA6lPgFADM/WVURitbOW/47+Vs/2K6MqlhZx9ipDcUZ/ ftgK+4N656zjGb6eqbKto2w14jwaHdcMjCp/MecuHLhjzRXKo38mPx1/dIr0ADCCBPgwggPg oAMCAQICCmVBPb8AAAAAfhkwDQYJKoZIhvcNAQELBQAwUTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlU TEwgQ0EtMzAeFw0xNjA0MDQxMjUzNTdaFw0xOTA0MDQxMjUzNTdaMGIxCzAJBgNVBAYTAlVT MR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQZW9wbGUxITAf BgNVBAMTGFdpZ2dpbnMuRGF2aWQuUC41MDAxNTIwNzCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALxLr6lj3p6xTBv4hIMClz+oodyhI36yILLxw3lpNWMLMRgicN0xp5qE/TYq eA9JovmLQKXi5zy2NoOHo5I4xT7rgctVStlMoub/Cu+yU4AbQFY/TPUoeTcnPE8sSIdaZ8ya ZrRpzRMbZe4U6tbqhRMfoIZ8wwVoddo13wFhTd3tuKnBN/3KSowHy5rlBNmPz4rl6kjbr+l+ bLwqwnDu0LkgLXIe0s+pS+VhMpAegi4Glt7VBblvpk8gkZ2WLLb6F2V5Osdrk5auCLOwziIe TkysfpH/OJ8fwXw9spgHH8xvSzxv09mcLe+c6RyAcfCclemgVAwm5BioBvEdyFImbK8CAwEA AaOCAb8wggG7MB0GA1UdDgQWBBTK35v8BBqQXPD5Ewd/My8jOgtQ1TAOBgNVHQ8BAf8EBAMC BSAwHwYDVR0jBBgwFoAU12BmDntJjXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYi aHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYI KwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcw AYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQB gjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD6+0gAgFkAgEFMCUGA1UdJQQeMBwGBFUd JQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwIwYD VR0RBBwwGoEYRGF2aWQuV2lnZ2luc0BsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAE0UyFocglrX8UuUfV+S 6s4dgmpdkLuTDkrcdrhVY2X0jQZpqoL0sS6HrgFMto92VizlP0TRlmkcuONlX7KhJaP9/HCr yrylnV/fJ+ZbCGIaT6DOiQZNCYrjTpPgolXfNYjLwOwOev8l3ORSU7Oj7/R4RTVPDlUg+2KS RyVh/AumAw1dHwffTMtuAYXo5GtDKWzO9i1Q/QDRksiBhUtf1LoXLDskwf5hatrLav1AVIR2 BtD0pIi2NWsT2+zWFO5qkzqh81aVhHxRAs2Fry80eiH/pMkLvo6rR/4OdqsGFyvPxOgq33c0 wKHMaERy/bxTVLUD166IUvJIfE55/PwFTYIxggHlMIIB4QIBATBfMFExCzAJBgNVBAYTAlVT MR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMCCmU8VUQAAAAAfhUwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEW BBR0zQXySXWeoBl87olbHAoyMr+ReDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xODAyMjAxODQ3MjBaMA0GCSqGSIb3DQEBAQUABIIBAI6H8WLhStacwB0R YNTNX+GISRGZZHnR6Peiz7Jvg4UoMpDB0LpFvNMwkKhYrQTZ88mwiYqD5dpOqym3JkwRYViS W0KA4n3f2AhU7WDDDq9Ze2ibdqcg6veBmfKLYUlNz8uKwr/Z0N7G0IvuxjT5/a1pvrDB7S8P rPsMgc5NDz2ZMdPvux3/h4/adNG5s23taQsvy1P44X5zegvaWkJAeFeZ4/4aKHHy1OmTVVXK /wc4En5JIcTwQ2coip4DIbY0oDG4Ilbcg3CVIRBGZZhuFwtAKq/zyyVikj6h9kkvNIztv1hf uD5w+GmKqYROezOMjd/+XQsFvnKZ8IZWgg6hDyw= --B_3601979240_1141897982-- From nobody Tue Feb 20 13:05:43 2018 Return-Path: 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 E68CD12D955; Tue, 20 Feb 2018 13:05:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 KKSOUbosH3Sz; Tue, 20 Feb 2018 13:05:40 -0800 (PST) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B92C126CD6; Tue, 20 Feb 2018 13:05:40 -0800 (PST) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Tue, 20 Feb 2018 21:05:36 +0000 From: Rick Taylor To: "Wiggins, David - 0665 - MITLL" , Lou Berger , Abdussalam Baryun CC: manet , "draft-ietf-manet-dlep-latency-extension@ietf.org" Thread-Topic: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt Thread-Index: AQHTpeuLyTOgGDggRE6oXD83soFJ16OkjYSAgAZFtQCAAXwKgIAAR4KAgAEBoQCAABI8AIAAJnyA Date: Tue, 20 Feb 2018 21:05:35 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801D330F0F6@tss-server1.home.tropicalstormsoftware.com> References: <151865086912.7521.1302513672018061966@ietfa.amsl.com> <1b0c761b-9fda-49e0-8344-52750c232b74@labn.net> <4FEB14CD-DE8D-4735-9FCA-8912EB49AB82@ll.mit.edu> In-Reply-To: <4FEB14CD-DE8D-4735-9FCA-8912EB49AB82@ll.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 21:05:42 -0000 V2UgaGF2ZSBiZWVuIGZhaXJseSBjb25zaXN0ZW50IGluIFJGQzgxNzUgdG8gcmVmZXIgdG8gRExF UCAqbWVzc2FnZXMqICBJJ20gbm90IHN1cmUgYWRkaW5nICd0eXBlcycgaGVscHMuLi4NCg0KUmlj aw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG1hbmV0IFttYWlsdG86 bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFdpZ2dpbnMsIERhdmlkIC0NCj4g MDY2NSAtIE1JVExMDQo+IFNlbnQ6IDIwIEZlYnJ1YXJ5IDIwMTggMTg6NDcNCj4gVG86IExvdSBC ZXJnZXI7IEFiZHVzc2FsYW0gQmFyeXVuDQo+IENjOiBtYW5ldDsgZHJhZnQtaWV0Zi1tYW5ldC1k bGVwLWxhdGVuY3ktZXh0ZW5zaW9uQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbWFuZXRdIEkt RCBBY3Rpb246IGRyYWZ0LWlldGYtbWFuZXQtZGxlcC1sYXRlbmN5LWV4dGVuc2lvbi0NCj4gMDIu dHh0DQo+IA0KPiBPbiAyLzIwLzE4LCAxMjo0MiBQTSwgIm1hbmV0IG9uIGJlaGFsZiBvZiBMb3Ug QmVyZ2VyIiA8bWFuZXQtDQo+IGJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGxiZXJnZXJA bGFibi5uZXQ+IHdyb3RlOg0KPiAgICAgT24gMi8xOS8yMDE4IDk6MTkgUE0sIEFiZHVzc2FsYW0g QmFyeXVuIHdyb3RlOg0KPiAgICAgPiBCdXQgSU1PIGl0IGlzIG5vdCBjbGVhciB3aGVyZSB0aGUg TGF0ZW5jeSBSYW5nZSBpdGVtIG9wZXJhdGVzIHdpdGhpbg0KPiAgICAgPiA4MTc1LA0KPiAgICAg Pg0KPiANCj4gICAgIFRoZSBkcmFmdCBjdXJyZW50bHkgc2F5czoNCj4gDQo+ICAgICAgICAgICBU aGUgTGF0ZW5jeSBSYW5nZSBEYXRhIEl0ZW0gTUFZIGJlIGNhcnJpZWQgaW4gdGhlIHNhbWUgbWVz c2FnZXMNCj4gICAgIC4uLiBhcyAgdGhlIExhdGVuY3kgRGF0YSBJdGVtIGRlZmluZWQgaW4gW1JG QzgxNzVdLg0KPiANCj4gICAgIElzIHRoaXMgbm90IHN1ZmZpY2llbnQ/DQo+IA0KPiBQZXJoYXBz IEFCIGlzIHJlYWRpbmcgdGhpcyBhcyAiaWYgYSBzcGVjaWZpYywgb24tdGhlLXdpcmUgbWVzc2Fn ZSBoYXMgYSBMYXRlbmN5DQo+IERhdGEgSXRlbSBpbiBpdCwgdGhlbiB0aGF0IHBhcnRpY3VsYXIg bWVzc2FnZSBpcyBhbGxvd2VkIHRvIGhhdmUgYSBMYXRlbmN5DQo+IFJhbmdlIERhdGEgSXRlbS4g IE90aGVyd2lzZSwgaXQgY2Fubm90IGhhdmUgYSBMYXRlbmN5IFJhbmdlIERhdGEgSXRlbS4NCj4g QUIsIGlzIHRoYXQgeW91ciBpbnRlcnByZXRhdGlvbj8gIElmIHNvLCB0aGVuIG1heWJlIGp1c3Qg c2F5aW5nICJtZXNzYWdlDQo+IHR5cGVzIg0KPiBpbnN0ZWFkIG9mICJtZXNzYWdlcyIgaXMgZW5v dWdoIGNsYXJpZmljYXRpb24uDQo+IA0KPiBEYXZpZA0KDQo= From nobody Tue Feb 20 13:26:54 2018 Return-Path: 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 1E83D126B6D; Tue, 20 Feb 2018 13:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Fb87TXWsDoqe; Tue, 20 Feb 2018 13:26:50 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E625A120724; Tue, 20 Feb 2018 13:26:49 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id p78so16486635iod.13; Tue, 20 Feb 2018 13:26:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=n3Ozx9t7b1WLVCZbrWkVwcpJCHbb/rHU8EuWwwzqRBo=; b=TbgbZVch4owG6w7H4PYOPYc7ZYFN/AzYm1u5esJW6PBfjpbXpJ9Yl4fOneJsRBSU+z bkRWcNzzN8Gb3bhifOB9eZpK9N5Exp5D8P8KU6DaYYulBB+4zJk+1+Ah1q8to4xU6QxP vg7giWA8JsydtLBpXOj0UIC+S3thR9O829vWbk2Dv8R3OV9EqW/MTID32GWO9yq+BKwT mNyw1SOcdQCPJhpokgGTAEgaKnkpm45xs0jrv/GQns4L2/fHqOqewKmrwAm/wRuolOSs XvEQdWPcDHTdn801a5QrMjGOQoxKbk1QOx5uIZajpG7Azpig1Ku4bjhI/wwyMfy7Ug1N 1qsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=n3Ozx9t7b1WLVCZbrWkVwcpJCHbb/rHU8EuWwwzqRBo=; b=o4bXzvooqAwybQu4AMnVYfvtDC6ISJ/EeUG2+glo7QyjOPJDaRpXplpEpdGVLUz+kK o5hH5Dz9R1uSKc/fyais1XPJ71jNca2OEdmCObd6D4cq2rhIT0k5w9j83YSqKPCKOWFM lI2IXbcLZIREcrTIQwucN+orFdprm/jIEB6yx/gi8MIR3WrYbLe6sQOUjWH3KOi1kKeB 4uE0R7ysEHgcVgnRWPSKz49B/NSA+V2HUeuLIiLT7Hf3fbkMW7+WCMTqVcSkhsOrBqZu cvOgLA4moXF0kXZY3NTobnMqsnh3bifJWhhe9/O8u1VKEvcNlc42md+aCpX768G5HTgT 35Jw== X-Gm-Message-State: APf1xPDQkqHRzXZorvaF1o3nPtgaTF9ekA9QL66fxnx68OiH3QLpws1b ghoJZgPoL26SxVf06/BLa+8Oga4Ls1R88Hazm89new== X-Google-Smtp-Source: AG47ELtpRTZQEzd7TAbtquH4I6WoIFtQzcYKElx46GpPg8h/6Jj0hisq3ybXK/6PmlkQqOUEJ47dtd6HLx2wXpvjz7o= X-Received: by 10.107.143.151 with SMTP id r145mr1355601iod.297.1519162009078; Tue, 20 Feb 2018 13:26:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.162.79 with HTTP; Tue, 20 Feb 2018 13:26:48 -0800 (PST) In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801D330F0F6@tss-server1.home.tropicalstormsoftware.com> References: <151865086912.7521.1302513672018061966@ietfa.amsl.com> <1b0c761b-9fda-49e0-8344-52750c232b74@labn.net> <4FEB14CD-DE8D-4735-9FCA-8912EB49AB82@ll.mit.edu> <38A5475DE83986499AEACD2CFAFC3F9801D330F0F6@tss-server1.home.tropicalstormsoftware.com> From: Stan Ratliff Date: Tue, 20 Feb 2018 16:26:48 -0500 Message-ID: To: Rick Taylor Cc: "Wiggins, David - 0665 - MITLL" , Lou Berger , Abdussalam Baryun , manet , "draft-ietf-manet-dlep-latency-extension@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c05a1ace853740565ab7785" Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 21:26:52 -0000 --94eb2c05a1ace853740565ab7785 Content-Type: text/plain; charset="UTF-8" I agree with Rick on adding 'types'. So, I'll propose some text. Maybe this will help? "The Latency Range Data Item MAY be carried in any message where the Latency Data Item [RFC8175] is allowed. The Latency Range Data Item MAY be carried in addition to, or in lieu of, the Latency Data Item." Regards, Stan > The Latency Range Data Item MAY be carried in the same messages > ... as the Latency Data Item defined in [RFC8175]. On Tue, Feb 20, 2018 at 4:05 PM, Rick Taylor wrote: > We have been fairly consistent in RFC8175 to refer to DLEP *messages* I'm > not sure adding 'types' helps... > > Rick > > > -----Original Message----- > > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Wiggins, David > - > > 0665 - MITLL > > Sent: 20 February 2018 18:47 > > To: Lou Berger; Abdussalam Baryun > > Cc: manet; draft-ietf-manet-dlep-latency-extension@ietf.org > > Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency- > extension- > > 02.txt > > > > On 2/20/18, 12:42 PM, "manet on behalf of Lou Berger" > bounces@ietf.org on behalf of lberger@labn.net> wrote: > > On 2/19/2018 9:19 PM, Abdussalam Baryun wrote: > > > But IMO it is not clear where the Latency Range item operates > within > > > 8175, > > > > > > > The draft currently says: > > > > The Latency Range Data Item MAY be carried in the same messages > > ... as the Latency Data Item defined in [RFC8175]. > > > > Is this not sufficient? > > > > Perhaps AB is reading this as "if a specific, on-the-wire message has a > Latency > > Data Item in it, then that particular message is allowed to have a > Latency > > Range Data Item. Otherwise, it cannot have a Latency Range Data Item. > > AB, is that your interpretation? If so, then maybe just saying "message > > types" > > instead of "messages" is enough clarification. > > > > David > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --94eb2c05a1ace853740565ab7785 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with Rick on adding 'types'. So, I= 9;ll propose some text. Maybe this will help?=C2=A0

"The Latency Range Data Item MAY be carried in any message where the= Latency Data Item [RFC8175] is allowed. The Latency Range Data Item MAY be= carried in addition to, or in lieu of, the Latency Data Item."
<= div>
Regards,
Stan


>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0T= he Latency Range Data Item MAY be carried in the same messages
>=C2=A0 =C2=A0 =C2=A0... as=C2=A0 the Latency Data Ite= m defined in [RFC8175].


On Tue, Feb 2= 0, 2018 at 4:05 PM, Rick Taylor <rick@tropicalstormsoftware.c= om> wrote:
We have been fai= rly consistent in RFC8175 to refer to DLEP *messages*=C2=A0 I'm not sur= e adding 'types' helps...

Rick

> -----Original Message-----
> From: manet [mailto:manet-bo= unces@ietf.org] On Behalf Of Wiggins, David -
> 0665 - MITLL
> Sent: 20 February 2018 18:47
> To: Lou Berger; Abdussalam Baryun
> Cc: manet; draft-ietf-manet-dlep-latency-extension@ietf.org
> Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-ex= tension-
> 02.txt
>
> On 2/20/18, 12:42 PM, "manet on behalf of Lou Berger" <ma= net-
> bounces@ietf.org on behalf of = lberger@labn.net> wrote:
>=C2=A0 =C2=A0 =C2=A0On 2/19/2018 9:19 PM, Abdussalam Baryun wrote:
>=C2=A0 =C2=A0 =C2=A0> But IMO it is not clear where the Latency Rang= e item operates within
>=C2=A0 =C2=A0 =C2=A0> 8175,
>=C2=A0 =C2=A0 =C2=A0>
>
>=C2=A0 =C2=A0 =C2=A0The draft currently says:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The Latency Range Data Item MA= Y be carried in the same messages
>=C2=A0 =C2=A0 =C2=A0... as=C2=A0 the Latency Data Item defined in [RFC8= 175].
>
>=C2=A0 =C2=A0 =C2=A0Is this not sufficient?
>
> Perhaps AB is reading this as "if a specific, on-the-wire message= has a Latency
> Data Item in it, then that particular message is allowed to have a Lat= ency
> Range Data Item.=C2=A0 Otherwise, it cannot have a Latency Range Data = Item.
> AB, is that your interpretation?=C2=A0 If so, then maybe just saying &= quot;message
> types"
> instead of "messages" is enough clarification.
>
> David

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--94eb2c05a1ace853740565ab7785-- From nobody Tue Feb 20 13:29:32 2018 Return-Path: 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 3E67F120724 for ; Tue, 20 Feb 2018 13:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 Fb-ME2pCBugj for ; Tue, 20 Feb 2018 13:29:28 -0800 (PST) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 4290712D9FE for ; Tue, 20 Feb 2018 13:29:28 -0800 (PST) Received: from cmgw3 (unknown [10.0.90.84]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id C6EF51E0C0C for ; Tue, 20 Feb 2018 14:29:27 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id D9VQ1x0052SSUrH019VTAk; Tue, 20 Feb 2018 14:29:27 -0700 X-Authority-Analysis: v=2.2 cv=XM9AcUpE c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=Op4juWPpsa0A:10 a=r77TgQKjGQsHNAKrUKIA:9 a=pGLkceISAAAA:8 a=5vjwwrbCAAAA:8 a=48vgC7mUAAAA:8 a=wU2YTnxGAAAA:8 a=4L10xC7HllNewYiCeiUA:9 a=CpAN2ahoQ45pSmDM:21 a=CaPx_l9YAnP1XQBq:21 a=QEXdDO2ut3YA:10 a=0EtYwLFh1Ms0GNwKeQEA:9 a=-4mRGW4wqisAcqQG:21 a=P2Lmjt_B166EVUV8:21 a=-zRbAq-rgm-M0zDe:21 a=_W_S_7VecoQA:10 a=pV4yRLctw-KkoPKGQz8o:22 a=w1C3t2QeGrPiZgrLijVG:22 a=Yz9wTY_ffGCQnEDHKrcv:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:MIME-Version:Subject:References:In-Reply-To: Message-ID:Date:CC:To:From:Sender:Reply-To:Content-Transfer-Encoding: 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=kgRx0Ffp9fTfXoERGdbSo0HOrlTM0S8jCrU/i3gbRhI=; b=nDfEEWH+mBwrXoDdM4h1Gz8UlR ILxlv/Ci6iecN5GJGhFIjtSuO5AqfrwG3GUDajCWpphCNs0Ge98fsHz+KIdxoX3hZFh+HI/gQClZa eUe6n2chpmjg+qPuOuv8OuXRx; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:58345 helo=[11.4.0.163]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1eoFTX-002MgG-Nr; Tue, 20 Feb 2018 14:29:23 -0700 From: Lou Berger To: Stan Ratliff , Rick Taylor CC: "Wiggins, David - 0665 - MITLL" , Abdussalam Baryun , manet , Date: Tue, 20 Feb 2018 16:29:21 -0500 Message-ID: <161b51ef380.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: References: <151865086912.7521.1302513672018061966@ietfa.amsl.com> <1b0c761b-9fda-49e0-8344-52750c232b74@labn.net> <4FEB14CD-DE8D-4735-9FCA-8912EB49AB82@ll.mit.edu> <38A5475DE83986499AEACD2CFAFC3F9801D330F0F6@tss-server1.home.tropicalstormsoftware.com> User-Agent: AquaMail/1.13.2-730 (build: 101300200) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------161b51ef7a3194a27d31a62f49" 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: 100.15.86.101 X-Exim-ID: 1eoFTX-002MgG-Nr X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([11.4.0.163]) [100.15.86.101]:58345 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 21:29:31 -0000 This is a multi-part message in MIME format. ------------161b51ef7a3194a27d31a62f49 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit Stan, "In lieu" of a mandatory 8175 item is a pretty big change. I don't think we want to go there. I think the rest of the text is fine. On February 20, 2018 4:27:16 PM Stan Ratliff wrote: > I agree with Rick on adding 'types'. So, I'll propose some text. Maybe this > will help? > > "The Latency Range Data Item MAY be carried in any message where the > Latency Data Item [RFC8175] is allowed. The Latency Range Data Item MAY be > carried in addition to, or in lieu of, the Latency Data Item." > > Regards, > Stan > > >> The Latency Range Data Item MAY be carried in the same messages >> ... as the Latency Data Item defined in [RFC8175]. > > > On Tue, Feb 20, 2018 at 4:05 PM, Rick Taylor > wrote: > >> We have been fairly consistent in RFC8175 to refer to DLEP *messages* I'm >> not sure adding 'types' helps... >> >> Rick >> >> > -----Original Message----- >> > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Wiggins, David >> - >> > 0665 - MITLL >> > Sent: 20 February 2018 18:47 >> > To: Lou Berger; Abdussalam Baryun >> > Cc: manet; draft-ietf-manet-dlep-latency-extension@ietf.org >> > Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency- >> extension- >> > 02.txt >> > >> > On 2/20/18, 12:42 PM, "manet on behalf of Lou Berger" > > bounces@ietf.org on behalf of lberger@labn.net> wrote: >> > On 2/19/2018 9:19 PM, Abdussalam Baryun wrote: >> > > But IMO it is not clear where the Latency Range item operates >> within >> > > 8175, >> > > >> > >> > The draft currently says: >> > >> > The Latency Range Data Item MAY be carried in the same messages >> > ... as the Latency Data Item defined in [RFC8175]. >> > >> > Is this not sufficient? >> > >> > Perhaps AB is reading this as "if a specific, on-the-wire message has a >> Latency >> > Data Item in it, then that particular message is allowed to have a >> Latency >> > Range Data Item. Otherwise, it cannot have a Latency Range Data Item. >> > AB, is that your interpretation? If so, then maybe just saying "message >> > types" >> > instead of "messages" is enough clarification. >> > >> > David >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> ------------161b51ef7a3194a27d31a62f49 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Stan,

"In lieu" of a mandatory 8175= item is a pretty big change.  I don't think we want to go there. = ; I think the rest of the text is fine.

On February 20, 2018 4:27:16 PM Stan Ratliff <ratliffst= an@gmail.com> wrote:

I agree with Rick on adding 'types'. So, I= 9;ll propose some text. Maybe this will help?=C2=A0

"The Latency Range Data Item MAY be carried in any message where the= Latency Data Item [RFC8175] is allowed. The Latency Range Data Item MAY be= carried in addition to, or in lieu of, the Latency Data Item."
<= div>
Regards,
Stan


>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0T= he Latency Range Data Item MAY be carried in the same messages
>=C2=A0 =C2=A0 =C2=A0... as=C2=A0 the Latency Data Ite= m defined in [RFC8175].


On Tue, Feb 2= 0, 2018 at 4:05 PM, Rick Taylor <rick@tropicalstormsoftware.c= om> wrote:
We have been fai= rly consistent in RFC8175 to refer to DLEP *messages*=C2=A0 I'm not sur= e adding 'types' helps...

Rick

> -----Original Message-----
> From: manet [mailto:manet-bo= unces@ietf.org] On Behalf Of Wiggins, David -
> 0665 - MITLL
> Sent: 20 February 2018 18:47
> To: Lou Berger; Abdussalam Baryun
> Cc: manet; draft-ietf-manet-dlep-latency-extension@ietf.org
> Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-ex= tension-
> 02.txt
>
> On 2/20/18, 12:42 PM, "manet on behalf of Lou Berger" <ma= net-
> bounces@ietf.org on behalf of = lberger@labn.net> wrote:
>=C2=A0 =C2=A0 =C2=A0On 2/19/2018 9:19 PM, Abdussalam Baryun wrote:
>=C2=A0 =C2=A0 =C2=A0> But IMO it is not clear where the Latency Rang= e item operates within
>=C2=A0 =C2=A0 =C2=A0> 8175,
>=C2=A0 =C2=A0 =C2=A0>
>
>=C2=A0 =C2=A0 =C2=A0The draft currently says:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The Latency Range Data Item MA= Y be carried in the same messages
>=C2=A0 =C2=A0 =C2=A0... as=C2=A0 the Latency Data Item defined in [RFC8= 175].
>
>=C2=A0 =C2=A0 =C2=A0Is this not sufficient?
>
> Perhaps AB is reading this as "if a specific, on-the-wire message= has a Latency
> Data Item in it, then that particular message is allowed to have a Lat= ency
> Range Data Item.=C2=A0 Otherwise, it cannot have a Latency Range Data = Item.
> AB, is that your interpretation?=C2=A0 If so, then maybe just saying &= quot;message
> types"
> instead of "messages" is enough clarification.
>
> David

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

------------161b51ef7a3194a27d31a62f49-- From nobody Tue Feb 20 13:32:11 2018 Return-Path: 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 BE5E5124E15; Tue, 20 Feb 2018 13:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 B719M8mQtOCJ; Tue, 20 Feb 2018 13:32:07 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C28A120724; Tue, 20 Feb 2018 13:32:07 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id g21so6230731ioj.5; Tue, 20 Feb 2018 13:32:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wEUa/Szhr0i11EnnhajcTmiO6xwylaeeCJ46LsEHGzo=; b=a5DM/D+VxlCJxYCWVV2KNvCIqHOErvUr4Dn5w9dQY42pGXU9nz6hMIssGrYHM3UUR2 kKOi4tIup9PuGPeiOHcnXiWsjED9c9IMOrVOpfUaptUI5xACFsqE0OsG3DHA/aiXWbME dV8+8frIkeLImYFelrRTefHytol7p2jwiTgTonLZvM0JS68rzZRP8rlE/CUtyDKrwwdB a2Huc+uJ5hy2HL7KK/m/HnWZPBA4Sv9BjALfGM6lDh6PaYG2/D4Dq8ubAir8H/oF+dW9 81pF++jtxcGY/I3H7mfGdASfK78qpYxlzMBTu2GRVFZ6Owrys6s993XrT7230Vu2N7dA GHPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wEUa/Szhr0i11EnnhajcTmiO6xwylaeeCJ46LsEHGzo=; b=Wo8DR9mvbKgmkJNJboFj9bfWrFbzKWPKldr+Xx5kp72/TvsrHlAZDxafDjatyDUhCe zpX2Uyk5r6rlf615z9CnysjgrukdLKh04HO/lVFE5qncbbcSQLps0Gh/IRAVoAC4UjE3 jwqqIZ0RhO6/8t9TogqaDDiJ5SRdtKusjiWHlaW4qr0PXVPJJW2xCi0RNKDH9s5tKBRk hNAEQNtWd3d5wRgUbxGo5FmEiQOeiF2zFEjEuXD8LndHwq86ZHoKlEaTtoQzYmnGEeee gXp25I3EcUjuNFZ035pTY7YAv9pSpSiY6vQNsWFfc5A3NXHUVnJkDv9guSjzXUI6izlS fqbA== X-Gm-Message-State: APf1xPD+QkYwtMDdkjHwNa1GeoYrW1s4Gl9wn0oMAIz+hq+YP9kwjYv3 JPo8InAS+8XnBB9vFMezBXGcfXfgAkATM7KDD60= X-Google-Smtp-Source: AH8x224GLhaDQHyNW4WNhvg4BDZaS96/USu5/f1eMcdAaWrin3DMs3D6HhzL2LAk157LKRtBANI9zLZJv0MajQoZsZE= X-Received: by 10.107.179.70 with SMTP id c67mr1405803iof.220.1519162326585; Tue, 20 Feb 2018 13:32:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.162.79 with HTTP; Tue, 20 Feb 2018 13:32:06 -0800 (PST) In-Reply-To: <161b51ef380.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> References: <151865086912.7521.1302513672018061966@ietfa.amsl.com> <1b0c761b-9fda-49e0-8344-52750c232b74@labn.net> <4FEB14CD-DE8D-4735-9FCA-8912EB49AB82@ll.mit.edu> <38A5475DE83986499AEACD2CFAFC3F9801D330F0F6@tss-server1.home.tropicalstormsoftware.com> <161b51ef380.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> From: Stan Ratliff Date: Tue, 20 Feb 2018 16:32:06 -0500 Message-ID: To: Lou Berger Cc: Rick Taylor , "Wiggins, David - 0665 - MITLL" , Abdussalam Baryun , manet , draft-ietf-manet-dlep-latency-extension@ietf.org Content-Type: multipart/alternative; boundary="001a11485318d518250565ab8a81" Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 21:32:10 -0000 --001a11485318d518250565ab8a81 Content-Type: text/plain; charset="UTF-8" Lou, On Tue, Feb 20, 2018 at 4:29 PM, Lou Berger wrote: > Stan, > > "In lieu" of a mandatory 8175 item is a pretty big change. I don't think > we want to go there. I think the rest of the text is fine. > Point taken. So, you're good with the second sentence changing to "The latency Range Data Item MAY be carried in addition to the Latency Data Item." ?? Regards, Stan > On February 20, 2018 4:27:16 PM Stan Ratliff > wrote: > >> I agree with Rick on adding 'types'. So, I'll propose some text. Maybe >> this will help? >> >> "The Latency Range Data Item MAY be carried in any message where the >> Latency Data Item [RFC8175] is allowed. The Latency Range Data Item MAY be >> carried in addition to, or in lieu of, the Latency Data Item." >> >> Regards, >> Stan >> >> >> > The Latency Range Data Item MAY be carried in the same >> messages >> > ... as the Latency Data Item defined in [RFC8175]. >> >> >> On Tue, Feb 20, 2018 at 4:05 PM, Rick Taylor > com> wrote: >> >>> We have been fairly consistent in RFC8175 to refer to DLEP *messages* >>> I'm not sure adding 'types' helps... >>> >>> Rick >>> >>> > -----Original Message----- >>> > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Wiggins, >>> David - >>> > 0665 - MITLL >>> > Sent: 20 February 2018 18:47 >>> > To: Lou Berger; Abdussalam Baryun >>> > Cc: manet; draft-ietf-manet-dlep-latency-extension@ietf.org >>> > Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency- >>> extension- >>> > 02.txt >>> > >>> > On 2/20/18, 12:42 PM, "manet on behalf of Lou Berger" >> > bounces@ietf.org on behalf of lberger@labn.net> wrote: >>> > On 2/19/2018 9:19 PM, Abdussalam Baryun wrote: >>> > > But IMO it is not clear where the Latency Range item operates >>> within >>> > > 8175, >>> > > >>> > >>> > The draft currently says: >>> > >>> > The Latency Range Data Item MAY be carried in the same >>> messages >>> > ... as the Latency Data Item defined in [RFC8175]. >>> > >>> > Is this not sufficient? >>> > >>> > Perhaps AB is reading this as "if a specific, on-the-wire message has >>> a Latency >>> > Data Item in it, then that particular message is allowed to have a >>> Latency >>> > Range Data Item. Otherwise, it cannot have a Latency Range Data Item. >>> > AB, is that your interpretation? If so, then maybe just saying >>> "message >>> > types" >>> > instead of "messages" is enough clarification. >>> > >>> > David >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >> >> --001a11485318d518250565ab8a81 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Lou,=C2=A0


On Tue, Feb 20, 2018 at 4:29 PM, Lou Berger <lberger@lab= n.net> wrote:

Stan,

"In lieu" of a mandator= y 8175 item is a pretty big change.=C2=A0 I don't think we want to go t= here.=C2=A0 I think the rest of the text is fine.


Point taken. So, you're good with the seco= nd sentence changing to "The latency Range Data Item MAY be carried in= addition to the Latency Data Item." ??

Regar= ds,
Stan

=C2=A0

On February 20, 2018 4:27:16 PM Stan Ratliff <ratliffstan@gmail.com> wrot= e:

I agree with Rick on adding 'types'. So, I= 9;ll propose some text. Maybe this will help?=C2=A0

"The Latency Range Data Item MAY be carried in any message where the= Latency Data Item [RFC8175] is allowed. The Latency Range Data Item MAY be= carried in addition to, or in lieu of, the Latency Data Item."
<= div>
Regards,
Stan


>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0T= he Latency Range Data Item MAY be carried in the same messages
>=C2=A0 =C2=A0 =C2=A0... as=C2=A0 the Latency Data Ite= m defined in [RFC8175].


On Tue, Feb 2= 0, 2018 at 4:05 PM, Rick Taylor <rick@tropicalstormsoftware.<= wbr>com> wrote:
We have bee= n fairly consistent in RFC8175 to refer to DLEP *messages*=C2=A0 I'm no= t sure adding 'types' helps...

Rick

> -----Original Message-----
> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Wiggins, David -<= br> > 0665 - MITLL
> Sent: 20 February 2018 18:47
> To: Lou Berger; Abdussalam Baryun
> Cc: manet; draft-ietf-manet-dlep-latency-extension@iet= f.org
> Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-ex= tension-
> 02.txt
>
> On 2/20/18, 12:42 PM, "manet on behalf of Lou Berger" <ma= net-
> bounces@ietf.org= on behalf of lbe= rger@labn.net> wrote:
>=C2=A0 =C2=A0 =C2=A0On 2/19/2018 9:19 PM, Abdussalam Baryun wrote:
>=C2=A0 =C2=A0 =C2=A0> But IMO it is not clear where the Latency Rang= e item operates within
>=C2=A0 =C2=A0 =C2=A0> 8175,
>=C2=A0 =C2=A0 =C2=A0>
>
>=C2=A0 =C2=A0 =C2=A0The draft currently says:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The Latency Range Data Item MA= Y be carried in the same messages
>=C2=A0 =C2=A0 =C2=A0... as=C2=A0 the Latency Data Item defined in [RFC8= 175].
>
>=C2=A0 =C2=A0 =C2=A0Is this not sufficient?
>
> Perhaps AB is reading this as "if a specific, on-the-wire message= has a Latency
> Data Item in it, then that particular message is allowed to have a Lat= ency
> Range Data Item.=C2=A0 Otherwise, it cannot have a Latency Range Data = Item.
> AB, is that your interpretation?=C2=A0 If so, then maybe just saying &= quot;message
> types"
> instead of "messages" is enough clarification.
>
> David

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


--001a11485318d518250565ab8a81-- From nobody Tue Feb 20 14:16:54 2018 Return-Path: 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 A61CE126DFB; Tue, 20 Feb 2018 14:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 BAxOwYHX4UVB; Tue, 20 Feb 2018 14:16:50 -0800 (PST) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA01D1200B9; Tue, 20 Feb 2018 14:16:49 -0800 (PST) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Tue, 20 Feb 2018 22:16:45 +0000 From: Rick Taylor To: Stan Ratliff , Lou Berger CC: David - 0665 - MITLL Wiggins , Abdussalam Baryun , "manet@ietf.org" , "draft-ietf-manet-dlep-latency-extension@ietf.org" Thread-Topic: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt Thread-Index: AQHTpeuLyTOgGDggRE6oXD83soFJ16OkjYSAgAZFtQCAAXwKgIAAR4KAgAEBoQCAABI8AIAAJnyAgAAGEgCAAAC2gIAAAMUAgAAMesg= Date: Tue, 20 Feb 2018 22:16:45 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801D330F213@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_38A5475DE83986499AEACD2CFAFC3F9801D330F213tssserver1hom_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 22:16:52 -0000 --_000_38A5475DE83986499AEACD2CFAFC3F9801D330F213tssserver1hom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As long as it is obvious that this is after a successful extension negotiat= ion Rick (Sent from my phone) ----- Reply message ----- From: "Stan Ratliff" To: "Lou Berger" Cc: "Rick Taylor" , "Wiggins, David - 0665 = - MITLL" , "Abdussalam Baryun" , "manet" , "draft-ietf-manet-dlep-latency-extens= ion@ietf.org" Subject: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt Date: Tue, Feb 20, 2018 21:32 Lou, On Tue, Feb 20, 2018 at 4:29 PM, Lou Berger > wrote: Stan, "In lieu" of a mandatory 8175 item is a pretty big change. I don't think w= e want to go there. I think the rest of the text is fine. Point taken. So, you're good with the second sentence changing to "The late= ncy Range Data Item MAY be carried in addition to the Latency Data Item." ?= ? Regards, Stan On February 20, 2018 4:27:16 PM Stan Ratliff > wrote: I agree with Rick on adding 'types'. So, I'll propose some text. Maybe this= will help? "The Latency Range Data Item MAY be carried in any message where the Latenc= y Data Item [RFC8175] is allowed. The Latency Range Data Item MAY be carrie= d in addition to, or in lieu of, the Latency Data Item." Regards, Stan > The Latency Range Data Item MAY be carried in the same messages > ... as the Latency Data Item defined in [RFC8175]. On Tue, Feb 20, 2018 at 4:05 PM, Rick Taylor > wrote: We have been fairly consistent in RFC8175 to refer to DLEP *messages* I'm = not sure adding 'types' helps... Rick > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org= ] On Behalf Of Wiggins, David - > 0665 - MITLL > Sent: 20 February 2018 18:47 > To: Lou Berger; Abdussalam Baryun > Cc: manet; draft-ietf-manet-dlep-latency-extension@ietf.org > Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension- > 02.txt > > On 2/20/18, 12:42 PM, "manet on behalf of Lou Berger" bounces@ietf.org on behalf of lberger@labn.net> wrote: > On 2/19/2018 9:19 PM, Abdussalam Baryun wrote: > > But IMO it is not clear where the Latency Range item operates withi= n > > 8175, > > > > The draft currently says: > > The Latency Range Data Item MAY be carried in the same messages > ... as the Latency Data Item defined in [RFC8175]. > > Is this not sufficient? > > Perhaps AB is reading this as "if a specific, on-the-wire message has a L= atency > Data Item in it, then that particular message is allowed to have a Latenc= y > Range Data Item. Otherwise, it cannot have a Latency Range Data Item. > AB, is that your interpretation? If so, then maybe just saying "message > types" > instead of "messages" is enough clarification. > > David _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_38A5475DE83986499AEACD2CFAFC3F9801D330F213tssserver1hom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
As long as it is obvious that this is after a successful e= xtension negotiation

Rick

(Sent from my phone)

----- Reply message -----
From: "Stan Ratliff" <ratliffstan@gmail.com>
To: "Lou Berger" <lberger@labn.net>
Cc: "Rick Taylor" <rick@tropicalstormsoftware.com>, "W= iggins, David - 0665 - MITLL" <david.wiggins@ll.mit.edu>, "= Abdussalam Baryun" <abdussalambaryun@gmail.com>, "manet&quo= t; <manet@ietf.org>, "draft-ietf-manet-dlep-latency-extension@ie= tf.org" <draft-ietf-manet-dlep-latency-extension@ietf.org>
Subject: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt=
Date: Tue, Feb 20, 2018 21:32

Lou, 


On Tue, Feb 20, 2018 at 4:29 PM, Lou Berger <lberger@labn.net<= /a>> wrote:

Stan,

"In lieu" of a mandato= ry 8175 item is a pretty big change.  I don't think we want to go ther= e.  I think the rest of the text is fine.


Point taken. So, you're good with the second sentence changing to &quo= t;The latency Range Data Item MAY be carried in addition to the Latency Dat= a Item." ??

Regards,
Stan

 

On February 20, 2018 4:27:16 PM Stan Ratliff <ratliffstan@gmail.com> wrote:

I agree with Rick on adding 'types'. So, I'll propose some text. Maybe= this will help? 

"The Latency Range Data Item MAY be carried in any message where = the Latency Data Item [RFC8175] is allowed. The Latency Range Data Item MAY= be carried in addition to, or in lieu of, the Latency Data Item."

Regards,
Stan


&= gt;           The Latency Range Data Item MAY be carri= ed in the same messages
&= gt;     ... as  the Latency Data Item defined in [RFC8175].


On Tue, Feb 20, 2018 at 4:05 PM, Rick Taylor <ric= k@tropicalstormsoftware.com> wrote:
We have been fairly consistent in RFC8175 to refer to DLEP *messages* = I'm not sure adding 'types' helps...

Rick

> -----Original Message-----
> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Wiggins, David -<= br> > 0665 - MITLL
> Sent: 20 February 2018 18:47
> To: Lou Berger; Abdussalam Baryun
> Cc: manet; draft-ietf-manet-dlep-latency-extension@ietf.org
> Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-ex= tension-
> 02.txt
>
> On 2/20/18, 12:42 PM, "manet on behalf of Lou Berger" <ma= net-
> bounces@ietf.org= on behalf of lberger@labn.net&= gt; wrote:
>     On 2/19/2018 9:19 PM, Abdussalam Baryun wrote:
>     > But IMO it is not clear where the Latency Rang= e item operates within
>     > 8175,
>     >
>
>     The draft currently says:
>
>           The Latency Range Data Item MA= Y be carried in the same messages
>     ... as  the Latency Data Item defined in [RFC8= 175].
>
>     Is this not sufficient?
>
> Perhaps AB is reading this as "if a specific, on-the-wire message= has a Latency
> Data Item in it, then that particular message is allowed to have a Lat= ency
> Range Data Item.  Otherwise, it cannot have a Latency Range Data = Item.
> AB, is that your interpretation?  If so, then maybe just saying &= quot;message
> types"
> instead of "messages" is enough clarification.
>
> David

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


--_000_38A5475DE83986499AEACD2CFAFC3F9801D330F213tssserver1hom_-- From nobody Tue Feb 20 14:53:58 2018 Return-Path: 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 EDACE12E03F for ; Tue, 20 Feb 2018 14:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 eTo2QfdkZxvH for ; Tue, 20 Feb 2018 14:53:54 -0800 (PST) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) (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 0899C12E03C for ; Tue, 20 Feb 2018 14:53:54 -0800 (PST) Received: from CMOut01 (unknown [10.0.90.82]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id 9E536140422 for ; Tue, 20 Feb 2018 15:53:53 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id DAtp1x00Y2SSUrH01AtsZ4; Tue, 20 Feb 2018 15:53:53 -0700 X-Authority-Analysis: v=2.2 cv=Rf/gMxlv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=Op4juWPpsa0A:10 a=r77TgQKjGQsHNAKrUKIA:9 a=5vjwwrbCAAAA:8 a=pGLkceISAAAA:8 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=jHhOQAr4w4N9wrIy8xsA:9 a=cNJ4cJaYNd3Wokg0:21 a=i22mnJ8XwL0LrqAK:21 a=CjuIK1q_8ugA:10 a=febuGJr95vwA:10 a=nKsp94PS5oGf0SHxE0wA:9 a=vbClT0Nyg4YcJFf-:21 a=nKEiJG1Xp44HKElE:21 a=cDCBgCen0qXA4sw3:21 a=_W_S_7VecoQA:10 a=rUtsQoudGX4PATiiMU9I:22 a=pV4yRLctw-KkoPKGQz8o:22 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:MIME-Version:Subject:References:In-Reply-To: Message-ID:Date:CC:To:From:Sender:Reply-To:Content-Transfer-Encoding: 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=0RrDkjrDYqnPQqardGkMPTbp5S9BrpnXW0KqbHLfh1I=; b=ke0npbP+UoMYDGoc2WrOf7cwRw 7sjGAJ+hPtfToar5JZ0ZBo7bljgVdZNRQiKpKAttg93eYFdLXJYuebp9as/zHjgLjrV0Fznaen51n oDCwdU7+7Eh3/fQ26ivws4+8W; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:58458 helo=[11.4.0.163]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1eoGnF-002uCo-Cp; Tue, 20 Feb 2018 15:53:49 -0700 From: Lou Berger To: Rick Taylor , Stan Ratliff CC: "David - 0665 - MITLL Wiggins" , Abdussalam Baryun , , Date: Tue, 20 Feb 2018 17:53:47 -0500 Message-ID: <161b56c4090.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801D330F213@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F9801D330F213@tss-server1.home.tropicalstormsoftware.com> User-Agent: AquaMail/1.13.2-730 (build: 101300200) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------161b56c4491194a27d3fe255d" 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: 100.15.86.101 X-Exim-ID: 1eoGnF-002uCo-Cp X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([11.4.0.163]) [100.15.86.101]:58458 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 22:53:56 -0000 This is a multi-part message in MIME format. ------------161b56c4491194a27d3fe255d Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit Agreed. On February 20, 2018 5:17:20 PM Rick Taylor wrote: > As long as it is obvious that this is after a successful extension negotiation > > Rick > > (Sent from my phone) > > ----- Reply message ----- > From: "Stan Ratliff" > To: "Lou Berger" > Cc: "Rick Taylor" , "Wiggins, David - 0665 > - MITLL" , "Abdussalam Baryun" > , "manet" , > "draft-ietf-manet-dlep-latency-extension@ietf.org" > > Subject: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt > Date: Tue, Feb 20, 2018 21:32 > > Lou, > > > On Tue, Feb 20, 2018 at 4:29 PM, Lou Berger > > wrote: > > Stan, > > "In lieu" of a mandatory 8175 item is a pretty big change. I don't think > we want to go there. I think the rest of the text is fine. > > Point taken. So, you're good with the second sentence changing to "The > latency Range Data Item MAY be carried in addition to the Latency Data > Item." ?? > > Regards, > Stan > > > > On February 20, 2018 4:27:16 PM Stan Ratliff > > wrote: > > I agree with Rick on adding 'types'. So, I'll propose some text. Maybe this > will help? > > "The Latency Range Data Item MAY be carried in any message where the > Latency Data Item [RFC8175] is allowed. The Latency Range Data Item MAY be > carried in addition to, or in lieu of, the Latency Data Item." > > Regards, > Stan > > >> The Latency Range Data Item MAY be carried in the same messages >> ... as the Latency Data Item defined in [RFC8175]. > > > On Tue, Feb 20, 2018 at 4:05 PM, Rick Taylor > > wrote: > We have been fairly consistent in RFC8175 to refer to DLEP *messages* I'm > not sure adding 'types' helps... > > Rick > >> -----Original Message----- >> From: manet [mailto:manet-bounces@ietf.org] >> On Behalf Of Wiggins, David - >> 0665 - MITLL >> Sent: 20 February 2018 18:47 >> To: Lou Berger; Abdussalam Baryun >> Cc: manet; >> draft-ietf-manet-dlep-latency-extension@ietf.org >> Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension- >> 02.txt >> >> On 2/20/18, 12:42 PM, "manet on behalf of Lou Berger" > bounces@ietf.org on behalf of >> lberger@labn.net> wrote: >> On 2/19/2018 9:19 PM, Abdussalam Baryun wrote: >> > But IMO it is not clear where the Latency Range item operates within >> > 8175, >> > >> >> The draft currently says: >> >> The Latency Range Data Item MAY be carried in the same messages >> ... as the Latency Data Item defined in [RFC8175]. >> >> Is this not sufficient? >> >> Perhaps AB is reading this as "if a specific, on-the-wire message has a Latency >> Data Item in it, then that particular message is allowed to have a Latency >> Range Data Item. Otherwise, it cannot have a Latency Range Data Item. >> AB, is that your interpretation? If so, then maybe just saying "message >> types" >> instead of "messages" is enough clarification. >> >> David > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > ------------161b56c4491194a27d3fe255d Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agreed.

On February 20, 2018 5:17:20 PM Rick Taylor <rick@tropi= calstormsoftware.com> wrote:

As long as it is obvious that this is after a successful e= xtension negotiation

Rick

(Sent from my phone)

----- Reply message -----
From: "Stan Ratliff" <ratliffstan@gmail.com>
To: "Lou Berger" <lberger@labn.net>
Cc: "Rick Taylor" <rick@tropicalstormsoftware.com>, "W= iggins, David - 0665 - MITLL" <david.wiggins@ll.mit.edu>, "= Abdussalam Baryun" <abdussalambaryun@gmail.com>, "manet&quo= t; <manet@ietf.org>, "draft-ietf-manet-dlep-latency-extension@ie= tf.org" <draft-ietf-manet-dlep-latency-extension@ietf.org>
Subject: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt=
Date: Tue, Feb 20, 2018 21:32

Lou, 


On Tue, Feb 20, 2018 at 4:29 PM, Lou Berger <lberger@labn.net<= /a>> wrote:

Stan,

"In lieu" of a mandato= ry 8175 item is a pretty big change.  I don't think we want to go ther= e.  I think the rest of the text is fine.


Point taken. So, you're good with the second sentence changing to &quo= t;The latency Range Data Item MAY be carried in addition to the Latency Dat= a Item." ??

Regards,
Stan

 

On February 20, 2018 4:27:16 PM Stan Ratliff <ratliffstan@gmail.com> wrote:

I agree with Rick on adding 'types'. So, I'll propose some text. Maybe= this will help? 

"The Latency Range Data Item MAY be carried in any message where = the Latency Data Item [RFC8175] is allowed. The Latency Range Data Item MAY= be carried in addition to, or in lieu of, the Latency Data Item."

Regards,
Stan


&= gt;           The Latency Range Data Item MAY be carri= ed in the same messages
&= gt;     ... as  the Latency Data Item defined in [RFC8175].


On Tue, Feb 20, 2018 at 4:05 PM, Rick Taylor <ric= k@tropicalstormsoftware.com> wrote:
We have been fairly consistent in RFC8175 to refer to DLEP *messages* = I'm not sure adding 'types' helps...

Rick

> -----Original Message-----
> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Wiggins, David -<= br> > 0665 - MITLL
> Sent: 20 February 2018 18:47
> To: Lou Berger; Abdussalam Baryun
> Cc: manet; draft-ietf-manet-dlep-latency-extension@ietf.org
> Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-ex= tension-
> 02.txt
>
> On 2/20/18, 12:42 PM, "manet on behalf of Lou Berger" <ma= net-
> bounces@ietf.org= on behalf of lberger@labn.net&= gt; wrote:
>     On 2/19/2018 9:19 PM, Abdussalam Baryun wrote:
>     > But IMO it is not clear where the Latency Rang= e item operates within
>     > 8175,
>     >
>
>     The draft currently says:
>
>           The Latency Range Data Item MA= Y be carried in the same messages
>     ... as  the Latency Data Item defined in [RFC8= 175].
>
>     Is this not sufficient?
>
> Perhaps AB is reading this as "if a specific, on-the-wire message= has a Latency
> Data Item in it, then that particular message is allowed to have a Lat= ency
> Range Data Item.  Otherwise, it cannot have a Latency Range Data = Item.
> AB, is that your interpretation?  If so, then maybe just saying &= quot;message
> types"
> instead of "messages" is enough clarification.
>
> David

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


------------161b56c4491194a27d3fe255d-- From nobody Tue Feb 20 16:01:31 2018 Return-Path: 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 46AF212E056; Tue, 20 Feb 2018 16:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Rv1T1Tw0LOwy; Tue, 20 Feb 2018 16:01:27 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91CB912E055; Tue, 20 Feb 2018 16:01:27 -0800 (PST) Received: by mail-oi0-x22a.google.com with SMTP id 24so10833848oij.3; Tue, 20 Feb 2018 16:01:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vOY8GUVWKF2OWev3xDo5r61sazUEULH8sOHTeG9JRXM=; b=QqC6nXM3gT444j0tZQMZJ4EICHTWZGTPWaULNoA7DtGOMBdZF8crHiCQadI1vYwE6r ZElZQ+LcjFcNr9QtvFsVYZez8EvEytNpa20p6zCeCl8Wsm5e4PdMCcfNLt13qe9hi84b tBoAAE31Ca4/38WbX2tbXytKJjs12Ehl1UmsD9WlwJCgzB9omftbn5sE02ps0gBtd+c8 3NGv0rfh5UHMKyc6BWvZU7u1hONu7W2U/o7bTneISsgvh5dbUZBv2+61rb2W77NYOqYu jN3wMKDrBM5MjwICURZs5jEHXI3x0xh00dZwucMdfgrY+14lXEwjBvK4Z8O7S8ZEe/xa 2DpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vOY8GUVWKF2OWev3xDo5r61sazUEULH8sOHTeG9JRXM=; b=iUiYOo0XcvlZoBzQjHJCjonk2ZcMs5tSbgopbuH+tpS1K8wytpRlJkOeKZC2Oarblo k9bC3VK5HJLhHYN2BqfXLdSaNPbzuNZB2WthaCYwHJwSNXKAhmfjHPbOLMdAQRyPWmLS AJBWXXhrAhFkZFscCNzhfLrLbOM2eoLEYvblsNRc5Cstl/1Cf+Bhdzoq37MwlW+OtWBz s9li7/qZVTqi+LQxMdiCTt2uz5PNrltgtBubWTcEgeB+cMluJW6Y2u/lSVxkDYeSq3O5 pXUDV6WH1VSrwgC6oSB5c5mSo5dC21LpnoKbYCKoz//+NFT8D6Ku0HfTChm0a+41WXsW sH/g== X-Gm-Message-State: APf1xPDH0FAdKZkEKetAYzEC7lFAJGrHn1k55wH4sL9QPWATZJe/jxFk aUZqnd+1kAunvtw1b8sg6R6LpUdyEphU9fZe/nU= X-Google-Smtp-Source: AH8x2247JjhpRIWOKkCiVEacXdof2bYm5FWIkxy+mTJkTOWWTmvBvZiidDs7Dqfitghc7VQYUdejGeDoi1RzIopuB1w= X-Received: by 10.202.204.203 with SMTP id c194mr997346oig.156.1519171286857; Tue, 20 Feb 2018 16:01:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.36 with HTTP; Tue, 20 Feb 2018 16:01:26 -0800 (PST) In-Reply-To: <4FEB14CD-DE8D-4735-9FCA-8912EB49AB82@ll.mit.edu> References: <151865086912.7521.1302513672018061966@ietfa.amsl.com> <1b0c761b-9fda-49e0-8344-52750c232b74@labn.net> <4FEB14CD-DE8D-4735-9FCA-8912EB49AB82@ll.mit.edu> From: Abdussalam Baryun Date: Wed, 21 Feb 2018 02:01:26 +0200 Message-ID: To: "Wiggins, David - 0665 - MITLL" Cc: Lou Berger , manet , "draft-ietf-manet-dlep-latency-extension@ietf.org" Content-Type: multipart/alternative; boundary="001a1134f342e7fd960565ada0ea" Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 00:01:29 -0000 --001a1134f342e7fd960565ada0ea Content-Type: text/plain; charset="UTF-8" On Tue, Feb 20, 2018 at 8:47 PM, Wiggins, David - 0665 - MITLL < David.Wiggins@ll.mit.edu> wrote: > On 2/20/18, 12:42 PM, "manet on behalf of Lou Berger" < > manet-bounces@ietf.org on behalf of lberger@labn.net> wrote: > On 2/19/2018 9:19 PM, Abdussalam Baryun wrote: > > But IMO it is not clear where the Latency Range item operates within > > 8175, > > > > The draft currently says: > > The Latency Range Data Item MAY be carried in the same messages > ... as the Latency Data Item defined in [RFC8175]. > > Is this not sufficient? > > Perhaps AB is reading this as "if a specific, on-the-wire message has a > Latency > Data Item in it, then that particular message is allowed to have a Latency > Range > Data Item. Otherwise, it cannot have a Latency Range Data Item. > AB, is that your interpretation? Yes but also that we already have for Latency item per message types, MUST, MAY, SHOULD, > If so, then maybe just saying "message types" > instead of "messages" is enough clarification. > That may conflict with the MUST in section 12.6, which is a MUST carry message type. AB --001a1134f342e7fd960565ada0ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Feb 20, 2018 at 8:47 PM, Wiggins, David - 0665 - MITLL <David.Wiggins@ll.mit.edu> wrote:
O= n 2/20/18, 12:42 PM, "manet on behalf of Lou Berger" <manet-bounces@ietf.org on behalf of = lberger@labn.net> wrote:
=C2=A0 =C2=A0 On 2/19/2018 9:19 PM, Abdussalam Baryun wrote:
=C2=A0 =C2=A0 > But IMO it is not clear where the Latency R= ange item operates within
=C2=A0 =C2=A0 > 8175,
=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 The draft currently says:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The Latency Range Data Item MAY be carri= ed in the same messages
=C2=A0 =C2=A0 ... as=C2=A0 the Latency Data Item defined in [RFC8175].

=C2=A0 =C2=A0 Is this not sufficient?

Perhaps AB is reading this as "if a specific, on-the-wire messa= ge has a Latency
Data Item in it, then that particular message is allowed to have a Latency = Range
Data Item.=C2=A0 Otherwise, it cannot have a Latency Range Data Item.
AB, is that your interpretation?

Yes but al= so that we already have for Latency item per message types, MUST, MAY, SHOU= LD,
=C2=A0
=C2=A0 If so, then maybe just sa= ying "message types"
instead of "messages" is enough clarification.

That may conflict with the MUST in section 12.6, which is= a MUST carry message type.

AB

--001a1134f342e7fd960565ada0ea-- From nobody Tue Feb 20 16:12:09 2018 Return-Path: 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 E1F9212E05D; Tue, 20 Feb 2018 16:12:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 4QEfaU4uGDZ2; Tue, 20 Feb 2018 16:12:05 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F8EF12E058; Tue, 20 Feb 2018 16:12:05 -0800 (PST) Received: by mail-oi0-x22a.google.com with SMTP id y4so10672201oix.2; Tue, 20 Feb 2018 16:12:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+derX9XPMGeYi6FHdruWfJPRYwhIcjwjYKIlRmswH5E=; b=jfaR3Sqcy0ab2fW+8JXksPob6LBqFB0urbUbIMf8K/6LoB4mB0kvIUQMxqKky/S5P8 gS9/zljoV1VXEmgMfKuKltFO7jgLiK4VUrJacMDztDkVSNSrEFRvA15ExpCsPvrHTxWV YE0B7Bw2HEtq8FQsWCOj7sSGmw2k5egOdHpJczSnPZrt9V3igMh4zFw0QYP6QF8A3Tqj lekvMvF4PdJeq/aj4vms49jiOqcgcjTNv1HAGC4P7mDtZYBbcjcItPACYuM4wvC13kEb N2qLON/O+iVQiJCsvh3qNadfGw0/UyWtFnwY0aTXJM510g8rLOoCZ9c06X2ksIvpYQUq AOwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+derX9XPMGeYi6FHdruWfJPRYwhIcjwjYKIlRmswH5E=; b=p2lCkr/I2uMyhou2rp3Con7Tb+oLxRWDIJ1XyOxIMRRggxKPb0Mb13kgpp7Dt/AUgQ 9KSCEi4NZj7jrKPOFfQcDhGhRMZfSQBnFegLDF6OzbMU9kVdotEbVYL8EQozRkoZSxRd fFT7fqveuwuf/AdA/n+9nv66Pxspd8gV0vE8qLoT2+8i/wMER9BKofmHNHj4brspi+ka yTGDoi+oFxa04XICUYOrssyEZdREXbjDFLZCPopHxMZAu5q8Zrrc3CZGoKpew+SZxHe0 oOrV8kCJ7ymndAd6Kdzg598f1uI6AAOLr7jN8KsywHoRBXGBSkxDqhbT0IONYKDVkJVP Zr7Q== X-Gm-Message-State: APf1xPCyk7n1gbPhq1xyKoJLELp6SbK//EkM4rSfJtGB7fjwVmEbP8T1 H25upllyHyNtVTojTfkX4c/KIMb38M5PewIJEB0= X-Google-Smtp-Source: AH8x226cf4JUlKj28ck6DoImcDUXubsqbp58Jix1SMADZGhpmxq7dbmL31KJ73gIA4f3OfMWHHTO1QwL9fl1EfQD0Zk= X-Received: by 10.202.216.136 with SMTP id p130mr952670oig.277.1519171925044; Tue, 20 Feb 2018 16:12:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.36 with HTTP; Tue, 20 Feb 2018 16:12:04 -0800 (PST) In-Reply-To: <161b56c4090.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> References: <38A5475DE83986499AEACD2CFAFC3F9801D330F213@tss-server1.home.tropicalstormsoftware.com> <161b56c4090.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> From: Abdussalam Baryun Date: Wed, 21 Feb 2018 02:12:04 +0200 Message-ID: To: Lou Berger Cc: Rick Taylor , Stan Ratliff , David - 0665 - MITLL Wiggins , manet , draft-ietf-manet-dlep-latency-extension@ietf.org Content-Type: multipart/alternative; boundary="001a113d5a72f1f3740565adc609" Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 00:12:08 -0000 --001a113d5a72f1f3740565adc609 Content-Type: text/plain; charset="UTF-8" +1 AB On Wed, Feb 21, 2018 at 12:53 AM, Lou Berger wrote: > Agreed. > > On February 20, 2018 5:17:20 PM Rick Taylor com> wrote: > >> As long as it is obvious that this is after a successful extension >> negotiation >> >> Rick >> >> (Sent from my phone) >> >> ----- Reply message ----- >> From: "Stan Ratliff" >> To: "Lou Berger" >> Cc: "Rick Taylor" , "Wiggins, David - >> 0665 - MITLL" , "Abdussalam Baryun" < >> abdussalambaryun@gmail.com>, "manet" , " >> draft-ietf-manet-dlep-latency-extension@ietf.org" > latency-extension@ietf.org> >> Subject: [manet] I-D Action: draft-ietf-manet-dlep-latency- >> extension-02.txt >> Date: Tue, Feb 20, 2018 21:32 >> >> Lou, >> >> >> On Tue, Feb 20, 2018 at 4:29 PM, Lou Berger wrote: >> >>> Stan, >>> >>> "In lieu" of a mandatory 8175 item is a pretty big change. I don't >>> think we want to go there. I think the rest of the text is fine. >>> >> >> Point taken. So, you're good with the second sentence changing to "The >> latency Range Data Item MAY be carried in addition to the Latency Data >> Item." ?? >> >> Regards, >> Stan >> >> >> >>> On February 20, 2018 4:27:16 PM Stan Ratliff >>> wrote: >>> >>>> I agree with Rick on adding 'types'. So, I'll propose some text. Maybe >>>> this will help? >>>> >>>> "The Latency Range Data Item MAY be carried in any message where the >>>> Latency Data Item [RFC8175] is allowed. The Latency Range Data Item MAY be >>>> carried in addition to, or in lieu of, the Latency Data Item." >>>> >>>> Regards, >>>> Stan >>>> >>>> >>>> > The Latency Range Data Item MAY be carried in the same >>>> messages >>>> > ... as the Latency Data Item defined in [RFC8175]. >>>> >>>> >>>> On Tue, Feb 20, 2018 at 4:05 PM, Rick Taylor < >>>> rick@tropicalstormsoftware.com> wrote: >>>> >>>>> We have been fairly consistent in RFC8175 to refer to DLEP *messages* >>>>> I'm not sure adding 'types' helps... >>>>> >>>>> Rick >>>>> >>>>> > -----Original Message----- >>>>> > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Wiggins, >>>>> David - >>>>> > 0665 - MITLL >>>>> > Sent: 20 February 2018 18:47 >>>>> > To: Lou Berger; Abdussalam Baryun >>>>> > Cc: manet; draft-ietf-manet-dlep-latency-extension@ietf.org >>>>> > Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency- >>>>> extension- >>>>> > 02.txt >>>>> > >>>>> > On 2/20/18, 12:42 PM, "manet on behalf of Lou Berger" >>>> > bounces@ietf.org on behalf of lberger@labn.net> wrote: >>>>> > On 2/19/2018 9:19 PM, Abdussalam Baryun wrote: >>>>> > > But IMO it is not clear where the Latency Range item operates >>>>> within >>>>> > > 8175, >>>>> > > >>>>> > >>>>> > The draft currently says: >>>>> > >>>>> > The Latency Range Data Item MAY be carried in the same >>>>> messages >>>>> > ... as the Latency Data Item defined in [RFC8175]. >>>>> > >>>>> > Is this not sufficient? >>>>> > >>>>> > Perhaps AB is reading this as "if a specific, on-the-wire message >>>>> has a Latency >>>>> > Data Item in it, then that particular message is allowed to have a >>>>> Latency >>>>> > Range Data Item. Otherwise, it cannot have a Latency Range Data >>>>> Item. >>>>> > AB, is that your interpretation? If so, then maybe just saying >>>>> "message >>>>> > types" >>>>> > instead of "messages" is enough clarification. >>>>> > >>>>> > David >>>>> >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>> >>>> >>>> >> --001a113d5a72f1f3740565adc609 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

AB

On Wed, Feb 21, 2018 at 12:= 53 AM, Lou Berger <lberger@labn.net> wrote:

Agreed.

On February 20, 2018 5:17:20 PM Rick Taylor <rick@tropicalstormsoftwa= re.com> wrote:

As long as it is obvious that this is after a successful e= xtension negotiation

Rick

(Sent from my phone)

----- Reply message -----
From: "Stan Ratliff" <ratliffstan@gmail.com>
To: "Lou Berger" <lberger@labn.net>
Cc: "Rick Taylor" <rick@tropicalstormsoftware.com>, "= ;Wiggins, David - 0665 - MITLL" <david.wiggins@ll.mit.edu>, "Abdussa= lam Baryun" <abdussalambaryun@gmail.com>, "manet" <manet@ietf.org>, &quo= t;draft-ietf-manet-dlep-latency-extension@ietf.org"= ; <draft-ietf-manet-dlep-latency-extension@ietf.org&= gt;
Subject: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-0= 2.txt
Date: Tue, Feb 20, 2018 21:32

Lou,=C2=A0


On Tue, Feb 20, 2018 at 4:29 PM, Lou Berger <lberger@labn.net<= /a>> wrote:

Stan,

"In lieu" of a mandat= ory 8175 item is a pretty big change.=C2=A0 I don't think we want to go= there.=C2=A0 I think the rest of the text is fine.


Point taken. So, you're good with the second sentence changing to = "The latency Range Data Item MAY be carried in addition to the Latency= Data Item." ??

Regards,
Stan

=C2=A0

On February 20, 2018 4:27:16 PM Stan Ratliff <ratliffstan@gmail.com> wrote:

I agree with Rick on adding 'types'. So, I'll propose some= text. Maybe this will help?=C2=A0

"The Latency Range Data Item MAY be carried in any message where = the Latency Data Item [RFC8175] is allowed. The Latency Range Data Item MAY= be carried in addition to, or in lieu of, the Latency Data Item."

Regards,
Stan


>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The Latency Range Data Item MAY be carri= ed in the same messages
>=C2=A0 =C2=A0 =C2=A0... as=C2=A0 the Latency Data Item defined in [RFC8175].


On Tue, Feb 20, 2018 at 4:05 PM, Rick Taylor <ric= k@tropicalstormsoftware.com> wrote:
We have been fairly consistent in RFC8175 to refer to DLEP *messages*=C2=A0= I'm not sure adding 'types' helps...

Rick

> -----Original Message-----
> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Wiggins, David -<= br> > 0665 - MITLL
> Sent: 20 February 2018 18:47
> To: Lou Berger; Abdussalam Baryun
> Cc: manet; draft-ietf-manet-dlep-latency-extension@ietf.org
> Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-ex= tension-
> 02.txt
>
> On 2/20/18, 12:42 PM, "manet on behalf of Lou Berger" <ma= net-
> bounces@ietf.org= on behalf of lberger@labn.net&= gt; wrote:
>=C2=A0 =C2=A0 =C2=A0On 2/19/2018 9:19 PM, Abdussalam Baryun wrote:
>=C2=A0 =C2=A0 =C2=A0> But IMO it is not clear where the Latency Rang= e item operates within
>=C2=A0 =C2=A0 =C2=A0> 8175,
>=C2=A0 =C2=A0 =C2=A0>
>
>=C2=A0 =C2=A0 =C2=A0The draft currently says:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The Latency Range Data Item MA= Y be carried in the same messages
>=C2=A0 =C2=A0 =C2=A0... as=C2=A0 the Latency Data Item defined in [RFC8= 175].
>
>=C2=A0 =C2=A0 =C2=A0Is this not sufficient?
>
> Perhaps AB is reading this as "if a specific, on-the-wire message= has a Latency
> Data Item in it, then that particular message is allowed to have a Lat= ency
> Range Data Item.=C2=A0 Otherwise, it cannot have a Latency Range Data = Item.
> AB, is that your interpretation?=C2=A0 If so, then maybe just saying &= quot;message
> types"
> instead of "messages" is enough clarification.
>
> David

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



--001a113d5a72f1f3740565adc609-- From nobody Tue Feb 20 16:26:26 2018 Return-Path: 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 1BACB12E055; Tue, 20 Feb 2018 16:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 qC5NwFjl7pPm; Tue, 20 Feb 2018 16:26:20 -0800 (PST) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4DB212E050; Tue, 20 Feb 2018 16:26:19 -0800 (PST) Received: by mail-oi0-x231.google.com with SMTP id b8so6877698oib.11; Tue, 20 Feb 2018 16:26:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zOgq6H9ZnWE37seQKyJXbp6SYC8QdgAP9u2ClE3nQxw=; b=im9B8CTvcQOFSEstJNpOQ7dUnQStJ6vLRCNXjT8dEfEcgOVnhVJVYsNIZrqV9MqkBz ODa+64tRS5W0nMYA+ZEDXlPowSktWyD0K6Hz0Es3OYS+Iga0U05oEmTAgzFwpNss7+/j fX0hvTK83Qq7IcG2z7rfvNnQSb9wvW+yxEg4yaVRTGZKrCuXGb62zsAbTdIiJ/435BSF v9amwTuNiFUiog4M0PnT5Y6yt7/RQKMWrTjIW37ovNGo9r+ASH3UBC0WfxB77w6SjX4s 6736gdUrG3STdN314Qa64etVjnt+CfSlCMKpysIJ/5EFUkpQ4ezNjKNXiU/EvGBmXo2v ZleA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zOgq6H9ZnWE37seQKyJXbp6SYC8QdgAP9u2ClE3nQxw=; b=jp+S1HhoPEHgh4Ep8Ape2qjqCCRSXQcTGLgYPUrkltdp0vxLR7SJxv+YIdWaAMG5cu s52LggXyoArQNx/v+5UOnDldKLZK4R563iljX9N/IIZtDY52scg9OVWfI+2gYbMKW3ed m7zFEvtgQ9GmKdgoFs/vsu4SHmR81uZjRXC3cpf/oPbvKz8oijwxxqkrO4WeBxkA2SRT V5BbFGSJXt50fAxQA4DU2EF+PQadTuPtrcIp0D6jtgazPdrxIaYuRi0MhRBpJqi1pMw4 2kQzd/vbjBLADJhCFXnWOUJD32e8hBZU1WeAGAiso8U+4yC9H3VgjjSc1ozsFy0Xku0Z 39zQ== X-Gm-Message-State: APf1xPB5abn8Fc1RYKbAFDjfYeba/YH2S49jCZ0k7lbp9uajBM3yKgkX YALfepWT3Z2xJ/pcCWdFm3S6T0aJuQcwvyXMk7I= X-Google-Smtp-Source: AG47ELsLQiG+hySKVl0MTEfIhVZf2r7otm9uxss3+cr+LvcM7ALE1YWf3O3VRsH5My85T1V5WT3WNaGIYTNJc95GRXo= X-Received: by 10.202.62.135 with SMTP id l129mr905543oia.333.1519172779306; Tue, 20 Feb 2018 16:26:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.36 with HTTP; Tue, 20 Feb 2018 16:26:18 -0800 (PST) In-Reply-To: References: <151865086912.7521.1302513672018061966@ietfa.amsl.com> <1b0c761b-9fda-49e0-8344-52750c232b74@labn.net> <4FEB14CD-DE8D-4735-9FCA-8912EB49AB82@ll.mit.edu> <38A5475DE83986499AEACD2CFAFC3F9801D330F0F6@tss-server1.home.tropicalstormsoftware.com> <161b51ef380.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> From: Abdussalam Baryun Date: Wed, 21 Feb 2018 02:26:18 +0200 Message-ID: To: Stan Ratliff Cc: Lou Berger , Rick Taylor , "Wiggins, David - 0665 - MITLL" , manet , draft-ietf-manet-dlep-latency-extension@ietf.org Content-Type: multipart/alternative; boundary="001a113cd6ccdcf60a0565adf9fc" Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 00:26:23 -0000 --001a113cd6ccdcf60a0565adf9fc Content-Type: text/plain; charset="UTF-8" Hi Stan, New> The Latency Range Data Item MAY be carried in any message where the Latency Data Item [RFC8175] is allowed. The Latency Range Data Item MAY be carried in addition to the Latency Data Item carried in any message." thanks now it easier to understand, agreed, AB On Tue, Feb 20, 2018 at 11:32 PM, Stan Ratliff wrote: > Lou, > > > On Tue, Feb 20, 2018 at 4:29 PM, Lou Berger wrote: > >> Stan, >> >> "In lieu" of a mandatory 8175 item is a pretty big change. I don't think >> we want to go there. I think the rest of the text is fine. >> > > Point taken. So, you're good with the second sentence changing to "The > latency Range Data Item MAY be carried in addition to the Latency Data > Item." ?? > > Regards, > Stan > > > >> On February 20, 2018 4:27:16 PM Stan Ratliff >> wrote: >> >>> I agree with Rick on adding 'types'. So, I'll propose some text. Maybe >>> this will help? >>> >>> "The Latency Range Data Item MAY be carried in any message where the >>> Latency Data Item [RFC8175] is allowed. The Latency Range Data Item MAY be >>> carried in addition to, or in lieu of, the Latency Data Item." >>> >>> Regards, >>> Stan >>> >>> >>> > The Latency Range Data Item MAY be carried in the same >>> messages >>> > ... as the Latency Data Item defined in [RFC8175]. >>> >>> >>> On Tue, Feb 20, 2018 at 4:05 PM, Rick Taylor < >>> rick@tropicalstormsoftware.com> wrote: >>> >>>> We have been fairly consistent in RFC8175 to refer to DLEP *messages* >>>> I'm not sure adding 'types' helps... >>>> >>>> Rick >>>> >>>> > -----Original Message----- >>>> > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Wiggins, >>>> David - >>>> > 0665 - MITLL >>>> > Sent: 20 February 2018 18:47 >>>> > To: Lou Berger; Abdussalam Baryun >>>> > Cc: manet; draft-ietf-manet-dlep-latency-extension@ietf.org >>>> > Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency- >>>> extension- >>>> > 02.txt >>>> > >>>> > On 2/20/18, 12:42 PM, "manet on behalf of Lou Berger" >>> > bounces@ietf.org on behalf of lberger@labn.net> wrote: >>>> > On 2/19/2018 9:19 PM, Abdussalam Baryun wrote: >>>> > > But IMO it is not clear where the Latency Range item operates >>>> within >>>> > > 8175, >>>> > > >>>> > >>>> > The draft currently says: >>>> > >>>> > The Latency Range Data Item MAY be carried in the same >>>> messages >>>> > ... as the Latency Data Item defined in [RFC8175]. >>>> > >>>> > Is this not sufficient? >>>> > >>>> > Perhaps AB is reading this as "if a specific, on-the-wire message has >>>> a Latency >>>> > Data Item in it, then that particular message is allowed to have a >>>> Latency >>>> > Range Data Item. Otherwise, it cannot have a Latency Range Data Item. >>>> > AB, is that your interpretation? If so, then maybe just saying >>>> "message >>>> > types" >>>> > instead of "messages" is enough clarification. >>>> > >>>> > David >>>> >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>> >>> > --001a113cd6ccdcf60a0565adf9fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Stan,

New> The Latency= Range Data Item MAY be carried in any message where the Latency Data Item = [RFC8175] is allowed. The Latency Range Data Item MAY be carried in additio= n to the Latency Data Item carried in any message."

thanks now it easier to understand,

agreed,=

AB


On Tue, Feb 20, 2018= at 11:32 PM, Stan Ratliff <ratliffstan@gmail.com> wrote= :
Lou,=C2=A0


On Tue, Feb 20, 2018 at 4:29= PM, Lou Berger <lberger@labn.net> wrote:

Stan,

"In lieu" of a mandat= ory 8175 item is a pretty big change.=C2=A0 I don't think we want to go= there.=C2=A0 I think the rest of the text is fine.


Point taken. So, you're good with= the second sentence changing to "The latency Range Data Item MAY be c= arried in addition to the Latency Data Item." ??

<= div>Regards,
Stan

=C2=A0

On February 20, 2018 4:27:16 PM Stan Ratliff <ratliffstan@gmail.com> wr= ote:

I agree with Rick on adding 'types'. So, I= 9;ll propose some text. Maybe this will help?=C2=A0

"The Latency Range Data Item MAY be carried in any message where the= Latency Data Item [RFC8175] is allowed. The Latency Range Data Item MAY be= carried in addition to, or in lieu of, the Latency Data Item."
<= div>
Regards,
Stan


>=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0The Latency Range Data Item MAY be carried in the same mes= sages
>= ;=C2=A0 =C2=A0 =C2=A0... as=C2=A0 the Latency Data Item defined in [RFC8175= ].


On Tue, Feb 2= 0, 2018 at 4:05 PM, Rick Taylor <rick@tropicalstormsoftware.c= om> wrote:
We have been fairly consi= stent in RFC8175 to refer to DLEP *messages*=C2=A0 I'm not sure adding = 'types' helps...

Rick

> -----Original Message-----
> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Wiggins, David -<= br> > 0665 - MITLL
> Sent: 20 February 2018 18:47
> To: Lou Berger; Abdussalam Baryun
> Cc: manet; draft-ietf-manet-dlep-latency-extension@iet= f.org
> Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-ex= tension-
> 02.txt
>
> On 2/20/18, 12:42 PM, "manet on behalf of Lou Berger" <ma= net-
> bounces@ietf.org= on behalf of lbe= rger@labn.net> wrote:
>=C2=A0 =C2=A0 =C2=A0On 2/19/2018 9:19 PM, Abdussalam Baryun wrote:
>=C2=A0 =C2=A0 =C2=A0> But IMO it is not clear where the Latency Rang= e item operates within
>=C2=A0 =C2=A0 =C2=A0> 8175,
>=C2=A0 =C2=A0 =C2=A0>
>
>=C2=A0 =C2=A0 =C2=A0The draft currently says:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The Latency Range Data Item MA= Y be carried in the same messages
>=C2=A0 =C2=A0 =C2=A0... as=C2=A0 the Latency Data Item defined in [RFC8= 175].
>
>=C2=A0 =C2=A0 =C2=A0Is this not sufficient?
>
> Perhaps AB is reading this as "if a specific, on-the-wire message= has a Latency
> Data Item in it, then that particular message is allowed to have a Lat= ency
> Range Data Item.=C2=A0 Otherwise, it cannot have a Latency Range Data = Item.
> AB, is that your interpretation?=C2=A0 If so, then maybe just saying &= quot;message
> types"
> instead of "messages" is enough clarification.
>
> David

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



--001a113cd6ccdcf60a0565adf9fc-- From nobody Tue Feb 20 18:57:53 2018 Return-Path: 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 F2C5C124D68 for ; Tue, 20 Feb 2018 18:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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] 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 Ev46e_fFZ-95 for ; Tue, 20 Feb 2018 18:57:49 -0800 (PST) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) (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 B63411241F3 for ; Tue, 20 Feb 2018 18:57:49 -0800 (PST) Received: from cmgw4 (unknown [10.0.90.85]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id BCD4A1E07AD for ; Tue, 20 Feb 2018 19:57:47 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id DExj1x00X2SSUrH01ExmPM; Tue, 20 Feb 2018 19:57:47 -0700 X-Authority-Analysis: v=2.2 cv=G85sK5s5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=Op4juWPpsa0A:10 a=wU2YTnxGAAAA:8 a=pGLkceISAAAA:8 a=5vjwwrbCAAAA:8 a=48vgC7mUAAAA:8 a=8m3_hxmXnGKK1NOH7GUA:9 a=FyygjwgwXuniU2vL:21 a=puBofw2iBos7R6bX:21 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=pV4yRLctw-KkoPKGQz8o:22 a=w1C3t2QeGrPiZgrLijVG:22 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=n4kMfBoW/IES0QaCNrPrbNPdu+xfzPHVNbF+dfER3HM=; b=C80+LdC74n8e1zgQ+HbvkiJb5k qIcK3tqNQtb5Dj9II7YIggcF1WsaJmTfuJFrVrAt4/6y5MtDIxga4huNx2l18ATFLIjqQjZl7axWa fLi008ptdCbKT3oE/NUCP6lCp; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:45750 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1eoKbH-004GU6-Iu; Tue, 20 Feb 2018 19:57:43 -0700 To: Stan Ratliff Cc: Rick Taylor , "Wiggins, David - 0665 - MITLL" , Abdussalam Baryun , manet , draft-ietf-manet-dlep-latency-extension@ietf.org References: <151865086912.7521.1302513672018061966@ietfa.amsl.com> <1b0c761b-9fda-49e0-8344-52750c232b74@labn.net> <4FEB14CD-DE8D-4735-9FCA-8912EB49AB82@ll.mit.edu> <38A5475DE83986499AEACD2CFAFC3F9801D330F0F6@tss-server1.home.tropicalstormsoftware.com> <161b51ef380.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> From: Lou Berger Message-ID: <4f5c2356-1303-e59f-23c6-7695db9ddb2a@labn.net> Date: Tue, 20 Feb 2018 21:57:41 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: 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: 100.15.86.101 X-Exim-ID: 1eoKbH-004GU6-Iu X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:45750 X-Source-Auth: lberger@labn.net X-Email-Count: 6 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 02:57:52 -0000 How about:  The Latency Range Data Item MAY be   carried in any message where the Latency Data Item [RFC8175] is   allowed and is carried as an additional data item.  When present, the   Latency Range Data Item MUST be processed according to the same rules   as the Latency Data Item defined in . Lou On 2/20/2018 4:32 PM, Stan Ratliff wrote: > Lou, > > > On Tue, Feb 20, 2018 at 4:29 PM, Lou Berger > wrote: > > Stan, > > "In lieu" of a mandatory 8175 item is a pretty big change.  I > don't think we want to go there.  I think the rest of the text is > fine. > > > Point taken. So, you're good with the second sentence changing to "The > latency Range Data Item MAY be carried in addition to the Latency Data > Item." ?? > > Regards, > Stan > > On February 20, 2018 4:27:16 PM Stan Ratliff > > wrote: > >> I agree with Rick on adding 'types'. So, I'll propose some text. >> Maybe this will help? >> >> "The Latency Range Data Item MAY be carried in any message where >> the Latency Data Item [RFC8175] is allowed. The Latency Range >> Data Item MAY be carried in addition to, or in lieu of, the >> Latency Data Item." >> >> Regards, >> Stan >> >> >> >          The Latency Range Data Item MAY be carried in the same >> messages >> >    ... as  the Latency Data Item defined in [RFC8175]. >> >> >> On Tue, Feb 20, 2018 at 4:05 PM, Rick Taylor >> > > wrote: >> >> We have been fairly consistent in RFC8175 to refer to DLEP >> *messages*  I'm not sure adding 'types' helps... >> >> Rick >> >> > -----Original Message----- >> > From: manet [mailto:manet-bounces@ietf.org >> ] On Behalf Of Wiggins, David - >> > 0665 - MITLL >> > Sent: 20 February 2018 18:47 >> > To: Lou Berger; Abdussalam Baryun >> > Cc: manet; draft-ietf-manet-dlep-latency-extension@ietf.org >> >> > Subject: Re: [manet] I-D Action: >> draft-ietf-manet-dlep-latency-extension- >> > 02.txt >> > >> > On 2/20/18, 12:42 PM, "manet on behalf of Lou Berger" > > bounces@ietf.org on behalf of >> lberger@labn.net > wrote: >> >     On 2/19/2018 9:19 PM, Abdussalam Baryun wrote: >> >     > But IMO it is not clear where the Latency Range item >> operates within >> >     > 8175, >> >     > >> > >> >     The draft currently says: >> > >> >           The Latency Range Data Item MAY be carried in the >> same messages >> >     ... as  the Latency Data Item defined in [RFC8175]. >> > >> >     Is this not sufficient? >> > >> > Perhaps AB is reading this as "if a specific, on-the-wire >> message has a Latency >> > Data Item in it, then that particular message is allowed to >> have a Latency >> > Range Data Item.  Otherwise, it cannot have a Latency Range >> Data Item. >> > AB, is that your interpretation? If so, then maybe just >> saying "message >> > types" >> > instead of "messages" is enough clarification. >> > >> > David >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> > From nobody Wed Feb 21 10:46:24 2018 Return-Path: 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 75DA512D890; Wed, 21 Feb 2018 10:46:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151923877744.11047.11623792201807106273@ietfa.amsl.com> Date: Wed, 21 Feb 2018 10:46:17 -0800 Archived-At: Subject: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 18:46:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks WG of the IETF. Title : DLEP Latency Range Extension Authors : Bow-Nan Cheng Lou Berger Filename : draft-ietf-manet-dlep-latency-extension-03.txt Pages : 5 Date : 2018-02-21 Abstract: This document defines an extension to the DLEP protocol to provide the range of latency that may be experienced on a link. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-latency-extension/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-manet-dlep-latency-extension-03 https://datatracker.ietf.org/doc/html/draft-ietf-manet-dlep-latency-extension-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-latency-extension-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 21 11:29:01 2018 Return-Path: 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 7415612D964 for ; Wed, 21 Feb 2018 11:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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] autolearn=ham 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 315Gnjn5I7Q9 for ; Wed, 21 Feb 2018 11:28:58 -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 BF3F3124BAC for ; Wed, 21 Feb 2018 11:28:58 -0800 (PST) Received: from cmgw4 (unknown [10.0.90.85]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id 45C731760C0 for ; Wed, 21 Feb 2018 12:28:57 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id DXUt1x01N2SSUrH01XUwSX; Wed, 21 Feb 2018 12:28:57 -0700 X-Authority-Analysis: v=2.2 cv=G85sK5s5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=Op4juWPpsa0A:10 a=48vgC7mUAAAA:8 a=RehFWjLUiUovX4E7yc0A:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 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:To:Subject:Sender:Reply-To:Cc: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=Yx7O9zyZDJrkVENmgV711C7qLkJh99W0pYrRIOnUlh4=; b=HCChWaYuOHsQBCBnrTsz/aE4a5 hRXBDY9VJd/MBrTFMXPuFPgm+dJBeeKyEjrVvCR+9s33zYyLgyfjvKvaUXbHmnXFEUrpy//uDr7/4 QMh2fJEx3p7ELeCRfQDd5QZd+; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:45270 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1eoa4T-000uMv-Nh for manet@ietf.org; Wed, 21 Feb 2018 12:28:53 -0700 To: manet@ietf.org References: <151923877744.11047.11623792201807106273@ietfa.amsl.com> From: Lou Berger Message-ID: Date: Wed, 21 Feb 2018 14:28:51 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <151923877744.11047.11623792201807106273@ietfa.amsl.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: 100.15.86.101 X-Exim-ID: 1eoa4T-000uMv-Nh X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:45270 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 19:29:00 -0000 Hi,     I thought it would be good to publish my (our) understanding of the current consensus points on the LC/List.  Please comment if you think there are any changes still needed. Lou On 2/21/2018 1:46 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Mobile Ad-hoc Networks WG of the IETF. > > Title : DLEP Latency Range Extension > Authors : Bow-Nan Cheng > Lou Berger > Filename : draft-ietf-manet-dlep-latency-extension-03.txt > Pages : 5 > Date : 2018-02-21 > > Abstract: > This document defines an extension to the DLEP protocol to provide > the range of latency that may be experienced on a link. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-latency-extension/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-manet-dlep-latency-extension-03 > https://datatracker.ietf.org/doc/html/draft-ietf-manet-dlep-latency-extension-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-latency-extension-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Thu Feb 22 08:55:18 2018 Return-Path: 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 F3DEF12DA00 for ; Tue, 20 Feb 2018 11:07:32 -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=ham 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 OmEpfflTu41w for ; Tue, 20 Feb 2018 11:07:32 -0800 (PST) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) (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 E255512D95C for ; Tue, 20 Feb 2018 11:07:31 -0800 (PST) Received: from CMOut01 (unknown [10.0.90.82]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id 70C4614071E for ; Tue, 20 Feb 2018 12:07:31 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id D77T1x0122SSUrH0177W9m; Tue, 20 Feb 2018 12:07:31 -0700 X-Authority-Analysis: v=2.2 cv=Rf/gMxlv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=Op4juWPpsa0A:10 a=48vgC7mUAAAA:8 a=wU2YTnxGAAAA:8 a=jvHO9dImqAaqpHzfXpsA:9 a=7P_OSIAwS9NavnPG:21 a=yYBGcWs_i0kSykXu:21 a=CjuIK1q_8ugA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=Yz9wTY_ffGCQnEDHKrcv:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From: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=UfAEzulUGH+L2m0nE7r7HUM+WdjmoXltW/Pvda9qdtw=; b=dInbA+hn0ak/QCUxSALLNVsCvS ++wljTx5r5Uyrkk5FR/DPmdPqaYApJk2mX6hWvsg96jDyRKT97um2py99xY+prRKeoqkdf/9+0xM6 rd9M09mUgyCrKxhtDzO2On1yc; Received: from [172.58.185.61] (port=22954 helo=[IPV6:2607:fb90:64ba:b75d:0:3:59bf:6501]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1eoDGB-001VHa-8T; Tue, 20 Feb 2018 12:07:27 -0700 From: Lou Berger To: "Wiggins, David - 0665 - MITLL" , Abdussalam Baryun CC: manet , Date: Tue, 20 Feb 2018 14:07:24 -0500 Message-ID: <161b49d01e0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <4FEB14CD-DE8D-4735-9FCA-8912EB49AB82@ll.mit.edu> References: <151865086912.7521.1302513672018061966@ietfa.amsl.com> <1b0c761b-9fda-49e0-8344-52750c232b74@labn.net> <4FEB14CD-DE8D-4735-9FCA-8912EB49AB82@ll.mit.edu> User-Agent: AquaMail/1.13.2-730 (build: 101300200) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit 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: 172.58.185.61 X-Exim-ID: 1eoDGB-001VHa-8T X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPV6:2607:fb90:64ba:b75d:0:3:59bf:6501]) [172.58.185.61]:22954 X-Source-Auth: lberger@labn.net X-Email-Count: 4 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: X-Mailman-Approved-At: Thu, 22 Feb 2018 08:55:17 -0800 Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 19:07:33 -0000 That's reasonable. Thanks, Lou On February 20, 2018 1:47:57 PM "Wiggins, David - 0665 - MITLL" wrote: > On 2/20/18, 12:42 PM, "manet on behalf of Lou Berger" > wrote: > On 2/19/2018 9:19 PM, Abdussalam Baryun wrote: > > But IMO it is not clear where the Latency Range item operates within > > 8175, > > > > The draft currently says: > > The Latency Range Data Item MAY be carried in the same messages > ... as the Latency Data Item defined in [RFC8175]. > > Is this not sufficient? > > Perhaps AB is reading this as "if a specific, on-the-wire message has a Latency > Data Item in it, then that particular message is allowed to have a Latency > Range > Data Item. Otherwise, it cannot have a Latency Range Data Item. > AB, is that your interpretation? If so, then maybe just saying "message types" > instead of "messages" is enough clarification. > > David > From nobody Thu Feb 22 09:33:39 2018 Return-Path: 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 7131812D879 for ; Thu, 22 Feb 2018 09:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 0IKAL8_9OkRW for ; Thu, 22 Feb 2018 09:33:35 -0800 (PST) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C556F12D87B for ; Thu, 22 Feb 2018 09:33:34 -0800 (PST) Received: by mail-wr0-x22f.google.com with SMTP id u49so11382710wrc.10 for ; Thu, 22 Feb 2018 09:33:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:mime-version:to:from:subject:date:in-reply-to:references; bh=bIvNWk1kX7upwnosuy0/5yKwNjDuzzS5mtNpfO67liA=; b=IMWVioiCRL4Bkdrlrt8ssrJnXh5xFMPlSN8DMCGH/76dAmBsOArKg/wbx9N3KnmGvt fMAX6/8C4TPvFoSw+HjxVyB17tEl1bJHYWx5GnfR1eZFwo8+SKdw2lhskrpEppi4NYIX 5JT+pTfEO0B+Z/bd2s8qf6DMQFDEOZeud2QT7/asYiLR+z0oR1Z/UWgCJmDOiNEJpp3N aVQGNchuUEO3E3TFP0rrQeq2pNKJksZMHWgitGg6zN/DW7/ByoRxd0S0ThouQQxL+2W9 QW44m8EmwQcBJn7mSY6CBZePTe03iC316sxneKJdFYhBTO7QvGXbxTgctWfwCPzTPihA fQwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:from:subject:date :in-reply-to:references; bh=bIvNWk1kX7upwnosuy0/5yKwNjDuzzS5mtNpfO67liA=; b=rf5uEutsBm5+IMwyIAYVf/PgbUWzzCSqWkHiBMQUt7x6Lpyu5xeeV3nF6hBFoJ8AW+ xQCyrxS3svyD9T6hchttCsvSee1xOqJscc6YrVEBOZpKygsJ4wv/isPngygqSl8nEr5N NBZBgiXmEg7X1JmlqxmajzeoplIATvsDQX94D+jUX1bFElQbgi9WsOAdT+qcwTkOXO48 UnUVKoBNWe57YlPy0tSdqAXYB1H+mE0JEJw9UxVcCOKAUN9R6o8HsRll3ZqfdWzP8eTY DWn92t975TVhwebHH7Ltenri/lwuARA1N+rFaT0MYMuN7ITlhcy9H5S9ojcTa2ZoW+uZ EU/Q== X-Gm-Message-State: APf1xPDXqolV0PK1xfxm4QiT22W1Qedb7/GVmCa4nZKOdnWUA0OKLLr8 hv1ginPOlemyo//p1INF04f8BhLR X-Google-Smtp-Source: AH8x227mymauu2i92lYvdoxCJ2Ymvhn6RL6wDATSnkeR/tU+mkaPxwi+UgxgQMwFbPgAp9jQrxroGA== X-Received: by 10.223.152.141 with SMTP id w13mr7060538wrb.12.1519320813119; Thu, 22 Feb 2018 09:33:33 -0800 (PST) Received: from [100.72.51.28] (ip-109-41-193-220.web.vodafone.de. [109.41.193.220]) by smtp.gmail.com with ESMTPSA id 7sm1029799wmq.42.2018.02.22.09.33.31 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 22 Feb 2018 09:33:32 -0800 (PST) Message-ID: <5a8efeec.07101c0a.dd077.654f@mx.google.com> MIME-Version: 1.0 To: "manet@ietf.org" From: HvFK Date: Thu, 22 Feb 2018 18:33:31 +0100 In-Reply-To: <151050578647.30922.14809688093789592753@ietfa.amsl.com> References: <151050578647.30922.14809688093789592753@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="_3A35DF64-B5B1-4DE8-997A-2C493C4F85F4_" Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-da-credit-extension-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 17:33:37 -0000 --_3A35DF64-B5B1-4DE8-997A-2C493C4F85F4_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Dear all, I am currently Working on da-credit-extension and the dlep-pause-= extension. Am I right when saying that both are either-or and should not be= combined in the same DLEP session? (at least it doesn't make sense) Cheers Georg=20 ----- Urspr=C3=BCngliche Nachricht ----- Von: "internet-drafts@ietf.org" Gesendet: =E2=80=8E12.=E2=80=8E11.=E2=80=8E2017 17:56 An: "i-d-announce@ietf.org" Cc: "manet@ietf.org" Betreff: [manet] I-D Action: draft-ietf-manet-dlep-da-credit-extension-03.t= xt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks WG of the IETF. Title : DLEP DiffServ Aware Credit Windowing Extension Authors : Bow-Nan Cheng David Wiggins Lou Berger Filename : draft-ietf-manet-dlep-da-credit-extension-03.txt Pages : 24 Date : 2017-11-12 Abstract: This document defines an extension to the DLEP protocol that enables a DiffServ aware credit-windowing scheme for destination-specific and shared flow control. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-da-credit-extension/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-manet-dlep-da-credit-extension-03 https://datatracker.ietf.org/doc/html/draft-ietf-manet-dlep-da-credit-exten= sion-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-dlep-da-credit-extensi= on-03 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_3A35DF64-B5B1-4DE8-997A-2C493C4F85F4_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Dear all, I am currently Working on da-credit-extension a= nd the dlep-pause-extension. Am I right when saying that both are either-or= and should not be combined in the same DLEP session? (at least it doesn't = make sense)
Cheers
Georg
Von: internet-drafts@ietf.org<= /a>
Gesendet: =E2=80=8E12.=E2=80=8E11.=E2=80=8E2017 17:56=
An: i-d-announc= e@ietf.org
Cc: mane= t@ietf.org
Betreff: [manet] I-D Action: draft-ietf-ma= net-dlep-da-credit-extension-03.txt


A New Internet-= Draft is available from the on-line Internet-Drafts directories.
This dr= aft is a work item of the Mobile Ad-hoc Networks WG of the IETF.

&nb= sp;       Title     =       : DLEP DiffServ Aware Credit Windowing Exten= sion
        Authors   = ;      : Bow-Nan Cheng
    =             &nb= sp;         David Wiggins
 =             &nb= sp;            Lou B= erger
Filename        : draft-ietf-m= anet-dlep-da-credit-extension-03.txt
Pages     = ;      : 24
Date     =        : 2017-11-12

Abstract:
 = ;  This document defines an extension to the DLEP protocol that enable= s
   a DiffServ aware credit-windowing scheme for destination-= specific and
   shared flow control.


The IETF datat= racker status page for this draft is:
https://datatracker.ietf.org/doc/d= raft-ietf-manet-dlep-da-credit-extension/

There are also htmlized ve= rsions available at:
https://tools.ietf.org/html/draft-ietf-manet-dlep-d= a-credit-extension-03
https://datatracker.ietf.org/doc/html/draft-ietf-m= anet-dlep-da-credit-extension-03

A diff from the previous version is= available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-dlep= -da-credit-extension-03


Please note that it may take a couple of= minutes from the time of submission
until the htmlized version and diff= are available at tools.ietf.org.

Internet-Drafts are also available= by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______= ________________________________________
manet mailing list
manet@iet= f.org
https://www.ietf.org/mailman/listinfo/manet
= --_3A35DF64-B5B1-4DE8-997A-2C493C4F85F4_-- From nobody Wed Feb 28 08:12:48 2018 Return-Path: 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 442F712D0C3; Wed, 28 Feb 2018 08:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=idirect.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 InD60RdWX-4b; Wed, 28 Feb 2018 08:12:43 -0800 (PST) Received: from mx0b-00229401.pphosted.com (mx0a-00229401.pphosted.com [148.163.157.249]) (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 C538A124B17; Wed, 28 Feb 2018 08:12:43 -0800 (PST) Received: from pps.filterd (m0097894.ppops.net [127.0.0.1]) by mx0b-00229401.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1SGAW8E030358; Wed, 28 Feb 2018 11:10:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=idirect.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=dk1; bh=gpp3kpEtTDA00WgyGK+Oa1xBNGBZYHlAdeoLKNeCoeQ=; b=HkeJ8imj/lRUfDMQz4skgoxu7T2oFmb67D1myBGyWtSYKGbd/in2DEG24/gnFzPRBU8h 7NNlhqSO3ZsIUF+lf9Qxq5gJJN1xHJmafCm8HZtKfDWdGqJ7u3cu/TsbIpkpFRfj0XNh HLAX+TEnu0AhrdxMEvaeI+mLJTPuNtTEqrCAieprokrZ4hibioeSIAWAwH2Ga3i7Xua+ aeqgpKlnxWiB2n1m/iSjsmcvBr3UwodtiPnUu5ZdLG8ZlHtjlhv3WaONK0+A7ccnKQvj LwcXfVzJpWkbU5oSXTw1bjJCMRWv77G3zxGPYJcoyqI4FEkx89KhSeFXwECevrncZvl0 Og== Received: from webmail.idirect.net ([198.180.159.2]) by mx0b-00229401.pphosted.com with ESMTP id 2gb4q9jsd7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Wed, 28 Feb 2018 11:10:32 -0500 Received: from vausditchmc3.idirect.net (10.250.251.203) by vausditchmc1.idirect.net (10.250.251.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1415.2; Wed, 28 Feb 2018 11:13:59 -0500 Received: from vausditchmc3.idirect.net ([fe80::a089:5025:3057:5d51]) by vausditchmc3.idirect.net ([fe80::a089:5025:3057:5d51%13]) with mapi id 15.01.1415.002; Wed, 28 Feb 2018 11:10:29 -0500 From: "Ratliff, Stanley" To: Daniele Ceccarelli , "manet-chairs@ietf.org" , "manet@ietf.org" CC: Alvaro Retana , "ccamp-chairs@ietf.org" , "BRUNGARD, DEBORAH A (ATTLABS) (db3546@att.com)" Thread-Topic: IETF 101 - CCAMP & MANET session slot request Thread-Index: AdOwp1CYYdWSc/BsTNiXgMs43Eun3gABfbSQAABK1NA= Date: Wed, 28 Feb 2018 16:10:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.250.251.20] Content-Type: multipart/alternative; boundary="_000_e31fbd3f99164e9898a78323eaaef632idirectnet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-28_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outboundspam_notspam policy=outboundspam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802280196 Archived-At: Subject: Re: [manet] IETF 101 - CCAMP & MANET session slot request X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 16:12:46 -0000 --_000_e31fbd3f99164e9898a78323eaaef632idirectnet_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hello MANET WG, Instead of a dedicated MANET meeting this IETF, we've opted to do a couple = of joint sessions - one with the MBONE/MCAST group, another (as you can see= below) with CCAMP. The focus of the CCAMP/MANET meeting will be discussing= DLEP and modifications going forward, and whether the technology can apply= to CCAMP. Please let myself or Justin know if you're interested in a presentation slo= t for the joint CCAMP/MANET meeting. Regards, Stan From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Wednesday, February 28, 2018 11:04 AM To: manet-chairs@ietf.org Cc: Alvaro Retana ; ccamp-chairs@ietf.org; BRUNGARD= , DEBORAH A (ATTLABS) (db3546@att.com) Subject: FW: IETF 101 - CCAMP & MANET session slot request . Justin, Stan, please forward the slot and slides requests for the join session to MANET. We've setup a survey in Gizmo where it is possible to ask for a slot specif= ying the desired session. Cheers, Daniele From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: mercoled=EC 28 febbraio 2018 16:56 To: CCAMP (ccamp@ietf.org) > Cc: ccamp-chairs@ietf.org Subject: IETF 101 - CCAMP & MANET session slot request Dear CCAMP and MANET It's time to start building the agenda for the two sessions scheduled @IETF= 101 Please note that we have 2 sessions: - Session 1: CCAMP only - Monday - Morning session I (2.5h) - Session 2: CCAMP & MANET joint session - Monday - Afternoon sess= ion (1h) Agenda Requests: - To submit a request, please fill the survey at the following link: https:= //www.surveygizmo.com/s3/4229243/IETF101-CCAMP-slot-request - Please specify which session you're requesting a slot for. - Please fill the survey no later than Sunday, March 4th. Presentations: If you are presenting slides please make sure you send them to all *indi= viduals* listed above (Chairs, Secretary and exclude CCAMP) no later than = Friday, March 16th. (please note we're meeting on Monday morning and aftern= oon respectively) Reminder about a few important dates: * 2018-03-05 (Monday): Internet Draft submission cut-off (for all draft= s, including -00) by UTC 23:59. Upload using the ID Submission Tool. * 2018-03-07 (Wednesday): Draft Working Group agendas due by UTC 23:59.= Upload using the Meeting Materials Management Tool. * 2018-03-12 (Monday): Revised Working Group agendas due by UTC 23:59. = Upload using the Meeting Materials Management Tool. Best Regards, Daniele, Fatai, =D3scar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This electronic message and any files transmitted with it contains information from iDirect, which may be privileged, proprietary and/or confidential. It is intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please delete it and immediately notify the sender. --_000_e31fbd3f99164e9898a78323eaaef632idirectnet_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1"

Hello MANET WG,

 

Instead of a dedicated MANET meeting = this IETF, we’ve opted to do a couple of joint sessions – one w= ith the MBONE/MCAST group, another (as you can see below) with CCAMP. The focus of the CCAMP/MANET meeting will be discussing DLEP a= nd modifications going forward, and whether the technology can apply to CCA= MP.

 

Please let myself or Justin know if y= ou’re interested in a presentation slot for the joint CCAMP/MANET mee= ting.

 

Regards,

Stan

 

 

From: Daniele Ceccarelli [mailto:dan= iele.ceccarelli@ericsson.com]
Sent: Wednesday, February 28, 2018 11:04 AM
To: manet-chairs@ietf.org
Cc: Alvaro Retana <aretana.ietf@gmail.com>; ccamp-chairs@ietf.= org; BRUNGARD, DEBORAH A (ATTLABS) (db3546@att.com) <db3546@att.com><= br> Subject: FW: IETF 101 - CCAMP & MANET session slot request
.

Justin, Stan,<= o:p>

 

please forward the slot and slides requests for the= join session to MANET.

We’ve setup a survey in Gizmo where it is pos= sible to ask for a slot specifying the desired session.

 

Cheers,
Daniele 

 

 

 

Dear CCAMP and MANET

 

It’s time to start building the a= genda for the two sessions scheduled @IETF 101

&nbs= p;

Plea= se note that we have 2 sessions:=

-     &= nbsp;    Session 1: CCAMP only – M= onday – Morning session I (2.5h)

-     &= nbsp;    Session 2: CCAMP & MANET jo= int session – Monday – Afternoon session (1h)

&nbs= p;

Agenda Requests:

-&nb= sp;To submit a request, please fill the survey at the following link: https://www.surveygizmo.com/s3/4229243/IETF101-CCAMP-slot-request

- Please specify which session you’re requ= esting a slot for.

- Please fill the survey no later than&= nbsp;Sunday, March 4th.

&nbs= p;

Presentations:

&nbs= p; If you are presenting slides please make sure you send them to  all= *individuals* listed above (Chairs, Secretary and exclude CCAMP) no later&= nbsp; than Friday, March 16th. (please note we’re meeting on Monday morning and afternoon respectively)

&nbs= p;

Reminder about a few important dates:

  • 2018-03-05 (Monday): Internet Draft submission cut-off = (for all drafts, including -00) by UTC 23:59. Upload using the <= a href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracke= r.ietf.org_submit_&d=3DDwMFAw&c=3DLlUvidvlhStGUSxQl0giOA&r=3DQz= gCKlK-eUsbLW5r8KZAL9L_yqNON1dbKtMa-Wbxna8&m=3DCR6UmcPQb2VMfniAlJb-l8CDg= VqkEf4Gr-yYXqeL-Wk&s=3DLMxxBPE83EFQUgmag-pVdPi6xZTvoyOvExCWF6xJnT4&= e=3D">ID Submission Tool.
  • 2018-03-07 (Wednesday): Draft Working Group agendas due= by UTC 23:59. Upload using the <= a href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracke= r.ietf.org_meeting_101_materials&d=3DDwMFAw&c=3DLlUvidvlhStGUSxQl0g= iOA&r=3DQzgCKlK-eUsbLW5r8KZAL9L_yqNON1dbKtMa-Wbxna8&m=3DCR6UmcPQb2V= MfniAlJb-l8CDgVqkEf4Gr-yYXqeL-Wk&s=3DCjuMx9CRWk7bfreU7bLNPeIUErsDdfF-xk= vrwnXRtq0&e=3D">Meeting Materials Management Tool.<= /span>
  • 2018-03-12 (Monday): Revised Working Group agendas due = by UTC 23:59. Upload using the Meeting Materials Management Tool.

Best Regards,<= o:p>

 

Daniele, Fatai, =D3scar 

 

 

This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
--_000_e31fbd3f99164e9898a78323eaaef632idirectnet_--