Thanks for the review. I think I've addressed everything here in the latest revision (07).
Responses inline: On Mon, Aug 25, 2025 at 8:32 PM Peter Yee via Datatracker <[email protected]> wrote: > 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. I think I've made this more consistent throughout. Let me know if you see any remaining issues. > 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? I don't think there's really a change for me to make here. My response is, "For whatever reason any RESTCONF client would choose between JSON and XML." > 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. I attempted to clarify the requirement that the responses somehow maintain integrity end-to-end, even if the client itself is not using DNSSEC. Please review what's there and let me know if that is satisfactory. > 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. Agreed. I removed that language and just left it up to configuration. > 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. This feels like editorial or poetic license. "DORMS" is hardly the worst abbreviation to come out of the IETF, and we're running out of short, memorable names. All below are now fixed AFAICT: > 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”. Thanks, Kyle _______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
