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

["Olle E. Johansson" <[e-mail]>]

> On 13 Sep 2021, at 16:19, A. Jean Mahoney <[e-mail]> wrote:
> 
> 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.
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
> 
> 
>> We still do have discussion on WebRTC backwards compatibility that has not resolved.
> 
> +1 to supporting RUEs built on top of WebRTC.
> 
> 
>> Brian
>>> On Sep 10, 2021, at 1:26 PM, Paul Kyzivat <[e-mail]> 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.
> 
> 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
> 
> 
>>> 
>>> 	Thanks,
>>> 	Paul
>>> 
>>> -- 
>>> Rum mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rum
> 
> -- 
> Rum mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rum