Subject: [Rum] REMINDER: WGLC ends Monday, Sept 13

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Sep 2021 13:26:54 -0400

Discussion has lagged since Labor Day. Of note, there was no resolution 
on how the RUE handles video mail and MWI.

What is in the draft now will remain unless somebody proposes some 
changes that preserve a single RUE implementation to work with an 
arbitrary provider system to allow the user to learn pending video mail 
and then play and manage it.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Fri, 10 Sep 2021 14:23:19 -0400

Thanks for the reminder.

I would like to add that the proposed compromise actions on IPv6 (adding the support mandate for the backwards compatibility RFCs) and SRTP (adding a requirement to support OSRTP) were very welcome, and I will add them to the document assuming Paul calls consensus on those items.  

We still do have discussion on WebRTC backwards compatibility that has not resolved.

Brian

> On Sep 10, 2021, at 1:26 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> Discussion has lagged since Labor Day. Of note, there was no resolution on how the RUE handles video mail and MWI.
> 
> What is in the draft now will remain unless somebody proposes some changes that preserve a single RUE implementation to work with an arbitrary provider system to allow the user to learn pending video mail and then play and manage it.
> 
> 	Thanks,
> 	Paul
> 
> -- 
> Rum mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rum

---

From: "A. Jean Mahoney" <[email-masked]>
Date: Mon, 13 Sep 2021 09:19:46 -0500

Hi all,

Tossing in my comments on the open issues and review of -07:

On 9/10/21 1:23 PM, Brian Rosen wrote:
> Thanks for the reminder.
> 
> I would like to add that the proposed compromise actions on IPv6 (adding the support mandate for the backwards compatibility RFCs) 

+1 on this proposal. ([with my sipcore WG co-chair hat on briefly] I'm 
also okay with a new doc in the sipcore WG regarding this, but I agree 
with Brian that we don't want to have this document sitting in MISSREF 
state waiting for that future sipcore doc to hit the RFC Editor Queue).

> and SRTP (adding a requirement to support OSRTP) were very welcome, and I will add them to the document assuming Paul calls consensus on those items.

I'm not a fan of opportunistic security (I have trust issues). If OSRTP 
[RFC8643] is made a requirement, then the text should talk about how it 
is there to support transition and the bid-down risk should be discussed 
in the Security Considerations section. RFC 8643 would also be a downref.

> We still do have discussion on WebRTC backwards compatibility that has not resolved.

+1 to supporting RUEs built on top of WebRTC.

>> What is in the draft now will remain unless somebody proposes some changes that preserve a single RUE implementation to work with an arbitrary provider system to allow the user to learn pending vi…

There was a discussion about allowing a configuration of a SIP or HTTPS 
URL for retrieving video mail and adding a section on 
retrieving/managing video mail. +1 to adding that.

My review of -07 follows. My background is not in the VRS space, so my 
review is more editorial.

Minor issues:

---
3.  The requirements language needs the following current boilerplate 
and a reference to RFC 8174:

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
    "OPTIONAL" in this document are to be interpreted as described in BCP
    14 [RFC2119] [RFC8174] when, and only when, they appear in all
    capitals, as shown here.  Lower- or mixed-case uses of these key
    words are not to be interpreted as carrying special significance in
    this memo.

---
There are several places where there are multiple normative statements 
wrapped up in compound-complex sentences. I've suggested some untangling 
below:

5.2.5 - Perhaps reorder and split into two sentences:

Current:
    Because the RUE may have a more accurate and timely
    location of the device than the a manual entry location for nomadic
    RUE devices, but country-specific procedures require the location to
    be pre-loaded in some entity prior to placing an emergency call,
    implementations of a RUE device MAY send a Geolocation header
    containing its location in the REGISTER request if the configuration
    specifies it.

Perhaps:
    If the configuration specifies it, an implementation of a RUE device
    MAY send a Geolocation header field containing its location in the
    REGISTER request. Country-specific procedures require the location to
    be pre-loaded in some entity prior to placing an emergency call;
    however, the RUE may have a more accurate and timely device location
    than the manual, pre-loaded entry.

5.5 - (This feedback may be overcome by events; see Gunnar's comments 
regarding WebRTC data channel):

Current:
    Implementations MUST conform to [RFC8835] except that that this
    specification does not use the WebRTC data channel.

