Subject: [Insipid] Mirja Kühlewind's No Objection on draft-ietf-insipid-session-id-26: (with COMMENT)

From: "Mirja Kuehlewind" <[email-masked]>
Date: Mon, 15 Aug 2016 09:13:46 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-insipid-session-id-26: 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-insipid-session-id/

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

I'm wondering, given that RFC 7329 is informational and given that this
doc is backwards-compatitile to it, if this doc really obsoletes RFC7329,
or just updates it...?

---

From: "Paul Giralt (pgiralt)" <[email-masked]>
Date: Mon, 15 Aug 2016 17:44:24 +0000

Mirja, 

Thanks for the comments. The intent is for this draft to replace the functionality described in RFC 7329, not just update it. For all intents, it is a new specification that just happens to be designed to be backwards compatible with 7329. 

I’m referring to the differences between obsolete and update here: 

https://tools.ietf.org/rfc/

Obsoletes xxxx refers to other RFCs that this one replaces;
Obsoleted by xxxx refers to RFCs that have replaced this one.
Updates xxxx refers to other RFCs that this one merely updates but
does not replace); Updated by xxxx refers to RFCs that have updated
(but not replaced) this one.  Generally, only immediately succeeding
and/or preceding RFCs are indicated, not the entire history of each
related earlier or later RFC in a related series.

It seems to me that Obsoletes is appropriate because the intent is to do away with the old behavior, as it has several deficiencies that are addressed by the new draft. The new draft is also significantly different than 7239 in a variety of ways for which I’d be happy to provide more details if needed. 

-Paul

> On Aug 15, 2016, at 12:13 PM, Mirja Kuehlewind <[email-masked]> wrote:
>

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 18 Aug 2016 22:34:44 -0500

Closing the loop on a few comments before I approve the draft:

I think one way to look at this is, we hope not to see "new" 
implementations of 7329. But there's enough legacy implementations 
deployed we still need to work with them, and they aren't going away for 
a while.

On 15 Aug 2016, at 12:44, Paul Giralt (pgiralt) wrote:

> Mirja,
>
> Thanks for the comments. The intent is for this draft to replace the 
> functionality described in RFC 7329, not just update it. For all 
> intents, it is a new specification that just happens to be designed to 
> be backwards compatible with 7329.
>
> It seems to me that Obsoletes is appropriate because the intent is to 
> do away with the old behavior, as it has several deficiencies that are 
> addressed by the new draft. The new draft is also significantly 
> different than 7239 in a variety of ways for which I’d be happy to 
> provide more details if needed.
>
> -Paul
>
>
>
>> Please refer to 
>> https://www.ietf.org/iesg/statement/discuss-criteria.html
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 19 Aug 2016 19:03:17 +0200

Hi,

I understand the intention here and also looked at the definition cited by Paul below and my conclusion was that this rather seem like an update then obsolete. However, I don’t have a strong opinion and am fine with whatever you decide.

Mirja

> Am 19.08.2016 um 05:34 schrieb Ben Campbell <[email-masked]>:
> 
> I think one way to look at this is, we hope not to see "new" implementations of 7329. But there's enough legacy implementations deployed we still need to work with them, and they aren't going away for a while.
> 
> 
> 
> 
>