Subject: [MMUSIC] 4566bis outstanding issues

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 6 Jun 2014 21:19:16 +0000

Hi everyone

I went thru the mail archives since 01/2012 and tried to list the issues that seem to be unresolved at this point. I can put them in the tracker but I wanna provide a summary first.

For some of the issues below, no solution has been proposed. For the rest, there was no agreement on what to do. Here it goes:

1) 4566bis needs to provide ABNF syntax for all of the attributes 4566 defined. 

Comments: This was discussed again in a side meeting in London and there was not a consensus whether we actually needed this. 

2) 4566bis should update the format of the IANA registries to reflect the dependency between addrtype and net type.

Comments: There does not seem an agreement on this but it looks to be an easy fix.

3) Section 8.2.4 defines the IANA registry and populates it with the attributes defined in 4566, however, Section 8.2.4 does not specify the name or format of the table.

Comments: No text has been proposed or agreed but seems to be an easy fix if we wanna do this.

4) 4566bis does not make the registration of new network or address types mandatory. Section 8.2.6 and 8.2.7.

Comments: If we agree that this should be mandatory, we can change the text.

5) Source-level attributes defined in 5576. Should these attributes be included in the same table structure in the IANA registry? 

Comments: This seems to be an organizational issue rather than a technical issue. If we agree we need this, we can take on this as well.

6) Should we add a new column called "registered network type" in the addrtype table in the IANA registry as not all address types are applicable for all network types? 

Comments: This is also an IANA fix that we can do in this bis document or in a separate document (with all the other IANA registry changes).

These are the issues I was able to identify. There is one more thing related to ICE and I sent an email about this to Marc Petit-Huguenin. As soon as he responds and depending on his answer, I might add one more issue.

If there are things I missed, please let me know. The chairs and editors would like to close these issues and finalize 4566bis soon.

Thanks.
-acbegen

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 06 Jun 2014 20:59:14 -0400

Hi Ali,

It is great that you are working on this!!!

> Comments: This was discussed again in a side meeting in London and there was not a consensus whether we actually needed this.

IIRC the argument against doing this is that we might get it wrong.

But IMO we should do it because if we can't get it right how can we 
expect readers to get it right?

> Comments: If we agree that this should be mandatory, we can change the text.

IMO we should make this change

> Comments: This seems to be an organizational issue rather than a technical issue. If we agree we need this, we can take on this as well.

Yes, but IMO an important one. The current registries are hard to read, 
and easy to get wrong when adding new attributes.

Also, we ought to have templates for what goes into the IANA 
consideration section when defining new attributes, and that template 
would be best in this document.

> Comments: This is also an IANA fix that we can do in this bis document or in a separate document (with all the other IANA registry changes).

Similar comment to the one just above.

> If there are things I missed, please let me know. The chairs and editors would like to close these issues and finalize 4566bis soon.

There is an ongoing problem when SDP extensions are defined - lack of a 
consistent format for defining new attributes. Many people look to 4566 
for examples of how to do this, but it provides bad examples.

IMO 4566bis should show the definition of all attributes in a style that 
complies with a recommended format for defining attributes.

(Of course that implies that we could agree on such a format.)

	Thanks,
	Paul

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 13 Jun 2014 14:32:31 +0000

Thanks Paul for the comments. Before I comment on your email, I would like other participants to say their comments, too.

If you have comments on the following issues, please speak up.

On Jun 7, 2014, at 3:59 AM, Paul Kyzivat <[email-masked]> wrote:

> But IMO we should do it because if we can't get it right how can we expect readers to get it right?
> 
> Yes, but IMO an important one. The current registries are hard to read, and easy to get wrong when adding new attributes.
> 
> Also, we ought to have templates for what goes into the IANA consideration section when defining new attributes, and that template would be best in this document.
> 
> There is an ongoing problem when SDP extensions are defined - lack of a consistent format for defining new attributes. Many people look to 4566 for examples of how to do this, but it provides bad examples.
> 
> IMO 4566bis should show the definition of all attributes in a style that complies with a recommended format for defining attributes.
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 15 Jun 2014 15:11:10 -0600

> Hi everyone

[...]

