Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023) Mon, 10 April 2023 02:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB52AC151B1E for <>; Sun, 9 Apr 2023 19:33:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bklJ8fjxdCzP for <>; Sun, 9 Apr 2023 19:33:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3F84CC151547 for <>; Sun, 9 Apr 2023 19:33:51 -0700 (PDT)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (FangMail) with ESMTPS id 4PvtMJ5Sctz8R041; Mon, 10 Apr 2023 10:33:48 +0800 (CST)
Received: from ([]) by with SMTP id 33A2XfZ8035510; Mon, 10 Apr 2023 10:33:41 +0800 (+08) (envelope-from
Received: from mapi (njy2app01[null]) by mapi (Zmail) with MAPI id mid201; Mon, 10 Apr 2023 10:33:42 +0800 (CST)
Date: Mon, 10 Apr 2023 10:33:42 +0800
X-Zmail-TransId: 2af964337586ffffffffad2-3baa6
X-Mailer: Zmail v1.0
Message-ID: <>
In-Reply-To: <>
References:, 00b301d966d7$d1094df0$731be9d0$,, 004a01d968eb$5da8d810$18fa8830$,
Mime-Version: 1.0
Subject: Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: 33A2XfZ8035510
X-Fangmail-Gw-Spam-Type: 0
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 6433758C.002/4PvtMJ5Sctz8R041
Archived-At: <>
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Apr 2023 02:33:53 -0000

Jeff, Aijun,

Thank you for the comments.

Please see inline...


From: JeffreyHaas <>
To: Aijun Wang <>;
Cc: <>;
Date: 2023年04月07日 23:27
Subject: Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

> On Apr 6, 2023, at 8:53 PM, Aijun Wang <> wrote:
>> Providing additional detail to help illustrate the mechanism would be
>> in-scope and perhaps helpful.  Did you have any explicit recommendations for
>> the text?
> [WAJ] How about to refer the style of
> on-8?
That seems reasonable.  Let's see what the authors say.
 [XM]>>> I propose to add a summary using the style suggested by Aijun into the end 
of section 3, highlighting how to set the fields of the BFD Unaffiliated Echo packets. In 
addition, I'll switch the order of section 2 and section 3 as you suggested.

Best Regards,

Xiao Min

>>> Is there any other better style to point out the update to RFC5880?
>> Unfortunately, this is a common problem for internet-drafts that impact
>> protocol state machinery.  We have either the option of trying to issue a
>> "patch" on the draft, as we're doing here, or do a -bis of the base RFC to
>> more cleanly integrate the changes.
> [WAJ] How about to give the RFC also the version attribute like the draft?
> That is to say, for such "patch" or verbose text update, once the proposed
> draft is published, the updated contents will be incorporated into the base
> RFC automatically(no need to the overall long procedures for the bis
> document), but give its one new version number?  The bit RFC document can be
> labelled with the source that the updates are coming from.
> Maybe this should be discussed in more general scope?
> The final bis RFC document will be more easily referred and readable.
Using IEEE documents as an example, if there is an update to the base document, all of the changes are included in it.  If we ever do a RFC 5880-bis, or potentially do work to advance BFD to Internet Standard, this might be reasonable to do.
For now, the document is consistent with procedures we see in other working groups.
-- Jeff