Subject: Re: [Ice] Adam Roach's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT)

From: Adam Roach <[email-masked]>
Date: Thu, 1 Mar 2018 14:24:17 -0600

On 2/24/18 5:14 AM, Christer Holmberg wrote:
>
>>>> The document currently appears to contain normative statements that, while not literally contradictory, certainly point implementors in conflicting directions.
>>>> §5.1.1.1 says:
>>>>
>>>>    o  Host candidates corresponding to IPv6 link-local addresses MUST
>>>>       NOT be gathered.
>>>>
>>>> Further down, §6.1.2.2 says:
>>>>
>>>>    To keep the amount of resulting candidate pairs  reasonable and to
>>>> avoid candidate pairs that are highly unlikely to  work, IPv6
>>>> link-local addresses [RFC4291] MUST NOT be paired with  other than
>>>> link-local addresses.
>>>>
>>>> This second passage is nonsensical if IPv6 link local addresses MUST
>>>> NOT be gathered. Please remove or amend one of these normative statements. If the first statement is retained, please add rationale.
>>> Ben had the same comment. My suggestion was to remove the text in 6.1.2.2.
>>>
>>> I guess the rationale is since a local-link address may not be valid for communicating with the peer.
>> Well, it is if they're on the same link. For example, when I ssh from one machine in my house to another, it generally uses an
>> IPv6 link-local address. WebRTC is explicitly expected to use this optimal path if it exists. I think the fix that Ari proposes makes more sense.
> I agree. I will fix as suggested by Ari.

I reviewed the text in the -18 version of the document, and it doesn't 
seem to correctly reflect the suggestion -- or at least, it is 
ambiguous. What is in there now is:

>     o  If one or more host candidates corresponding to an IPv6 address
>        generated using a mechanism that prevents location tracking
>        [RFC7721] are gathered, host candidates corresponding to IPv6
>        addresses that do allow location tracking that are configured on
>        the same interface and are part of the same network prefix MUST
>        NOT be gathered; and host candidates corresponding to IPv6 link-
>        local addresses [RFC4291] MUST NOT be gathered.

The problematic phrase still appears; it's just after a semicolon now. 
It seems highly likely that impelementors will read the phrase as being 
unqualified rather than only applying when RFC 7721 addresses are used. 
Perhaps:

    o  If one or more host candidates corresponding to an IPv6 address
       generated using a mechanism that prevents location tracking
       [RFC7721] are gathered, host candidates corresponding to IPv6
       addresses that do allow location tracking that are configured on
       the same interface and are part of the same network prefix MUST
       NOT be gathered. Similarly, when host candidates corresponding
       to an IPv6 address generated using a mechanism that prevents
       location tracking are gathered, then host candidates corresponding
       to IPv6 link-local addresses [RFC4291] MUST NOT be gathered.

/a

---

From: Ari Keränen <[email-masked]>
Date: Thu, 1 Mar 2018 20:28:29 +0000

> On 1 Mar 2018, at 22.24, Adam Roach <[email-masked]> wrote:
> 
> I reviewed the text in the -18 version of the document, and it doesn't seem to correctly reflect the suggestion -- or at least, it is ambiguous. What is in there now is:
> 
> The problematic phrase still appears; it's just after a semicolon now. It seems highly likely that impelementors will read the phrase as being unqualified rather than only applying when RFC 7721 addresses are used. Perhaps:
> 
> 

This looks good to me. Thanks!

Cheers,
Ari

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 Mar 2018 21:44:20 +0000

Hi,

>>>>>>   To keep the amount of resulting candidate pairs  reasonable and 
>>>>>> to avoid candidate pairs that are highly unlikely to  work, IPv6 
>>>>>> This second passage is nonsensical if IPv6 link local addresses 
>>>>>> MUST NOT be gathered. Please remove or amend one of these normative statements. If the first statement is retained, please add rationale.
>>>> Well, it is if they're on the same link. For example, when I ssh 
>>>> from one machine in my house to another, it generally uses an
>> The problematic phrase still appears; it's just after a semicolon now. It seems highly likely that impelementors will read the phrase as being unqualified rather than only >applying when RFC 7721 addresses are used. Perhaps:
>> 
>> 

I created a pull request (also contains some other editorial nits, based on comments from Ari):

https://github.com/ice-wg/rfc5245bis/pull/62

Regards,

Christer