Early Review of draft-ietf-mboned-dorms-06
review-ietf-mboned-dorms-06-genart-early-yee-2025-08-25-00

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