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
