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

Martin Vigoureux <martin.vigoureux@nokia.com> Tue, 17 April 2018 19:32 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 C1A8912420B; Tue, 17 Apr 2018 12:32:08 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] 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 dOjStud2xhbX; Tue, 17 Apr 2018 12:32:05 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on070f.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::70f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E709F1241F5; Tue, 17 Apr 2018 12:32:04 -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=45FfOh7ZWOwFnR3+YZDD6mKpeNYRbC5kOo9UUWID2OM=; b=ZJa8GaXABInK4SBoxudYnm7Suaw0v1vRo0VPfmea1CUCsyiVCNTuEdD9ZmfX094XdSUxmjcefIuCBN+HbtV9oHHbxx1D24hJCu6C8wOqyBXaaVm+sBsmtyOAd1wnDoyDm+t3GAly5Azompmk5DPFhLAl3xExFcnvPpey8Uu95Gc=
Received: from [IPv6:2a01:cb04:a1a:4c00:f443:6b8b:e1f8:5e65] (2a01:cb04:a1a:4c00:f443:6b8b:e1f8:5e65) by AM4PR0701MB2131.eurprd07.prod.outlook.com (2603:10a6:200:49::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.8; Tue, 17 Apr 2018 19:32:02 +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>
From: Martin Vigoureux <martin.vigoureux@nokia.com>
Message-ID: <ab28a63b-3da5-fc3d-a48a-44640bce385d@nokia.com>
Date: Tue, 17 Apr 2018 21:31:47 +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+RyBmXkVuo=yb1ivdf2-MPfPw-UAYHfP83d0RnZnxn-jkQN2A@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: DB6PR0802CA0044.eurprd08.prod.outlook.com (2603:10a6:4:a3::30) To AM4PR0701MB2131.eurprd07.prod.outlook.com (2603:10a6:200:49::12)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-HT: Tenant
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7193020); SRVR:AM4PR0701MB2131;
X-Microsoft-Exchange-Diagnostics: 1; AM4PR0701MB2131; 3:7DQDKqV8QpJCaKQKR9v7+JfGSR7iqdHnTrczPQ8lHpciMQvXxz2ueb6V9inhHayTDC5e75aznyUMJ7iNmey691/Nk0QEziQSM1wq4uYGBypBYGoKDj9BjFkUUGwHJ3nTokoBl2KPTaczqDDRts4bdlYqMyuR0cc1KA1Ij5O7SdJPpN/CE3zkL08fKbfNHu7lOtKqOuwMUzQ5im7zi5T+9fS42yGGn2kAAYky1n3tblYmRhT0xQgvL4H638+TEyBD; 25:nvw8nBNpNVxrfty9nrs2O76hrTGUp++Ee191bzoeU5bkBAp5hxh2YU53G3oUlmqUzun7ArW4vEYZR8/z7JyW15/j+qEyMM5m3GKa+0zjpMj5JHZgr7I3kpG9EJKAiolTKf1Z2MPzAJwBi6HSELBuSk5XevyydA7fDfVmCDQkXCjDpdwaUgFfvRSH8qFMEZy9V4orHUYv2e3oxjYOFb41l+TQSy+7EtjVJt/rDSAH4LvSsZJwd48bDZYuIvCf+9K13osVpk1nbwfVkcM63MNmWp3ANpnxYmih+Xi3DnzvXrUyPS0GT85ResZm0QyQ+qG8TwkVJ3s7BCnQjggGGxAivg==; 31:IUK5zhCEgvLIguYWp6d0PKFyz4mZzzgWXh5gccde+yVM4WwaqXUKSSiZ0XhgfMnmIzZOkZ4qufFkZZHlNBI9MU2VyNR0XNh0DyljXEYDbHbh4QZENfEDOxcXPCyRD5WGP41xbdlpq1BlfSs/bYi3iSxKFIqWGpolOGSAMjVqVWqXCskSWkplDF3b9+ZqDmemMnpCpnF/bslFY9vwUgNT2zPiqyVgpDfYen/b3D+2TPM=
X-MS-TrafficTypeDiagnostic: AM4PR0701MB2131:
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=martin.vigoureux@nokia.com;
X-Microsoft-Exchange-Diagnostics: 1; AM4PR0701MB2131; 20:ySjfRtdgwFEwLNzxhVKsQGs/Uy4am3NXn3BQLwucK9B0pp/87DnhH8nh8bNfO6S5t3f2AaZROUmEZbPWohUhZaR0v9WtSF9jd4zlfqlQhb1QCXJQ/PeBD84EGMgpEZR8s4rg4G9n5pay5hlhUA6YD0uIwWfO1IKaf9kwnLoLnn6hFSNIvE9eekVPaVYrtkr/RooyfPS0bNLfPrTqaaQsT6lnwaU4YDPNzh2QUyelZKshLqY7nUteyd8EFseyBMWp6LnuFlyJelaY7slOj2yXNcIwqMNJCLI8Cs5WFMvv6pu4ODUbc0TfHwYc0H0fKooEeLnXxyKY4Mv/oCflGOEiS861jQ/WipKfbjs7j8ynSU5k++2fNa2Uc500DMVUbW/Qeq7dIC3eIVNxlS1zTrC5TMsLgKkuvvW3yMEOYIDxKM4s5weoiykI0Jee8x5zscq0Ud3+ovq3wdgQkc+I0WO1JbSXhQU6ATc84XZuUOXcG45uOLZqvX07Xg8rGXmBIh9k; 4:wYsYWyxAHQIsjbA3+6xTb/0EJDBOaA90g4jmhhH6I6EAr3Zfpp0w+OpFBZ5ACcWLfS7J6W2hIppNSj0eObtj73qbzPkL00/pGoWk5ky2+dhkDXvScXv3EpoXvdjAk9s08TKlW8F4XDFVbZZkZTQfpI3snsHnmHqYdHkIvIA3K/T/QOPYmeax9g575MBM7zn5Mt0SPAJMDO6JfDPWjoM5Nv46aOuAlXuJo1qc9mzjeaJXOL/HJxz2O47NkZP5iDbXo9RbSYf6ydgOw/VVbpaOE0YHwZlHpRB5XuUXv3iorF6yCIfHmVx9THRDPcSru4hh
X-Microsoft-Antispam-PRVS: <AM4PR0701MB213108143C50F2B71A2F42F78CB70@AM4PR0701MB2131.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)(3002001)(3231232)(11241501184)(806099)(944501361)(52105095)(10201501046)(93006095)(93001095)(6055026)(6041310)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:AM4PR0701MB2131; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0701MB2131;
X-Forefront-PRVS: 0645BEB7AA
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(39860400002)(366004)(39380400002)(54094003)(189003)(199004)(51444003)(377424004)(316002)(93886005)(64126003)(486006)(39060400002)(446003)(561944003)(58126008)(86362001)(53936002)(68736007)(6666003)(31696002)(6246003)(50466002)(3260700006)(2870700001)(476003)(2906002)(36756003)(6306002)(2616005)(25786009)(5890100001)(1706002)(11346002)(44832011)(1411001)(8676002)(81156014)(76176011)(5660300001)(305945005)(47776003)(52116002)(2486003)(52146003)(81166006)(23676004)(65806001)(65956001)(52396003)(105586002)(67846002)(6486002)(106356001)(186003)(345774005)(6116002)(16526019)(4326008)(6916009)(8936002)(46003)(65826007)(229853002)(478600001)(966005)(7736002)(59450400001)(31686004)(16799955002)(97736004)(386003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR0701MB2131; H:[IPv6:2a01:cb04:a1a:4c00:f443:6b8b:e1f8:5e65]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
Received-SPF: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: 1;AM4PR0701MB2131;23:EvMTFFQEORji/thENY7pcYsyZlnT8CStG0xm7j0Gu1NN/OZJODV9yMfiYcqNhaKedZDPv2KjT/syrOJNqA0hJqhtXjn+HnmXCjfusVlg/teW7aTId64MjE+nmI84CJD5dTMOVAjkrMxlD97zy7OrRZSq7GgBheLarPHYAMNHnAs/XSqpkFklsgyQ9Jcpg60NkxAt8oqCIkMFOBxultXzMDEjcRlpJCCr5IYRhbM6/+5sbl/J+21WHtLhXYsVieKF/ob4OZTn2j3+IMn+iG9hlzzWoWNqe3v/Aquntbwe39Ygrhg+7wcERFFDbZvZmLQ1/F+DsxFkviaCkRScisEdg/UpKX1DL/Y8yXBemD8xCsEMSgu1KefPXp3WdRrKWvHstb9zLns9cuNSU1+smsYLVH5mux5AJqtpiurHPiqHaV4/ZrqdpZSfLSRzzNLFpreZOIGpY2t28bdjlv5i5BZosB/MpyeigZ0OxY5Ql0clOwrOFab9Y7Xu5L8n7CxYUkcjgTYAMkxY0GVubcySJtmaOheFwI8kpNHQfJcBvMqEry+LExHqnPa+xwgYRuATY+Mxj2PlscdVAdjYOI8+SaB8ZUUeSOJy6hMDa92Dt9ycIqfa9hLVR89vBrL0e3wAFAEJIYfPFVsGleupeJ7lJ1WHJBz5US+yHsWWdd7yB3RlxnieOukAlyUQ8yWzZjLRkkwXErqiJblrGef7NYx0LVvkkGt35xcmVO4bc1VqCaaYoTQBlWSt/rd+wSe/9ujn3MGTh2xCtJFfJtweHyGEaKs1VNhEw5hU6rnhXRxSLu15wAlbHLTiEdxap8UV+uBuCFYcxzQYB/G3yppV7sHH9f8l013pp8BPiH6RhhoOkkmZsFHYsB0f4Zi9LnE73EPwjpGkACOdsrA2l7Wx0B1BVeY/LbLn3IXJxHLVABAWwwtI6LBZjx/9E2y37FoI0aJU8/Vv9kMj7140mM8j+TJfCHZnru4XrTBvB4sSiRAqJpFyoAlmlt6slg6rlNeZSUMe+PeYUVC3EWWYn6k9lcG1++5sUSHcxTJVPbZEz2IX8tNK3Z+gV4GJfZuR2om7/P1ZAEJK3sxA5UZq+4rjC2+qb0ch8sZz7+LHYwPnf3KayPC/LwP+UHyBQ+23V5bd7yHhPpuafeXGui/fRYClJqe85VOki5pnmo++ZLIydm35tPRopgfI7JBvimHEAJVmF9UzKdSjORc+zQgwXM+1Qhjjj4OWt8i4TvYYwaSVmFrWTka2ZMq4I4SNgGstOQqK1kpLgK+zAPZ1pDPK6HtMe4OBrgPKMgBJqumKktmO9hjD9Ig6mavyVfdYU6fiE9eMjVDTj28O9vJ2J02eaU95MXh9bfb34W27omDlnkQVluR01ryAFvsyErXXhcj4cPEkhsOisB6LbgI9nV1YaRu3UqJtLVDX/JUvaIih3oNkRcNg/Z7IArHMrDyUpKrkWELI52VS4Q16OCJa7vATTtMajjECctFU0jcj86QhqiwHm4rV5SbOqY2bH0KHyzL7LzqyZxP+LkLRaLQx+O1F5MT/YbwbpQfpYpzL0e0HdpxrK6jH5rXO4zvcFtztGqk6WN2u4EKJGnltwxImCVLh+4MbfMoPgQ2TyDo+/ASgo/BMiTUinETCmdT8v3ustLx4pZWT00xHtLQOrn+6h22SErpaBGOa41U9RA==
X-Microsoft-Antispam-Message-Info: 1q34aMD2ZakjtZipYAkyDruFbyCWTgzIBCWl3IgNSqqa62LjNzjZQBtMKgI50aFiCkeyR0R+ZNPt3We52pw5ZbvRLj9cVKUqdCs4PBtMLW29nMpsPcbwV+S/WaJpXmec/pxFyk8PDN/ILHTMIQFoY4Dy2hL8l5PrKsywlJlZvDFCW8CmiWWhoJHw7g61KV/Xvnuefnc3cbYil5aCULlJ/ppFIHiyTXl//yChoOlu9av7p/+7Z5ZMgbzooRTHbGv5
X-Microsoft-Exchange-Diagnostics: 1; AM4PR0701MB2131; 6:R7jf8NsUUxENgepvBNbkpowi8PJBO3x50wmjhndj/UOxUUt02dwf28M6oWGFfujh8xxpe+ucUSIaanVd/ZGPBv3NS8jlUc7lm0Ee3kWSSMBE1WH4Yg4/jAn+eja+pdA/4d0XsKWcO1JGWyqxlUme8FIXkRnP0ZVsny+6HUcsFP8IY6qsBF7iBTVrzL4M2hb7ODGHPvgwQkRk+NPIfRl/nKx2eRtafGSbg/inJ8hjMIu/CL4RnGNa/5AR8FONrZadUQw1/eajt/BdzzJhsI7/YmbwdLETxmpGokxKl3GwmIkeYInjXjqQKx/bAIyAInlTh3zhgI8NWdPfpX3lozHtwDX7rPD/nX/d5Nva1NUVb0KdtoV7r2tfYoTYTZzJfGJ+tgNyDFzGGFECjRlizddft9ZA2X00fGEnpjtCcrS+5u8n09UYrsnkozPVCSIj03gGytdqFY3MmWbFlPwKrcYK/Q==; 5:fCArsbIbts0pLRq8dC9OmTpHvXml2lJX/kU7ydnqjqM5oX6RraPhfp/16mc3Q8phij+TqhpiyRyUPZnm9+d+SwVHRGGNb1iyf8pYht2/64HBdoxUrzqROyzVB+uzqcdr4KT8OD4THYRerbWweOQbrUX85TWvX3atg/rEDDUj69w=; 24:24X/cfHgejkI7+K/X0iHqTYZAc1/r2Wo8RdOU7BFVP71nQMj1GsOxI3xI4MnDzCViZYTWjeR1+G5LkMuSaYrPoSAdYoz7YdRafZsQRXTUvg=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; AM4PR0701MB2131; 7:AWgqAxgxo+EJDhfCewgd33RLU4n+uXJimkhJY1MPio3d8UYEioI8NBPttiL5mTcWJCRAU4ZCNjWCqSnLn8lN4jcDovJEWzkIaOWqjmYr478/FCSPNOIKubwGdF5zRTQhRpGQTOJRnKJ4iZXvIAKUt2LVr+SUOtXK6Bf51gck23syQfEgJPbp+fvxUKOVIln/IfB8I/N3LlVpVihmxhRbctT/310Krp9Fuz+5CK52RzWQdgxPIxBTr6kGkhmd1cZE
X-MS-Office365-Filtering-Correlation-Id: 177d560f-c941-487a-9069-08d5a499e521
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Apr 2018 19:32:02.0489 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 177d560f-c941-487a-9069-08d5a499e521
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0701MB2131
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/QfwruFzt8jHKDyiGxbxZpKjQvTg>
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: Tue, 17 Apr 2018 19:32:09 -0000

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