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

From: Christer Holmberg <[email-masked]>
Date: Mon, 5 Aug 2019 12:54:24 +0000

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

---

From: Roman Shpount <[email-masked]>
Date: Mon, 5 Aug 2019 16:43:56 -0400

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

> > This is effectively creating a new registry, but this information is not
> present in the IANA Considerations section.
>
> 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

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.

> > Is there any reason why component-id ABNF production allows up to 5
> digits, while the description only allows 3?
>
> 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

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

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

---

From: "Alexey Melnikov" <[email-masked]>
Date: Tue, 06 Aug 2019 10:27:32 +0100

Hi,

On Mon, Aug 5, 2019, at 9:44 PM, Roman Shpount wrote:
> On Mon, Aug 5, 2019 at 8:54 AM Christer Holmberg <[email-masked]> wrote:
>> > In 4.1:
>>  >
> I think Alexey is talking about extension-att-name/extension-att-value in candidate-attribute definition.

Yes.

>  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
> 
> 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.
This is exactly my point.

If the WG doesn't want to establish a new registry, then the sentence I quoted above must be removed, as it doesn't mean anything outside of IANA Considerations. In particular, if IESG is to approve an extension, how would implementors be able to find it, if IANA registry is not used? (Arguably, you can say that you still want to limit extensions to IETF stream, in that case the sentence still need to be reworded to something like: "Such extensions MUST be made in an IETF stream RFC and the assignments MUST contain the specific extension and a reference to the document defining the usage of the extension.")

>  We will need to run this by mmusic group if we want to change this.

Best Regards,
Alexey

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Aug 2019 10:33:13 +0000

Hi,

I suggest to simply remove the sentence - or at least most of it.

Because, I do think it's important to say that one must ignore name/value pairs that one does not understand.

Something like:

"The grammar allows for new name/value pairs to be added at the end of the attribute.
An implementation MUST ignore any name/value pairs it doesn't understand."

Regards,

Christer

Lähettäjä: Alexey Melnikov <[email-masked]>
Lähetetty: tiistai 6. elokuuta 2019 12.28
Vastaanottaja: Roman Shpount <[email-masked]>; Christer Holmberg <[email-masked]>
Kopio: The IESG <[email-masked]>; Flemming Andreasen <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Aihe: Re: [MMUSIC] Alexey Melnikov's Discuss on draft-ietf-mmusic-ice-sip-sdp-37: (with DISCUSS and COMMENT)

Hi,

The syntax says:

Yes.

Best Regards,
Alexey