Subject: [Ice] Éric Vyncke's No Objection on draft-ietf-ice-pac-04: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Tue, 21 Apr 2020 07:29:39 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-ice-pac-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ice-pac/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for this short and easy to read document.

But, I cannot refrain from wondering about this part as the trickle-ice I-D is
still in RFC editor queue => easier to fix it in the body of the trickle-ice
IMHO (could be wrong): "[RFC EDITOR NOTE: Please replace RFC XXXX with the RFC
number of
   draft-ietf-ice-trickle once it has been published.  Please also
   indicate that this specification updates RFC XXXX.]"

I also wonder why section 1 talks about 'race conditions' while the issue is
related to a too short default time-out or in the use cases of section 3. (in
my mind, 'race conditions' is an unusual sequence of events).

Explanations will be welcome (albeit not blocking).

-éric

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Apr 2020 16:29:07 +0000

Hi Éric,

Thank You for the review! Please see inline.

    > number of draft-ietf-ice-trickle once it has been published.  Please also

Originally we assumed that trickle-ice was going to be published before ice-pac. The reason trickle-ice has been on hold in the RFC editor queue is because it is part of the Cluster 238 collection of drafts, which all are intended to be published at the same time.

Having said that, we think it is more clear to fix both RFC 8445 and trickle-ice in the same place (this draft). Much of the content is describing the problems, and making the trickle update in trickle-ice would mean that we would have to copy/paste most of the text there.

    > my mind, 'race conditions' is an unusual sequence of events).

English is not my native language, so I hope Justin can comment on this.
    
Regards,

Christer

---

From: Barry Leiba <[email-masked]>
Date: Tue, 21 Apr 2020 13:35:02 -0400

>     > my mind, 'race conditions' is an unusual sequence of events).

For what it's worth, a "race condition" is simply a case where results
differ based on the order that things happen (depending upon "who wins
the race").  If the results of something are different depending upon
factors such as which entity has more latency at the moment, which
process got swapped out at the wrong time, or just who happened to get
a "better" time-slice just now, we have a race condition.

In the case described in the document, if a candidate gets its "name"
in while the endpoint is still processing things, that candidate is
considered; if it's a little too late, say because of network latency
or slower processing somewhere or the like, then it doesn't get
considered.  That sounds like a race condition to me.

Barry

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 21 Apr 2020 19:24:09 +0000

Hello Christer,

Thank you for the explanation about the update of a document still "blocked" in the RFC editor queue. Up to you and your responsible AD.

Even after Barry's kind explanations about "race conditions" (in French "conditions de course" :-) ...), I feel that this does not apply to this document (cfr use case in section 3.1) but I really do not mind. Just wanted to raise a flag.

Regards and thank you for your document

-éric

-----Original Message-----
From: Christer Holmberg <[email-masked]>
Date: Tuesday, 21 April 2020 at 18:29
To: Eric Vyncke <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Nils Ohlmeier <[email-masked]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-ice-pac-04: (with COMMENT)

    Hi Éric,

    Regards,

    Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Apr 2020 21:45:17 +0000

Hi Éric,

Thanks for your comments! Unless Justin says it's not a race condition, I'll keep it :)

Regards,

Christer

On 21/04/2020, 22.24, "Eric Vyncke (evyncke)" <[email-masked]> wrote:

    Hello Christer,

    
    
    -éric
    
    -----Original Message-----
    From: Christer Holmberg <[email-masked]>
    Date: Tuesday, 21 April 2020 at 18:29
    To: Eric Vyncke <[email-masked]>, The IESG <[email-masked]>
    Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Nils Ohlmeier <[email-masked]>
    Subject: Re: Éric Vyncke's No Objection on draft-ietf-ice-pac-04: (with COMMENT)
    
        Hi Éric,

    

    

        Regards,
    
        Christer

---

From: Justin Uberti <[email-masked]>
Date: Mon, 27 Apr 2020 18:38:11 -0700

I looked into this a bit more closely and I tend to agree that 'race
condition' isn't the ideal term here, because most of the listed situations
(3.1, 3.2) are not timing-specific. Here's my simple suggestion:

OLD:
        However, there is an inherent race condition
        here; if, before learning about any peer-reflexive candidates, an
        endpoint runs out of candidate pairs to check, either because it has
        none, or it considers them all to have failed, it will prematurely
        declare failure and terminate ICE processing. This race condition
can
        occur in many common situations.

NEW:
        However, there is an inherent *problem*
        here; if, before learning about any peer-reflexive candidates, an
        endpoint runs out of candidate pairs to check, either because it has
        none, or it considers them all to have failed, it will prematurely
        declare failure and terminate ICE processing. This *problem* can
        occur in many common situations.

On Tue, Apr 21, 2020 at 2:45 PM Christer Holmberg <
[email-masked]> wrote:

>     Thank you for the explanation about the update of a document still
> "blocked" in the RFC editor queue. Up to you and your responsible AD.
>
>     Even after Barry's kind explanations about "race conditions" (in
> French "conditions de course" :-) ...), I feel that this does not apply to
> this document (cfr use case in section 3.1) but I really do not mind. Just
> wanted to raise a flag.
>
>     Cc: "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>,
> Nils Ohlmeier <[email-masked]>
>         Originally we assumed that trickle-ice was going to be published
> before ice-pac. The reason trickle-ice has been on hold in the RFC editor
> queue is because it is part of the Cluster 238 collection of drafts, which
> all are intended to be published at the same time.
>
>         Having said that, we think it is more clear to fix both RFC 8445
> and trickle-ice in the same place (this draft). Much of the content is
> describing the problems, and making the trickle update in trickle-ice would
> mean that we would have to copy/paste most of the text there.
>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 28 Apr 2020 07:19:42 +0000

It works for me (and my comment was non-blocking anyway)

-éric

From: iesg <[email-masked]> on behalf of Justin Uberti <[email-masked]>
Date: Tuesday, 28 April 2020 at 03:38
To: Christer Holmberg <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, The IESG <[email-masked]>, Nils Ohlmeier <[email-masked]>, Eric Vyncke <[email-masked]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-ice-pac-04: (with COMMENT)

I looked into this a bit more closely and I tend to agree that 'race condition' isn't the ideal term here, because most of the listed situations (3.1, 3.2) are not timing-specific. Here's my simple suggestion:

OLD:
        declare failure and terminate ICE processing. This race condition can

NEW:
        However, there is an inherent problem
        here; if, before learning about any peer-reflexive candidates, an
        endpoint runs out of candidate pairs to check, either because it has
        none, or it considers them all to have failed, it will prematurely
        declare failure and terminate ICE processing. This problem can
        occur in many common situations.

On Tue, Apr 21, 2020 at 2:45 PM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi Éric,

Regards,

Christer

On 21/04/2020, 22.24, "Eric Vyncke (evyncke)" <[email-masked]<mailto:[email-masked]>> wrote:

    Hello Christer,

    -éric

    -----Original Message-----
    From: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
    Date: Tuesday, 21 April 2020 at 18:29
    To: Eric Vyncke <[email-masked]<mailto:[email-masked]>>, The IESG <[email-masked]<mailto:[email-masked]>>
    Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:ice@ietf..org>>, Nils Ohlmeier <[email-masked]<mailto:[email-masked]>>
    Subject: Re: Éric Vyncke's No Objection on draft-ietf-ice-pac-04: (with COMMENT)

        Hi Éric,

        Having said that, we think it is more clear to fix both RFC 8445 and trickle-ice in the same place (this draft). Much of the content is describing the problems, and making the trickle update in trickle-ice would mean that we would have to copy/paste most of the text there..

        Regards,

        Christer