Thanks Jeff for refreshing the cache on those mailing-list comments. I was part of that conversation, and frankly did not remember them — now I do. And to put that in perspective, that was almost 6 **years** ago!
I also missed the Errata, which was good. And there’s also a couple other held for doc update: https://www.rfc-editor.org/errata_search.php?rfc=5884 I will start with the last bit, borrowing from your text Jeff: Carlos is also completely unaware of anyone experiencing any sort of confusion covering RFC 5884 procedures other than Greg. And also, it’s a clarification that does not hurt. I do not feel norao impacts 5884, but at the same time bundling all the updates on a RFC 5884-bis sounds like a most appropriate suggestion to me. I’m happy to help if needed. And to that, I’d also bundle in the changes from RFC 7726. Thanks, Carlos. > On Feb 4, 2024, at 11:36 AM, Jeffrey Haas <jh...@pfrc.org> wrote: > > +bfd WG. > > Some original comments to Adrian were: > > https://mailarchive.ietf.org/arch/msg/rtg-bfd/SYouXfNrVyKHErqacOuM2fICzMc/ > > Apparently, Greg didn't consider this worth holding his peace over. > > https://www.rfc-editor.org/errata/eid5085 was filed and accepted as a > clarification for RFC 5884 as part of a prior round of this discussion. > > LSP Ping is getting its norao update currently in MPLS. While it's my > opinion that the current set of changes to that document don't negatively > impact backward compatibility with RFC 5884, it's a normative enough change > that perhaps it's worth moving forward with the small updates to RFC 5884. > > In my opinion, the appropriate work is to take this to BFD for RFC 5884-bis, > which would be co-reviewed with MPLS. I believe we can get at least one of > the original authors to pick up that work. > > That said, the BFD chairs are completely unaware of anyone experiencing any > sort of confusion covering RFC 5884 procedures other than Greg. > > -- Jeff > > > >> On Jan 24, 2024, at 2:55 PM, Carlos Pignataro <cpign...@gmail.com >> <mailto:cpign...@gmail.com>> wrote: >> >> Hi! >> >> Review of draft-mirsky-mpls-bfd-bootstrap-clarify >> Version 05 >> Type Getting Ready for WG Adoption >> Team MPLS WG Review Team >> Reviewer: Carlos Pignataro >> >> I have been asked to provide a ‘getting ready for WG adoption’ review of >> this document, on behalf of the MPLS WG review team. >> >> There are generally two relevant questions at this stage: >> >> 1. knowing whether the document is in scope for the working group, and >> 2. knowing whether the document is ready to be considered for WG adoption >> >> My perspective is that: >> >> 1. Maybe - RFC 4884, the RFC that this document would update if approved, >> was progressed as draft-ietf-bfd-mpls in the bfd wg. As such, I wonder if >> that ought to be followed here. From a practical standpoint, both WGs (mpls >> and bfd) would have to review this document, but it is a chair decision and >> guidance whether this should live in mpls or bfd (and frankly I have no >> strong position either way so long as both WGs are in the loop, simply >> pointing historic datapoints.) The document is clearly in scope on the >> intersection of both WGs, and historically was in bfd. >> >> 2. Yes – this document addresses clear clarifications for implementation >> interoperability. Granted, this protocol is deployed without these >> clarifications, but are (at least) theoretical gaps. >> >> A couple of further comments, since I read the document. Overall, well >> written and clear, achieves its goal, and: >> >> a. Backwards compatibility is paramount, and neither of those two words >> appear in the document. I recommend a section detailing implications. >> >> b. Section 5, IPv6, seems like an after-though, since it is not mentioned in >> the Abstract. Further, that case and explanation is well covered in RFC >> 8029, and as such seems like a distraction. >> >> c. There are various nits and an editorial pass would help with clarity. >> These include things like unqualified “echo reply” uses. >> >> Thanks, >> >> Carlos Pignataro >> >> _______________________________________________ >> mpls mailing list >> m...@ietf.org <mailto:m...@ietf.org> >> https://www.ietf.org/mailman/listinfo/mpls >