Re: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison

<karagian@cs.utwente.nl> Fri, 02 March 2012 10:30 UTC

Return-Path: <karagian@cs.utwente.nl>
X-Original-To: pcn@ietfa.amsl.com
Delivered-To: pcn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B1B21F8B21 for <pcn@ietfa.amsl.com>; Fri, 2 Mar 2012 02:30:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.504
X-Spam-Level:
X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHk4LB3hqUog for <pcn@ietfa.amsl.com>; Fri, 2 Mar 2012 02:30:18 -0800 (PST)
Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7345C21F8B20 for <pcn@ietf.org>; Fri, 2 Mar 2012 02:30:14 -0800 (PST)
Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 2 Mar 2012 11:30:26 +0100
Received: from EXMBX04.ad.utwente.nl ([169.254.4.150]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.01.0339.001; Fri, 2 Mar 2012 11:30:13 +0100
From: karagian@cs.utwente.nl
To: toby.moncaster@cl.cam.ac.uk, pcn@ietf.org
Thread-Topic: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison
Thread-Index: AQHM+FkxhTXOfjwcgkGGPdMD7WPldZZWzcQQ
Date: Fri, 02 Mar 2012 10:30:12 +0000
Message-ID: <FF1A9612A94D5C4A81ED7DE1039AB80F22C51CE8@EXMBX04.ad.utwente.nl>
References: <9C874ADA-1419-4AF4-B075-47FEDA98E999@cl.cam.ac.uk>
In-Reply-To: <9C874ADA-1419-4AF4-B075-47FEDA98E999@cl.cam.ac.uk>
Accept-Language: nl-NL, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.89.12.129]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PCN WG list <pcn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcn>, <mailto:pcn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcn>
List-Post: <mailto:pcn@ietf.org>
List-Help: <mailto:pcn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Mar 2012 10:30:19 -0000

Hi,

I agree with Toby that Option 1 is probably the best one to choose!

Best regards,
Georgios

> -----Original Message-----
> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of
> Toby Moncaster
> Sent: vrijdag 2 maart 2012 10:45
> To: pcn
> Subject: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison
> 
> Adrian Farrel is keen to find out what the WG intentions are regarding the
> "other" WG encoding drafts. Just to remind everyone, the original idea was
> to have the baseline encoding and a set of 3 experimental encodings that
> built on it. Then Bob got RFC6040 published and we decided to push 3-in-1
> encoding as the main standard. This left the other experimental encodings in
> limbo. They are:
> 
> draft-ietf-pcn-psdm-encoding-01 <http://tools.ietf.org/html/draft-ietf-pcn-
> psdm-encoding-01>
> 
> draft-ietf-pcn-3-state-encoding-01 <http://tools.ietf.org/html/draft-ietf-
> pcn-3-state-encoding-01>
> 
> These are both cited in the encoding comparison draft which poses some
> potential problems. Firstly we are not meant to refer to IDs in RFCs, secondly
> these have both long expired so will eventually disappear from any archives,
> thirdly I believe Michael may still want to use PSDM experimentally?
> 
> There would seem to be 3 possible courses of action:
> 
> 1) We ask for these to be published as historical RFCs so they can be
> referenced from encoding comparison
> 2) we ask for these to be published as experimental schemes so they can be
> referenced and can be used
> 3) we remove all reference from the encoding comparison
> 
> OPtion 1 is probably the easiest as (hopefully) they would not need too much
> updating. Option 2 requires more work on the drafts (in light of the fact we
> are obsolete RFC5696 which they both depend on), but would at least hold
> the door open to future work. Option 3 partially defeats the point of the
> encoding comparison document.
> 
> I have a very slight preference for option 1, but what do other people think?
> 
> Toby
> _______________________________________________
> PCN mailing list
> PCN@ietf.org
> https://www.ietf.org/mailman/listinfo/pcn