RE: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Aijun Wang <[e-mail]>]

Hi, Jeffrey:

Please see the inline replies [WAJ]

-----Original Message-----
From: Jeffrey Haas <[e-mail]> 
Sent: Thursday, April 6, 2023 10:22 PM
To: Aijun Wang <[e-mail]>
Cc: [e-mail]
Subject: Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April,
2023)

Aijun,


> On Apr 4, 2023, at 5:28 AM, Aijun Wang <[e-mail]> wrote:
> From the description of this document, the state machine of local 
> device is conformed that described in RFC5880, the main standard parts 
> of this document are the contents of related fields within the BFD 
> ECHO Packet. If so, I suggested to point out these fields and its 
> value in more explicit manner, to facilitate the implementation
interoperability.

Perversely, the fact that this mechanism has an implementation "talking to
itself" means the interoperability considerations are not a primary issue.

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
https://datatracker.ietf.org/doc/html/draft-ietf-idr-vpn-prefix-orf-00#secti
on-8?

> Should the section 2(update to RFC5880) be moved afterwards the 
> section 3(Unaffiliated BFD Echo Procedures)?
> And I am worrying that is it easy for the reader/implementer to keep 
> up with the updated contents in current manner, because they must 
> compare the two documents simultaneously?

I agree that this would be a helpful change.  It would move the procedure
ahead of the changes that impact the BFD normative text.

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

Since I think this feature is best documented as an optional extension at
this time, the "patch" format is our best option.

-- Jeff