Re: AD review of draft-ietf-bfd-multipoint-14

Martin Vigoureux <martin.vigoureux@nokia.com> Wed, 18 April 2018 13:23 UTC

Return-Path: <martin.vigoureux@nokia.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DEF1243F6; Wed, 18 Apr 2018 06:23:17 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 UO4zN6AjFelx; Wed, 18 Apr 2018 06:23:13 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0095.outbound.protection.outlook.com [104.47.0.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 057531267BB; Wed, 18 Apr 2018 06:23:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Sqm+f/nUOERiKw9rTo+v/TordYdDiF6IimBja0vWymc=; b=A3lGczzkWezhhAUfeypo9qkSmx+rF2QoALXvCJn6/iDHuE7Nzu8gqDz4UV/Uf8MY4ofzT/FlExWqIrlutaO8hXfa9EnRLgJ/ZcseZaTuDXk5QW3nlUPN/ZeTOufUotWo3dgHIAvy9iqn9Od99QO5dCT+8ugzHrBT+HQN3A2uekA=
Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com;
Received: from [IPv6:2a01:cb04:a1a:4c00:f443:6b8b:e1f8:5e65] (2a01:cb04:a1a:4c00:f443:6b8b:e1f8:5e65) by HE1PR0701MB2139.eurprd07.prod.outlook.com (2603:10a6:3:2b::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.7; Wed, 18 Apr 2018 13:23:09 +0000
Subject: Re: AD review of draft-ietf-bfd-multipoint-14
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: draft-ietf-bfd-multipoint@ietf.org, "Reshad Rahman (rrahman)" <rrahman@cisco.com>, bfd-chairs@ietf.org, rtg-bfd@ietf.org
References: <ef98cd8b-2e3a-40bc-42e9-82cb64d1f87d@nokia.com> <CA+RyBmUKiawoqi2G6Kz8wPYSeYG1L0hUk8zmDVK+kSCZaA_3Yw@mail.gmail.com> <b160454c-5fec-4c57-2c37-20ccf3b8dceb@nokia.com> <CA+RyBmXkVuo=yb1ivdf2-MPfPw-UAYHfP83d0RnZnxn-jkQN2A@mail.gmail.com> <ab28a63b-3da5-fc3d-a48a-44640bce385d@nokia.com> <CA+RyBmUKuV=YsLckqj8NBVXxtRw1i0VPxiy1zc4ucb+tGxtcrw@mail.gmail.com>
From: Martin Vigoureux <martin.vigoureux@nokia.com>
Message-ID: <bbaab4ef-6e0e-de41-f751-32f12db4672b@nokia.com>
Date: Wed, 18 Apr 2018 15:22:42 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <CA+RyBmUKuV=YsLckqj8NBVXxtRw1i0VPxiy1zc4ucb+tGxtcrw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
X-Originating-IP: [2a01:cb04:a1a:4c00:f443:6b8b:e1f8:5e65]
X-ClientProxiedBy: CWLP265CA0012.GBRP265.PROD.OUTLOOK.COM (2603:10a6:401:10::24) To HE1PR0701MB2139.eurprd07.prod.outlook.com (2603:10a6:3:2b::12)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-HT: Tenant
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:HE1PR0701MB2139;
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB2139; 3:6riEyUs1EPhHEXtrciRGXK1hQK3THnM48dhGFCvtKBwLB42ipVCqjw8dj4/OoRcDxZtK3e5MM2AB0wi4a/JMz9px3aFGopEmobdu8kzLbuk7YGGEaTF7YETyDZ79bqk9EtVlPm9wGUOAnGIUmGHAIIyO+Q0j4/8Dk3DhTXymeN3PNErakSQ9oaqIaLgAwD8zDp/i5ggCWIGK5pasPDgM5JWO3JfL/+xSRzOwUAJYASZlvcKpcfHfNDvPS7r2Npml; 25:LpzutKLPTCLyXLiD+2YxvMhZ+84hC7o7Y9fK6XG+cIzoCDIhTC1GuSbMbdfIcU8GqhT0zq/J+TJdgVMeQBSaUAXt1Ki0BvkR3rrfg1WwCh0wtr2G6+5kBN45vhzYkuhI7K96pcwXNP07rXzpcUaAWLZtEeBwYYtNEJ9xVw8ojBu9w+Fz0lEh/PzKVVN8kUIgjMLTOGYfNUr+S6mtZzdFoAfiR/Yy99SPtz5kbW4eoDTIbejHOPIExi67WYeerlTaIknT/bpV9QDnO19Pb+e4mYPf8ybTByHlzFGcLkOERXQ0CAmSY2LPassU6gP6P/q1ZZVeh1ZenjprcpGsLCMvHg==; 31:fYaSQtT8sPvYUPz7SoSiqK9Pl0emj0z9OYbB2++CHYQp4TFD8GC9I1ij6O90dG+IICJb9jC55D6yR3UlbJM6sYv13jJjchE8aIBLEbuS1VT85nu7bk+o5OOB95OAT+dptSYuW4QhAXRuY04lQZOZJOtW9ZS8rti0DaCebTTiKfG3MQoWXJRomzI7gHsPYdRGTPcGe7+D8laCzio08hb7718QjsSeurHBxta0UESNR80=
X-MS-TrafficTypeDiagnostic: HE1PR0701MB2139:
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB2139; 20:tmF2bZx43CY4cn0TFhp3l5A8sGO/xALrorFr8xrOS05BbBFyPoqqFUB2Gf2uIPLJYjFW8uhoWjyEfdIIucK9m9sN2XDIEMOIxb9wBjtyw21vtM8QNIbdUkidXvJc5Yi62Mo10032VZOH1yIo2dUsT18Gvb3bTGDCNHYioYggBwYDocEKx/PNZjcbzBZcz1QoUB9M480gSSOv0CO3ShsRysdpoGNRLKiSnzIXfSJgT/m2ZLKG13Shl35XAFbJ1lTSMoPSEDdaBGjArEcKJNpdFoNvJ9bAgDYY9xSzVpt5q7lbi3f+qZ/W0zo0oJ+deg/sTXeJp83hdSHk8hfV6KsrJ9tbXvMwEw0Ca1gyLC/Fxtpc5IXNkt/SzsXvlX37lX2sfGmMnZmjP/MucUpbihAVh57Voud1GLYz3irW6rRvW9n5OFoznIjRXx/lvXhumXlx3k6egV9um3dd2c3lJeKX7uKN6tQ4ehSjckHnNS6exzc9YXtZJ0bgkl8qFHRe/1jh; 4:siNoWHSHZH1NPSVY5o117olL1S4Qhd19HFTLSpjhAvEfiOcOMslYl9RB2LV3wAUK/Cs5YBvIUrDziirC64Kq8jIzIlS2Ky5isGhs88HBM7QugNiBKFu2TzPQOnEkUGkR8GOJ+BpVAQT3KvpCXmD9Y5LFwu7m6w6Ok930fie6EhyipMjHtnziTc+f31a21y2u3qR48F4ugrP3umMLs3aykm0IUl+J8xcQlOSNfhPYC7YP+p9B6+mDgC/Z6+XO2q2Nj5+cinEEfXRzISADgzh2MgW8olDsrZ9BQxusOKYxj0UCNLA8eLV3N9S52i5QdmPv
X-Microsoft-Antispam-PRVS: <HE1PR0701MB213936BD3378546D4B21377F8CB60@HE1PR0701MB2139.eurprd07.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(82608151540597);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231232)(11241501184)(806099)(944501327)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041310)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:HE1PR0701MB2139; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2139;
X-Forefront-PRVS: 06469BCC91
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(39380400002)(366004)(376002)(39860400002)(396003)(346002)(51444003)(54094003)(40764003)(377424004)(64126003)(44832011)(446003)(6916009)(2616005)(1411001)(67846002)(76176011)(16799955002)(305945005)(52116002)(23676004)(7736002)(6666003)(93886005)(52146003)(2486003)(65826007)(52396003)(65806001)(966005)(5660300001)(561944003)(65956001)(386003)(59450400001)(6246003)(6306002)(476003)(47776003)(53546011)(11346002)(50466002)(31686004)(6486002)(4326008)(316002)(1706002)(229853002)(2870700001)(6116002)(39060400002)(36756003)(53936002)(25786009)(16526019)(2906002)(31696002)(81166006)(46003)(345774005)(478600001)(86362001)(8676002)(106356001)(58126008)(186003)(3260700006)(68736007)(8936002)(5890100001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2139; H:[IPv6:2a01:cb04:a1a:4c00:f443:6b8b:e1f8:5e65]; FPR:; SPF:None; LANG:en; MLV:ovrnspm; PTR:InfoNoRecords;
X-Microsoft-Exchange-Diagnostics: 1;HE1PR0701MB2139;23:jTwdeN4OgSapeYEENU4AsRWQ3TbvWMkrQL0gJAcYcslrYWY9ea1mHX2TijBO8zyBmE9BTRR4Jak7pBzJqLQ1nJf7FKcXlqy40YedksgXJPZ7xDt+MaeRZBMeM+0YhlKEXe93tmaNsw25LMroG8nqbtiq7g+6hmPlcY20A+lkPprTVev/xX9IY7zEA+sXlPVgWt3QXB9hTeFtURfQWoUZLZAMVUJcUKHwcaBWg7Be362sI0FHvqJK5eUwzk2LhiSnuwV7IKJ4NS6oDEn0uMUKF7/3Z5UVLFMpFQftOBZK6dBJ8/7Y+KRF3ihNPmhcZbCJ/SsPcP1oOzKJpd1RFzfgdJXGziRxUkAid26QzDNWHt+RBtnuQkYNU2m5tR8ZI8jD5YNUJrA+jbdvPph3BPyudurHvics4Nx6cDOGp0PxzIrUN+YxLoI77Vk9n+CaLDhLvS+PI97YD+gdScqsAlz+8m9YfAuJ/WG3Xcz/OBVgUNWQncIrJDiAXXUxfLNU7IArCm1Lm/TDG0UIyVFzbEnn1uiMtCVp2c7lcgG5qdAMsE9D0fXl5LYizSqMpsuoabiDa4buVUjw9/BTjUOqRBdyxI6JWajNLdwuRBcYRFuTFAa4axbJUrN37mDTbsaWCP8LXAwOkdodv57LB+k49Vk2vPFBsj+8OiJMbGk7ldFvqhUCYVTwfP6SorJ032kM1zUnzaMhpLf8uvf7k5yjU1MA6rAemkFKRKhlWMmgO3OIZw/f8YV8TGbM7aLyLtqMBuqhaQDER6AzRfIfUC6RODZEX2LLJefqMSYhLvD4fEtuJ/meK27fTCWhMTw36IihAJiubTu5MIrr3ncEmIKqrf7dVucZs4hJLrPcs1GciKTcHYZEJHt1yG/KLx4LVv/V6thK/1zWIIWN41gdbL/YGaCAXZoAfDWlaAljjAHqKaG3pQYCyAODfGaEEBMqqOqL7E1atJ8GZKYb2B43cEEX/gxQgnF5CsX+IY3ZRYa1dDMnj2RdPaPI1XiZchzwPjvXPIZFWQ48Zivpn32BHB0vyADjVcIW2C0kkYod/6bWWDySD4GDpiVPr3zsm5nyYooxvFAcWKQuDgHwtQB4cCEGQr25yWDpXk2yiQ4rBzGHND7YtdmBwsGy0yQWnJkp7iXnP8OzUoaydRWEIHuJVHI2PprGY+8JFIlwdNYgBNoc3LDWSBRiYcxkkkBC6zgizSlpOfZnTDrbvBb4zStILf5o1C/XzhStrRBwB5aFDyqRylbQA1QdKcCMdNK8ap4841PwJ7YwV5WGg7zJHPNwEACwc95y51wyDllcpt1tqUFsvm4isQfPd5DYTEjQJiTLoH9OWEGMLEqdy53M/ZV9bsDbok43FPFRhyI8nBsKwGCBzDoj2i3Xw8Ngm5wfh19EaS71rhpjcoYcPSkfWun57hzB4CDukXNFce4hcTOXN/mwTcLI/qhsmM5rWntMPgx/uBRNe6m0BvVR5yg0Z3e3sq7altqye+F04OcuheU5X+wruhNtWsay1R/3sd7NfUi8fikSzEvcBADhBa57EmUYi9dbv3Qlp/2btYxAysLQcxkzRJh6QS/pAuoUBGbhTYO21RDjBMJtJpmr0GnBzc3gY27PCi/TuQ==
X-Microsoft-Antispam-Message-Info: 7YuDIINMObFnHkHAH+rzlrXqosuG/CeeKk/ept5+OWkZ+/Ji9iPr/Yp0GFg9m4kf1ID0GqbxTigxPbPkm7N1XPEhFJQExPbw2W9fJtlHorj9UoWWgKqi3VNnfQB858XmpVb2QbrFXJNJea3rQovhrNxhyLyOaq5ayRP9ZVkBNe4PIP+45mQTIysgFs5XXlj4r80ixwpA5sGGQzLNhoMghBh3aBN1SUVxJ2r4Q0wIBSXfiS84oY03ocFh/CczNZT/
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB2139; 6:4XQOGmk/Qwzgd7ngs/HV6okZQ1MnztH7kl5G7hkzSFFF/LLVnayIuphALlEnIuPya22xC+9+O8qc/XzZJtGfTHQfb6hqwEBbh4DqyiJFxLbCN3KVqpv+xDfpSk3mhxnVnecjeNhPrAZuu7mv0oIhzUXdwXJGvLFgcbqYkXPIiTwQaz2ngUmB/eYLD3qyJG2jYVDVZ/xwqDMD68GZlZcRx2uBQGQuJe1WKxKus5rxK5dlpWe5niGL2NQNnYbF+JObKELF4MZuqtUlC6zkM0gkX2nE/jRnAWANT8XnWQQuSCeO+LRoktm5Gh87JGn/aNl4LDkYBrbeox+KScn2ppbaQ9KosE9wgDDKi6Th8maA68hIXqPHCpa/Ha3uFoNBPQAD30dH1Wa46Lj63ALpua+VPZfulBbmLb1ZlZovaakzjkfpKTIr7O0oKkErySRgMF5aR121xiCmER5O2pTCDaIAtg==; 5:+LBP+i0zTaUlfKB7Jp3+jb4hdGs5ORvnfaPuecgHpKirCGMFJtvqS2pza3ndlh3Xnl3Bwtk0Riyof9BNPgwOymebrZMQfq85L8yiFj55Vtbn8QxrUPK+Tx/Iwirjz2pjsQQblvGaitM1YFb4zW3SuyTzQNCvgxaSDlCmvXQxsR0=; 24:Gf0oYDPxK85RteKwvqA64fwyd9/iCd0wirTOe5liibs9V7eT2cRmw6juoMsKx9zaaoSqus/HwED0nB4XBDJJNPS6qL2XZ3LU+ACAwRxUCTI=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB2139; 7:885fuz4n2k4Q42bFurnlTEU/BNS8WKLu0nUd6+ajis61BArZP6Vvlevm2S8wC1ZOGuHGzIMFcXRDb3e29PXYf3Lbm8p/vuUbkdA/NQWJHT4GtN0ikhII/OsWpAe1+5VLvWaMgOFpgVCiTE3iXv0+jsgSBDSvj/hs1YG8+dpaytjp+eig1VOv7yxo6r6vxqR2lt3q5ur7Y5COLRqwilrRMhpHNHZ1EL5FpHoNJDI62Xnem3YMA4EWl7nKveTcpYce
X-MS-Office365-Filtering-Correlation-Id: 99285f01-86f7-42c3-b45b-08d5a52f877b
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Apr 2018 13:23:09.3907 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 99285f01-86f7-42c3-b45b-08d5a52f877b
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2139
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/xQcZrpH1AobnHOmxndew_ntRcGw>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Apr 2018 13:23:18 -0000

Greg,

thanks. Sorry, but reading again the document I found:
          This variable MUST be initialized to the appropriate type when
          the session is created, according to the rules in Section 4.13
I might have parsed 4.13 (and subsections) too quickly but I did not 
find any rule regarding the initalization of this variable. Is that 
indeed the case? If so then I would suggest to simply remove the pointer.

-m

Le 2018-04-17 à 22:20, Greg Mirsky a écrit :
> Hi Martin,
> I've added references to 4.7 and 4.13.2. The new version -15 has been published.
> Thank you for your help and support.
> 
> Regards,
> Greg
> 
> On Tue, Apr 17, 2018 at 12:31 PM, Martin Vigoureux
> <martin.vigoureux@nokia.com> wrote:
>> Greg,
>>
>> I'm fine your proposal below.
>> Please post the final update whenever you can.
>> Thx
>>
>> -m
>>
>>
>> Le 2018-04-17 à 20:40, Greg Mirsky a écrit :
>>>
>>> Hi Martin,
>>> I have not ignored that comment but missed to ack its acceptance. Two
>>> other outstanding questions:
>>>
>>>    * the text, that I've misinterpreted earlier, is in the Overview
>>> section:
>>>
>>>                   Although this document describes a single head and a
>>>          set of tails
>>>                   spanned by a single multipoint path, the protocol is
>>>          capable of
>>>                   supporting (and discriminating between) more than one
>>>          multipoint
>>>               path
>>>                   at both heads and tails.
>>>               There is no text to describe how one could achieve that.
>>>          Wouldn't it
>>>               be worth adding some?
>>>
>>>          GIM>> The question of applicability of this specification to
>>>          mp2mp scenario came up at BIER WG meeting in London. Perhaps we
>>>          can say the these questions are ouside the scope of this
>>>          document and discuss whether there are interested to work on
>>>          mp2mp case as a separete document?
>>>
>>>      I don't read this part of the document as talking about mp2mp but
>>>      rather as talking about multiple p2mp trees.
>>>
>>>      Sections 4.7 and 4.13.2 provides details on demultiplexing BFD
>>>      control packets at a MultipointTail. Would the reference to these
>>>      sections be sufficient?
>>>    * yes, moved the reference to Point-to-Point session to section 4.4.1
>>>
>>> Attached please find the diff between -14 and the working version of the
>>> draft. Please let me know if the changes address your comments. Will upload
>>> the new version promptly.
>>>
>>> Regards,
>>> Greg
>>>
>>> On Tue, Apr 17, 2018 at 9:49 AM, Martin Vigoureux
>>> <martin.vigoureux@nokia.com <mailto:martin.vigoureux@nokia.com>> wrote:
>>>
>>>      Greg,
>>>
>>>      thanks. please see in-line.
>>>
>>>      once I see the update published I will request IETF LC.
>>>
>>>      -m
>>>
>>>      Le 2018-04-17 à 18:34, Greg Mirsky a écrit :
>>>
>>>          Hi Martin,
>>>          thank you for your thorough review, thoughtful comments and kind
>>>          words.
>>>          Please find my answers to your questions in-line and tagged GIM>>.
>>>
>>>          Regards,
>>>          Greg
>>>
>>>          On Tue, Apr 17, 2018 at 8:06 AM, Martin Vigoureux
>>>          <martin.vigoureux@nokia.com <mailto:martin.vigoureux@nokia.com>
>>>          <mailto:martin.vigoureux@nokia.com
>>>
>>>          <mailto:martin.vigoureux@nokia.com>>> wrote:
>>>
>>>               [resend, wrong bfd wg address in first attempt ...]
>>>
>>>               Authors, WG,
>>>
>>>               thank you for this document. It is clear and well written.
>>>               I didn't find any technical comment to make so I've been
>>>          nit picking :-)
>>>               Please find those comments below.
>>>
>>>               regards,
>>>               martin
>>>
>>>               ---
>>>               Please check and address the nits:
>>>
>>> https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-bfd-multipoint-14.txt
>>>
>>> <https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-bfd-multipoint-14.txt>
>>>
>>> <https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-bfd-multipoint-14.txt
>>>
>>> <https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-bfd-multipoint-14.txt>>
>>>
>>>               On that aspect, does this document really update 7880 as
>>>          the header
>>>               says? The Introduction only refers to 5880 and it is not
>>>          clear in
>>>               the body of the Document what effectively impacts 7880. The
>>>          only
>>>               thing I saw is the addition of new session types but that
>>>          does not
>>>               require an update in my opinion. Could you clarify?
>>>               GIM>> Yes, you'correct, the only connection to RFC 7880 are
>>>          the new
>>>               values of bfd.sessionType. The proposal to list RFC 7880 as
>>>          updated
>>>               by this specification was inteded to address Errata to RFC
>>> 7880
>>>               <https://www.rfc-editor.org/errata_search.php?rfc=7880
>>>          <https://www.rfc-editor.org/errata_search.php?rfc=7880>>.
>>>
>>>      I am not sure how this document relates to or addresses the errata.
>>>      So I still think it does not update 7880.
>>>
>>>
>>>                   i.e. existence of a path between the sender and the
>>>          receiver.
>>>               do you mean "forwarding path"?
>>>               GIM>> Yes. Updated to
>>>
>>>               i.e. existence of a forwarding path between the sender and
>>>          the receiver
>>>
>>>      thx
>>>
>>>
>>>               Section 2. and Section 3. seem a bit redundant. They both
>>>          state the
>>>               same thing but from a different angle. Not critical.
>>>
>>>
>>>                   Although this document describes a single head and a
>>>          set of tails
>>>                   spanned by a single multipoint path, the protocol is
>>>          capable of
>>>                   supporting (and discriminating between) more than one
>>>          multipoint
>>>               path
>>>                   at both heads and tails.
>>>               There is no text to describe how one could achieve that.
>>>          Wouldn't it
>>>               be worth adding some?
>>>
>>>          GIM>> The question of applicability of this specification to
>>>          mp2mp scenario came up at BIER WG meeting in London. Perhaps we
>>>          can say the these questions are ouside the scope of this
>>>          document and discuss whether there are interested to work on
>>>          mp2mp case as a separete document?
>>>
>>>      I don't read this part of the document as talking about mp2mp but
>>>      rather as talking about multiple p2mp trees.
>>>
>>>
>>>
>>>
>>>                   Point-to-point sessions, as described in [RFC5880], are
>>>          of type
>>>                   PointToPoint.
>>>               Does this really fit in Section 4.2 which looks to be about
>>> the
>>>               mpBFD session model.
>>>
>>>          GIM>> I think that this short reminder is helpful to explain why
>>>          this document adds value PointToPoint, section 4.4.1, to the
>>>          defined in RFC 7880 bfd.sessionType variable.
>>>
>>>      Well, I would move the text to 4.4.1 then, but not critical.
>>>
>>>
>>>
>>>
>>>                   Sessions of type MultipointHead MUST NOT send BFD
>>>          control packets
>>>                   with the State field being set to INIT, and MUST be
>>>          ignored on
>>>                   receipt.
>>>               English is not my native language but I wonder if this
>>>          really says
>>>               what you want. It seems that "Sessions" is the subject of
>>>          "MUST be
>>>               ignored" while I think it's the packets which are the
>>> intended
>>>               subject. So I'd write:
>>>                   and those packets MUST be ignored on receipt.
>>>
>>>      You chose to ignore that one or simply missed it?
>>>
>>>
>>>
>>>                   Because there is no three-way handshake in Multipoint
>>>          BFD, a newly
>>>                   started head (that does not have any previous state
>>>          information
>>>                   available) SHOULD start with bfd.SessionState set to
>>>          Down and with
>>>                   bfd.RequiredMinRxInterval set to zero in the
>>>          MultipointHead session.
>>>
>>>                   To shut down a multipoint session a head MUST
>>>          administratively set
>>>                   bfd.SessionState in the MultipointHead session to
>>>          either Down or
>>>                   AdminDown and SHOULD set bfd.RequiredMinRxInterval to
>>>          zero.  The
>>>               In both these paragraphs one could read that the head
>>>          "SHOULD set
>>>               bfd.RequiredMinRxInterval to zero" while 4.4.2 says MUST.
>>>               Clarification needed?
>>>
>>>          GIM>> Section 4.4.2 mandates initialization of
>>>          bfd.RequiredMinRxInterval and, I think, applies to the first
>>>          paragraph you've pointed. Would the following be clear and
>>>          consistent:
>>>               Because there is no three-way handshake in Multipoint BFD,
>>>          a newly
>>>               started head (that does not have any previous state
>>> information
>>>               available) SHOULD start with bfd.SessionState set to Down and
>>>               bfd.RequiredMinRxInterval _MUST be_ set to zero in the
>>>          MultipointHead session.
>>>          The second paragraph describes manipulation with the value of
>>>          bfd.RequiredMinRxInterval which process, as noted in section
>>>          4.10, "is outside the scope of this document". That may be
>>>          reason to use SHOULD and not MUST.
>>>
>>>      Yes, i'd live with that. But then you might also want to clarify in
>>>      4.4.2. <http://4.4.2.>:
>>>      OLD:
>>>                This variable MUST be set to 0 for session type
>>>      MultipointHead.
>>>      NEW:
>>>                This variable MUST be initialized to 0 for session type
>>>                MultipointHead.
>>>
>>>
>>>
>>>
>>>
>>>
>>>               s/M, P bit/M and P bits/
>>>
>>>          GIM>> Thanks, done.
>>>
>>>               ---
>>>
>>>
>>>
>>
>