Perhaps:
    Implementations MUST conform to [RFC8835] except for its guidance on
    the WebRTC data channel, which this specification does not use.

6.3 - Perhaps reorder and split into two sentences:

Current:
    Implementations MUST conform to [RFC7742] with the exception that,
    since backwards compatibility is desirable and older devices do not
    support VP8, that only H.264, as specified in [RFC7742] is Mandatory
    to Implement and VP8 support is OPTIONAL at both the device and
    providers.

Perhaps:
    Implementations MUST conform to [RFC7742] with following exceptions:
    only H.264, as specified in [RFC7742], is Mandatory to Implement, and
    VP8 support is OPTIONAL at both the device and providers. This is
    because backwards compatibility is desirable, and older devices do
    not support VP8.

6.6 - Perhaps split into two sentences. The second statement seems to be 
missing what must be specified:

Current:
    The SDP offers and answers MUST conform to the SDP rules in [RFC8829]
    except that the RUE Interface uses SIP transport for SDP and the SDP
    for real time text MUST specify [RFC4103].

Perhaps:
    The SDP offers and answers MUST conform to the SDP rules in [RFC8829]
    except that the RUE interface uses SIP transport for SDP. The SDP
    for real-time text MUST specify the T.140 payload type [RFC4103].

6.7 - RUE shouldn't be controlling the user's privacy, the user should 
be controlling the user's privacy :-) Perhaps split into two sentences.

Current:
    The RUE MUST be able to control privacy of the user by implementing a
    one-way mute of audio and or video, without signaling, locally, but
    MUST maintain any NAT bindings by periodically sending media packets
    on all active media sessions containing silence/comfort noise/black
    screen/etc. per [RFC6263].

Perhaps:
    The RUE MUST provide for user privacy by implementing a local
    one-way mute of audio and/or video without signaling. However, RUE
    MUST maintain any NAT bindings by periodically sending media packets
    on all active media sessions containing silence/comfort noise/black
    screen/etc. per [RFC6263].

7.1 - The following is hard to parse. "attempt to continue" doesn't seem 
to mesh well with "MUST". Maybe "MUST continue"?

Current:
    If the request triggers a challenge for digest
    authentication credentials, the RUE MUST attempt to continue using
    matching "credentials" from the configuration.

9.1 - Perhaps separate the normative statements into two sentences:

Current:
    To achieve backwards compatibility, implementations MUST ignore any
    object members they do not implement and 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.

Perhaps:
    To achieve backwards compatibility, implementations MUST ignore any
    object members they do not implement.  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.

9.2 - What is the required parameter in the following?

Current:
    A required parameter which contains an instance identifier.

9.2.2 - What is meant by "CONDITIONAL", which is not a BCP14 keyword? 
Please specify the condition here and perhaps use "bold" formatting: 
"*conditional*"

----------------------------------------------------
Nits:

---
General

In several places the term "section" is doubled. I think this is an 
xml2rfc artifact: "Section Section" / "Section"

"header" / "header field" - when talking about named header fields.

"real time text" / "real-time text"

---
Abstract

"a hearing persons" / "a hearing person"

It's unclear whether "interpreters may be supplied by a company" means 
that the company provides the equipment or the actual interpreters. 
Perhaps "interpreters may be employed by a company"

H-I needs to be expanded

"video calls direct" / "direct video calls"

---
2.  Terminology

General: Capitalization of terms is inconsistent. For instance, 
"provider" is inconsistently capitalized: 73 lowercase, 72 capitalized. 
I suggest using lowercase. Other terms that are inconsistent: "URI" / 
"uri". "one stage" / "1 stage" / "one-stage"

Add line break before "Point-to-Point Call (P2P Call):"

FCC-VRS-GUIDE appears to be a cross reference, but there is no 
corresponding entry in the references section.

---
4.  General Requirements

Add a period to the end of the 1st paragraph.

UTF/8 / UTF-8

---
5.  SIP Signaling

Perhaps use bullet lists for the lists in the first and third paragraphs?

5.2.1 - missing closing paren: "(Section 9.2."

5.2.2 - broken cross reference in paragraph 2.

5.3 - "MUST, be able" / "MUST be able"

---
6. Media

First paragraph - missing quote around "non-browser""

---
9. Provisioning and Provider Selection

The following is hard to parse ("that allows" / "can allow"):

