Ballot for draft-ietf-pim-mofrr-tilfa
Discuss
Yes
No Objection
No Record
Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
(Directed primarily to the PIM WG chairs and responsible AD) While related to PIM, this document does not appear to be in-scope for the current PIM WG charter. ==[ snip from the charter ]== 1) Management: YANG models for PIM, IGMP, and MLD will be developed, for both configuration and operational states. If updates to existing MIB modules are necessary, the WG may work on those. 2) Improve PIM authentication. 3) Improve and Extend PIM Join Attributes to support different types of multicast applications. 4) Optimization approaches for IGMP and MLD to adapt to link conditions in wireless and mobile networks and be more robust to packet loss. ==[ snip ]== This draft not a YANG module per (1), is not related to authentication per (2), does not specify new join attributes per (3) and is not an optimization for IGMP/MLD per (4).
Thank you to Meral Shirazipour for the GENART.
# Éric Vyncke, INT AD, comments for draft-ietf-pim-mofrr-tilfa-06 Thank you for the work put into this document. Please find below one blocking DISCUSS points (trivial to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Stig Venaas for the shepherd's detailed write-up including the WG consensus ***but it lacks*** the justification of the intended status and I am supportive of John Scudder's point about intended status. I hope that this review helps to improve the document, Regards, -éric # DISCUSS (blocking) As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics: ## Copyright This I-D appears to use a very old template and the copyright text is wrong and no more valid... E.g., s/Simplified BSD License text/Revised BSD License text/ and approved by the authors of course.
# COMMENTS (non-blocking) ## Section 1 It seems that draft-ietf-rtgwg-segment-routing-ti-lfa is about segment routing, is it also the case for this I-D ? If so (as indicated further in the text), suggest to add this to the abstract. Should "MDT" be expanded ? ## Section 1.1 There is a single occurence of BCP14 terms (in the security section), consider removing this section. ## Section 2.1 `current MoFRR` won't age well once this I-D is published as an RFC; suggest using "RFC7381 MoFRR" Cosmetic: the aasvg tool may render the figure 1 in a much nicer way.
Thank you for this document. I have no technical comments, and I found the document easy to digest and follow. However, I would like to question the structure of the document as it does not follow https://datatracker.ietf.org/doc/html/rfc7322#section-4.1.1 where the 'Abstract' should be before 'Status of this memo' and 'Copyright notice'. Please bring the Abstract to the front of the document.
I’m conflicted as to whether Informational is the right type for this document — it doesn’t change wire encodings, but it does change elements of procedure, albeit in backward-compatible ways. I grant it’s an arguable point though. Too bad the shepherd writeup fails to answer the question “Why is this the proper type of RFC?” 😢 Also, I was sad there was no HTML rendering available. If you’d be willing to share what motivated you to go to the extra work of uploading a non-XML source format, I’d be interested in knowing.
I support Roman's DISCUSS position. In Security Considerations, there's this: The security considerations of LFA, R-LFA, and MoFRR described in [RFC5286], [RFC7490], and [RFC7431] SHOULD apply to this document. How can you establish a normative interoperability requirement against a document? For that matter, since this is Informational, why is BCP 14's inclusion appropriate?
I am supporting Roman's discuss.