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

["Eric Vyncke (evyncke)" <[e-mail]>]

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

-éric

From: iesg <[e-mail]> on behalf of Justin Uberti <[e-mail]>
Date: Tuesday, 28 April 2020 at 03:38
To: Christer Holmberg <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, The IESG <[e-mail]>, Nils Ohlmeier <[e-mail]>, Eric Vyncke <[e-mail]>
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:
        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 <[e-mail]<mailto:[e-mail]>> wrote:
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)" <[e-mail]<mailto:[e-mail]>> wrote:

    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 <[e-mail]<mailto:[e-mail]>>
    Date: Tuesday, 21 April 2020 at 18:29
    To: Eric Vyncke <[e-mail]<mailto:[e-mail]>>, The IESG <[e-mail]<mailto:[e-mail]>>
    Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:ice@ietf..org>>, Nils Ohlmeier <[e-mail]<mailto:[e-mail]>>
    Subject: Re: Éric Vyncke's No Objection on draft-ietf-ice-pac-04: (with COMMENT)

        Hi Éric,

        Thank You for the review! Please see inline.

            ----------------------------------------------------------------------
            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.]"

        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..

            > 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).

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

        Regards,

        Christer