Subject: [MMUSIC] Fwd: I-D Action:draft-westerlund-mmusic-ice-options-registry-00.txt

From: Magnus Westerlund <[email-masked]>
Date: Thu, 11 Nov 2010 13:22:04 +0800

MMUSIC,

In the work on the draft-ietf-avt-ecn-for-rtp in AVT we found that ICE,
RFC 5245 does not create a registry for ICE options. This was discussed
in the AVT meeting on Monday here in Beijing. The preference there was
to have a seperate draft to create the registry that should be
progressed as soon as possible.

So I request this is progressed in MMUSIC. It should be simple, the main
thing that requires consensus on is under what policy registrations are
allowed to be done. Currently the draft suggest "Specification Required".

Cheers

Magnus

-------- Ursprungligt meddelande --------
Ämne: I-D Action:draft-westerlund-mmusic-ice-options-registry-00.txt
Datum: Thu, 11 Nov 2010 05:00:02 +0100
Från: [email-masked] <[email-masked]>
Svar till: [email-masked] <[email-masked]>
Till: [email-masked] <[email-masked]>

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : IANA Registry for Interactive Connectivity
Establishment (ICE) Options
	Author(s)       : M. Westerlund, C. Perkins
	Filename        : draft-westerlund-mmusic-ice-options-registry-00.txt
	Pages           : 5
	Date            : 2010-11-10

It has been identified that Interactive Connectivity Establishment
(ICE) is missing a registry for ICE options.  This document defines
this missing IANA registry.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-westerlund-mmusic-ice-options-registry-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 12 Nov 2010 13:59:16 +0800

Thanks for creating the draft. The chairs agree that we should progress 
this (quickly); if anybody in the group feels otherwise, please let us 
know.

In terms of the draft itself, a couple of minor comments:

- "Specification Required" seems good to me.
- Do we want to replicate the ice-options ABNF in this document, or 
should we just refer to RFC 5245 ?
- Where does the 20 character option-tag limit come from ?
- "Organization having the change control". It doesn't have to be an 
organization - could be one or more individuals as well.

Thanks

-- Flemming

On 11/11/10 1:22 PM, Magnus Westerlund wrote:
>         Filename        : 
> draft-westerlund-mmusic-ice-options-registry-00.txt
>         Pages           : 5
>         Date            : 2010-11-10
>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 17 Nov 2010 13:40:32 +0100

> - "Specification Required" seems good to me.
Good

> should we just refer to RFC 5245 ?

I think we can clarify that RFC 5245 is authorative, but keep it here
for ease of reference. It is annoying when you need to go to some other
document to learn what the limiatations are. Especially considering that
the IANA staff will look up this document as registry reference when
doing assignments.

> - Where does the 20 character option-tag limit come from ?
Pulled out of a rabbits hat. The ICE spec doesn't provide an upper
limit. I think that is sloopy and in fact an attack vector. You should
have an upper bound. To avoid getting very long names I added a "SHOULD
NOT" limit of 20 characters.

> organization - could be one or more individuals as well.

Correct, to be fixed in next revision.

Thanks for the review

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 17 Nov 2010 08:47:02 -0500

> the IANA staff will look up this document as registry reference when
Sounds good.
> NOT" limit of 20 characters.
But if it's "SHOULD NOT", then your implementation still needs to 
support option-tags longer than 20 characters and hence the attack 
vector still exists. Also, knowing how developers often read "SHOULD 
NOT", I'm a little concerned about people just implementing 20 character 
support (in which case it should have been a MUST NOT). It's not a big 
deal to me, but it does seem kind of arbitrary. I'd suggest we either 
change it to "MUST NOT", or we lower-case it and simply recommend people 
avoid long option-tags (which I think is motivated more by message size 
and parsing efficiency).

Thanks

-- Flemming

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 17 Nov 2010 16:19:36 +0100

> avoid long option-tags (which I think is motivated more by message size

That is fine, I can write it as "recommend to not use more than 20
characters in ice-options"

-- 

Magnus Westerlund