Document: draft-ietf-mboned-dorms Title: Discovery Of Restconf Metadata for Source-specific multicast Reviewer: Peter Yee Review result: Ready with Issues
Document: draft-ietf-mboned-dorms Title: Discovery Of Restconf Metadata for Source-specific multicast Reviewer: Peter Yee Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-mboned-dorms-06 Reviewer: Peter Yee Review Date: 2025-08-25 IETF LC End Date: None IESG Telechat date: None Summary: This is a well-written draft that provides a means for multicast clients to seek out information on a source-specific multicast stream via a combination of DNS SRV lookup and RESTCONF server request. The “considerations” sections are well thought out and greatly strengthen the document. Nits aside, I have a few small issues with the document but otherwise find it ready to progress. [Ready with issues] Major issues: None Minor issues: Page 8, section 2.3.1, example: Receiver and client are being used interchangeably here. It’s a bit confusing. Perhaps try to use client (since this is a DORMS operation) and save “receiver” for things that are actually related to SSM multicast operations, which are mostly outside of the scope of this document in any case? This comment applies the next two parts of the example as well. Page 8, section 2.3.1, example, GET: How does the client know how to choose between the /host-meta and /host-meta.json in its GET request? Are they merely synonymous? Page 17, section 4.4, 2nd paragraph, 2nd sentence: I’d argue that a secure connection to a trusted DNS server that is obtaining DNS records for a DORMS server that are not protected by DNSSEC doesn’t protect the DORMS client from being given a bogus pointer to the DORMS server. My problem is with the “or” in the sentence. Either the left side of the “or” is needed, or both sides are, but not solely the right side. Page 21, section 6.3, 3rd paragraph: I don’t understand how a DNS cache expiration time correlates at all with a client’s inability to understand a DORMS server’s response and then checking for a new (and hopefully understandable) response from the DORMS server. While I agree that ignore list entries should time out, I’m not seeing the path from that to the suggested durations and times given. Nits/editorial comments: General: While I appreciate the stretch that went into making DORMS the acronym for the method described in the draft, it makes for a belabored title with the incorrect mixed case for “RESTCONF” and the atypical capitalization of “Of”. Assuredly, this is a matter of taste, although I found it disconcerting the first time I saw “Restconf” instead of RFC 8040’s RESTCONF. There are a few cases (mostly section titles) where “Yang” appears in the document. Replace them with “YANG”. Specific: Page 5, section 1.3.3., 2nd sentence: delete the comma after “traffic”. Add a comma after “e.g.”. Page 6, section 2: change “Metdata” in the section title to “Metadata”. Page 6, section 2.1, 3rd paragraph, last sentence: change “futher” to “further”. Page 7, section 2.2, 3rd paragraph: change “a SRV” to “an SRV” as already seen in section 2.3. Page 15, section 4.1, 1st paragraph after both sets of bullet items, 3rd sentence: append a comma after “Therefore”. Page 17, section 4.3, 2nd paragraph, 1st sentence: insert a hyphen between “security” and “related”. Page 17, section 4.4., 1st paragraph, 1st sentence: change “Boostrap” to “Bootstrap”. Page 19, 2nd paragraph: change “denial of service” to “denial-of-service”. Page 19, section 5.2, 2nd paragraph, 2nd sentence: consider changing “to succeed a multicast join” to “for a successful multicast join”. _______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
