Subject: Re: [MMUSIC] New Version Notification for draft-ietf-mmusic-trickle-ice-sip-17.txt

From: Thomas Stach <[email-masked]>
Date: Fri, 22 Jun 2018 22:29:15 +0200

All,

    Changes from draft-ietf-mmusic-trickle-ice-sip-16

    o  some editorial corrections based on Ben's input

Kind Regards
Thomas

On 2018-06-22 22:27, [email-masked] wrote:
> A new version of I-D, draft-ietf-mmusic-trickle-ice-sip-17.txt
> has been successfully submitted by Thomas Stach and posted to the
> IETF repository.
>
> Name:		draft-ietf-mmusic-trickle-ice-sip
> Revision:	17
> Title:		A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE)
> Document date:	2018-06-21
> Group:		mmusic
> Pages:		47
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-mmusic-trickle-ice-sip-17.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-mmusic-trickle-ice-sip/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-17
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-trickle-ice-sip
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-trickle-ice-sip-17
>
> Abstract:
>     The Interactive Connectivity Establishment (ICE) protocol describes a
>     Network Address Translator (NAT) traversal mechanism for UDP-based
>     multimedia sessions established with the Offer/Answer model.  The ICE
>     extension for Incremental Provisioning of Candidates (Trickle ICE)
>     defines a mechanism that allows ICE Agents to shorten session
>     establishment delays by making the candidate gathering and
>     connectivity checking phases of ICE non-blocking and by executing
>     them in parallel.
>
>     This document defines usage semantics for Trickle ICE with the
>     Session Initiation Protocol (SIP).  The document also defines a new
>     SIP Info Package to support this usage together with the
>     corresponding media type.  Additionally, a new SDP 'end-of-
>     candidates' attribute and a new SIP Option Tag 'trickle-ice' are
>     defined.
>
>                                                                                    
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>

---

From: Adam Roach <[email-masked]>
Date: Fri, 22 Jun 2018 15:45:59 -0500

I've cleared my DISCUSS on the document. As one minor note, it appears 
that this comment from my review has not yet been addressed:

> §4.4:
>
> >     a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 5000 typ srflx
> >         raddr 2001:db8:a0b:12f0::1 rport 8998
>
> Thanks for the IPv6 example; however, I have a *lot* of heartburn with the
> selection of an example that demonstrates IPv6 NAT behavior. Since 
> ICE's srflx
> behavior is fundamentally tied to IPv4 NATs (and should not be an 
> issue with
> IPv6, as NATs are unnecessary), I think it's okay for the srvflx 
> examples to go
> ahead and show IPv4 addresses.
>
> I *really* don't want to publish an RFC that demonstrates NATting of IPv6

As the most recent version of the document still contains:

       a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 5000 typ srflx
           raddr 2001:db8:a0b:12f0::1 rport 8998

Was this intentional or an oversight?

/a

---

From: Thomas Stach <[email-masked]>
Date: Sat, 23 Jun 2018 11:23:29 +0200

Adam,

thanks for spotting this. This was clearly an oversight.

I'll change on the spot.

Regards

Thomas