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

Martin Vigoureux <martin.vigoureux@nokia.com> Tue, 17 April 2018 16:49 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 95538127599; Tue, 17 Apr 2018 09:49:49 -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, RCVD_IN_MSPIKE_H2=-0.001, 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 FYtRWh-8AryY; Tue, 17 Apr 2018 09:49:46 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0137.outbound.protection.outlook.com [104.47.1.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B50E126DEE; Tue, 17 Apr 2018 09:49:46 -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=WNFx1BuYD8yhUnO/a2cnDQTYvndDHBw7Im6lWaalF+8=; b=TbffxrVJB/Of2C3ldYlijUv7WY/z+n91iM1X7e6Dzt5aq3lWlOZbG4HInIRyFvvdSbX+K/USpzuROO/jFK14kmeIIEASw88r3REgcB3E9NBSLM40JzNSj9LMi+BQ3uKbtiF3PJwj6EnYfQ5ewVWxDmo1ycPihFU2ftrE9SyEo7s=
Received: from [IPv6:2a01:cb04:a1a:4c00:f443:6b8b:e1f8:5e65] (2a01:cb04:a1a:4c00:f443:6b8b:e1f8:5e65) by DB6PR0701MB2135.eurprd07.prod.outlook.com (2603:10a6:4:50::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.10; Tue, 17 Apr 2018 16:49:42 +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>
From: Martin Vigoureux <martin.vigoureux@nokia.com>
Message-ID: <b160454c-5fec-4c57-2c37-20ccf3b8dceb@nokia.com>
Date: Tue, 17 Apr 2018 18:49:38 +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+RyBmUKiawoqi2G6Kz8wPYSeYG1L0hUk8zmDVK+kSCZaA_3Yw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-Originating-IP: [2a01:cb04:a1a:4c00:f443:6b8b:e1f8:5e65]
X-ClientProxiedBy: HE1PR09CA0069.eurprd09.prod.outlook.com (2603:10a6:7:3d::13) To DB6PR0701MB2135.eurprd07.prod.outlook.com (2603:10a6:4:50::14)
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:DB6PR0701MB2135;
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2135; 3:fKOFxU6FeemMChri2Rapa1NTk4fKAkDRnbB9LyczxP1/u99Ud9wesIV65fvzxHCvJElvfacLVW1LdkSbjr2aZk4uUwL67zllhjBjDOR63MiqsPCUeoeGLXrubtnnTU5GyR/0Xg58MXX0ArIJCVOvSrUeVXXCfy47od49k6l0dq9S/tTsgeLy8/Y5syAtK9ECRiHulT7Ks8dQ0nU/mNtRUoliJNKQoRi46S6zv2nuAKppxfwsyp6DYsmeylGKDCFc; 25:osPOqwW3oF3seh075uyUGETfvZUQhQTad0adoq30/icH51iFEgrHj4cu+1HM85pikqLOpukMev+V8dtbA6alAY+XcRJlc9xWPqVUwuE4LrHsyiYLuhi2k5MIHDfDJzuekHyLyTOEb6dZqpZhBniy6cCap2ZADcQtKpcZvPcMdoS7GUdG8bWI83njkySxoeL3bxdeZtjqZ8JKryFBRzlQbI83D56tgkQvPe8sDjoM0SdFAUg785Tb3BEJIrS0EcJNl/XpoDZeDSL8Q7AXDQJncCv2K43Jw+ecaG37VwSIN+DDWZRPI+ByPijD0D7g8f/haf78vCx27yEK/KU/4VOsbg==; 31:Z6GpLqV8d9yj9QEdXEgSvJ8HEJlfCsnFtRG8PxgxQjt3Melb4nCdq7BhLjq0LMGHBqvvhw3HHzhdXtDWy1f1SGviETzZFcJVgUFdAU26C7pOgMZlJN6l6vgm5VvFDGXWfpQyjVUJQle6bs1RdZI2ms5sedUseiuDGdd4lWObzeE7vBugyed+7NMl3wxshZT86zD8YhBpK3u/GmumLRvedCZ9tE4BFKgpITF4YmrdtmE=
X-MS-TrafficTypeDiagnostic: DB6PR0701MB2135:
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=martin.vigoureux@nokia.com;
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2135; 20:KJFx+1ru+B8HZU5q2oLCO7YZXYBV8H3HBodBTXORDYSTHMcyAhRPQK6u2Cb0A8ZKd1RtwAT5JInzF+/DBsajSm2wVJ2byH5UVcb6xNyI4CfIkP3GY1eEHjeYyLDK5CUbvasZK+roG0nJL89qDKFERmg9o5JuBAFFBU5dL5nuAFouhlggDXDekPJbUj5X8x9BydMJVsAUbHzSeuUVCuz991L6bianDBen2FT0WCsGa850fSLVlzeI+//1NcKOEB6/3UOdfxu6xDTSGW6GSPS672Rjo+N9ZDsxGIg6wEI+AlC2T+0QRKn6UbAEFKvRVyYoHgTUCsRwHBYLQQLR33ZqESyoqcSXzaXRZ+Dr8PujwGOMJ3Rs1Vmu4eJA17OxmonqfJ2WW8AhLjmjtmVFaRzK8/okUziWeKLbH1woOW6YbMtcRwlOTEeyoZ/lcq1AgyK4Zvwxo/p2+VYHx48rPtCnvnENu9Jm7VUJDkwCicGj9dUebQVtyrYyBAo5l8gbw8j8; 4:TfgGNXWG+6ryCBeqdeZPwZa5f2tdQjSnO5pqPOGm8fkxd2qt1oMDCZiy5Vci3bR9Xsxov1jBCvFr8sXy5jWZviIquIXbSUWPoMEkAvDpE7l/1jxt/i8XxktrJBScEdXaCULLtOnAmsgtMRFQZ89V9LVFUyFcKKdk3Ptunr6adeoGl7wVGmYimu7db3LfzP+t9Szq3WzQhfq3AWIcuSrJOAQoao1XxlLFLxxPIUMSiPR5/fDTla/MSakbkuPdSIx8hZ+NYUgDAWgFeI1LldX3NspfmDNjrFpS2MOUegSc6dHk2tevNpaJDmuZxRcjX9/R
X-Microsoft-Antispam-PRVS: <DB6PR0701MB2135FB829EEA177545F24E388CB70@DB6PR0701MB2135.eurprd07.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(82608151540597);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231232)(11241501184)(806099)(944501359)(52105095)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:DB6PR0701MB2135; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2135;
X-Forefront-PRVS: 0645BEB7AA
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(396003)(376002)(39860400002)(366004)(346002)(39380400002)(54094003)(51444003)(189003)(199004)(377424004)(16526019)(186003)(46003)(386003)(59450400001)(53936002)(6306002)(2486003)(11346002)(476003)(52146003)(6246003)(39060400002)(561944003)(23676004)(446003)(486006)(2616005)(97736004)(47776003)(76176011)(229853002)(65826007)(16799955002)(6116002)(6916009)(68736007)(52396003)(67846002)(5660300001)(52116002)(305945005)(65956001)(7736002)(65806001)(345774005)(6666003)(1411001)(31686004)(6486002)(106356001)(81156014)(8676002)(8936002)(81166006)(478600001)(105586002)(966005)(58126008)(25786009)(36756003)(50466002)(1706002)(86362001)(31696002)(2906002)(3260700006)(4326008)(2870700001)(316002)(64126003)(44832011); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2135; 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;DB6PR0701MB2135;23:cKnsqJHB63bpvPiB//vwy0XB5Hzcl0saZXGmbExW11ZeTloj9IctTeL2jQ3coDDZRmZCwDCfOHVhohAGPfsW8cW2+E22eqTTus2t114ZUL5bqrVMsWSIoU5CrPX22rqFAtYFu/tFCshi/R2dnb5jXqGCqxBGlMumu3cJ/xzXJ2aKraYoflOoYbqaSEInx+CtlydqZQPZhFyKM5RPWfrYCSt6WJrIaJF3Wtaxx4sXzp6+sXCFl72PAzRs95SufX+6JnoG7y5McL16Y+giTRlfcDlCMa77r7hd12uX/vwfeuDyZE98bKTwr9xXesbMbkGvG1NgFdQQ0uiRtCznCOaniiGFXGIYJNghsz5XK172mA1n8lONUwZiui0qd2d2oJcq+/jXxEs+g4dasRQ3R5RslXI4neheJ5y3ePSEfNVf0SQOFVtuL0Ut7VCh0+BIFxY+sRKHeqoXS1LN3qo9iLMb0OXatZFl7Y6lPpPbT/qeS3do1ohFxH+GDchxUNr4XOxjjkkmWant46z08Dg6/A7VlBDcmDrRYwigW7QfHA1r3ZEQNmNOA9mvJCLUK7GN0kSa1p2VOo1CsLm5cQ3L+ScprBSf5j1NW/su4zXovZMkviaus10zVPDcc/UjxiPw7v7VD5DdrhEFf7QMblDnU1qbe7V/69un7xK3A5F8t+zOXqwih4NrvXVXA2+y33uhxjVI872TEsK8FBLmrFLLXlD5Rgr+D370nQ4OOvmq4urofOXqaTE9e43T7tEdQt6uSDH91wgwR6MVmgWA/KaP+rGYIjGvCFoPZMWTCcpk3eMlBcA3bJwDWKhQNtJ4/+M/a/2axXQW4qNQ++lbnxkdl7uKeq3gE640QTtLKmYCGZUlhd9iPDdYBOptQqkUL0idSW6YKPuZ/mHy7lvaZhna6A3gqV+lKnd6JF/E2YzfHghGfrUTnN98OFO1DamMgWJ2Vl1XftRR4DQHo93BxGlg2Xtd0kfvXq5ji+osTh3eeRa3nQEgFQfBDL/ARbGqh2W0uEaxXVcLLBnKmdvRjxCNfyWtfVXJTtgvkqTaxrsLXC7whws/9QuUzey9e7TIahUxgHRwEaL8sqozenRg/8eBwdbhh+tSCAoMVimOM0SKriy1GFlxIAfRB1MoMNGFHhhZpmyyKRid8kCg1m3CqJh8DxoGw13l6us6jFNtX8Nn5OP9neTin1I6Xo+VvTfUe7tv0Jh4Q3u6I7hlGu2mGeeXl84f2O9Lhr2R0mh0qL3AOm/6PdGIh0ZOdkRwBjRdx2U43O8pfxvSQsGDaoxifKbsQm29UiyHe0FmPQPJjp7TBxFOxyd3ber5f4NOligsRDUL332Gz4K2R5OPifdR5DBAAcx0bJf1azPg8YYPmwiX9pcE6jyrJOKscyFoY2kiYfhz0QwoM3gWOOQACmgtqfqprw+sUqwlyAfzv0AVGrITIAGOhVsrXQ8JyuJ9SjVOoC4NgtxMificvb6veCSeMJocoLe4BN2UOn3bhLOj1q9SxRj5WGaVFl2V6oR9lFLbUaHsJResuWEStAfV0+Rk7f32uGOULdTvpdfh6etwdOgcOhR/JXgTgi4WvN2XB+6leKMjyuQbX3lLMlIwYv7SC9a8FWD6zQj4JXDfRaAUAuuhgLRLVxY=
X-Microsoft-Antispam-Message-Info: LdfsC/TL8FPhHrWbw+ntWRwSDMeH5YLBWn3xVa/42LX/dJbs+Z47Mv1c0atn6wt90E8JNuIxt6QquC4HrGLqR/yXQ7whSMOE3OcqGZ7ZLEJAdztBmh4wjIuxhJLIXbd21OdWY+ZKGATF6cyz1WW1yIFZmfPEUzLDA6zUyOhHa34/IJdyUyvi6jTlwTGJcaUsLV+mrnuKw2gpfu6x2LSZxqqN2CX84qvVd6kkwIaOw3RC8q556Pb/eIPZ+J9udJl1
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2135; 6:IR9NQTKtsq5VnQTo0lUjqJSLY/4tlm0W45ea4QL4KcbZ9R/mIJawffVvc/BIrqZPJZPhfs7v+LKdmTr4TqdSTxPWY2c4Ck7AhRa5THJSNiVHYFg/MlEqWLGzhGKk5HQQF7GGK/gQt/039EpVcW87MlWFqWOBVDEApgYqQb+aIDr/5nSvne21N5M1Pgmg5pCtsPIKZnJp7YoIvTYU2ezuG4l+GwVrKE6LF+JnnPXpk4eOhzSxk6h4nfvR0DlNEeROdtY8Zh/TmqPk44Nx6B/1rP3p2ytaKaoKHBz61gDxzceOpc9Hw6fncUCYcmZueUU4bKfnPy9aXy4YJ+TgYipXPH5iYavmMHmqsq1etYfRzitG4pR82/joDtoRRgW3P1f4W7EshVv2b2zs2ShI/H+d+9+wY3MPbLyrPoODscdnyNINn1swV8yVD3M+kSHNxvN4sgYNxdhVEJqohzdb8FICOQ==; 5:4NBpIVBRDzuhjWNR3Cxt4HiaxRgOH5ub8aiRjRjvo+BbJiYYtZ1fJFjAzDDsjsBgpbGX2EHGqrVgp/HgGeiR9p6iiUEDXcKfgW5PJYbB33f2iEi04SQHq2EMpNY6kA1AcfQGhplxZ6tXDqrxG0WPn8NHGU9wFOZ8kJmH6XhtH30=; 24:Dxf7UVO1OFkthaNtSSygrSI+xIMGr66+M/1qmbpmd7SjdXeMi9mdL74zOXyt1NCoAJYTXD8eOHsmS//TpM3Xp8fv3mWlwFmNXi5tCa4kxcg=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2135; 7:B7EGYP+eE22iUNwKoSJFDzcBzNfWg71Mqu0rfTxxQZQgk0T+czVYvjd+AKvCgZI53PzqQMfJXO6TH8hJzPEBfsSp2Qe5h4uo6l/PWG1RmAE3t3tFQ3odxEULjLGhBhfBz3ZeYIF1VtnyeA8PbAAO1VdzwJ+qbHKKHZ1T19/fDVXzmaMBlciiZ53chaZrTKizMVg46jIfdNRbiHdh/Sj7QTBbUIZNcZ6oGIILjY7useEGqZ4/UNrdSOoggfmMGS0e
X-MS-Office365-Filtering-Correlation-Id: b0662cba-2efb-454d-7bc9-08d5a483384a
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Apr 2018 16:49:42.8314 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b0662cba-2efb-454d-7bc9-08d5a483384a
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2135
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/r_xbx4zbKo1p5HD5H7ysx_abPr4>
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 16:49:49 -0000

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