Re: [tcpm] Adopting draft-fairhurst-tcpm-newcwv

Pasi Sarolahti <pasi.sarolahti@iki.fi> Fri, 07 December 2012 14:01 UTC

Return-Path: <pasi.sarolahti@iki.fi>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2687B21F8983 for <tcpm@ietfa.amsl.com>; Fri, 7 Dec 2012 06:01:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mieTcLs35qrI for <tcpm@ietfa.amsl.com>; Fri, 7 Dec 2012 06:01:17 -0800 (PST)
Received: from kirsi2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6A521F893E for <tcpm@ietf.org>; Fri, 7 Dec 2012 06:01:17 -0800 (PST)
Received: from [192.168.1.65] (80.223.92.46) by kirsi2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 5087141600A29BF8; Fri, 7 Dec 2012 16:01:14 +0200
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="iso-8859-1"
From: Pasi Sarolahti <pasi.sarolahti@iki.fi>
In-Reply-To: <c06d44a9ce957e8518da19aa0d774be2.squirrel@www.erg.abdn.ac.uk>
Date: Fri, 07 Dec 2012 16:01:11 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <AD451E03-64B9-4B06-888C-58F55A02E61D@iki.fi>
References: <098EB5EC-480D-4DC6-898F-26CD9E31B580@iki.fi> <CAK6E8=d_Fu1+LUAbCzocp9x9HnbKqRhrU5wJ9Oqh_66-2BfAHg@mail.gmail.com> <c06d44a9ce957e8518da19aa0d774be2.squirrel@www.erg.abdn.ac.uk>
To: gorry@erg.abdn.ac.uk
X-Mailer: Apple Mail (2.1283)
Cc: tcpm <tcpm@ietf.org>
Subject: Re: [tcpm] Adopting draft-fairhurst-tcpm-newcwv
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Dec 2012 14:01:18 -0000

On Dec 3, 2012, at 11:02 AM, <gorry@erg.abdn.ac.uk> <gorry@erg.abdn.ac.uk> wrote:

> 
> I suggested "PS" - largely because I did not see a need for a specific
> experiment if the WG successfully finished the draft (and know it can be
> implemented).

RFC 2026 does not require that Experimental RFC defines any specific experiment. 

> Here's my thinking:

Thanks, useful reasoning about both cases.

[...]

> To me, I just want to get it deployed, and  recognise that the final
> status will only be determined at the end of the standards process. I'm
> happy to add/update whatever the draft with  text the WG suggests at the
> start of this draft - e.g. explaining why the draft needs to be EXP or why
> the standards status could change from PS to EXP as the work progresses.
> Other thoughts?

It would be best if we could decide on the status early, because it may affect how people review the document. If the WG is not confident about going for PS (for example, if people feel the design options have not been sufficiently investigated), then EXP should be the default option, I think. On the other hand, if we had to change the status at a late phase, I'd be much more comfortable at downgrading from PS to EXP than promoting a document to PS after people have thought they have been looking at an experimental document.

I think it is a good idea to add some text discussing the status, for example based on what you had in the Email. This could be something to be removed from the final version, but might support us in discussing this issue further, for example in the next meeting.

- Pasi