> 
> 
> These are the issues I was able to identify. There is one more thing
> related to ICE and I sent an email about this to Marc Petit-Huguenin. As
> soon as he responds and depending on his answer, I might add one more
> issue.
> 

Let me first explain the problem as I perceive it:

The SDP was designed so that different endpoints can be part of an RTP
session, i.e. each m= section can used a different IP address.  For example
one can imagine that during an IETF meeting each microphone has its own IP
address and stream audio directly to some destination (in that example the IP
address in the SDP is only use for RTCP).  If this use case was not possible,
then it would be only possible to use c= at the session level.
draft-loreto-splices-disaggregated-media was, I think, the first document to
call this "media disaggregation".

Now if we expand this to ICE, it means that each ICE agent declared in a SDP
has to be independent of each other, i.e. each microphone in our example has
it's own ICE agent, and they do not even to be from the same vendor.  That
means that all SDP attributes needs to be at least media-level attributes, and
eventually both media- and session- level attributes.  IANA fixed the problem
for ice-mismatch, but the problem still exists for ice-options, and fixing it
is part of rfc5245bis.

Now my suggestion was that for future SDP attributes, people should really
think about the disaggregated case when they choose between a session-level
only attribute or an attribute that works at both session- and media-level,
because using a session-level only attribute prevents media disaggregation.  I
could not find this problem in any existing attribute at the time I did the
analysis but in ICE attributes, but note that this is not a problem specific
to ICE.

So I would suggest adding some text after this paragraph in section 8.2.4:

'Submitters of registrations should ensure that the specification is
 in the spirit of SDP attributes, most notably that the attribute is
 platform independent in the sense that it makes no implicit
 assumptions about operating systems and does not name specific pieces
 of software in a manner that might inhibit interoperability.'

Something like this:

'Submitters of registrations should also carefully choose the type of
attribute. They should not choose a session-level only type when the attribute
can have different values when media is disaggregated, i.e. when each m=
section has its own IP address on a different endpoint.  In that case the
attribute type chosen should be "both".'

Thanks.

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 28 Jun 2014 17:17:35 +0000

I have not seen any objections to this change request? So, I will include Marc's text in the next revision.

-acbegen

On Jun 16, 2014, at 12:11 AM, Marc Petit-Huguenin <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> 
> iQIcBAEBCAAGBQJTngvsAAoJECnERZXWan7EkoEP+QH/FamXyYcisXxR8vtRBUAV
> D0MrwvRzzjQfAEW2aRSYPC12de0UeC7uYCOx9l7Cv1NKcFccdD/3NsDUNYy5C++Q
> siL0YAcTIhuCiBYkYPUEq3Ix3CrXGnspBV2kbJdcBPgGuIw7jXNHQh5l5bvoAtJs
> isHGev6rn6wGR2WheiYtlQ1AInFmjD5MqOyu9xtAAbdIJBWrqFzDsSq4vAevSyzL
> EYPgW6Op6UoP6zGIB45PRXiGP//5Gj8jri9wXjp3M8cyvgpK6CoHoNe6m1rGuWqS
> pMOh6vZRjRbkRpcufJ29tuV8SJ513m5x0pDSiCZAyNi47q3zgN+W++i4eX1ujnbN
> D/UjmQmacSFO3N/QWvuAlZH9VRSVHdUbyw/NXUFFhCjexSokn/nBh7eFFvwMJyp6
> ZuxpKjcg+wrOxjkocSq8bNXcQLR1yohADKN1ePyHHvZ84+gkinlIpKMuegEBBFi5
> OVe0O4QiRjKd3h1ewO98tzPUKVhaD9nSkLT7eOjHU3Xfz5Ol5tlA50+5P7tcN43h
> OO10nUijN4lxBsTi0WNC2sFpE3WXQ8gAkWHKyedfeMx9Uvl2SF18QFujAeD1oYIN
> jS+SuZOlO7S6t2naMzyJj10yOxzgSnNYBGBQQ2yP1oE1qtiZjCDhTTaJIMjTgCYu
> V/fj5tQ5v43FLPpKlD+8
> =qu35
> -----END PGP SIGNATURE-----