Skip to main content

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