Subject: [MMUSIC] Alexey Melnikov's Discuss on draft-ietf-mmusic-ice-sip-sdp-37: (with DISCUSS and COMMENT)

From: Alexey Melnikov via Datatracker <[email-masked]>
Date: Mon, 05 Aug 2019 04:07:26 -0700

Alexey Melnikov has entered the following ballot position for
draft-ietf-mmusic-ice-sip-sdp-37: 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-ice-sip-sdp/

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

This is a fine document and I only found a few minor things that should be easy
to fix.

In 4.1:

   The candidate attribute can itself be extended.  The grammar allows
   for new name/value pairs to be added at the end of the attribute.

   Such extensions MUST be made through IETF Review or IESG Approval
   [RFC8126] and the assignments MUST contain the specific extension and
   a reference to the document defining the usage of the extension.

This is effectively creating a new registry, but this information is not
present in the IANA Considerations section.

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

This is a fine document and I only found nits:

1) A document which is effectively a bis of RFC 5245 should have a section
describing changes since the original RFC. Can such section be added?

2) In 4.1:

component-id          = 1*5DIGIT

   <component-id>:  is a positive integer between 1 and 256 (inclusive)
      that identifies the specific component of the data stream for
      which this is a candidate.

Is there any reason why component-id ABNF production allows up to 5 digits,
while the description only allows 3?

3) In 9.2:

   o  Name, Email, and Address of a contact person for the registration

Considering EU GDPR, I think the WG needs to discuss whether collecting postal
address is needed, and if it is, whether IANA has to publish them on the
website.