Subject: [MMUSIC] FW: AUTH48 [SG]: RFC 5245 <draft-ietf-mmusic-ice-19.txt> NOW AVAILABLE

From: Jean-Francois Mule <[email-masked]>
Date: Fri, 26 Mar 2010 07:49:09 -0600

FYI, auth48 changes in ICE.

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Thursday, March 25, 2010 2:10 PM
To: RFC Editor
Cc: [email-masked]; [email-masked]
Subject: Re: AUTH48 [SG]: RFC 5245 <draft-ietf-mmusic-ice-19.txt> NOW AVAILABLE

Enclosed is an updated xml file for ICE. All changes that were made fell 
into one of the following categories:

* a bug fix as reported to me or on the list since approval
* alignment with TURN
* responses to RFC-ed questions
* minor fixes to errors made during the rfc-ed process

A summary of the actual semantic protocol changes are:

Bug fixes in ICE:

* The SDP syntax for IP addresses used <connection-address> from RFC
   4566 but did not provide an indication of whether the address was v4
   or v6. The text now indicates that an agent uses the presence of a
   colon to differentiate v4 and v6 addresses.

* When an agent gets a 487 (Role Conflict) response to a connectivity
   check and it changes roles, it must also recompute pair
   priorities. This was not mentioned. It now is.

* Binding indications used for keepalives now include FINGERPRINT at
   SHOULD strength.

* Clarified that an agent MUST ignore candidate lines whose candidates
   have IP addresses utilizing versions not supported or understood by
   the agent.

* Clarified that, when computing a triggered check, the local
   candidate is always a host candidate or relayed candidate, and never
   server reflexive.

* Added wording to ICE for handling permissions, a new feature in TURN
   that was added after approval of ICE. The basic rule is that the
   client creates a permsision just prior to sending a connectivity
   check through a TURN server (this is RECOMMENDED). The permissions
   need to be kept alive until ICE completes. Once completed, if a
   relayed candidate has been selected, the spec RECOMMENDS that a
   channel be bound towards the remote candidate.

* Deprecating RFC4092 and RFC4091, not just RFC4091.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 27 Mar 2010 04:58:53 +0100

Now this deprecates an additional document, I was just checking the IANA registries for those documents. Should RFC 5245 now be added against the SIP option-tag entry for sdp-anat. There are some SDP parameters registered by RFC 4091 as well.

Also from a formal perspective, can AUTH48 changes deprecate another RFC?

regards

Keith

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jean-Francois Mule
> Sent: Friday, March 26, 2010 1:49 PM
> To: [email-masked]
> Subject: [MMUSIC] FW: AUTH48 [SG]: RFC 5245 
> <draft-ietf-mmusic-ice-19.txt> NOW AVAILABLE
> 
> Subject: Re: AUTH48 [SG]: RFC 5245 
> <draft-ietf-mmusic-ice-19.txt> NOW AVAILABLE
> 
> Enclosed is an updated xml file for ICE. All changes that 
> were made fell into one of the following categories:
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Tom Taylor <[email-masked]>
Date: Fri, 26 Mar 2010 21:58:20 -0700

The additional deprecation was part of the IESG writeup when it approved the 
document.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 29 Mar 2010 12:34:19 +0200

Shame they forgot to tell the SIP list which happened to "own" 4092.

The IANA comments still apply.

Keith 

> From: Tom Taylor [mailto:[email-masked]] 
> Sent: Saturday, March 27, 2010 4:58 AM
> To: DRAGE, Keith (Keith)
> Cc: Jean-Francois Mule; [email-masked]
> Subject: Re: [MMUSIC] FW: AUTH48 [SG]: RFC 5245 
> The additional deprecation was part of the IESG writeup when 
> it approved the document.
> 
> > Now this deprecates an additional document, I was just 
> checking the IANA registries for those documents. Should RFC 
> 5245 now be added against the SIP option-tag entry for 
> sdp-anat. There are some SDP parameters registered by RFC 
> 4091 as well.
> > 
> were made 
> >> fell into one of the following categories:
> >>
> >>    4566 but did not provide an indication of whether the 
> address was 
> >> v4