Interoperability Profile for Relay User Equipment
draft-ietf-rum-rue-11
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-01-26
|
11 | Gunter Van de Velde | Request closed, assignment withdrawn: Jouni Korhonen Last Call OPSDIR review |
2024-01-26
|
11 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue |
2022-05-31
|
11 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2022-05-19
|
11 | (System) | RFC Editor state changed to AUTH48 |
2022-04-01
|
11 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2022-03-09
|
11 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2022-03-09
|
11 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2022-03-09
|
11 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2022-03-01
|
11 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2022-03-01
|
11 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2022-02-28
|
11 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2022-02-24
|
11 | (System) | RFC Editor state changed to EDIT |
2022-02-24
|
11 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2022-02-24
|
11 | (System) | Announcement was received by RFC Editor |
2022-02-23
|
11 | (System) | IANA Action state changed to In Progress |
2022-02-23
|
11 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2022-02-23
|
11 | Cindy Morgan | IESG has approved the document |
2022-02-23
|
11 | Cindy Morgan | Closed "Approve" ballot |
2022-02-23
|
11 | Cindy Morgan | Ballot approval text was generated |
2022-02-23
|
11 | (System) | Removed all action holders (IESG state changed) |
2022-02-23
|
11 | Murray Kucherawy | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2022-02-17
|
11 | Brian Rosen | New version available: draft-ietf-rum-rue-11.txt |
2022-02-17
|
11 | (System) | New version accepted (logged-in submitter: Brian Rosen) |
2022-02-17
|
11 | Brian Rosen | Uploaded new revision |
2022-02-07
|
10 | Roman Danyliw | [Ballot comment] Thank you to Russ Mundy for the SECDIR review. Thank you for addressing my DISCUSS and COMMENT feedback. |
2022-02-07
|
10 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2022-02-06
|
10 | Benjamin Kaduk | [Ballot comment] Many thanks for the updates in the -10; we look to be nice and self-consistent (modulo carddav-domain, see below) now. I especially like … [Ballot comment] Many thanks for the updates in the -10; we look to be nice and self-consistent (modulo carddav-domain, see below) now. I especially like the example passwords -- good entropy there :) There are some editorial/formatting nits that crept in, but I'm sure the RFC Editor can fix those up and didn't bother enumerating them here. A few final comments/suggestions: The description of "carddav-domain" uses "server address" in the OpenAPI description string but in the prose description we call it "contacts-domain" (not "carddav-domain") and we describe it as just "a domain name" (vs address). It would be good to tighten those up into closer alignment. Section 9.2 The data returned is a JSON object consisting of an array of key/ value configuration parameters to be used by the RUE. s/consisting of an array of/consisting of/, I think -- the openAPI looks like just an object, no array. Section 9.2.2 * contacts: (optional) An HTTPS URI ("contacts-uri"), (optional) user name ("contacts-username") and password ("contacts-password") that may be used to export (retrieve) the subscriber's complete [...] * carddav: (optional) A domain name ("contacts-domain"), (optional) user name ("carddav-username") and password ("carddav-password") identifying a "CardDAV" server and account that can be used to I'd go with "An object containing [URI/domain name], and optional [user name and password]," for both of these. The OpenAPI description is clear (and authoritative, thanks for that!), but this is an easy tweak to help readability. |
2022-02-06
|
10 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2022-01-24
|
10 | Martin Duke | [Ballot comment] Thanks for addressing my DISCUSS, and your work to make the internet more accessible for all. |
2022-01-24
|
10 | Martin Duke | [Ballot Position Update] Position for Martin Duke has been changed to No Objection from Discuss |
2022-01-21
|
10 | Paul Kyzivat | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This review is written … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This review is written against draft-ietf-rum-rue-10 on 21-jan-2022. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Video Relay Service (VRS) is a term used to describe a method by which a hearing person can communicate with a deaf, hard of hearing or hearing impaired user using an interpreter ("Communications Assistant") connected via a videophone to the deaf/hard of hearing/ hearing impaired user and an audio telephone call to the hearing user. The CA interprets using sign language on the videophone link and voice on the telephone link. Often the interpreters may be employed by a company or agency termed a "provider" in this document. The provider also provides a video service that allows users to connect video devices to their service, and subsequently to CAs and other deaf/hard of hearing/hearing impaired users. It is desirable that the videophones used by the deaf, hard of hearing or hearing impaired user conform to a standard so that any device may be used with any provider and that direct video calls between deaf, hard of hearing or hearing impaired users work. This document describes the interface between a videophone and a provider. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There was not a lot of energy in the group to move the work along. Notably, the representatives of VRS providers were reluctant to contribute and mostly offered objections. Reaching consensus under these conditions was challenging and often consensus was quite rough. Document Quality: Are there existing implementations of the protocol? There is a partial implementation by Mitre. This is intended as a verification and test vehicle. They have committed to creating a full implementation when the document becomes an RFC. Have a significant number of vendors indicated their plan to implement the specification? No. But the most likely vendors are the VRS providers. They do what they are required to do by the FCC. It is expected that the FCC will mandate this and then they will implement it. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? No. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Shepherd: Paul Kyzivat AD: Murray Kucherawy (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The shepherd has actively reviewed and provided feedback and suggestions on every version of this document, and verified all the formal language-based content, and reviewed the results of IdNits. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. This version of the document addresses concerns raised in a security review of the prior version. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The market in which implementations of this document will primarily be deployed is unusual. The server side is controlled by a small set of VRS providers that are funded by the FCC and governed by rules issued by the FCC. The deployment of this standard will presumably be driven by new FCC requirements referencing it. The subject area covered by this document has heretofore been addressed with proprietary devices and/or software. The motivation for this work comes from outside the VRS provider community, while most people with experience building RUE-like devices work for the VRS providers. There are compromises made with the VRS providers that have shaped the document in ways that is somewhat different from how it would have come out without their participation, yet the participation of these providers is deemed essential, and their co-operation is sincerely appreciated. On the other hand, the rough consensus process has indeed overcome objections of all the participating providers, and they are not happy with certain aspects of the document. The shepherd is satisfied that the IETF processes on determining consensus were fairly applied, and the document represents a reasonable compromise between the providers as a whole and the rest of the work group. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Many IPR disclosures have been filed repeatedly against every new draft version of this document by one of the VRS providers. Based on a superficial examination, these seem to cover primarily features that impact downstream actions within the VRS provider and not the functionality addressed by this document. (Disclaimer, this is not a legal analysis.) Participants have been afforded opportunities to suggest any changes in the document that may further avoid the IPR claimed in the patents, and no suggestions have been made. Given the market in which this will be applied the current participants (all the VRS providers) clearly have already come to grips with the IPR environment. It is possible that an outsider who wants to create and sell a compatible RUE device might need to address some IPR issues. It isn't clear that there is any such candidate among the current participants of the work group. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The consensus is reluctant. Many of the participants represent the interests of the VRS providers, and seemingly would prefer there be no such standard. (Presumably they assume they will be compelled by the FCC to support it.) However, despite repeated requests, their objections have not been accompanied by contribution of constructive alternatives. The rest of the reviews and opinions come from more experienced IETF participants and they have generally been solidly in favor of the document as it now is constituted. In a few cases, some compromise has been achieved, where the more experienced IETFers would have preferred somewhat different text, but were persuaded the the compromise text was acceptable. Similarly, there are a few instances where the providers were initially against requirements deemed essential by our more experienced IETF participants, they offered some suggested additional requirements that the IETFers did not think were necessary, and they were accepted. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? Representatives of a major VRS provider have contacted this chairperson/shepherd with a request for guidance on how they may escalate their concerns. They were referred to the Responsible Area Director. If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. IdNits reports some errors and warnings that are bogus: * 3 instances of lines with non-ascii characters. These all appear in reference citations where they are now permitted. One of these is also reported as a line too long, due solely to the non-ascii character being counted as multiple bytes. * 2 warnings for "looks like a reference" for use of [1] and [2] in examples. In addition three downrefs are reported, referencing RFC2818, RFC3960 and RFC5168. These are discussed in (15) below. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The shepherd verified the json using the tool jsonlint , and the OpenAPI 3.1 descriptions of the interfaces using . (13) Have all references within this document been identified as either normative or informative? YES (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? NO (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. There are three downrefs, referencing RFC2818, RFC3960 and RFC5168. RFC2818 is an informational RFC that describes how to use TLS to secure HTTP connections. The RUE document defines web interfaces that run securely over HTTPS and TLS. Doing so requires following the guidance in RFC2818. Hence we made this a normative reference. RFC3960 is an informational RFC that describes how SIP entities handle early media. Early media is media that happens before a call is answered, which may be tones and announcements but also could be from an IVR system that doesn’t signal answer until a live agent answers the call. It’s the case that virtually every implementation has to do what RFC3960 says because otherwise things don’t work, yet the text has no normative RFC119 language. Hence we made this a normative reference. RFC5168 documents an older way to request full frame refresh on a video stream that many older devices still use. To connect to them it is necessary to do what RFC5168 says. We want that backward compatibility, so we required it. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. NO (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). The definition of the new RUE Provider List registry is properly specified. The update to the SIP Call-Info header field purpose is in good order. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. The new RUE Provider List needs an expert. This is a per-country registry. The expert should ideally be comfortable working with this sort of regulatory environment. The document editor, Brian Rosen, will volunteer to be the expert and there are other candidates who could be considered (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. The shepherd verified the json using the tool jsonlint , and the OpenAPI 3.1 descriptions of the interfaces using . (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? N/A |
2022-01-20
|
10 | Robert Wilton | [Ballot comment] [Clearing discuss points based on Brian's clarification and proposed resolution text.] Hi Brian, Thank you for working on this. This technology is quite … [Ballot comment] [Clearing discuss points based on Brian's clarification and proposed resolution text.] Hi Brian, Thank you for working on this. This technology is quite a long way outside of my expertise, and hence my review is primarily focused on the Configuration section (section 9). Nit: when used with the following interface => when used with the following OpenAPI interface Nit: with a corresponding a entry point -> with a corresponding entry point Minor version definitions SHALL only add objects, non-required members of existing objects, and non-mandatory-to use functions and SHALL NOT delete any objects, members of objects or functions. Would "delete or change" be more correct than just "delete" here? Somewhat related to the discuss comment, but it wasn't clear to me why the versioning is described as part of the "Rue Provider Selection" section and I think that the document would arguably be clearer if the versioning moved to its own separate 9.X section, making it clear that the versioning applies to the entire API? Nit: The method the API Key is obtained is not specified in this document. => Perhaps "The method used to obtain the API key ..." The provider MAY refuse to provide service to an implementation presenting an API Key it does not recognize. Why is this not a MUST? Is the "instance-identifier" arbitrarily chosen by the client? Otherwise, it wasn't clear to me how a client would discover or know what "instance-identifier" to use. It might be helpful if the text clarified this, and possibly even the parameter name could be changed to make it more obvious that it is a client provided value? Regards, Rob |
2022-01-20
|
10 | Robert Wilton | [Ballot Position Update] Position for Robert Wilton has been changed to No Objection from Discuss |
2022-01-20
|
10 | Zaheduzzaman Sarker | [Ballot comment] Thanks for addressing the comments in the Discuss. The changes made in version -10 look good to me. |
2022-01-20
|
10 | Zaheduzzaman Sarker | [Ballot Position Update] Position for Zaheduzzaman Sarker has been changed to No Objection from Discuss |
2022-01-19
|
10 | (System) | Changed action holders to Murray Kucherawy (IESG state changed) |
2022-01-19
|
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2022-01-19
|
10 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2022-01-19
|
10 | Brian Rosen | New version available: draft-ietf-rum-rue-10.txt |
2022-01-19
|
10 | (System) | New version approved |
2022-01-19
|
10 | (System) | Request for posting confirmation emailed to previous authors: Brian Rosen |
2022-01-19
|
10 | Brian Rosen | Uploaded new revision |
2021-12-16
|
09 | (System) | Changed action holders to Murray Kucherawy, Brian Rosen (IESG state changed) |
2021-12-16
|
09 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2021-12-16
|
09 | Lars Eggert | [Ballot comment] Document still refers to the "Simplified BSD License", which was corrected in the TLP on September 21, 2021. It should instead refer to … [Ballot comment] Document still refers to the "Simplified BSD License", which was corrected in the TLP on September 21, 2021. It should instead refer to the "Revised BSD License". No reference entries found for: [RFC6655]. Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Term "traditional"; alternatives might be "classic", "classical", "common", "conventional", "customary", "fixed", "habitual", "historic", "long-established", "popular", "prescribed", "regular", "rooted", "time-honored", "universal", "widely used", "widespread". Thanks to Matt Joras for their General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/v7czr4R50Y-rupMcCDcnBbAtIJs). ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 6.2. , paragraph 3, nit: - [RFC8865], using the WebRTC data chanel. RFC 8865 also has some + [RFC8865], using the WebRTC data channel. RFC 8865 also has some + + Section 7.2. , paragraph 2, nit: - xCard [RFC6351] xml format. - ^^^ + xCard [RFC6351] XML format. + ^^^ Section 8. , paragraph 2, nit: - provider supports video mail at least one of these mechansism MUST be - - + provider supports video mail at least one of these mechanisms MUST be + + Section 9.1. , paragraph 6, nit: - The V1.0 provider list is a json object consisting of an array where - ^^^^ + The V1.0 provider list is a JSON object consisting of an array where + ^^^^ Section 9.2. , paragraph 3, nit: - "redexample.net", the provider configuration would be obtained from + "red.example.net", the provider configuration would be obtained from + + Section 9.2. , paragraph 6, nit: - The data returned is a json object consisting of an array of key/ - ^^^^ + The data returned is a JSON object consisting of an array of key/ + ^^^^ Section 9.2.1. , paragraph 2, nit: - * signup: (OPTIONAL) an array of json objects consisting of: - ^^^^ + * signup: (OPTIONAL) an array of JSON objects consisting of: + ^^^^ Section 9.2.1. , paragraph 5, nit: - * dialAround: an array of json objects consisting of: - ^^^^ + * dialAround: an array of JSON objects consisting of: + ^^^^ Section 9.2.1. , paragraph 9, nit: - * helpDesk: (OPTIONAL) an array of json objects consisting of: - ^^^^ + * helpDesk: (OPTIONAL) an array of JSON objects consisting of: + ^^^^ Section 9.3. , paragraph 2, nit: - with OpenAPI 3.0 ([OpenApi]) descriptions in yaml form. - ^^^^ + with OpenAPI 3.0 ([OpenApi]) descriptions in YAML form. + ^^^^ Section 10.1. , paragraph 4, nit: - * list entry point: a string is used to compose the uri to the - ^^^ + * list entry point: a string is used to compose the URI to the + ^^^ "Table of Contents", paragraph 2, nit: > . . . . . . . . . . . . 12 5.3. Mid Call Signaling . . . . . . . . . . . . > ^^^^^^^^ This word is normally spelled with a hyphen. "Table of Contents", paragraph 2, nit: > . . . . . . . . . . . . . 35 Acknowledgements . . . . . . . . . . . . . . . > ^^^^^^^^^^^^^^^^ Do not mix variants of the same word ("acknowledgement" and "acknowledgment") within a single text. Section 2. , paragraph 11, nit: > vice such as a laptop, tablet or smart phone; or proprietary equipment connec > ^^^^^^^^^^^ Nowadays, it's more common to write this as one word. Section 5.1. , paragraph 4, nit: > ord) MUST be supplied within the credentials section of the configuration and > ^^^^^^^^^^^ An apostrophe may be missing. Section 5.2.1. , paragraph 1, nit: > f this document. To allow time to timeout an unanswered call and direct it t > ^^^^^^^ The word "timeout" is a noun. The verb is spelled with a white space. Section 5.2.4. , paragraph 3, nit: > might require the location to be pre-loaded in some entity prior to placing > ^^^^^^^^^^ This word is normally spelled as one. Section 5.2.4. , paragraph 3, nit: > device location than the manual, pre-loaded entry. That information MAY be u > ^^^^^^^^^^ This word is normally spelled as one. Section 5.2.5. , paragraph 2, nit: > bscriber Information blocks. 5.3. Mid Call Signaling Implementations MUST sup > ^^^^^^^^ This word is normally spelled with a hyphen. Section 5.2.5. , paragraph 3, nit: > number" includes numbers such as toll free numbers that are not actually E.1 > ^^^^^^^^^ This word is normally spelled with a hyphen. Section 7.2. , paragraph 3, nit: > lished a registry that contains a two letter country code and an entry point > ^^^^^^^^^^ When "two-letter" is used as a modifier, it is usually spelled with a hyphen. Section 7.2. , paragraph 4, nit: > ble for display, with a corresponding a entry point to obtain information abo > ^ Use "an" instead of "a" if the following word starts with a vowel sound, e.g. "an article", "an hour". Section 9.1. , paragraph 2, nit: > ersions of the major version. The versions mechanism returns an array of supp > ^^^^^^^^ An apostrophe may be missing. Section 9.1. , paragraph 10, nit: > figuration service MAY be different than the version of the provider list se > ^^^^ Did you mean "different from"? "Different than" is often considered colloquial style. Section 11. , paragraph 27, nit: > rfc-editor.org/info/rfc8126>. Acknowledgements Brett Henderson and Jim Mallo > ^^^^^^^^^^^^^^^^ Do not mix variants of the same word ("acknowledgement" and "acknowledgment") within a single text. |
2021-12-16
|
09 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
2021-12-16
|
09 | Francesca Palombini | [Ballot comment] Thank you for the work on this document. Many thanks to Rich Salz for his review: https://mailarchive.ietf.org/arch/msg/art/FAnGx_MrrlJVdU8WxbGG_BOFVe8/ . I only had time to … [Ballot comment] Thank you for the work on this document. Many thanks to Rich Salz for his review: https://mailarchive.ietf.org/arch/msg/art/FAnGx_MrrlJVdU8WxbGG_BOFVe8/ . I only had time to scan the document, but did not find any major ART issues. Francesca |
2021-12-16
|
09 | Francesca Palombini | [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini |
2021-12-16
|
09 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. This seems like a nice functionality to make the Internet more inclusive. Please find … [Ballot comment] Thank you for the work put into this document. This seems like a nice functionality to make the Internet more inclusive. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Paul Kyzivat for the shepherd's write-up including the section about the WG consensus. And being honest about the rough consensus and lack of energy. Thank you also Paul for the review of the 222 (!!!) IPR declarations (with some duplicates). I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Abstract -- Please expand "HoH" -- Section 4 -- While I like "Implementations MUST support IPv4 and IPv6", it may be too strong though. -- Section 6.7 -- In "RUE MUST maintain any NAT bindings by periodically sending media packets", I wonder whether it is required in the case of IPv6 (usually no NAT but perhaps stateful devices on the path)... Perhaps change "NAT bindings" into "states in the network (e.g., NAT bindings)" ? -- Section 9.1 -- I wonder why the focus is on the country and not the language... I.e., in my country, Belgium, there are 3 official languages and all of these languages are shared with other countries... I would suggest that either requesting by language or having the supported language(s) returned by the request. |
2021-12-16
|
09 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2021-12-15
|
09 | John Scudder | [Ballot comment] I appreciate your work on this topic. I do have one question I’d like answered: RFC 3261 is updated by a long list … [Ballot comment] I appreciate your work on this topic. I do have one question I’d like answered: RFC 3261 is updated by a long list of other RFCs. In the course of developing this spec, did you consider, for each of those, whether it should be listed as a normative reference? My guess is that the answer is “yes”, since §5 makes it appear some careful consideration was given to this question and several of the RFCs that update 3261 are listed in that section. Still, I’d be more comfortable if you’d confirm. (Another way to think of this is, for all the RFCs that update 3261 and are NOT already referenced by your spec, are you confident they don’t need to be referenced?) |
2021-12-15
|
09 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2021-12-15
|
09 | Roman Danyliw | [Ballot discuss] ** Is there a reason that credential re-use is being suggested as a fall back. It seems risky to reuse the credentials across … [Ballot discuss] ** Is there a reason that credential re-use is being suggested as a fall back. It seems risky to reuse the credentials across services. This fall-back also appears to contradict the guidance in Section 5.1. which says “This username/password combination SHOULD NOT be the same as that used for other purposes, such as retrieving the RUE configuration”. See: -- Section 7.1. Per access to the CardDAV server, “[i]f no matching credentials are configured, the RUE MUST use the SIP credentials from the configuration.” -- Section 9.2.2. sip-password says “If it was never supplied, the password used to authenticate to the configuration service is used for SIP, STUN and TURN.” -- Section 9.2.2. carddav field says that “If username or password are not supplied, the main account credentials are used. “ ** Is there a reason that a minimum transport requirements of using HTTPS is not defined for accessing the SIP-supporting elements of this architecture. -- Section 7.1. Access to the CardDAV service? Does the guidance in Section 7.2 (The RUE stores/retrieves the contact list (address book) by issuing an HTTPS POST or GET request.) imply that? -- Section 9. Using the overall API? Does the guidance in Section 9.2 (A RUE device may retrieve a provider configuration the using a simple HTTPs web service) imply that? -- Section 9.2.1. For the URI configuration options noted in this section (e.g., the uri in signup)? ** Section 11. There are more than 10 20 normative SIP protocol references in this document. Which of their security considerations apply? |
2021-12-15
|
09 | Roman Danyliw | [Ballot comment] Thank you to Russ Mundy for the SECDIR review. ** Section 2. Thanks for defining all of this terminology up front. As many … [Ballot comment] Thank you to Russ Mundy for the SECDIR review. ** Section 2. Thanks for defining all of this terminology up front. As many of these are components in the architecture, I would have benefit from a diagram early in the document showing how these components integrate. ** Section 5.1. The paragraph starting with “The registrar MAY authenticate using SIP digest authentication …”, should likely say that the technique for provisioning the credentials is out of scope for this profile. ** Section 8. Typo. s/mechansism/mechanism/ ** Section 9.1 IANA has established a registry that contains a two letter country code and an entry point string. Recommend adding a forward reference to Section 10.1. ** Section 9.1. For example, if the entryPoint is "example.com", the provider list would be obtained from https://example.com/rum/V1/Providers. This example doesn’t match the syntax of Section 9.3. “V1” here and “v1” in Section 9.3. ** Section 9.2. It would be helpful in this narrative text for the input values names to match the actual field names used in the API in Section 9.3. Specifically, “API Key” is “apiKey”, and “instance identifier” is “instanceId” ** Section 9.2.1. Per the language value in the signup configuration option, please provide a reference to the IAN language subtag registry (https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry). ** Section 9.2.2. sendLocationWithRegistation is listed as a stand-alone field here, but in Section 9.3, it is shown to be part of the carddav object. Which is correct? ** Section 9.2.3. Figure 4. This example is not conformance to the previously described syntax. All of the values of the “uri” fields should be a URI, but all of them are missing a scheme. ** Section 9.3. [OpenAPI] needs to be a normative reference as its syntax is needed to understand this section. |
2021-12-15
|
09 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2021-12-15
|
09 | Warren Kumari | [Ballot comment] I have very little substantive to add -- other ADs are already holding DISCUSSes for the concerns that I had. I would like … [Ballot comment] I have very little substantive to add -- other ADs are already holding DISCUSSes for the concerns that I had. I would like to note though that I find this sort of document (e.g: "Implementations of the RUE Interface MUST conform to the following core SIP standards: [ ]") really useful. When a customer (or pointy-haired-boss) asks you to implement or deploy some new protocol you've never even heard of, it is incredibly helpful to have 1: a use-case/requirements doc so you know what the protocol does, 2: an overview / architecture, 3: a list of other important docs and 4: an operational/deployment doc. This document covers a number of these parts. |
2021-12-15
|
09 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2021-12-15
|
09 | Benjamin Kaduk | [Ballot discuss] Thanks for writing this document; it's an important topic and I look forward to seeing interoperability in this space. However, I don't think … [Ballot discuss] Thanks for writing this document; it's an important topic and I look forward to seeing interoperability in this space. However, I don't think this document is quite ready for publication yet, as it has a number of internal inconsistencies (and at least one external inconsistency with IETF procedures) that would get in the way of interoperable implementation. (1) The procedure for substituting an entryPoint from the provider list into the OpenAPI interface description for obtaining configuration data appears to be incompatible with BCP 190. Though there's not quite enough detail for me to be able to tell exactly what behavior is intended, the procedure of "replace localhost in the template with the value from provider discovery" seems like it implies that the value from provider discovery is just a hostname, and that we are requiring the RUM services to be accessible via HTTP at path /rum/v1 on that machine. The URI path namespace is under control of the owner of the host, and we cannot assert that we will occupy that portion of the namespace. The current version of BCP 190, RFC 8820, does allow us to say (effectively) "delegate a subtree of the path namespace to the protocol" by letting the owner of the host pick what base path to use for the protocol (even that would not have been allowed by its predecessor, RFC 7320), but we do need to let that host-specific path prefix be indicated somehow, whether by URL template or allowing a base path to be indicated in the provider discovery process. (2) There are a lot of inconsistencies about the parameters and data format of the various API responses as specified in prose, OpenAPI description, and examples. In particular, we also fail to make a clear statement about whether the prose or the OpenAPI description is normative and takes precedence in case of disagreement. I'll list a bunch of things here; I made a fairly careful reading but am not willing to assert that this is a comprehensive listing. (A number of them also get comments in the section-by-section comments; sorry about that duplication.) Sections 9.2.1 and 9.2.2 list configuration data items in the "configuration data for new user sign up and dial around" and "configuration data for the RUE" configuration retrieval APIs, and per the note at the end of §9.2 they include the REQUIRED data items. However, there are a couple data items that are mentioned elsewhere in the document as if they are always going to be present, but are not present in these lists of required configuration parameters. In particular we talk about the "provider-domain" as coming from the configuration, and it appears in examples, but is not mentioned in the prose or OpenAPI format description. The prose (and some examples) refer to an "outbound-proxies" RUE configuration element, but §9.2.2 and the OpenAPI description list the singular "outbound-proxy" (and with the corresponding difference in format/structure). The prose mentions "credentials" from the configuration, but no parameter of that name appears (there is some mention of password under "carddav" but that seems insufficiently generic to match all instances; sip-password also exists). "display-name" appears in the example in Figure 5 but is not listed in §9.2.2 The prose for the provider configuration resource indicates that the dialAround property is mandatory (it is not marked as "(OPTIONAL)"), but the OpenAPI specification does not list this property as required. The prose for the provider configuration's "signup" property says that it is an array of JSON objects, but the OpenAPI description says that it is just a single object (not an array). Likewise for "dialAround" and "helpDesk". The prose for "phone-number" specifies E.164 format, but the OpenAPI description does not. "carddav" is triply inconsistent: the prose says username, password, and domain name are separated by "@" (presumably, in a single string), but the example only shows username and domain name in user@domain form, and the OpenAPI description says it should be an object with separate properties for username/password/domain, as well as an additional "sendLocationWithRegistration" property that is probably not supposed to be a child of "carddav". (repeating from the previous), the "sendLocationWithRegistration" property is listed as belonging to the "carddav" object in the OpenAPI description, though the prose and example indicate it should be a property of the toplevel configuration object. The prose and OpenAPI description indicate that "ice-servers" is an array of strings, but the example has an array of objects that use the dictionary key to indicate whether each URI is a TURN or STUN server. |
2021-12-15
|
09 | Benjamin Kaduk | [Ballot comment] There are a number of references to "the configuration" in the body text prior to §9.2 where the configuration service is discussed. E.g., … [Ballot comment] There are a number of references to "the configuration" in the body text prior to §9.2 where the configuration service is discussed. E.g., the first paragraph of §5.1 gives a hard requirement for registration and then makes a conditional reference to "the configuration" without any prose discussing how configuration retrieval interacts with registration. it may be useful to have a brief introductory mention of the data flow involving registration and configuration retrieval and how the two initialization processes (don't) interact. I have a high-level comment or two about password usage in this document. I recognize that we're constrained in practice by the current state of SIP specification and the deployed ecosystem, but while username/password may currently be the lowest common denominator for authentication, it's far from best current practice. In a scenario like the one here, where the RUE is a dedicated (often hardware) product talking over a fixed protocol to a nearly fixed small set of providers, there's plenty of scope for using strong cryptography to authenticate the RUE, including public-key cryptography where the verifier does not need to store any per-user secret information. At present, Digest seems to be the strongest mechanism in the registry for usage with SIP, but I would advise assuming that that will change in the future and writing the spec and implementation in a way that is compatible with stronger authentication schemes. Furthermore, this document in several places (I note a few in the per-secton comments) recommends or even requires the reuse of a username/password pair across multiple services. Best practices are to use any given password at exactly one service. In this regard one can roughly model the password as analogous to a pre-shared key -- it is useful for authenticating a peer in the sense that if the value is known only to two entities, and the party you're communicating with proves that they know the value, they must be the only other party that knows the secret value. But once you reuse the password at multiple services, that logic falls apart, as the party you're communicating with could be the user, or it could be another service that shares the secret. Granted, when used with digest the password itself is not sent to the server for every authentication, but the server typically has access to it at some point, and even possession of the password hash in a verification database allows for offline brute-force attack, which has become comparatively cheap in recent years and even the availability of dedicated hardware for password cracking. In particular, SHA-512 is not considered to be a best-practice hash function for password hashing, since it is highly parallelizable and not "memory-hard". RFC 9106 specifies Argon2 (via the IRTF CFRG), the winner of the password hashing competition; it is the state of the art for password hashing, and even prior to that publication we had scrypt available in RFC 7914 that is a significant improvement on the SHA-2 family of functions. That said, it's not currently listed in the IANA registry for hash algorithms for HTTP (and SIP) digest authentication, so I am not sure that we can usefully advocate for its usage at the present time. Section 4 Thanks for mandating RFC 7525 compliance. I note that draft-ietf-uta-rfc7525bis is in progress in the UTA WG. Though it will probably be published after this document, it may be a useful informative reference with forward-looking guidance on how to best secure TLS. All text data payloads not otherwise constrained by a specification in another standards document MUST be encoded as Unicode UTF-8. I think we'd typically reference RFC 8259 here. Section 5.1 The registrar MAY authenticate using SIP digest authentication. The credentials to be used (username and password) MUST be supplied within the credentials section of the configuration and identified by the realm the registrar uses in a digest challenge. This username/ Which entity is authenticating to which other entity here? The phrasing " MAY authenticate" implies that it is X that is authenticating to some other entity, but that does not seem to correspond to my model of the flow here, where the RUE is authenticating to the registrar. If the flow is to be the other way, we would say "the registrar MAY authenticate the RUE using SIP digest authentication". Also, I note that (HTTP) SCRAM authentication has superior security properties to Digest, but unfortunately I don't see any evidence that its use for SIP is defined yet. Section 5.2.1 The SIP URIs in the To field and the Request-URI MUST be formatted as specified in subsection Section 5.4 using the destination phone number, or as SIP URIs, as provided in the configuration (Section 9.2). [...] I'm not sure that I'm unpacking this properly. (The construction "the SIP URIs MUST be formatted as [...], or as SIP URIs", makes me wonder if there are somehow non-SIP URIs involved even though we start off with "the SIP URIs".) Is the idea that I either take the URI directly from the configuration ("as-is") or I format it as per §5.4 but not anything else? Section 5.2.2 party telephone number. In two-stage dial-around, the To URI is the front door URI (see Section 9.2) of the dial-around provider and the domain of the URI is the provider domain from the configuration. The Is "the URI" in "the domain of the URI" referring to "the To URI", or some other URI (the Request-URI, perhaps)? The prose lists the call originator as (VRS user) +1-555-222-0001, but the URIs in Figure 1 that are not the call recipient appear as +18135551212; are those numbers supposed to be different like that? Section 5.2.3 owner". The URI MAY be an HTTPS URI or Content-Indirect URL. The latter is defined by [RFC2392] to locate message body parts. This RFC 2392 seems to define a "Content-ID" URI (with "cid" scheme) but not a "Content-Indirect" URL. Section 5.2.5 Implementations MUST implement Additional Data, [RFC7852]. RUE devices MUST implement Data Provider, Device Implementation and Owner/Subscriber Information blocks. The string "Device Implementation" does not seem to appear in RFC 7852, though "Device Information" does. Section 7.1 of an email address. If the request triggers a challenge for digest authentication credentials, the RUE MUST continue using matching "credentials" from the configuration. If no matching credentials are configured, the RUE MUST use the SIP credentials from the configuration. [...] Do we really want a MUST-level requirement to reuse the SIP credentials? Best practices for credentials are to have a 1:1 relationship between credentials and where they are used and this sort of reuse is basically the polar opposite. Section 9.1 non-mandatory-to use functions and SHALL NOT delete any objects, members of objects or functions. This means an implementation of a specific major version and minor version is backwards compatible with all minor versions of the major version. [...] (This might all be covered by Rob's discuss point; I will read the replies on that thread and you don't need to duplicate content here for my benefit.) This statement doesn't seem to contain enough information to be useful. I think that a statement about backwards (or forwards) compatibility should be specific about whether it applies to the implementation of the client or the web service, and that backwards compatibility would require that the implementation in question interoperate with a peer at any same or previous minor version. Just saying "compatible with all minor versions of the major version" would also make a statement about forward compatibility, which I think is allowable under these rules for what is allowed to change in minor versions, and it would be useful to make a statement about forward compatibility. Section 9.2 The interface to obtain configuration data is described by an OpenAPI [OpenAPI] interface description. In that interface description, the "servers" component is specified as "localhost". The entry point obtained from the provider list (Section 9.1) is substituted for "localhost" to obtain the server prefix of the interface. [...] I note that the OpenAPI description for /Versions has an override for "servers", and the value listed there does not include the string "localhost". Some clarity that it is also expected to be affected by this kind of substitution seems in order. In both the queries, an optional parameter may be provided to the interface which is an API Key. The implementation MAY have an API Key obtained from the provider and specific to the implementation. The method the API Key is obtained is not specified in this document. The provider MAY refuse to provide service to an implementation presenting an API Key it does not recognize. I note that the IETF does have a standard for conveying authorization information on the web -- OAuth 2.0. It may not be a direct "drop-in" fit here, due to the need for a preexisting relationship with an authorization server, but perhaps it is worth mentioning as an option in addition to this provider-specific "API key" protocol? Also in both queries, the RUE device provides a required parameter which contains an instance identifier. This parameter MUST be the same value each time this instance (same implementation on same device) queries the interface. This MAY be used by the provider, for example, to associate a location with the instance for emergency calls. Is there any cryptography to provide assurance that the instance identifier is indeed always used only by the one single instance? The description here sounds roughly like a bearer token, which is far from best practice for this sort of thing. Indeed, in other contexts a given instance is often identified solely by its public key, and must authenticate with the corresponding private key in order to act as the identified instance. The configuration API also provides the same version mechanism as specified above in Section 9.1. The version of the configuration service MAY be different than the version of the provider list service. Not only that, but the services are expected to be versioned independently, so there is no particular relationship between version X.Y of the one and version X.Y of the other...right? Actually, having gone and looked further, the OpenAPI document seems to indicate that there's a single /Versions resource common across the /Providers, /ProviderConfig, and /RueConfig APIs, which makes me confused as to how the versions of the two services might actually be different (let alone versioned independently). Section 9.2.1 - uri: a URI to the website for creating a new account in the supported language. The new user signup URI may only initiate creation of a new account. Various vetting, approval and other processes may be needed, which could take time, before the account is established. The result of creating a new account would be a username and password, which would be manually I strongly suggest using a more generic phrasing (e.g., "would be account credentials (e.g., username and password)") to allow for seamless transition to stronger authentication technologies without specification change. Section 9.2.2 * lifetime: (optional) Specifies how long (in seconds) the RUE MAY cache the configuration values. Values may not be valid when lifetime expires. If the RUE caches configuration values, it MUST cryptographically protect them. [...] In other contexts, "cryptographically protect" would mean to encrypt, cryptographically sign, or compute a keyed MAC over the data. If the intent here is just to record a cryptographic checksum of the data, that's probably better stated in terms of a checksum. In particular, this current text gives no indication of what threat the cryptography is supposed to protect against, so implementations are unlikely actually provide uniform protection against the intended threat. * sip-password: (optional) a password used for SIP, STUN and TURN authentication. The RUE device retains this data, which must be stored securely. [...] Akin to the above, this doesn't indicate what threat "stored securely" is intended to protect against. While I would *hope* that "protect passwords" is instinctive to developers, I wouldn't want to rely on it. password MUST be used. If it was never supplied, the password used to authenticate to the configuration service is used for SIP, STUN and TURN. In the general case, this directive is a gaping security hole (exposing the RUE's SIP credentials to arbitrary external STUN/TURN servers, for example). I think we must qualify that the reuse of credentials is only for the servers listed in the "ice-servers" configuration directive. (And ideally we would not encourage reuse of credentials at all.) * carddav: (optional) A username, password and domain name (separated by ""@"") identifying a "CardDAV" server and account that can be used to synchronize the RUE's contact list with the contact list managed by the provider. If username or password are not supplied, the main account credentials are used. There are three data items but only one separator listed. Is this really to be "username@password@domain"? It would be great if we could make ourselves more generic than username+password as credentials, and (as mentioned previously) avoid reuse of credentials. * ice-servers: (optional) An array of URLs identifying STUN and TURN servers available for use by the RUE for establishing media streams in calls via the provider. Is any given entry required to offer both STUN and TURN services, or can a server provide just one or the other? Both this text and my understanding of the OpenAPI description seem to indicate that this is a flat list intermingling STUN and TURN servers, but the example in Figure 5 seems to show each element of the array being a JSON object that contains one or more of the keys "stun" and "turn". The structure in that example would obviate any confusion about which services are offered, and is probably preferred. Section 9.2.3 "contacts": "https://red.example.net:443/contacts/1dess45awd", I suggest putting a bit more entropy in the URL, in the vein of https://www.w3.org/2001/tag/doc/capability-urls/ (even if this resource is likely to require the username+password authentication discussed earlier). "carddav": "bob@red.example.com" , The prose indicates this should contain a password as well as the username and domain name that are present. How is the password specified? Section 9.3 Given the "are formally specified" language, I expect that the intent is for the OpenAPI description to be normative and take precedence in case of conflict with the prose/examples. It's probably worth stating that explicitly. - in: query name: instanceId schema: type: string required: true description: Unique string for this implementation on this device Is this self-assigned by the client or assigned by some external authority? The allocation procedure is important for ensuring that the instance IDs are actually globally unique (with high probability). (Note that this parameter is used in both /ProviderConfig and /RueConfig.) Section 10.2 The rest of the document does not appear to contain any text covering the usage of the "rue-owner" purpose value. Should we say something about when it's used and what semantics it conveys? Section 11 I think we should make some statement that incorporates by reference the security considerations of the protocols being profiled. There are perhaps too many to list individually, so something like "this document requires implementation and use of a number of other specifications in order to fulfil the RUE profile; the security considerations described in those documents apply accordingly to the RUE interactions" would probably work. It is perhaps obvious, but when a CA participates in a conversation they have access to the content of the conversation even though it is nominally a conversation between the two endpoints. I think we should still state this explicitly, and perhaps note that there is an expectation that the CA will keep the communication contents in confidence, often backed by contractual or legal requirements. There's probably also something useful to say to compare the privacy properties of one-stage vs two-stage dial-around, in terms of which entities have access to information about the communicating endpoints. I am not entirely sure if the referenced documents already cover this, but having the provider maintain the user's contacts database means that there is increased risk surface for unauthorized disclosure of that information (compared to it being maintained locally). Since different providers (within a given country) may have different policies, we might want to caution RUE implementations to have a user interaction step before proceeding to actually register with any given provider. NITS No need to reply to any of these; if you disagree, that's fine. Section 5.2.1 Negotiated media MUST follow the guidelines specified in Section 6 of this document. If they MUST be followed, are they really guidelines, or requirements? Section 5.2.3 To identify the owner of a RUE, the initial INVITE for a call from a RUE, or the 200 OK accepting a call by a RUE, identifies the owner by I think s/the 200 OK accepting a call by a RUE/the 200 OK a RUE uses to accept a call/ would avoid ambiguity about whether this binds as (accepting a (call by a RUE)) vs ((accepting [of] a call) by a RUE). Section 9.1 provider names for a country code suitable for display, with a corresponding a entry point to obtain information about that provider. s/corresponding a/corresponding/ Section 9.2 HTTPs web service. There are two entry points. One is used without user credentials or parameters, the response includes configuration data for new user sign up and dial around. The other uses the Comma splice. Section 9.2.2 * videomail: (optional) An SIP or HTTPS URI that can be called to retrieve video mail messages. Can an HTTPS URI really "be called"? (This text also appears in §9.3.) |
2021-12-15
|
09 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2021-12-15
|
09 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2021-12-15
|
09 | Robert Wilton | [Ballot discuss] There are a couple of points related to versioning that I would like to see clarified, but I hope that it should be … [Ballot discuss] There are a couple of points related to versioning that I would like to see clarified, but I hope that it should be fairly easy to do so. 1. This means an implementation of a specific major version and minor version is backwards compatible with all minor versions of the major version. Is it actually compatible with all other minor versions, or only other minor versions with a greater minor version number. E.g., could an implementation be coded to use/expect a object added in a minor version but that is not present in preceding minor versions? 2. The configuration API also provides the same version mechanism as specified above in Section 9.1. The version of the configuration service MAY be different than the version of the provider list service. It wasn't obvious to me, that for a given provider, how this is communicated. I'm not that familiar with OpenAPI, but looks like the /Versions path is a top level API path, and the data that is contains seems to just be version numbers. Hence, how would a client know which versions apply to provider list service and/or which versions apply to the provide configuration service. |
2021-12-15
|
09 | Robert Wilton | [Ballot comment] Hi Brian, Thank you for working on this. This technology is quite a long way outside of my expertise, and hence my review … [Ballot comment] Hi Brian, Thank you for working on this. This technology is quite a long way outside of my expertise, and hence my review is primarily focused on the Configuration section (section 9). Nit: when used with the following interface => when used with the following OpenAPI interface Nit: with a corresponding a entry point -> with a corresponding entry point Minor version definitions SHALL only add objects, non-required members of existing objects, and non-mandatory-to use functions and SHALL NOT delete any objects, members of objects or functions. Would "delete or change" be more correct than just "delete" here? Somewhat related to the discuss comment, but it wasn't clear to me why the versioning is described as part of the "Rue Provider Selection" section and I think that the document would arguably be clearer if the versioning moved to its own separate 9.X section, making it clear that the versioning applies to the entire API? Nit: The method the API Key is obtained is not specified in this document. => Perhaps "The method used to obtain the API key ..." The provider MAY refuse to provide service to an implementation presenting an API Key it does not recognize. Why is this not a MUST? Is the "instance-identifier" arbitrarily chosen by the client? Otherwise, it wasn't clear to me how a client would discover or know what "instance-identifier" to use. It might be helpful if the text clarified this, and possibly even the parameter name could be changed to make it more obvious that it is a client provided value? Regards, Rob |
2021-12-15
|
09 | Robert Wilton | [Ballot Position Update] New position, Discuss, has been recorded for Robert Wilton |
2021-12-15
|
09 | Éric Vyncke | Request closed, assignment withdrawn: Suzanne Woolf Telechat INTDIR review |
2021-12-15
|
09 | Éric Vyncke | Closed request for Telechat review by INTDIR with state 'Withdrawn': The document is on the IESG telechat in 1 day (deadline was yesterday). No need … Closed request for Telechat review by INTDIR with state 'Withdrawn': The document is on the IESG telechat in 1 day (deadline was yesterday). No need anymore for a review (still welcome by the authors probably). |
2021-12-14
|
09 | Zaheduzzaman Sarker | [Ballot discuss] First of all thanks for working on this technology to make communication available and easy for special human beings. (I have worked with … [Ballot discuss] First of all thanks for working on this technology to make communication available and easy for special human beings. (I have worked with them to converter text to sign language in my bachelor hence had a special feeling while reading this specification). I understood from the email discussions on the TSVART review (https://mailarchive.ietf.org/arch/msg/tsv-art/Z_Ne5au4rCHwcig8bospMcLyzTc/) that in the system RUI is deployed, we will have gateway(s) with two legs - one with WebRTC (client <--> gateway) and one with RUI client communicating with RUI server (gateway <--> server). With this understanding I have some points which I believe worth discussing. - WebRTC communication will be congestion and rate controlled. This will use RTCP feedbacks to make the rate control and congestion control happen in the WebRTC peers. On the WebRTC part of the leg, this RTCP feedbacks will be available according to the WebRTC specification. However, this specification does not discuss how those RTCP feedback will be converted from the RUI server to RUI client (i.e the gateway) direction and vice versa. This will require the gateway to have such conversion functions to actually work. what is the thinking here? has this been considered? as I am not sure how is the network looks like between the RUI client and RUI server, there might be the Internet connecting them hence need to have congestion controlled traffic. - Thanks to Bernard Aboba for a comprehensive TSVART review of this draft and I would like to bring some issues, identified in that review, here to make sure they are addressed- * clarification on the use of ICE * clarification on what is a WebRTC client, WebRTC server, gateway, RUI client and RUI server. I believe all four have been conceptually used in the specification without concretely defining their roles. for example - if server is mentioned it need to be distinguishable if it is WebRTC server or RUI server ( I noted that there are servers in this specification which are clearly understandable). |
2021-12-14
|
09 | Zaheduzzaman Sarker | [Ballot Position Update] New position, Discuss, has been recorded for Zaheduzzaman Sarker |
2021-12-10
|
09 | Erik Kline | [Ballot comment] [S5; nit] * Both RFCs 6655 and 6665 are mentioned. I think the 6655 reference should actually be to 6665 (unless "AES-CCM … [Ballot comment] [S5; nit] * Both RFCs 6655 and 6665 are mentioned. I think the 6655 reference should actually be to 6665 (unless "AES-CCM Cipher Suites for TLS" is of specific importance). [S6; nit] * W.R.T.: "Mandatory to Implement" means a conforming implementation must implement the specified capability. It seems like, since 8174 is in use, this "must" might be a "MUST", to avoid any ambiguity. |
2021-12-10
|
09 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Tina Dang | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-10
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-12-07
|
09 | Martin Duke | [Ballot discuss] Thanks to Bernard Adoba for the TSVART review. It largely informs my DISCUSS. 1. If I understand correctly, this draft is not at … [Ballot discuss] Thanks to Bernard Adoba for the TSVART review. It largely informs my DISCUSS. 1. If I understand correctly, this draft is not at all about interoperating with a WebRTC endpoint, instead borrowing some requirements from that family of specs rather than re-inventing the wheel. That's great, but putting that explicitly in the intro would be helpful. 2. In particular, the statement that RUE is a "non-browser endpoint" is confusing if it's not actually meant to interoperate with WebRTC. I *think* you're attempting to distinguish between WebRTC's browser-only requirements and endpoint requirements, but I could be wrong here. 3. In Section 5.5, you require conformance with RFC8835 with a few vaguely worded exceptions. It would be helpful to actually go through that document enumerate exactly which normative statements in 8835 do not apply. That said, I'm not sure I agree with Bernard that 8835 requires *use* of ICE, rather than support, but maybe we can clarify this in the TSVART thread. 4. As Bernard points out, this ambiguity extends to IPv4 and 6 support. The 8835 requirements are specific to browsers, so they might not apply. If you require support for both, but not necessarily on the same device, it would be good to say so. 5. In Sec. 6, it says "This specification adopts the media specifications for WebRTC ([RFC8825])." Is this a normative statement? Must RUEs comply with the entirety of that document, or is this an informative statement and the real requirements are in the subsections of Sec 6? From the discussion, it sounds like you want to include the requirements for WebRTC "endpoints", but not for WebRTC "browsers". It would help to clarify all this. It's also possible that my initial understanding is incorrect, in which case the later points don't make any sense and some explanatory text is needed. |
2021-12-07
|
09 | Martin Duke | [Ballot comment] Thanks for your work to make the internet more accessible for all. |
2021-12-07
|
09 | Martin Duke | [Ballot Position Update] New position, Discuss, has been recorded for Martin Duke |
2021-12-03
|
09 | Carlos Jesús Bernardos | Request for Telechat review by INTDIR is assigned to Suzanne Woolf |
2021-12-03
|
09 | Carlos Jesús Bernardos | Request for Telechat review by INTDIR is assigned to Suzanne Woolf |
2021-12-01
|
09 | Éric Vyncke | Requested Telechat review by INTDIR |
2021-11-29
|
09 | Bernard Aboba | Request for Telechat review by TSVART Completed: Ready with Issues. Reviewer: Bernard Aboba. Sent review to list. |
2021-11-29
|
09 | Magnus Westerlund | Request for Telechat review by TSVART is assigned to Bernard Aboba |
2021-11-29
|
09 | Magnus Westerlund | Request for Telechat review by TSVART is assigned to Bernard Aboba |
2021-11-19
|
09 | Cindy Morgan | Placed on agenda for telechat - 2021-12-16 |
2021-11-18
|
09 | Murray Kucherawy | Ballot has been issued |
2021-11-18
|
09 | Murray Kucherawy | [Ballot Position Update] New position, Yes, has been recorded for Murray Kucherawy |
2021-11-18
|
09 | Murray Kucherawy | Created "Approve" ballot |
2021-11-18
|
09 | Murray Kucherawy | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2021-11-18
|
09 | Murray Kucherawy | Ballot writeup was changed |
2021-11-11
|
09 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Russ Mundy. Submission of review completed at an earlier date. |
2021-11-10
|
09 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Russ Mundy. |
2021-11-10
|
09 | Rich Salz | Request for Last Call review by ARTART Completed: Ready. Reviewer: Rich Salz. Sent review to list. |
2021-11-08
|
09 | Murray Kucherawy | Awaiting ARTART review, and possibly reviews from other directorates. |
2021-11-08
|
09 | Murray Kucherawy | IESG state changed to Waiting for AD Go-Ahead::AD Followup from Waiting for Writeup |
2021-11-08
|
09 | Matt Joras | Request for Last Call review by GENART Completed: Ready. Reviewer: Matt Joras. Sent review to list. |
2021-11-08
|
09 | Barry Leiba | Request for Last Call review by ARTART is assigned to Rich Salz |
2021-11-08
|
09 | Barry Leiba | Request for Last Call review by ARTART is assigned to Rich Salz |
2021-11-08
|
09 | Jaime Jimenez | Assignment of request for Last Call review by ARTART to Jaime Jimenez was rejected |
2021-10-27
|
09 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2021-10-26
|
09 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2021-10-23
|
09 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'Withdrawn' |
2021-10-23
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Russ Mundy |
2021-10-23
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Russ Mundy |
2021-10-21
|
09 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2021-10-21
|
09 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-rum-rue-09. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-rum-rue-09. If any part of this review is inaccurate, please let us know. The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete. First, a new registry is to be created called the "RUE Provider List" registry. IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If it needs a new page, does it also need a new category at http://www.iana.org/protocols (and if so, should the page and the category have the same name)? The new registry is to be managed via Expert Review as defined in RFC 8126. IANA understands that there are no initial registrations in the new registry. Second, in the Header Field Parameters and Parameter Values on the Session Initiation Protocol (SIP) Parameters registry page located at: https://www.iana.org/assignments/sip-parameters/ this draft will be added to the references for the following, existing registration: Header Field: Call-Info Parameter Name: purpose Predefined Values: Yes Reference: [RFC3261][RFC5367][RFC6910][RFC6993][RFC7082][RFC7852][RFC8688][ RFC-to-be ] The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Lead IANA Services Specialist |
2021-10-21
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jouni Korhonen |
2021-10-21
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jouni Korhonen |
2021-10-19
|
09 | Adam Montville | Assignment of request for Last Call review by SECDIR to Adam Montville was rejected |
2021-10-18
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Adam Montville |
2021-10-18
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Adam Montville |
2021-10-14
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Matt Joras |
2021-10-14
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Matt Joras |
2021-10-12
|
09 | Paul Kyzivat | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This review is written … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This review is written against draft-ietf-rum-rue-09 on 12-oct-2021. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Video Relay Service (VRS) is a term used to describe a method by which a hearing person can communicate with a deaf, hard of hearing or hearing impaired user using an interpreter ("Communications Assistant") connected via a videophone to the deaf/HoH user and an audio telephone call to the hearing user. The CA interprets using sign language on the videophone link and voice on the telephone link. Often the interpreters may be employed by a company or agency termed a "provider" in this document. The provider also provides a video service that allows users to connect video devices to their service, and subsequently to CAs and other deaf/HoH users. It is desirable that the videophones used by the deaf, hard of hearing or hearing impaired user conform to a standard so that any device may be used with any provider and that direct video calls between deaf, hard of hearing or hearing impaired users work. This document describes the interface between a videophone and a provider. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There was not a lot of energy in the group to move the work along. Notably, the representatives of VRS providers were reluctant to contribute and mostly offered objections. Reaching consensus under these conditions was challenging and often consensus was quite rough. Document Quality: Are there existing implementations of the protocol? There is a partial implementation by Mitre. This is intended as a verification and test vehicle. They have committed to creating a full implementation when the document becomes an RFC. Have a significant number of vendors indicated their plan to implement the specification? No. But the most likely vendors are the VRS providers. They do what they are required to do by the FCC. It is expected that the FCC will mandate this and then they will implement it. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? No. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Shepherd: Paul Kyzivat AD: Murray Kucherawy (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The shepherd has actively reviewed and provided feedback and suggestions on every version of this document, and verified all the formal language-based content, and reviewed the results of IdNits. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. The normal security review will be important for this document and the shepherd will make sure the conclusions of that review are attended to carefully by the author and the working group. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The market in which implementations of this document will primarily be deployed is unusual. The server side is controlled by a small set of VRS providers that are funded by the FCC and governed by rules issued by the FCC. The deployment of this standard will presumably be driven by new FCC requirements referencing it. The subject area covered by this document has heretofore been addressed with proprietary devices and/or software. The motivation for this work comes from outside the VRS provider community, while most people with experience building RUE-like devices work for the VRS providers. There are compromises made with the VRS providers that have shaped the document in ways that is somewhat different from how it would have come out without their participation, yet the participation of these providers is deemed essential, and their co-operation is sincerely appreciated. On the other hand, the rough consensus process has indeed overcome objections of all the participating providers, and they are not happy with certain aspects of the document. The shepherd is satisfied that the IETF processes on determining consensus were fairly applied, and the document represents a reasonable compromise between the providers as a whole and the rest of the work group. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Many IPR disclosures have been filed repeatedly against every new draft version of this document by one of the VRS providers. Based on a superficial examination, these seem to cover primarily features that impact downstream actions within the VRS provider and not the functionality addressed by this document. (Disclaimer, this is not a legal analysis.) Participants have been afforded opportunities to suggest any changes in the document that may further avoid the IPR claimed in the patents, and no suggestions have been made. Given the market in which this will be applied the current participants (all the VRS providers) clearly have already come to grips with the IPR environment. It is possible that an outsider who wants to create and sell a compatible RUE device might need to address some IPR issues. It isn't clear that there is any such candidate among the current participants of the work group. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The consensus is reluctant. Many of the participants represent the interests of the VRS providers, and seemingly would prefer there be no such standard. (Presumably they assume they will be compelled by the FCC to support it.) However, despite repeated requests, their objections have not been accompanied by contribution of constructive alternatives. The rest of the reviews and opinions come from more experienced IETF participants and they have generally been solidly in favor of the document as it now is constituted. In a few cases, some compromise has been achieved, where the more experienced IETFers would have preferred somewhat different text, but were persuaded the the compromise text was acceptable. Similarly, there are a few instances where the providers were initially against requirements deemed essential by our more experienced IETF participants, they offered some suggested additional requirements that the IETFers did not think were necessary, and they were accepted. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? No. If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. IdNits reports some errors and warnings that are bogus: * 3 instances of lines with non-ascii characters. These all appear in reference citations where they are now permitted. One of these is also reported as a line too long, due solely to the non-ascii character being counted as multiple bytes. * 2 warnings for "looks like a reference" for use of [1] and [2] in examples. In addition three downrefs are reported, referencing RFC2818, RFC3960 and RFC5168. These are discussed in (15) below. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The shepherd verified the json using the tool jsonlint , and the OpenAPI 3.1 descriptions of the interfaces using . (13) Have all references within this document been identified as either normative or informative? YES (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? NO (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. There are three downrefs, referencing RFC2818, RFC3960 and RFC5168. RFC2818 is an informational RFC that describes how to use TLS to secure HTTP connections. The RUE document defines web interfaces that run securely over HTTPS and TLS. Doing so requires following the guidance in RFC2818. Hence we made this a normative reference. RFC3960 is an informational RFC that describes how SIP entities handle early media. Early media is media that happens before a call is answered, which may be tones and announcements but also could be from an IVR system that doesn’t signal answer until a live agent answers the call. It’s the case that virtually every implementation has to do what RFC3960 says because otherwise things don’t work, yet the text has no normative RFC119 language. Hence we made this a normative reference. RFC5168 documents an older way to request full frame refresh on a video stream that many older devices still use. To connect to them it is necessary to do what RFC5168 says. We want that backward compatibility, so we required it. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. NO (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). The definition of the new RUE Provider List registry is properly specified. The update to the SIP Call-Info header field purpose is in good order. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. The new RUE Provider List needs an expert. This is a per-country registry. The expert should ideally be comfortable working with this sort of regulatory environment. The document editor, Brian Rosen, will volunteer to be the expert and there are other candidates who could be considered (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. The shepherd verified the json using the tool jsonlint , and the OpenAPI 3.1 descriptions of the interfaces using . (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? N/A |
2021-10-12
|
09 | Paul Kyzivat | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Video Relay Service (VRS) is a term used to describe a method by which a hearing persons can communicate with deaf/Hard of Hearing user using an interpreter ("Communications Assistant") connected via a videophone to the deaf/HoH user and an audio telephone call to the hearing user. The CA interprets using sign language on the videophone link and voice on the telephone link. Often the interpreters may be supplied by a company or agency termed a "provider" in this document. The provider also provides a video service that allows users to connect video devices to their service, and subsequently to CAs and other deaf/HoH users. It is desirable that the videophones used by the deaf/HoH/H-I user conform to a standard so that any device may be used with any provider and that video calls direct between deaf/HoH users work. This document specifies the interface between a videophone and a provider. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There was not a lot of energy in the group to move the work along. Notably, the representatives of VRS providers were reluctant to contribute and mostly offered objections. Reaching consensus under these conditions was challenging and often consensus was quite rough. Document Quality: Are there existing implementations of the protocol? There is a partial implementation by Mitre. This is intended as a verification and test vehicle. They have committed to creating a full implementation when the document becomes an RFC. Have a significant number of vendors indicated their plan to implement the specification? No. But the most likely vendors are the VRS providers. They do what they are required to do by the FCC. It is expected that the FCC will mandate this and then they will implement it. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? No. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Shepherd: Paul Kyzivat AD: Murray Kucherawy (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The shepherd has actively reviewed and provided feedback and suggestions on every version of this document, and verified all the formal language-based content, and reviewed the results of IdNits. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. The normal security review will be important for this document and the shepherd will make sure the conclusions of that review are attended to carefully by the author and the working group. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The market in which implementations of this document will primarily be deployed is unusual. The server side is controlled by a small set of VRS providers that are funded by the FCC and governed by rules issued by the FCC. The deployment of this standard will presumably be driven by new FCC requirements referencing it. The subject area covered by this document has heretofore been addressed with proprietary devices and/or software. The motivation for this work comes from outside the VRS provider community, while most people with experience building RUE-like devices work for the VRS providers. There are compromises made with the VRS providers that have shaped the document in ways that is somewhat different from how it would have come out without their participation, yet the participation of these providers is deemed essential, and their co-operation is sincerely appreciated. On the other hand, the rough consensus process has indeed overcome objections of all the participating providers, and they are not happy with certain aspects of the document. The shepherd is satisfied that the IETF processes on determining consensus were fairly applied, and the document represents a reasonable compromise between the providers as a whole and the rest of the work group. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Many IPR disclosures have been filed repeatedly against every new draft version of this document by one of the VRS providers. Based on a superficial examination, these seem to cover primarily features that impact downstream actions within the VRS provider and not the functionality addressed by this document. (Disclaimer, this is not a legal analysis.) Participants have been afforded opportunities to suggest any changes in the document that may further avoid the IPR claimed in the patents, and no suggestions have been made. Given the market in which this will be applied the current participants (all the VRS providers) clearly have already come to grips with the IPR environment. It is possible that an outsider who wants to create and sell a compatible RUE device might need to address some IPR issues. It isn't clear that there is any such candidate among the current participants of the work group. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The consensus is reluctant. Many of the participants represent the interests of the VRS providers, and seemingly would prefer there be no such standard. (Presumably they assume they will be compelled by the FCC to support it.) However, despite repeated requests, their objections have not been accompanied by contribution of constructive alternatives. The rest of the reviews and opinions come from more experienced IETF participants and they have generally been solidly in favor of the document as it now is constituted. In a few cases, some compromise has been achieved, where the more experienced IETFers would have preferred somewhat different text, but were persuaded the the compromise text was acceptable. Similarly, there are a few instances where the providers were initially against requirements deemed essential by our more experienced IETF participants, they offered some suggested additional requirements that the IETFers did not think were necessary, and they were accepted. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? No. If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. IdNits reports some errors and warnings that are bogus: * 3 instances of lines with non-ascii characters. These all appear in reference citations where they are now permitted. One of these is also reported as a line too long, due solely to the non-ascii character being counted as multiple bytes. * 2 warnings for "looks like a reference" for use of [1] and [2] in examples. In addition two downrefs are reported, referencing RFC3960 and RFC5168. These are discussed in (15) below. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The shepherd verified the json using the tool jsonlint , and the OpenAPI 3.1 descriptions of the interfaces using . (13) Have all references within this document been identified as either normative or informative? YES (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? NO (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. There are two downrefs, referencing RFC3960 and RFC5168. RFC3960 is an informational RFC that describes how SIP entities handle early media. Early media is media that happens before a call is answered, which may be tones and announcements but also could be from an IVR system that doesn’t signal answer until a live agent answers the call. It’s the case that virtually every implementation has to do what RFC3960 says because otherwise things don’t work, yet the text has no normative RFC119 language. Hence we made this a normative reference. RFC5168 documents an older way to request full frame refresh on a video stream that many older devices still use. To connect to them it is necessary to do what RFC5168 says. We want that backward compatibility, so we required it. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. NO (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). The update to the SIP Call-Info header field purpose is in good order. * The IANA Considerations for the new RUE Provider List registry call for a URI, while the text calls for a domain name. The author has been informed and has committed to updating this in the next version to specify a URI in the IANA Considerations. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. The new RUE Provider List needs an expert. This is a per-country registry. The expert should ideally be comfortable working with this sort of regulatory environment. The document editor, Brian Rosen, will volunteer to be the expert and there are other candidates who could be considered (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. The shepherd verified the json using the tool jsonlint , and the OpenAPI 3.1 descriptions of the interfaces using . (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? N/A |
2021-10-12
|
09 | Paul Kyzivat | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This review is written … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This review is written against draft-ietf-rum-rue-09 on 12-oct-2021. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Video Relay Service (VRS) is a term used to describe a method by which a hearing person can communicate with a deaf, hard of hearing or hearing impaired user using an interpreter ("Communications Assistant") connected via a videophone to the deaf/HoH user and an audio telephone call to the hearing user. The CA interprets using sign language on the videophone link and voice on the telephone link. Often the interpreters may be employed by a company or agency termed a "provider" in this document. The provider also provides a video service that allows users to connect video devices to their service, and subsequently to CAs and other deaf/HoH users. It is desirable that the videophones used by the deaf, hard of hearing or hearing impaired user conform to a standard so that any device may be used with any provider and that direct video calls between deaf, hard of hearing or hearing impaired users work. This document describes the interface between a videophone and a provider. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There was not a lot of energy in the group to move the work along. Notably, the representatives of VRS providers were reluctant to contribute and mostly offered objections. Reaching consensus under these conditions was challenging and often consensus was quite rough. Document Quality: Are there existing implementations of the protocol? There is a partial implementation by Mitre. This is intended as a verification and test vehicle. They have committed to creating a full implementation when the document becomes an RFC. Have a significant number of vendors indicated their plan to implement the specification? No. But the most likely vendors are the VRS providers. They do what they are required to do by the FCC. It is expected that the FCC will mandate this and then they will implement it. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? No. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Shepherd: Paul Kyzivat AD: Murray Kucherawy (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The shepherd has actively reviewed and provided feedback and suggestions on every version of this document, and verified all the formal language-based content, and reviewed the results of IdNits. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. The normal security review will be important for this document and the shepherd will make sure the conclusions of that review are attended to carefully by the author and the working group. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The market in which implementations of this document will primarily be deployed is unusual. The server side is controlled by a small set of VRS providers that are funded by the FCC and governed by rules issued by the FCC. The deployment of this standard will presumably be driven by new FCC requirements referencing it. The subject area covered by this document has heretofore been addressed with proprietary devices and/or software. The motivation for this work comes from outside the VRS provider community, while most people with experience building RUE-like devices work for the VRS providers. There are compromises made with the VRS providers that have shaped the document in ways that is somewhat different from how it would have come out without their participation, yet the participation of these providers is deemed essential, and their co-operation is sincerely appreciated. On the other hand, the rough consensus process has indeed overcome objections of all the participating providers, and they are not happy with certain aspects of the document. The shepherd is satisfied that the IETF processes on determining consensus were fairly applied, and the document represents a reasonable compromise between the providers as a whole and the rest of the work group. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Many IPR disclosures have been filed repeatedly against every new draft version of this document by one of the VRS providers. Based on a superficial examination, these seem to cover primarily features that impact downstream actions within the VRS provider and not the functionality addressed by this document. (Disclaimer, this is not a legal analysis.) Participants have been afforded opportunities to suggest any changes in the document that may further avoid the IPR claimed in the patents, and no suggestions have been made. Given the market in which this will be applied the current participants (all the VRS providers) clearly have already come to grips with the IPR environment. It is possible that an outsider who wants to create and sell a compatible RUE device might need to address some IPR issues. It isn't clear that there is any such candidate among the current participants of the work group. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The consensus is reluctant. Many of the participants represent the interests of the VRS providers, and seemingly would prefer there be no such standard. (Presumably they assume they will be compelled by the FCC to support it.) However, despite repeated requests, their objections have not been accompanied by contribution of constructive alternatives. The rest of the reviews and opinions come from more experienced IETF participants and they have generally been solidly in favor of the document as it now is constituted. In a few cases, some compromise has been achieved, where the more experienced IETFers would have preferred somewhat different text, but were persuaded the the compromise text was acceptable. Similarly, there are a few instances where the providers were initially against requirements deemed essential by our more experienced IETF participants, they offered some suggested additional requirements that the IETFers did not think were necessary, and they were accepted. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? No. If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. IdNits reports some errors and warnings that are bogus: * 3 instances of lines with non-ascii characters. These all appear in reference citations where they are now permitted. One of these is also reported as a line too long, due solely to the non-ascii character being counted as multiple bytes. * 2 warnings for "looks like a reference" for use of [1] and [2] in examples. In addition three downrefs are reported, referencing RFC2818, RFC3960 and RFC5168. These are discussed in (15) below. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The shepherd verified the json using the tool jsonlint , and the OpenAPI 3.1 descriptions of the interfaces using . (13) Have all references within this document been identified as either normative or informative? YES (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? NO (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. There are three downrefs, referencing RFC2818, RFC3960 and RFC5168. RFC2818 is an informational RFC that describes how to use TLS to secure HTTP connections. The RUE document defines web interfaces that run securely over HTTPS and TLS. Doing so requires following the guidance in RFC2818. Hence we made this a normative reference. RFC3960 is an informational RFC that describes how SIP entities handle early media. Early media is media that happens before a call is answered, which may be tones and announcements but also could be from an IVR system that doesn’t signal answer until a live agent answers the call. It’s the case that virtually every implementation has to do what RFC3960 says because otherwise things don’t work, yet the text has no normative RFC119 language. Hence we made this a normative reference. RFC5168 documents an older way to request full frame refresh on a video stream that many older devices still use. To connect to them it is necessary to do what RFC5168 says. We want that backward compatibility, so we required it. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. NO (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). The definition of the new RUE Provider List registry is properly specified. The update to the SIP Call-Info header field purpose is in good order. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. The new RUE Provider List needs an expert. This is a per-country registry. The expert should ideally be comfortable working with this sort of regulatory environment. The document editor, Brian Rosen, will volunteer to be the expert and there are other candidates who could be considered (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. The shepherd verified the json using the tool jsonlint , and the OpenAPI 3.1 descriptions of the interfaces using . (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? N/A |
2021-10-12
|
09 | Barry Leiba | Request for Last Call review by ARTART is assigned to Jaime Jimenez |
2021-10-12
|
09 | Barry Leiba | Request for Last Call review by ARTART is assigned to Jaime Jimenez |
2021-10-12
|
09 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2021-10-12
|
09 | Cindy Morgan | The following Last Call announcement was sent out (ends 2021-10-26): From: The IESG To: IETF-Announce CC: draft-ietf-rum-rue@ietf.org, pkyzivat@alum.mit.edu, rum-chairs@ietf.org, rum@ietf.org, superuser@gmail.com … The following Last Call announcement was sent out (ends 2021-10-26): From: The IESG To: IETF-Announce CC: draft-ietf-rum-rue@ietf.org, pkyzivat@alum.mit.edu, rum-chairs@ietf.org, rum@ietf.org, superuser@gmail.com Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Interoperability Profile for Relay User Equipment) to Proposed Standard The IESG has received a request from the Relay User Machine WG (rum) to consider the following document: - 'Interoperability Profile for Relay User Equipment' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2021-10-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Video Relay Service (VRS) is a term used to describe a method by which a hearing person can communicate with a deaf, hard of hearing or hearing impaired user using an interpreter ("Communications Assistant") connected via a videophone to the deaf/HoH user and an audio telephone call to the hearing user. The CA interprets using sign language on the videophone link and voice on the telephone link. Often the interpreters may be employed by a company or agency termed a "provider" in this document. The provider also provides a video service that allows users to connect video devices to their service, and subsequently to CAs and other deaf/HoH users. It is desirable that the videophones used by the deaf, hard of hearing or hearing impaired user conform to a standard so that any device may be used with any provider and that direct video calls between deaf, hard of hearing or hearing impaired users work. This document describes the interface between a videophone and a provider. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rum-rue/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/5120/ https://datatracker.ietf.org/ipr/5121/ https://datatracker.ietf.org/ipr/5122/ https://datatracker.ietf.org/ipr/5123/ https://datatracker.ietf.org/ipr/5124/ https://datatracker.ietf.org/ipr/5125/ https://datatracker.ietf.org/ipr/5126/ https://datatracker.ietf.org/ipr/5127/ https://datatracker.ietf.org/ipr/5128/ https://datatracker.ietf.org/ipr/5129/ https://datatracker.ietf.org/ipr/5130/ https://datatracker.ietf.org/ipr/5131/ https://datatracker.ietf.org/ipr/5132/ https://datatracker.ietf.org/ipr/3705/ https://datatracker.ietf.org/ipr/3706/ https://datatracker.ietf.org/ipr/3707/ https://datatracker.ietf.org/ipr/3708/ https://datatracker.ietf.org/ipr/3709/ https://datatracker.ietf.org/ipr/3710/ https://datatracker.ietf.org/ipr/3711/ https://datatracker.ietf.org/ipr/3712/ https://datatracker.ietf.org/ipr/3713/ https://datatracker.ietf.org/ipr/3714/ https://datatracker.ietf.org/ipr/3716/ https://datatracker.ietf.org/ipr/3717/ https://datatracker.ietf.org/ipr/3718/ https://datatracker.ietf.org/ipr/3719/ https://datatracker.ietf.org/ipr/3720/ https://datatracker.ietf.org/ipr/3721/ https://datatracker.ietf.org/ipr/3722/ https://datatracker.ietf.org/ipr/3723/ https://datatracker.ietf.org/ipr/3724/ https://datatracker.ietf.org/ipr/3725/ https://datatracker.ietf.org/ipr/3726/ https://datatracker.ietf.org/ipr/3727/ https://datatracker.ietf.org/ipr/3728/ https://datatracker.ietf.org/ipr/3729/ https://datatracker.ietf.org/ipr/3730/ https://datatracker.ietf.org/ipr/3731/ https://datatracker.ietf.org/ipr/3732/ https://datatracker.ietf.org/ipr/3733/ https://datatracker.ietf.org/ipr/3734/ https://datatracker.ietf.org/ipr/3735/ https://datatracker.ietf.org/ipr/3736/ https://datatracker.ietf.org/ipr/3737/ https://datatracker.ietf.org/ipr/3738/ https://datatracker.ietf.org/ipr/3739/ https://datatracker.ietf.org/ipr/3740/ https://datatracker.ietf.org/ipr/3755/ https://datatracker.ietf.org/ipr/4783/ https://datatracker.ietf.org/ipr/4784/ https://datatracker.ietf.org/ipr/4785/ https://datatracker.ietf.org/ipr/4786/ https://datatracker.ietf.org/ipr/4787/ https://datatracker.ietf.org/ipr/4788/ https://datatracker.ietf.org/ipr/4789/ https://datatracker.ietf.org/ipr/4790/ https://datatracker.ietf.org/ipr/4791/ https://datatracker.ietf.org/ipr/4792/ https://datatracker.ietf.org/ipr/4793/ https://datatracker.ietf.org/ipr/4794/ https://datatracker.ietf.org/ipr/4795/ https://datatracker.ietf.org/ipr/4796/ https://datatracker.ietf.org/ipr/4797/ https://datatracker.ietf.org/ipr/4798/ https://datatracker.ietf.org/ipr/4799/ https://datatracker.ietf.org/ipr/4800/ https://datatracker.ietf.org/ipr/4801/ https://datatracker.ietf.org/ipr/4802/ https://datatracker.ietf.org/ipr/4803/ https://datatracker.ietf.org/ipr/4804/ https://datatracker.ietf.org/ipr/4805/ https://datatracker.ietf.org/ipr/4806/ https://datatracker.ietf.org/ipr/4807/ https://datatracker.ietf.org/ipr/4808/ https://datatracker.ietf.org/ipr/4809/ https://datatracker.ietf.org/ipr/4810/ https://datatracker.ietf.org/ipr/4811/ https://datatracker.ietf.org/ipr/4812/ https://datatracker.ietf.org/ipr/4813/ https://datatracker.ietf.org/ipr/4814/ https://datatracker.ietf.org/ipr/4815/ https://datatracker.ietf.org/ipr/4816/ https://datatracker.ietf.org/ipr/4817/ https://datatracker.ietf.org/ipr/4428/ https://datatracker.ietf.org/ipr/4429/ https://datatracker.ietf.org/ipr/4430/ https://datatracker.ietf.org/ipr/4431/ https://datatracker.ietf.org/ipr/4432/ https://datatracker.ietf.org/ipr/4433/ https://datatracker.ietf.org/ipr/4434/ https://datatracker.ietf.org/ipr/4435/ https://datatracker.ietf.org/ipr/4436/ https://datatracker.ietf.org/ipr/4437/ https://datatracker.ietf.org/ipr/4438/ https://datatracker.ietf.org/ipr/4439/ https://datatracker.ietf.org/ipr/4440/ https://datatracker.ietf.org/ipr/4441/ https://datatracker.ietf.org/ipr/4442/ https://datatracker.ietf.org/ipr/4443/ https://datatracker.ietf.org/ipr/4444/ https://datatracker.ietf.org/ipr/4445/ https://datatracker.ietf.org/ipr/4446/ https://datatracker.ietf.org/ipr/4447/ https://datatracker.ietf.org/ipr/4448/ https://datatracker.ietf.org/ipr/4449/ https://datatracker.ietf.org/ipr/4450/ https://datatracker.ietf.org/ipr/4451/ https://datatracker.ietf.org/ipr/4452/ https://datatracker.ietf.org/ipr/4453/ https://datatracker.ietf.org/ipr/4454/ https://datatracker.ietf.org/ipr/4455/ https://datatracker.ietf.org/ipr/4456/ https://datatracker.ietf.org/ipr/4457/ https://datatracker.ietf.org/ipr/4458/ https://datatracker.ietf.org/ipr/4459/ https://datatracker.ietf.org/ipr/4460/ https://datatracker.ietf.org/ipr/4461/ https://datatracker.ietf.org/ipr/4462/ https://datatracker.ietf.org/ipr/4966/ https://datatracker.ietf.org/ipr/4967/ https://datatracker.ietf.org/ipr/4968/ https://datatracker.ietf.org/ipr/4969/ https://datatracker.ietf.org/ipr/4970/ https://datatracker.ietf.org/ipr/4971/ https://datatracker.ietf.org/ipr/4972/ https://datatracker.ietf.org/ipr/4973/ https://datatracker.ietf.org/ipr/4974/ https://datatracker.ietf.org/ipr/4975/ https://datatracker.ietf.org/ipr/4976/ https://datatracker.ietf.org/ipr/4977/ https://datatracker.ietf.org/ipr/4978/ https://datatracker.ietf.org/ipr/4979/ https://datatracker.ietf.org/ipr/4980/ https://datatracker.ietf.org/ipr/4981/ https://datatracker.ietf.org/ipr/4982/ https://datatracker.ietf.org/ipr/4983/ https://datatracker.ietf.org/ipr/4984/ https://datatracker.ietf.org/ipr/4985/ https://datatracker.ietf.org/ipr/4986/ https://datatracker.ietf.org/ipr/4987/ https://datatracker.ietf.org/ipr/4988/ https://datatracker.ietf.org/ipr/4989/ https://datatracker.ietf.org/ipr/4990/ https://datatracker.ietf.org/ipr/4991/ https://datatracker.ietf.org/ipr/4992/ https://datatracker.ietf.org/ipr/4993/ https://datatracker.ietf.org/ipr/4994/ https://datatracker.ietf.org/ipr/4995/ https://datatracker.ietf.org/ipr/4996/ https://datatracker.ietf.org/ipr/4997/ https://datatracker.ietf.org/ipr/4998/ https://datatracker.ietf.org/ipr/4999/ https://datatracker.ietf.org/ipr/5000/ https://datatracker.ietf.org/ipr/5098/ https://datatracker.ietf.org/ipr/5099/ https://datatracker.ietf.org/ipr/5100/ https://datatracker.ietf.org/ipr/5101/ https://datatracker.ietf.org/ipr/5102/ https://datatracker.ietf.org/ipr/5103/ https://datatracker.ietf.org/ipr/5104/ https://datatracker.ietf.org/ipr/5105/ https://datatracker.ietf.org/ipr/5106/ https://datatracker.ietf.org/ipr/5107/ https://datatracker.ietf.org/ipr/5108/ https://datatracker.ietf.org/ipr/5109/ https://datatracker.ietf.org/ipr/5110/ https://datatracker.ietf.org/ipr/5111/ https://datatracker.ietf.org/ipr/5112/ https://datatracker.ietf.org/ipr/5113/ https://datatracker.ietf.org/ipr/5114/ https://datatracker.ietf.org/ipr/5115/ https://datatracker.ietf.org/ipr/5116/ https://datatracker.ietf.org/ipr/5117/ https://datatracker.ietf.org/ipr/5118/ https://datatracker.ietf.org/ipr/5119/ |
2021-10-12
|
09 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2021-10-12
|
09 | Murray Kucherawy | Last call was requested |
2021-10-12
|
09 | Murray Kucherawy | Ballot approval text was generated |
2021-10-12
|
09 | Murray Kucherawy | Ballot writeup was generated |
2021-10-12
|
09 | (System) | Changed action holders to Murray Kucherawy (IESG state changed) |
2021-10-12
|
09 | Murray Kucherawy | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2021-10-12
|
09 | Murray Kucherawy | Last call announcement was generated |
2021-10-11
|
09 | (System) | Removed all action holders (IESG state changed) |
2021-10-11
|
09 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-10-11
|
09 | Brian Rosen | New version available: draft-ietf-rum-rue-09.txt |
2021-10-11
|
09 | (System) | New version accepted (logged-in submitter: Brian Rosen) |
2021-10-11
|
09 | Brian Rosen | Uploaded new revision |
2021-10-07
|
08 | Murray Kucherawy | Changed action holders to Brian Rosen |
2021-10-07
|
08 | (System) | Changed action holders to Murray Kucherawy, Brian Rosen (IESG state changed) |
2021-10-07
|
08 | Murray Kucherawy | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2021-10-05
|
08 | (System) | Changed action holders to Murray Kucherawy (IESG state changed) |
2021-10-05
|
08 | Murray Kucherawy | IESG state changed to AD Evaluation from Publication Requested |
2021-10-05
|
08 | Paul Kyzivat | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Video Relay Service (VRS) is a term used to describe a method by which a hearing persons can communicate with deaf/Hard of Hearing user using an interpreter ("Communications Assistant") connected via a videophone to the deaf/HoH user and an audio telephone call to the hearing user. The CA interprets using sign language on the videophone link and voice on the telephone link. Often the interpreters may be supplied by a company or agency termed a "provider" in this document. The provider also provides a video service that allows users to connect video devices to their service, and subsequently to CAs and other deaf/HoH users. It is desirable that the videophones used by the deaf/HoH/H-I user conform to a standard so that any device may be used with any provider and that video calls direct between deaf/HoH users work. This document specifies the interface between a videophone and a provider. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There was not a lot of energy in the group to move the work along. Notably, the representatives of VRS providers were reluctant to contribute and mostly offered objections. Reaching consensus under these conditions was challenging and often consensus was quite rough. Document Quality: Are there existing implementations of the protocol? There is a partial implementation by Mitre. This is intended as a verification and test vehicle. They have committed to creating a full implementation when the document becomes an RFC. Have a significant number of vendors indicated their plan to implement the specification? No. But the most likely vendors are the VRS providers. They do what they are required to do by the FCC. It is expected that the FCC will mandate this and then they will implement it. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? No. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Shepherd: Paul Kyzivat AD: Murray Kucherawy (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The shepherd has actively reviewed and provided feedback and suggestions on every version of this document, and verified all the formal language-based content, and reviewed the results of IdNits. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. The normal security review will be important for this document and the shepherd will make sure the conclusions of that review are attended to carefully by the author and the working group. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The market in which implementations of this document will primarily be deployed is unusual. The server side is controlled by a small set of VRS providers that are funded by the FCC and governed by rules issued by the FCC. The deployment of this standard will presumably be driven by new FCC requirements referencing it. The subject area covered by this document has heretofore been addressed with proprietary devices and/or software. The motivation for this work comes from outside the VRS provider community, while most people with experience building RUE-like devices work for the VRS providers. There are compromises made with the VRS providers that have shaped the document in ways that is somewhat different from how it would have come out without their participation, yet the participation of these providers is deemed essential, and their co-operation is sincerely appreciated. On the other hand, the rough consensus process has indeed overcome objections of all the participating providers, and they are not happy with certain aspects of the document. The shepherd is satisfied that the IETF processes on determining consensus were fairly applied, and the document represents a reasonable compromise between the providers as a whole and the rest of the work group. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Many IPR disclosures have been filed repeatedly against every new draft version of this document by one of the VRS providers. Based on a superficial examination, these seem to cover primarily features that impact downstream actions within the VRS provider and not the functionality addressed by this document. (Disclaimer, this is not a legal analysis.) Participants have been afforded opportunities to suggest any changes in the document that may further avoid the IPR claimed in the patents, and no suggestions have been made. Given the market in which this will be applied the current participants (all the VRS providers) clearly have already come to grips with the IPR environment. It is possible that an outsider who wants to create and sell a compatible RUE device might need to address some IPR issues. It isn't clear that there is any such candidate among the current participants of the work group. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The consensus is reluctant. Many of the participants represent the interests of the VRS providers, and seemingly would prefer there be no such standard. (Presumably they assume they will be compelled by the FCC to support it.) However, despite repeated requests, their objections have not been accompanied by contribution of constructive alternatives. The rest of the reviews and opinions come from more experienced IETF participants and they have generally been solidly in favor of the document as it now is constituted. In a few cases, some compromise has been achieved, where the more experienced IETFers would have preferred somewhat different text, but were persuaded the the compromise text was acceptable. Similarly, there are a few instances where the providers were initially against requirements deemed essential by our more experienced IETF participants, they offered some suggested additional requirements that the IETFers did not think were necessary, and they were accepted. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? No. If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. IdNits reports some errors and warnings that are bogus: * 3 instances of lines with non-ascii characters. These all appear in reference citations where they are now permitted. One of these is also reported as a line too long, due solely to the non-ascii character being counted as multiple bytes. * 2 warnings for "looks like a reference" for use of [1] and [2] in examples. In addition two downrefs are reported, referencing RFC3960 and RFC5168. These are discussed in (15) below. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The shepherd verified the json using the tool jsonlint , and the OpenAPI 3.1 descriptions of the interfaces using . (13) Have all references within this document been identified as either normative or informative? YES (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? NO (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. There are two downrefs, referencing RFC3960 and RFC5168. RFC3960 is an informational RFC that describes how SIP entities handle early media. Early media is media that happens before a call is answered, which may be tones and announcements but also could be from an IVR system that doesn’t signal answer until a live agent answers the call. It’s the case that virtually every implementation has to do what RFC3960 says because otherwise things don’t work, yet the text has no normative RFC119 language. Hence we made this a normative reference. RFC5168 documents an older way to request full frame refresh on a video stream that many older devices still use. To connect to them it is necessary to do what RFC5168 says. We want that backward compatibility, so we required it. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. NO (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). The update to the SIP Call-Info header field purpose is in good order. * The IANA Considerations for the new RUE Provider List registry call for a URI, while the text calls for a domain name. The author has been informed and has committed to updating this in the next version to specify a URI in the IANA Considerations. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. The new RUE Provider List needs an expert. This is a per-country registry. The expert should ideally be comfortable working with this sort of regulatory environment. The document editor, Brian Rosen, will volunteer to be the expert and there are other candidates who could be considered (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. The shepherd verified the json using the tool jsonlint , and the OpenAPI 3.1 descriptions of the interfaces using . (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? N/A |
2021-10-05
|
08 | Paul Kyzivat | Responsible AD changed to Murray Kucherawy |
2021-10-05
|
08 | Paul Kyzivat | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2021-10-05
|
08 | Paul Kyzivat | IESG state changed to Publication Requested from I-D Exists |
2021-10-05
|
08 | Paul Kyzivat | IESG process started in state Publication Requested |
2021-10-05
|
08 | Paul Kyzivat | Changed consensus to Yes from Unknown |
2021-10-05
|
08 | Paul Kyzivat | Intended Status changed to Proposed Standard from None |
2021-10-05
|
08 | Paul Kyzivat | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Video Relay Service (VRS) is a term used to describe a method by which a hearing persons can communicate with deaf/Hard of Hearing user using an interpreter ("Communications Assistant") connected via a videophone to the deaf/HoH user and an audio telephone call to the hearing user. The CA interprets using sign language on the videophone link and voice on the telephone link. Often the interpreters may be supplied by a company or agency termed a "provider" in this document. The provider also provides a video service that allows users to connect video devices to their service, and subsequently to CAs and other deaf/HoH users. It is desirable that the videophones used by the deaf/HoH/H-I user conform to a standard so that any device may be used with any provider and that video calls direct between deaf/HoH users work. This document specifies the interface between a videophone and a provider. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There was not a lot of energy in the group to move the work along. Notably, the representatives of VRS providers were reluctant to contribute and mostly offered objections. Reaching consensus under these conditions was challenging and often consensus was quite rough. Document Quality: Are there existing implementations of the protocol? There is a partial implementation by Mitre. This is intended as a verification and test vehicle. They have committed to creating a full implementation when the document becomes an RFC. Have a significant number of vendors indicated their plan to implement the specification? No. But the most likely vendors are the VRS providers. They do what they are required to do by the FCC. It is expected that the FCC will mandate this and then they will implement it. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? No. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Shepherd: Paul Kyzivat AD: Murray Kucherawy (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The shepherd has actively reviewed and provided feedback and suggestions on every version of this document, and verified all the formal language-based content, and reviewed the results of IdNits. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. The normal security review will be important for this document and the shepherd will make sure the conclusions of that review are attended to carefully by the author and the working group. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The market in which implementations of this document will primarily be deployed is unusual. The server side is controlled by a small set of VRS providers that are funded by the FCC and governed by rules issued by the FCC. The deployment of this standard will presumably be driven by new FCC requirements referencing it. The subject area covered by this document has heretofore been addressed with proprietary devices and/or software. The motivation for this work comes from outside the VRS provider community, while most people with experience building RUE-like devices work for the VRS providers. There are compromises made with the VRS providers that have shaped the document in ways that is somewhat different from how it would have come out without their participation, yet the participation of these providers is deemed essential, and their co-operation is sincerely appreciated. On the other hand, the rough consensus process has indeed overcome objections of all the participating providers, and they are not happy with certain aspects of the document. The shepherd is satisfied that the IETF processes on determining consensus were fairly applied, and the document represents a reasonable compromise between the providers as a whole and the rest of the work group. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Many IPR disclosures have been filed repeatedly against every new draft version of this document by one of the VRS providers. Based on a superficial examination, these seem to cover primarily features that impact downstream actions within the VRS provider and not the functionality addressed by this document. (Disclaimer, this is not a legal analysis.) Participants have been afforded opportunities to suggest any changes in the document that may further avoid the IPR claimed in the patents, and no suggestions have been made. Given the market in which this will be applied the current participants (all the VRS providers) clearly have already come to grips with the IPR environment. It is possible that an outsider who wants to create and sell a compatible RUE device might need to address some IPR issues. It isn't clear that there is any such candidate among the current participants of the work group. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The consensus is reluctant. Many of the participants represent the interests of the VRS providers, and seemingly would prefer there be no such standard. (Presumably they assume they will be compelled by the FCC to support it.) However, despite repeated requests, their objections have not been accompanied by contribution of constructive alternatives. The rest of the reviews and opinions come from more experienced IETF participants and they have generally been solidly in favor of the document as it now is constituted. In a few cases, some compromise has been achieved, where the more experienced IETFers would have preferred somewhat different text, but were persuaded the the compromise text was acceptable. Similarly, there are a few instances where the providers were initially against requirements deemed essential by our more experienced IETF participants, they offered some suggested additional requirements that the IETFers did not think were necessary, and they were accepted. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? No. If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. IdNits reports some errors and warnings that are bogus: * 3 instances of lines with non-ascii characters. These all appear in reference citations where they are now permitted. One of these is also reported as a line too long, due solely to the non-ascii character being counted as multiple bytes. * 2 warnings for "looks like a reference" for use of [1] and [2] in examples. In addition two downrefs are reported, referencing RFC3960 and RFC5168. These are discussed in (15) below. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The shepherd verified the json using the tool jsonlint , and the OpenAPI 3.1 descriptions of the interfaces using . (13) Have all references within this document been identified as either normative or informative? YES (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? NO (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. There are two downrefs, referencing RFC3960 and RFC5168. RFC3960 is an informational RFC that describes how SIP entities handle early media. Early media is media that happens before a call is answered, which may be tones and announcements but also could be from an IVR system that doesn’t signal answer until a live agent answers the call. It’s the case that virtually every implementation has to do what RFC3960 says because otherwise things don’t work, yet the text has no normative RFC119 language. Hence we made this a normative reference. RFC5168 documents an older way to request full frame refresh on a video stream that many older devices still use. To connect to them it is necessary to do what RFC5168 says. We want that backward compatibility, so we required it. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. NO (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). The update to the SIP Call-Info header field purpose is in good order. * The IANA Considerations for the new RUE Provider List registry call for a URI, while the text calls for a domain name. The author has been informed and has committed to updating this in the next version to specify a URI in the IANA Considerations. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. The new RUE Provider List needs an expert. This is a per-country registry. The expert should ideally be comfortable working with this sort of regulatory environment. The document editor, Brian Rosen, will volunteer to be the expert and there are other candidates who could be considered (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. The shepherd verified the json using the tool jsonlint , and the OpenAPI 3.1 descriptions of the interfaces using . (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? N/A |
2021-10-01
|
08 | Brian Rosen | New version available: draft-ietf-rum-rue-08.txt |
2021-10-01
|
08 | (System) | New version accepted (logged-in submitter: Brian Rosen) |
2021-10-01
|
08 | Brian Rosen | Uploaded new revision |
2021-09-15
|
07 | Paul Kyzivat | Notification list changed to pkyzivat@alum.mit.edu because the document shepherd was set |
2021-09-15
|
07 | Paul Kyzivat | Document shepherd changed to Paul Kyzivat |
2021-09-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-09-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-08-26
|
07 | Brian Rosen | New version available: draft-ietf-rum-rue-07.txt |
2021-08-26
|
07 | (System) | New version accepted (logged-in submitter: Brian Rosen) |
2021-08-26
|
07 | Brian Rosen | Uploaded new revision |
2021-07-29
|
06 | Brian Rosen | New version available: draft-ietf-rum-rue-06.txt |
2021-07-29
|
06 | (System) | New version accepted (logged-in submitter: Brian Rosen) |
2021-07-29
|
06 | Brian Rosen | Uploaded new revision |
2021-07-13
|
05 | Paul Kyzivat | Added to session: IETF-111: rum Thu-1630 |
2021-07-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-07-08
|
Jasmine Magallanes | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-06-14
|
05 | Brian Rosen | New version available: draft-ietf-rum-rue-05.txt |
2021-06-14
|
05 | (System) | New version approved |
2021-06-14
|
05 | (System) | Request for posting confirmation emailed to previous authors: Brian Rosen |
2021-06-14
|
05 | Brian Rosen | Uploaded new revision |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-04-15
|
Tess Hyden | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2021-03-05
|
04 | Paul Kyzivat | Added to session: IETF-110: rum Wed-1530 |
2021-02-05
|
04 | Brian Rosen | New version available: draft-ietf-rum-rue-04.txt |
2021-02-05
|
04 | (System) | New version approved |
2021-02-05
|
04 | (System) | Request for posting confirmation emailed to previous authors: Brian Rosen |
2021-02-05
|
04 | Brian Rosen | Uploaded new revision |
2020-12-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-12-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-12-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-12-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-12-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-12-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-12-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-12-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-12-08
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-11-19
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-11-19
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-11-19
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-11-19
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-11-19
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-11-19
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-11-19
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-11-19
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-11-19
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-11-19
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-11-19
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-11-19
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-11-19
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-11-19
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-11-19
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-11-19
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-11-19
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-11-19
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-11-19
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-11-19
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-11-19
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-11-19
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-11-19
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-11-19
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-11-19
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-11-19
|
Jenny Bui | Posted related IPR disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2020-11-11
|
03 | Paul Kyzivat | Added to session: IETF-109: rum Wed-1430 |
2020-08-25
|
03 | Brian Rosen | New version available: draft-ietf-rum-rue-03.txt |
2020-08-25
|
03 | (System) | New version approved |
2020-08-25
|
03 | (System) | Request for posting confirmation emailed to previous authors: Brian Rosen |
2020-08-25
|
03 | Brian Rosen | Uploaded new revision |
2020-08-01
|
02 | (System) | Document has expired |
2020-01-29
|
02 | Brian Rosen | New version available: draft-ietf-rum-rue-02.txt |
2020-01-29
|
02 | (System) | New version approved |
2020-01-29
|
02 | (System) | Request for posting confirmation emailed to previous authors: Brian Rosen |
2020-01-29
|
02 | Brian Rosen | Uploaded new revision |
2019-11-07
|
01 | Brian Rosen | Added to session: IETF-106: rum Thu-1000 |
2019-11-04
|
01 | Brian Rosen | New version available: draft-ietf-rum-rue-01.txt |
2019-11-04
|
01 | (System) | New version approved |
2019-11-04
|
01 | (System) | Request for posting confirmation emailed to previous authors: Brian Rosen |
2019-11-04
|
01 | Brian Rosen | Uploaded new revision |
2019-09-27
|
Jasmine Magallanes | Posted related IPR disclosure: Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue | |
2019-09-25
|
00 | Paul Kyzivat | This document now replaces draft-rosen-rue instead of None |
2019-09-25
|
00 | Brian Rosen | New version available: draft-ietf-rum-rue-00.txt |
2019-09-25
|
00 | (System) | WG -00 approved |
2019-09-24
|
00 | Brian Rosen | Set submitter to "Brian Rosen ", replaces to draft-rosen-rue and sent approval email to group chairs: rum-chairs@ietf.org |
2019-09-24
|
00 | Brian Rosen | Uploaded new revision |