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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Mon, 05 Aug 2019 19:24:24 -0700

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.

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 06 Aug 2019 17:43:13 +1000

I've combined the changes with Ben's.  See    https://github.com/martinthomson/sdp-uks/pull/11

> handling would be helpful:

Added requirement to use illegal_parameter.

> the new encoding to be done?

A JSON text is a string of tokens, not octets, by my reading.  The UTF-8 encoding is something that happens to JSON text to produce a sequence of octets, so you have to say that.

I realize that isn't clear from RFC 8259, but the risk I'm hedging against is the UTF-8 encoding not happening, not that it might happen twice (which is a nonsensical operation in many contexts, but I will concede still possible in some).  At least I hope that someone will realize that encoding twice is not a sensible option.

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 12 Aug 2019 23:03:10 +0000

Hi Martin!

Thanks this pull request.  It addresses my discuss points so I've cleared my discuss.

Regards,
Roman

> -----Original Message-----
> From: Martin Thomson [mailto:[email-masked]]
> Sent: Tuesday, August 6, 2019 3:43 AM
> To: Roman Danyliw <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; mmusic <[email-masked]>;
> [email-masked]
> Subject: Re: [MMUSIC] Roman Danyliw's Discuss on draft-ietf-mmusic-sdp-
> uks-06: (with DISCUSS and COMMENT)
> 
> I've combined the changes with Ben's.  See
> https://github.com/martinthomson/sdp-uks/pull/11
> 
> > (1) Section 3.2.  There are a few places where further clarity on
> > error handling would be helpful:
> 
> > (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?
> 
> A JSON text is a string of tokens, not octets, by my reading.  The UTF-8
> encoding is something that happens to JSON text to produce a sequence of
> octets, so you have to say that.
> 
> I realize that isn't clear from RFC 8259, but the risk I'm hedging against is the
> UTF-8 encoding not happening, not that it might happen twice (which is a
> nonsensical operation in many contexts, but I will concede still possible in
> some).  At least I hope that someone will realize that encoding twice is not a
> sensible option.