[MMUSIC] Roman Danyliw's Discuss on draft-ietf-mmusic-sdp-uks-06: (with DISCUSS and COMMENT)

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

Roman Danyliw has entered the following ballot position for
draft-ietf-mmusic-sdp-uks-06: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


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



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) Section 3.2.  There are a few places where further clarity on error
handling would be helpful:

-- Per “A peer that receives an "external_id_hash" extension that does not
match the value of the identity binding from its peer MUST immediately fail the
TLS handshake with an error”, which TLS error alert?

-- Per “A peer that receives an identity binding, but does not receive an
‘external_id_hash’extension MAY choose to fail the connection”, if it does
“fail the connection”, with which error alert?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(2) I support Ben’s DISCUSS on the clarity of Section 3.2. I would add a few
additional observations:

** Per the sentence, “The resulting string is then encoded using UTF-8”,
shouldn’t this JSON text already be UTF-8 per Section 8.1 of RFC8259 -- what’s
the new encoding to be done?

** Recommend a citation for the WebRTC identity assertion, SDP identity
attribute and PASSPoRT formats earlier than the last sentence of the relevant
paragraph

(3) Section 3.2.  The second “Note” in this section likely is meant to be
generic guidance regardless of whether SDP or PASSPoRT is used.  However, since
the first “Note” only applies to SDP, it could be read that this crypto agility
guidance only applies to PASSPoRT.  Recommend using a different convention.

(4) Section 3.  Per “Neither SIP nor WebRTC identity providers are not required
to perform this validation”, this sentence has a triple negative (i.e.,
neither, nor and not).  Please rephrase to clarify that these providers are
required to validate.