Thanks and I approve publication of the document. And, Yes this is a standalone STD.
- Bernie Volz > On Dec 17, 2025, at 1:40 PM, Megan Ferguson <[email protected]> > wrote: > > Michael, Bernie, and Tim > > Combining a few author responses here to close these topics out: > > 1) Regarding the text Michael pointed out: > >> I have read the 9915 top to bottom. >> I think the phrasing at 18.2.12: >> >>> A client not detected as having moved to a new link SHOULD initiate >> >> is still pretty awkward. >> The new phrasing, seems to suggest that an external entity is going to detect >> the client has moved. But, it's the client has to do the detection. >> I think the problem is that the sentences are too long/too few. >> I can live with this, but maybe someone else has a suggestion here. >> > We have updated to use Bernie’s suggestion (with a few editorial tweaks > related to tense and punctuation) as that seemed to be the consensus of the > messages. Please review and let us know if any further updates are necessary. > > 2) To address the “non-issues” in Michael’s mail: >> ---- non-issues: >> >> A question about the many minor changes where a list item has a : added. >> The colon appears in the <dt> as text, it's not produced by xml2rfc. >> Someone did s,</dt>,:</dt>,g right? > [rfced] Right. > >> So that seems like a stylistic thing that (authors) should just be more aware >> of. It seems like it aught to be something xml2rfc "enforces" > > [rfced] There is not a requirement that the term in a definition list be > followed by a colon. Sometimes a term is followed by other punctuation or a > line break (if newline="true"). From our perspective, this is a style choice > that should not be enforced by the tool. > >> >> I'm also curious about the how/why IA_PD-options got hyphen wrapped (section >> 21.22), but in our text it was just moved to a new line. >> > [rfced] The submitted XML file contained a non-breaking hyphen in that > instance. We did not keep the non-breaking hyphen, as typically words that > "naturally" contain hyphens can contain line breaks in RFCs. If you want > that particular term to be kept together, please let us know and we will > insert the entity (&nbhy;) > > 3) With regard to the header question from Bernie: > >> At least from the headers in this document: >> >> Internet Engineering Task Force (IETF) T. Mrugalski >> Request for Comments: 9915 ISC >> Obsoletes: 8415 B. Volz >> Category: Standards Track Individual Contributor >> ISSN: 2070-1721 M. Richardson >> SSW >> S. Jiang >> BUPT >> T. Winters >> QA Cafe >> December 2025 >> >> I’m not seeing any difference from headers on 8415 that indicate this would >> be an IETF Full Standard document? >> >> RFC8200 has “STD: 86”. > > [rfced] Thank you for bringing this to our attention. This document has been > assigned a new STD number (102). > > Please let us know if this is not correct (i.e., it should be part of an > existing STD). > See the complete list of Internet Standards here: > https://www.rfc-editor.org/standards > > > Please review the files carefully as we do not make changes after > publication. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9915.txt > https://www.rfc-editor.org/authors/rfc9915.pdf > https://www.rfc-editor.org/authors/rfc9915.html > https://www.rfc-editor.org/authors/rfc9915.xml > > The relevant diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9915-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9915-rfcdiff.html (comprehensive side > by side) > https://www.rfc-editor.org/authors/rfc9915-auth48diff.html (AUTH48 changes > only) > https://www.rfc-editor.org/authors/rfc9915-auth48rfcdiff.html (AUTH48 side by > side) > https://www.rfc-editor.org/authors/rfc9915-lastdiff.html (last version to > this) > https://www.rfc-editor.org/authors/rfc9915-lastrfcdiff.html (last to this > side by side) > > Please contact us with any further updates/questions/comments you may have. > > We will await approvals from each of the parties listed on the AUTH48 status > page prior to moving forward to publication. > > The AUTH48 status page for this document is available here: > > https://www.rfc-editor.org/auth48/rfc9915 > > Thank you. > > Megan Ferguson > RFC Production Center > >> On Dec 15, 2025, at 2:41 PM, Michael Richardson <[email protected]> >> wrote: >> >> >> I have read the 9915 top to bottom. >> I think the phrasing at 18.2.12: >> >>> A client not detected as having moved to a new link SHOULD initiate >> >> is still pretty awkward. >> The new phrasing, seems to suggest that an external entity is going to detect >> the client has moved. But, it's the client has to do the detection. >> I think the problem is that the sentences are too long/too few. >> I can live with this, but maybe someone else has a suggestion here. >> >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
