Hi Rebecca, All of these have been reviewed, and they look good to me. Approved.
-MSK, ART AD On Sat, Mar 15, 2025 at 5:28 AM Rebecca VanRheenen < rvanrhee...@staff.rfc-editor.org> wrote: > Hi Sergio and Murray*, > > Sergio - Thanks for sending these changes along. We’ve incorporated them > in the current versions of the files (see list below). Please let us know > if any further updates are needed or if you approve the document in its > current form. > > *Murray - Sergio has addressed all open questions and reviewed the edited > document. We’ve added a few more items to our list for you to review and > approve. Below is the complete list. These changes are best viewed in the > following diff files: > https://www.rfc-editor.org/authors/rfc9725-alt-diff.html and > https://www.rfc-editor.org/authors/rfc9725-auth48diff.html. > > 1) Change from “ICE” to "ICE/STUN” in Figure 1 (author explanation: "As > the messages exchanged are technically STUN requests/responses, although > used in the context of ICE.”) > > 2) Change in first paragraph of Section 4.3.1, including addition of “MUST” > > 3) Deleted text in third paragraph of Section 4.3.1, which includes > deletion of “OPTIONAL” (author explanation: it is awkwardly placed and we > already have stated that "Trickle ICE and ICE restart support are > RECOMMENDED for both WHIP sessions and clients." in Section 4.3) > > 4) Addition of “SHOULD” in first paragraph of Section 4.4.3 > > 5) Deleted text about "credential-type” in bulleted list in Section 4.6 > and in Figure 5 due to citing the newest version of W3C.REC-webrtc: > https://www.w3.org/TR/webrtc/ (author explanation: in the latest w3c > webrtc spec, the credential-type field has been removed, so we need to > update the section, removing it as follows) > > 6) Update to use correct template (from RFC 3553) in Section 6.2 rather > than template that was in the original Section 6.4.1. This change was made > with discussion with IANA. It involved removing/adding text (and we also > did some reorganization of the IANA sections), so the diffs are a bit > difficult to read. Please let me know if you need any clarification here. > > 7) Updates to registration template in Section 6.5.3 > > > — FILES (please refresh) — > > Updated XML file: > https://www.rfc-editor.org/authors/rfc9725.xml > > Updated output files: > https://www.rfc-editor.org/authors/rfc9725.txt > https://www.rfc-editor.org/authors/rfc9725.pdf > https://www.rfc-editor.org/authors/rfc9725.html > > Diff files showing all changes made during AUTH48: > https://www.rfc-editor.org/authors/rfc9725-auth48diff.html > https://www.rfc-editor.org/authors/rfc9725-auth48rfcdiff.html (side by > side) > > Diff files showing all changes: > https://www.rfc-editor.org/authors/rfc9725-diff.html > https://www.rfc-editor.org/authors/rfc9725-rfcdiff.html (side by side) > https://www.rfc-editor.org/authors/rfc9725-alt-diff.html (shows changes > where text is moved or deleted) > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9725 > > Thank you, > > RFC Editor/rv > > > > > On Mar 14, 2025, at 2:23 AM, Sergio Garcia Murillo < > sergio.garcia.muri...@gmail.com> wrote: > > > > Hi Rebecca, > > > > Just done a final review on the document, a couple of changes I think > that should be needed: > > > > In Figure 1: WHIP Session Setup and Teardown, replace: > > > > | ICE REQUEST | | > > +--------------------------------------->+ | > > | ICE RESPONSE | | > > |<---------------------------------------+ > > > > bye > > | ICE/STUN REQUEST | | > > +--------------------------------------->+ | > > | ICE/STUN RESPONSE | | > > |<---------------------------------------+ > > > > As the messages exchanged are technically STUN requests/responses, > although used in the context of ICE. > > > > In 4.3.1. HTTP PATCH Request Usage Remove "Support of ICE restarts is > OPTIONAL." as it is awkwardly placed and we already have stated that > "Trickle ICE and ICE restart support are RECOMMENDED for both WHIP sessions > and clients." in Section 4.3 > > > > In Section 4.6 replace the old [W3C.REC-webrtc-20210126] reference by > the latest final one https://www.w3.org/TR/webrtc/ (should be > [W3C.REC-webrtc] ?) > > > > Also, as a consequence, in the latest w3c webrtc spec, the > credential-type field has been removed, so we need to update the section > removing it as follows: > > > > OLD: > > > > username: If the Link header field represents a Traversal Using Relays > around NAT (TURN) server and the "credential-type" attribute has a > "password" value, then this attribute specifies the username to use with > that TURN server. > > credential: If the "credential-type" attribute is missing or has a > "password" value, this attribute represents a long-term authentication > password, as described in Section 9.2 of [RFC8489]. > > credential-type: If the Link header field represents a TURN server, then > this attribute specifies how the "credential" attribute value should be > used when that TURN server requests authorization. The default value if the > attribute is not present is "password". > > Figure 5 illustrates the Link headers included in a "201 Created" > response, providing the ICE server URLs and associated credentials. > > > > Link: <stun:stun.example.net>; rel="ice-server" > > Link: <turn:turn.example.net?transport=udp>; rel="ice-server"; > > username="user"; credential="myPassword"; > > credential-type="password" > > Link: <turn:turn.example.net?transport=tcp>; rel="ice-server"; > > username="user"; credential="myPassword"; > > credential-type="password" > > Link: <turns:turn.example.net?transport=tcp>; rel="ice-server"; > > username="user"; credential="myPassword"; > > credential-type="password" > > Figure 5: Example of a STUN/TURN Server's Configuration > > > > > > NEW: > > > > username: If the Link header field represents a Traversal Using Relays > around NAT (TURN) server then this attribute specifies the username to use > with that TURN server. > > credential: This attribute represents a long-term authentication > password, as described in Section 9.2 of [RFC8489]. > > Figure 5 illustrates the Link headers included in a "201 Created" > response, providing the ICE server URLs and associated credentials. > > > > Link: <stun:stun.example.net>; rel="ice-server" > > Link: <turn:turn.example.net?transport=udp>; rel="ice-server"; > > username="user"; credential="myPassword"; > > Link: <turn:turn.example.net?transport=tcp>; rel="ice-server"; > > username="user"; credential="myPassword"; > > Link: <turns:turn.example.net?transport=tcp>; rel="ice-server"; > > username="user"; credential="myPassword"; > > Figure 5: Example of a STUN/TURN Server's Configuration > > > > What do you think? > > > > Best regards > > Sergio > > > > > > On Thu, Mar 13, 2025 at 5:49 PM Rebecca VanRheenen < > rvanrhee...@staff.rfc-editor.org> wrote: > > Hi Sergio, > > > > Yes, we are almost there! > > > > We have updated the document per your reply to our followup questions. > All of our questions have now been addressed. > > > > Please contact us with any further updates or with your approval of the > document in its current form. Review the document carefully to ensure > satisfaction as we do not make changes once it has been published as an RFC. > > > > Note that we sent some items for the AD to review and approve. Once we > have all approvals, we will ask IANA to update the registries to match the > edited document. We will then prepare the document for publication. > > > > — FILES (please refresh) — > > > > Updated XML file: > > https://www.rfc-editor.org/authors/rfc9725.xml > > > > Updated output files: > > https://www.rfc-editor.org/authors/rfc9725.txt > > https://www.rfc-editor.org/authors/rfc9725.pdf > > https://www.rfc-editor.org/authors/rfc9725.html > > > > Diff files showing all changes made during AUTH48: > > https://www.rfc-editor.org/authors/rfc9725-auth48diff.html > > https://www.rfc-editor.org/authors/rfc9725-auth48rfcdiff.html (side > by side) > > > > Diff files showing all changes: > > https://www.rfc-editor.org/authors/rfc9725-diff.html > > https://www.rfc-editor.org/authors/rfc9725-rfcdiff.html (side by side) > > https://www.rfc-editor.org/authors/rfc9725-alt-diff.html (shows > changes where text is moved or deleted) > > > > For the AUTH48 status of this document, please see: > > https://www.rfc-editor.org/auth48/rfc9725 > > > > Thank you, > > > > RFC Editor/rv > > > > > > > > > On Mar 13, 2025, at 2:09 AM, Sergio Garcia Murillo < > sergio.garcia.muri...@gmail.com> wrote: > > > > > > Hi Rebecca, > > > > > > Almost there! Please find my responses below. > > > > > > Best regards > > > Sergio > > > > > > On Wed, Mar 5, 2025 at 12:57 AM Rebecca VanRheenen < > rvanrhee...@staff.rfc-editor.org> wrote: > > > Hi Sergio, > > > > > > Thank you for the reply. We updated the document and posted updated > files. > > > > > > We also have a few more questions; thank you for your patience as we > work through these! > > > > > > a) We updated the sentences in Section 6.5 as you suggest to make them > generic for both registries. However, are changes also needed for the > following sentences? > > > > > > Current: > > > A Standards Track RFC is also REQUIRED for registration of WHIP > > > extension URNs that modify WHIP extensions previously documented in > > > an existing RFC. > > > > > > An RFC specifying one or more new WHIP extension URNs MUST include > > > the completed registration template(s), which MAY be expanded with > > > additional information. > > > > > > > > > > > > I think that is fine, as the only URNs defined currently are the ones > defined for the extensions. > > > b) It seems the following text related to the template in Section > 6.5.3 should also be generic for both registries. What do you think about > the proposed updates below? > > > > > > Current: > > > A WHIP extension URN is defined by completing the following > template: > > > > > > URN: A unique URN for the WHIP extension (e.g., > > > "urn:ietf:params:whip:ext:example:server-sent-events”). > > > > > > Name: A descriptive name of the WHIP extension (e.g., "Sender Side > > > events”) > > > > > > Perhaps: > > > The following template should be completed for registrations of > WHIP > > > URNs and WHIP Extension URNs: > > > > > > URN: A unique URN (e.g., > "urn:ietf:params:whip:ext:example:server-sent-events”). > > > > > > Name: A descriptive name (e.g., "Sender Side events”) > > > > > > > > > I am fine with the proposed changes. > > > > > > c) Regarding the "IANA Registry Reference” description in the template > in Section 6.5.3, we question if something like the following would be more > accurate. Note that we updated the entry in the for "IANA Registry > Reference” in Section 6.3 and will ask that IANA update the registry to > match the edited document prior to publication. > > > > > > Current: > > > IANA Registry Reference: For parameters defined in an IETF Standards > > > Track document, list the RFC number. For parameters defined by > > > other organizations or in non-IETF documents, provide a stable, > > > publicly available reference (such as a URL or document ID). If > > > multiple specifications define or update the parameter, list all > > > relevant references. > > > > > > Perhaps: > > > IANA Registry Reference: The registry related to the new URN > > > > > > > > > I copied it from one of the examples you provided me as guidance, I am > fine with both. > > > > > > — FILES (please refresh) — > > > > > > Updated XML file: > > > https://www.rfc-editor.org/authors/rfc9725.xml > > > > > > Updated output files: > > > https://www.rfc-editor.org/authors/rfc9725.txt > > > https://www.rfc-editor.org/authors/rfc9725.pdf > > > https://www.rfc-editor.org/authors/rfc9725.html > > > > > > Diff files showing all changes made during AUTH48: > > > https://www.rfc-editor.org/authors/rfc9725-auth48diff.html > > > https://www.rfc-editor.org/authors/rfc9725-auth48rfcdiff.html (side > by side) > > > > > > Diff files showing all changes: > > > https://www.rfc-editor.org/authors/rfc9725-diff.html > > > https://www.rfc-editor.org/authors/rfc9725-rfcdiff.html (side by > side) > > > https://www.rfc-editor.org/authors/rfc9725-alt-diff.html (shows > changes where text is moved or deleted) > > > > > > For the AUTH48 status of this document, please see: > > > https://www.rfc-editor.org/auth48/rfc9725 > > > > > > Thank you, > > > > > > RFC Editor/rv > > > > > > > > >> On Feb 27, 2025, at 2:57 AM, Sergio Garcia Murillo < > sergio.garcia.muri...@gmail.com> wrote: > > >> > > >> > > >> Hi Rebeca, > > >> > > >> It took bit longer than expected, but please find my answers to the > IANA pending topics below > > >> > > >> Best regards > > >> Sergio > > >> > > >> On Fri, Feb 7, 2025 at 8:38 PM Rebecca VanRheenen < > rvanrhee...@staff.rfc-editor.org> wrote: > > >> E) > > >>> > c) Sections 6.3 and 6.4: It looks like Section 6.4.1 includes a > template from > > >>> > Appendix A of RFC 3406. However, entries in the "IETF URN > Sub-namespace for > > >>> > Registered Protocol Parameter Identifiers" registry > > >>> > (https://www.iana.org/assignments/params/) should use the > template in Section 4 > > >>> > of RFC 3553. > > >>> > > > >>> > For examples, see: > > >>> > Section 10.1.2 of RFC 9162 (urn:ietf:params:trans) > > >>> > Section 9.3 of RFC 8620 (urn:ietf:params:jmap) > > >>> > Section 9.6 of RFC 8555 (urn:ietf:params:acme) > > >>> > > > >>> > After discussion with IANA, we recommend 1) updating the text in > Section 6.3 > > >>> > to include the template from RFC 3553 as follows and 2) removing > Section 6.4. > > >>> > The text in Section 6.4 already appears in Section 4.9, and if > needed, > > >>> > information from the template in Section 6.4.1 can be folded into > Section 4.9. > > >>> > > > >>> > (Note that we would need you to provide text for the "Index value" > field in > > >>> > the suggested text below.) > > >>> > > > >>> > Original: > > >>> > > > >>> > 6.3. Registration of WHIP URN Sub-namespace and WHIP registries > > >>> > > > >>> > IANA is asked to add an entry to the "IETF URN Sub-namespace for > > >>> > Registered Protocol Parameter Identifiers" registry and create a > sub- > > >>> > namespace for the Registered Parameter Identifier as per > [RFC3553]: > > >>> > "urn:ietf:params:whip". > > >>> > > > >>> > To manage this sub-namespace, IANA is asked to create the > "WebRTC- > > >>> > HTTP ingestion protocol (WHIP) URNs" and "WebRTC-HTTP ingestion > > >>> > protocol (WHIP) extension URNs". > > >>> > > > >>> > > > >>> > Perhaps (section numbers per suggested organization in previous > question): > > >>> > > > >>> > 6.2. URN Sub-namespace for WHIP (urn:ietf:params:whip) > > >>> > > > >>> > IANA has added a new entry in the "IETF URN Sub-namespace for > > >>> > Registered Protocol Parameter Identifiers" registry, following > the > > >>> > template in [RFC3553]: > > >>> > > > >>> > Registry name: whip > > >>> > Specification: RFC 9725 > > >>> > Repository: <https://www.iana.org/assignments/whip> > > >>> > Index value: TBD > > >>> > > > >>> > To manage this sub-namespace, IANA has created two registries > within > > >>> > a new registry group called "WebRTC-HTTP Ingestion Protocol > (WHIP)": > > >>> > > > >>> > * "WebRTC-HTTP Ingestion Protocol (WHIP) URNs" registry (Section > 6.3) > > >>> > * "WebRTC-HTTP Ingestion Protocol (WHIP) Extension URNs" > registry (Section 6.4) > > >>> > > > >>> > > >>> If IANA is ok with that, I am fine too. What is the index value? > > >> > > >> After discussion with IANA, we have 1) removed the template in the > original Section 6.4 and 2) updated Section 6.2 as follows with the > template from RFC 3553. > > >> > > >> i) Is there any information in the original template that should be > moved to Section 4.9 or another section? We specifically wonder about > information in the “Declaration of Syntactic Structure” and “Identifier > Persistence Considerations” sections of the original template. > > >> > > >> I am not sure either, don't feel that they are needed, but not strong > opinion. > > >> > > >> ii) Regarding the index value, see Section 4 of RFC 3553 and perhaps > discuss with the WG Chair or AD if needed. You can also review some > examples in other documents: > > >> > > >> https://www.rfc-editor.org/rfc/rfc8520.html#section-17.7 > > >> https://www.rfc-editor.org/rfc/rfc8322.html#section-8.2 > > >> https://www.rfc-editor.org/rfc/rfc8555.html#section-9.6 > > >> https://www.rfc-editor.org/rfc/rfc9162.html#section-10.1.2 > > >> > > >> Current: > > >> 6.2. URN Sub-namespace for WHIP (urn:ietf:params:whip) > > >> > > >> IANA has added a new entry in the “IETF URN Sub-namespace for > > >> Registered Protocol Parameter Identifiers” registry, following the > > >> template in [RFC3553]: > > >> > > >> Registry name: whip > > >> Specification: RFC 9725 > > >> Repository: <https://www.iana.org/assignments/whip> > > >> Index value: TBD > > >> > > >> I like the text in one of the examples: > > >> > > >> Index: An IANA-assigned positive integer that identifies the > > >> registration. The first entry added to this registry uses the > > >> value 1, and this value is incremented for each subsequent > > >> entry added to the registry. > > >> > > >> > > >> F) > > >>> > i) Section 6.5.3: The template in this section and the fields on > the IANA > > >>> > registry do not exactly match, as shown below. Is it correct that > the template > > >>> > should be updated to match the registry? > > >>> > > > >>> > Link to registy: https://www.iana.org/assignments/whip/ > > >>> > > > >>> > Template: > > >>> > URN > > >>> > Reference > > >>> > Name > > >>> > Description > > >>> > Contact Information > > >>> > > > >>> > Registry: > > >>> > URI > > >>> > Description > > >>> > Reference > > >>> > IANA Registry Reference > > >>> > Change Controller > > >>> > > > >>> yes , it should be changed > > >> > > >> Per your reply, we have updated the registration template in Section > 6.5.3 to exactly match the registries at > https://www.iana.org/assignments/whip. > > >> > > >> i) In some cases, the field names from the original template seem > more accurate. For example, should “URI” be “URN”, and should “Description” > be “Name”? If needed, we will ask IANA to update the registry to match the > edited document. > > >> > > >> Yes, I think that they should be changed as you propose, could you > ask it to IANA please? > > >> > > >> ii) Please provide descriptions for the "IANA Registry Reference” and > "Change Controller” entries. > > >> > > >> Current: > > >> URI: A unique URN for the WHIP Protocol Extension (e.g., > > >> "urn:ietf:params:whip:ext:example:server-sent-events”) > > >> > > >> Description: A descriptive name of the WHIP Protocol Extension > (e.g., > > >> "Sender Side events") > > >> > > >> Reference: A formal reference to the publicly available > specification > > >> > > >> IANA Registry Reference: TBD > > >> > > >> Change Controller: TBD > > >> > > >> How about? > > >> > > >> IANA Registry Reference: > > >> For parameters defined in an IETF Standards Track document, list > the RFC number. > > >> For parameters defined by other organizations or in non-IETF > documents, > > >> provide a stable, publicly available reference (such as a URL or > document ID). > > >> If multiple specifications define or update the parameter, list > all relevant references. > > >> > > >> Change controller: > > >> For Standards-Track documents, state "IETF". > > >> Otherwise, give the name of the person or body > > >> that has change control over the specification. > > >> > > >> > > >> G) > > >>> > j) This document includes a lot of detail about registering URNs > in the > > >>> > "WebRTC-HTTP ingestion Protocol (WHIP) Extension URNs" registry. > Is any > > >>> > additional information necessary for registering in the other WHIP > registry? > > >>> > Both are "Specification Required". > > >>> > --> > > >>> > > >>> The section should apply for both registries, yes > > >> > > >> We updated the text in paragraph 1 of Section 6.5 to note that the > section applies to both new registries. We also moved paragraph 2 and 3 > from Section 6.5 to Section 6.3.2 because they are specific to the WHIP > Extension URNs registry; please review. > > >> > > >> Please review Sections 6.5.1-6.5.3 and let us know what additional > updates are needed. We specifically question if the following sentences > need to be updated to clarify that this section applies to both registries. > Please provide any updates using OLD/NEW format. > > >> > > >> Current: > > >> The IETF has created a mailing list, <w...@ietf.org>, which can be > > >> used for public discussion of proposals regarding WHIP extensions > > >> prior to registration. > > >> > > >> Registration of new "ext" type URNs (in the namespace > > >> "urn:ietf:params:whip:ext") belonging to a WHIP extension MUST be > > >> documented in a permanent and readily available public > specification, > > >> > > >> A Standards Track RFC is also REQUIRED for registration of WHIP > > >> extension URNs that modify WHIP extensions previously documented in > > >> an existing RFC. > > >> > > >> Once the registration procedure concludes successfully, IANA > creates > > >> or modifies the corresponding record in the "WebRTC-HTTP ingestion > > >> protocol (WHIP) Extension URNs" registry. > > >> > > >> An RFC specifying one or more new WHIP extension URNs MUST include > > >> the completed registration template(s), which MAY be expanded with > > >> additional information. > > >> > > >> The RFC MUST include the syntax and semantics of any > > >> extension-specific attributes that may be provided in a Link header > > >> field advertising the extension. > > >> > > >> A WHIP extension URN is defined by completing the following > template: > > >> > > >> > > >> > > >> In order to make it generic for both registries I propose the > following changes: > > >> > > >> OLD: > > >> The IETF has created a mailing list, <w...@ietf.org>, which can be > used for public discussion of proposals regarding WHIP extensions prior to > registration. Use of the mailing list is strongly encouraged. A designated > expert (DE) [RFC8126], appointed by the IESG, will monitor the < > w...@ietf.org> mailing list and review registrations. > > >> > > >> NEW: > > >> The IETF has created a mailing list, <w...@ietf.org>, which can be > used for public discussion of proposals prior to registration. Use of the > mailing list is strongly encouraged. A designated expert (DE) [RFC8126], > appointed by the IESG, will monitor the <w...@ietf.org> mailing list and > review registrations. > > >> > > >> OLD: > > >> Registration of new "ext" type URNs (in the namespace > "urn:ietf:params:whip:ext") belonging to a WHIP extension MUST be > documented in a permanent and readily available public specification, in > sufficient detail so that interoperability between independent > implementations is possible, and reviewed by the DE as per Section 4.6 of > [RFC8126]. A Standards Track RFC is REQUIRED for the registration of new > value data types that modify existing properties. A Standards Track RFC is > also REQUIRED for registration of WHIP extension URNs that modify WHIP > extensions previously documented in an existing RFC. > > >> > > >> NEW > > >> Registration of new entries on the WHIP registries defined in this > document MUST be documented in a permanent and readily available public > specification, in sufficient detail so that interoperability between > independent implementations is possible, and reviewed by the DE as per > Section 4.6 of [RFC8126]. A Standards Track RFC is REQUIRED for the > registration of new value data types that modify existing properties. A > Standards Track RFC is also REQUIRED for registration of WHIP extension > URNs that modify WHIP extensions previously documented in an existing RFC. > > >> > > >> OLD > > >> Once the registration procedure concludes successfully, IANA creates > or modifies the corresponding record in the "WebRTC-HTTP Ingestion Protocol > (WHIP) Extension URNs" registry. > > >> > > >> NEW > > >> Once the registration procedure concludes successfully, IANA creates > or modifies the corresponding record in the "WebRTC-HTTP Ingestion Protocol > (WHIP) URNs Registry" or "WebRTC-HTTP Ingestion Protocol (WHIP) Extension > URNs" or registry. > > >> > > >> > > >> > > > > > > >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
