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

From: Warren Kumari via Datatracker <[email-masked]>
Date: Wed, 22 Apr 2020 13:08:39 -0700

Warren Kumari 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:
----------------------------------------------------------------------

Like Eric (and others) I think making a change to trickle before it becomes an
RFC would be as better idea than Update'ing it in this way.

I also think it would be really useful for the Abstract to have a sentence
saying (in a very high level way *how* this updates RFC8445 e.g:  This document
updates RFC8445 by requiring that an ICE   agent wait a minimum amount of time
before declaring ICE failure,   even if there are no candidate pairs left".
This makes it clear to implementors if/why they need to read this document.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Apr 2020 21:32:22 +0000

Hi Warren,

Thank You for the review! Please see inline.

    > RFC would be as better idea than Update'ing it in this way.
    
    I prefer to keep the current way. In addition to the fact that lots of text would be identical, we would have to define the PAC timer in both specs, which would be confusing.

    > This makes it clear to implementors if/why they need to read this document.

    I will add such statement to the Abstract.

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Wed, 22 Apr 2020 16:44:12 -0500

> RFC would be as better idea than Update'ing it in this way.

To be clear, trickle has been through AUTH48, and the only reason it 
isn't RFC 8452 _right now_ is because we decided, back in 2018, to pull 
it back and make sure it had a number that was consecutive with other, 
related Cluster 238 documents.

If this is causing substantial heartburn, I would propose that the best 
remedy -- even if only because it highlights how pointlessly 
bureaucratic this objection is -- would be to ask the RPC to publish the 
post-AUTH48 trickle document _right now_ with the next available RFC 
number and then let ice-pac update it. The collateral damage will be 
that it's not published alongside documents that it really should be; 
but (IMHO) that's less worrisome than pulling it out of the queue after 
AUTH48 to do additional surgery on it.

/a

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Apr 2020 16:10:30 -0600

> AUTH48 to do additional surgery on it.

With my trickle co-author hat on, I'm +1 on surgery avoidance. :-)

Peter

---

From: Warren Kumari <[email-masked]>
Date: Thu, 23 Apr 2020 15:37:10 -0400

> related Cluster 238 documents.

Ooooh ooooh, you mean that if I dig in my heels, we can make C238 take
even more time?! "That's a nice cluster of documents you have there...
be a shame if anything were to happen to it...." :-P

>
> If this is causing substantial heartburn,

Nah, just seemed a bit silly -- I was unaware of the history; 'm fine
leaving it as it is...

W

> I would propose that the best

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 23 Apr 2020 19:53:35 +0000

Thanks, Warren!

As I indicated earlier, I will add some text to the Abstract regarding what is updated.

Regards,

Christer

On 23/04/2020, 22.38, "Warren Kumari" <[email-masked]> wrote:

    

    W