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

[Roman Shpount <[e-mail]>]

On Mon, Aug 5, 2019 at 8:54 AM Christer Holmberg <
[e-mail]> wrote:

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

I think Alexey is talking about
extension-att-name/extension-att-value in candidate-attribute
definition. Such as "tcptype active", "generation 0", and "network-id 2" in
the following ICE candidate example generated by Chrome:

a=candidate:1943319340 1 tcp 1518214911 10.7.18.148 9 typ host tcptype
active generation 0 network-id 2

Note that this was already in RFC 5245.
>

I agree this how it was already defined in RFC 5245. I did ask the group if
this required an additional IANA registry since it is currently impossible
to determine where these extensions are defined. For instance, I have no
idea in which RFC  "generation 0" is defined. The fact that we are not
changing the current definition was the main reason new IANA registry for
candidate extensions was not established. We will need to run this by
mmusic group if we want to change this.

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

I agree, this should be 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?


I do not think asking for optional name and contact information violates
GDPR, but in practice the only thing we need is reference RFC. All the
required information would be in the reference document itself, so I would
prefer removing redundant fields.
_____________
Roman Shpount