Current:
    One provides a directory of
    providers so that a user interface that allows easy provider
    selection either for registering or for dial-around.

Perhaps:
    One provides a directory of
    providers so that a user interface can allow easy provider
    selection either for registering or for dial-around.

9.1 - "V1" / "version 1.0 (V1)" Although are you sure you want to use 
just a major version number in the label?

9.2 - "configuration the using" / "configuration using"

9.2.1 - "objets" / "objects"

9.2.2 - "registration.Emergency" / "registration.  Emergency"

9.2.2 - Sentence fragment:

Current:
       Optionally contains a user name and/or
       password that may be used with the server.

9.3 - Should a reference for OpenAPI be provided?

----
10. Acknowledgments

This section should be placed immediately before the Author's Address 
address section and should be unnumbered.

----
11.  IANA Considerations

11.2 - "Registration of the rue-owner purpose parameter" /
"Registration of the rue-owner Value of the purpose Parameter"

---
13. Normative References

There is an odd break between section number and the section title.

Should the references be sorted alphabetically?

Best regards,
Jean

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 14 Sep 2021 09:11:18 +0200

> On 13 Sep 2021, at 16:19, A. Jean Mahoney <[email-masked]> wrote:
> 
> Hi all,
> 
> +1 on this proposal. ([with my sipcore WG co-chair hat on briefly] I'm also okay with a new doc in the sipcore WG regarding this, but I agree with Brian that we don't want to have this document sitting in MISSREF state waiting for that future sipcore doc to hit the RFC Editor Queue).
> 
> 
> I'm not a fan of opportunistic security (I have trust issues). If OSRTP [RFC8643] is made a requirement, then the text should talk about how it is there to support transition and the bid-down risk should be discussed in the Security Considerations section. RFC 8643 would also be a downref.
There is no consensus on OSRTP at all. I can’t see any reason why RUM users should not get the same privacy like all WebRTC users get with a mandatory SRTP. The IETF has already made decisions on this and new RFCs needs to focus on protecting the users from mass surveillance. 

I strongly think that SIP/TLS and DTLS/SRTP should be mandatory for this work.

/O
> There was a discussion about allowing a configuration of a SIP or HTTPS URL for retrieving video mail and adding a section on retrieving/managing video mail. +1 to adding that.
> 
> 
> 
> My review of -07 follows. My background is not in the VRS space, so my review is more editorial.
> 
> Minor issues:
> 
> ---
> 3.  The requirements language needs the following current boilerplate and a reference to RFC 8174:
> 
> There are several places where there are multiple normative statements wrapped up in compound-complex sentences. I've suggested some untangling below:
> 
> 5.5 - (This feedback may be overcome by events; see Gunnar's comments regarding WebRTC data channel):
> 
> Current:
> 6.6 - Perhaps split into two sentences. The second statement seems to be missing what must be specified:
> 
> Current:
> 6.7 - RUE shouldn't be controlling the user's privacy, the user should be controlling the user's privacy :-) Perhaps split into two sentences.
> 
> Current:
> 7.1 - The following is hard to parse. "attempt to continue" doesn't seem to mesh well with "MUST". Maybe "MUST continue"?
> 
> Current:
> 9.2.2 - What is meant by "CONDITIONAL", which is not a BCP14 keyword? Please specify the condition here and perhaps use "bold" formatting: "*conditional*"
> 
> In several places the term "section" is doubled. I think this is an xml2rfc artifact: "Section Section" / "Section"
> 
> It's unclear whether "interpreters may be supplied by a company" means that the company provides the equipment or the actual interpreters. Perhaps "interpreters may be employed by a company"
> 
> H-I needs to be expanded
> 
> General: Capitalization of terms is inconsistent. For instance, "provider" is inconsistently capitalized: 73 lowercase, 72 capitalized. I suggest using lowercase. Other terms that are inconsistent: "URI" / "uri". "one stage" / "1 stage" / "one-stage"
> 
> FCC-VRS-GUIDE appears to be a cross reference, but there is no corresponding entry in the references section.
> 
> ---
> 4.  General Requirements
> 
> 9.1 - "V1" / "version 1.0 (V1)" Although are you sure you want to use just a major version number in the label?
> 
> This section should be placed immediately before the Author's Address address section and should be unnumbered.
> 
> ----
> 11.  IANA Considerations
>