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

[Christer Holmberg <[e-mail]>]

Hi,

Thanks for the review! Please see inline.

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

Does it really mandate a registry? 

The syntax says:

	candidate-types       = "host" / "srflx" / "prflx" / "relay" / token

There are other SDP attributes (and SIP header fields etc) that allow extensions ("token", in this case), without a registry.

Note that this was already in RFC 5245.

---

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

Yes. I agree we should have some text about that.

---

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

I see no reason. The syntax allowed 5 digits also in 5245, but the maximum value was 256.

So, unless the other authors are aware of a reason why 5 digits needs to be allowed, I suggest: s/1*5DIGIT/1*3DIGIT

---

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

The sub-registry ( https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-pns ) created by the recently published RFC 8599 (SIP Push) doesn't require any personal information for registering a new pn-provider value (section 14.5). It only requires (in addition to the new value and a description) a reference to the document that specifies the new value.

So, we could either require e.g., a name and email, or simply not require any personal information.

Any opinions?

---

Regards,

Christer