[Rum] Roman Danyliw's Discuss on draft-ietf-rum-rue-09: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-rum-rue-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rum-rue/



----------------------------------------------------------------------
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?


----------------------------------------------------------------------
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.