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

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