Draft: draft-ietf-ice-rfc5245bis

Commentary: Added text for the ' ice2 ' ICE option , which is used by ICE entities to indicate that they are compliant with the rfc5245bis draft . 
 The text just says it needs to be unique . It does n't unique within what scope . I think it should be unique within the scope of a single component of a single media stream within a single session . But whatever we decide , it should be clear in the spec . Right now , it 's not . 
 Section 4.1.2 says " Each candidate for a media stream MUST have a unique priority " ( ) I think I 've always read that as in " unique within a media stream " , but indeed it can also be interpreted as " candidates in general " since all are part of some media stream . But I think media stream is the right scope . Uniqueness across components is taken care of by the " Component ID " part of the formula . I 'd suggest changing that text into " Each candidate for a media stream MUST have a unique priority in the scope of a media stream . " 
 I agree that we need to define the scope of the uniqueness - it 's something the IESG reviewers ( and sometimes also the Gen - ART reviewers ) ask about if unclear . 
 The problem with relying on the formula is that it 's only SHOULD strength . But the uniqueness is MUST strength . Which means that an implementation is free to use a different formula , but it must preserve the uniqueness , so the MUST - level text needs to clarify the uniqueness , not the SHOULD - level text . I like  's idea of adding to the MUST - level text to make it clear and not rely on the formula . So , two questions about that : Do we need to specify that it 's within the scope of a single session ( ICE restart ) ? I think it 's what is currently assumed by the text ( else ICE restarts would have to keep track of the priorities of past generations , which it does n't say needs to be done ) , but I think it would be nice to be explicit . Do we need to have uniqueness across components ? I do n't really see any reason for it , but maybe I 'm missing something . On the other hand , it does n't seem very difficult to keep them unique across components . So I do n't think it matters too much . 
 Related to this , note that the local preference value must also be unique - without any description of the scope of the uniqueness . Regarding your questions : 1 ) I assume " scope of an ICE session " means that the priority value is unique among all media streams associated with that session ? 2 ) Not sure I understand . If all candidates have unique priority values , that means the components will have unique priority values too . 
 Regarding " scope of an ICE session " , what I meant is that if you have an ICE restart , you can re - use values from the previous round of gathering . You do n't have to remember values from the past and avoid reusing them . I did not mean that a value has to be unique across all media streams ( that would be crazy ) . Regarding candidates having unique priorities across components , what I mean is : is it OK for two candidates to be for the same stream but different components and have the same priority ? I do n't see why not . But again , I do n't see it as big restriction to say that they have must be different . 
 I think this is still not resolved , and  pointed out that in IESG review they might ask about this . 
 Is n't this covered with the modified text in section 5.2 ? " In addition , each candidate MUST be assigned a unique priority amongst all candidates for the same data stream . " 
 " For the same data stream " is great ! I did n't realize that was in there . In that case , I think we can close the issue .
This section defines a new ICE option, 'ice2'.  The ICE option
indicates that the ICE agent that includes it (in an ice-options
attribute) is compliant to this specification.  For example, the ICE
agent will not use the aggressive nomination procedure defined in
RFC5245.
An ICE agent compliant to this specification MUST inform the peer
about the compliance using the 'ice2' ICE option.
NOTE: The encoding of the 'ice2' ICE option, and the message(s) used
to carry it to the peer, are protocol specific.  The encoding for the
Session Description Protocol (SDP) RFC4566 is defined in I-D.ietf-
mmusic-ice-sip-sdp.
The original ICE specification registered four new STUN attributes,
and one new STUN error response.  The STUN attributes and error
response are reproduced here.
The original ICE specification registered four new STUN attributes,
and one new STUN error response.  The STUN attributes and error
response are reproduced here.  In addition, this specification
registers a new ICE option.
IANA is requested to register the following ICE option in the "ICE
Options" sub-registry of the "Interactive Connectivity Establishment
(ICE) registry", following the procedures defined in RFC6336.