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

+1 - having the formal historical record seems like a good idea

Scott

On Mar 2, 2012, at 2:51 PM, Bob Briscoe wrote:

> +1
> 
> At 10:30 02/03/2012, karagian@cs.utwente.nl wrote:
>> 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
> 
> ________________________________________________________________
> Bob Briscoe,                                BT Innovate & Design 
> _______________________________________________
> PCN mailing list
> PCN@ietf.org
> https://www.ietf.org/mailman/listinfo/pcn