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

David Harrington <ietfdbh@comcast.net> Tue, 06 March 2012 18:23 UTC

Return-Path: <ietfdbh@comcast.net>
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 E7A3D21F88A1 for <pcn@ietfa.amsl.com>; Tue, 6 Mar 2012 10:23:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.952
X-Spam-Level:
X-Spam-Status: No, score=-101.952 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, USER_IN_WHITELIST=-100]
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 3vXlhLzcVlPX for <pcn@ietfa.amsl.com>; Tue, 6 Mar 2012 10:23:42 -0800 (PST)
Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id F24C721F8618 for <pcn@ietf.org>; Tue, 6 Mar 2012 10:23:41 -0800 (PST)
Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta10.westchester.pa.mail.comcast.net with comcast id iJMk1i0020vyq2s5AJPi2C; Tue, 06 Mar 2012 18:23:42 +0000
Received: from [192.168.1.33] ([71.233.85.150]) by omta05.westchester.pa.mail.comcast.net with comcast id iJPh1i0123Ecudz3RJPhjg; Tue, 06 Mar 2012 18:23:42 +0000
User-Agent: Microsoft-MacOutlook/14.14.0.111121
Date: Tue, 06 Mar 2012 13:23:38 -0500
From: David Harrington <ietfdbh@comcast.net>
To: philip.eardley@bt.com, karagian@cs.utwente.nl, toby.moncaster@cl.cam.ac.uk, pcn@ietf.org
Message-ID: <CB7BBCE1.1D69F%ietfdbh@comcast.net>
Thread-Topic: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison
In-Reply-To: <9510D26531EF184D9017DF24659BB87F331CDBF70A@EMV65-UKRD.domain1.systemhost.net>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
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: Tue, 06 Mar 2012 18:23:43 -0000

Hi,

It appears to me the drafts have already expired.
You can refer to expired drafts in an Informational document, using an
approach similar to this:

   The XYZ encoding was proposed in a draft document submitted to the PCN
WG in <October
   2006>. The PCN WG chose to not advance this draft.


This way there is no reference to the expired draft, and the intentions to
not carry the drafts forward is easy to see.

Now, as to whether publishing them as historical is the right way:
How much more detail is in the drafts that will be lost if we just let
them expire?
Is it important to the industry to keep a record of that historical
detail, or just a summary of the ideas in those drafts and why they didn't
work.
I can understand that academically, it might be nice to have these
published as historical records, but I tend to agree that having them
published as RFCs could confuse people who are not really knowledgeable
about IETF practice and the difference in types of RFCs.
If the summary seems adequate, then I recommend letting the drafts
disappear.
You should make sure all your documents do not contain any references to
those drafts.

--
David Harrington
Director, Transport Area
Internet Engineering Task Force (IETF)
Ietfdbh@comcast.net
+1-603-828-1401





On 3/5/12 6:22 AM, "philip.eardley@bt.com" <philip.eardley@bt.com> wrote:

>Yes - I think the encoding comparison draft provides a good historical
>record of the various encodings that we thought of and their pros/cons.
>Publishing the encodings as historical RFCs doesn't seem to me to add
>much value, and creates extra work for WG /iesg /ietf reviewers
>
>phil
>
>-----Original Message-----
>From: karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl]
>Sent: 05 March 2012 10:46
>To: Eardley,PL,Philip,DUB8 R; toby.moncaster@cl.cam.ac.uk; pcn@ietf.org
>Subject: RE: [PCN] IESG feedback from 3-in-1 encoding/ encoding
>comparison 
>
>Hi Phil,
>
>Do you mean that you are rather against publishing the other encodings
>drafts as historical RFCs.
>
>In a previous email I have mentioned that Option 1 (publish encodings
>drafts as historical RFCs) proposed by Toby is probably the best choice.
>
>However, I will not strongly insist on this option. I am also fine if we
>will not publish these encodings drafts as historical RFCs. The encoding
>comparison draft provides then the historical record of what these other
>encodings are (with the reference to the current I-Ds) like and the
>reasons pro/anti them.
>
>Best regards,
>Georgios
>
>
>> -----Original Message-----
>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
>> Sent: vrijdag 2 maart 2012 12:06
>> To: Karagiannis, G. (Georgios); toby.moncaster@cl.cam.ac.uk;
>>pcn@ietf.org
>> Subject: RE: [PCN] IESG feedback from 3-in-1 encoding/ encoding
>> comparison
>> 
>> Just a correction, lots of RFCs refer to internet drafts.
>> 
>> I don't think Adrian's comment was one about the mechanics of
>>references,
>> but what the status is of these other encodings.
>> So the solution is simple, the comparison doc spells out (more) clearly
>>that
>> they were ones we thought about, recorded here for posterity, but are
>>now
>> no longer being pursued - in favour of 3-in-1
>> 
>> << It appears that there are a number of alternative encoding being
>> proposed as documented in this I-D, draft-ietf-pcn-3-state-encoding,
>>draft-
>> ietf-pcn-psdm-encoding, etc., and as discussed in
>>draft-ietf-pcn-encoding-
>> comparison. It isn't clear to me whether these encodings are being
>>proposed
>> to co-exist, to be used by different operators depending on specific
>> environments, or whether they are being floated to see which one gets
>> more market-place support.>>
>> 
>> -----Original Message-----
>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of
>> karagian@cs.utwente.nl
>> Sent: 02 March 2012 10:30
>> To: toby.moncaster@cl.cam.ac.uk; pcn@ietf.org
>> Subject: Re: [PCN] IESG feedback from 3-in-1 encoding/ encoding
>> comparison
>> 
>> 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
>> _______________________________________________
>> PCN mailing list
>> PCN@ietf.org
>> https://www.ietf.org/mailman/listinfo/pcn
>_______________________________________________
>PCN mailing list
>PCN@ietf.org
>https://www.ietf.org/mailman/listinfo/pcn