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

["Bradner, Scott" <[e-mail]>]

Dave - 

just to be sure - you are not suggesting to not have a reference to an expired ID (by document name, not by filename) are you?

Scott

On Mar 6, 2012, at 1:23 PM, David Harrington wrote:

> 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)
> [e-mail]
> [phone]
> 
> 
> 
> 
> 
> On 3/5/12 6:22 AM, "[e-mail]" <[e-mail]> 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: [e-mail] [mailto:[e-mail]]
>> Sent: 05 March 2012 10:46
>> To: Eardley,PL,Philip,DUB8 R; [e-mail]; [e-mail]
>> 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: [e-mail] [mailto:[e-mail]]
>>> Sent: vrijdag 2 maart 2012 12:06
>>> To: Karagiannis, G. (Georgios); [e-mail];
>>> [e-mail]
>>> 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: [e-mail] [mailto:[e-mail]] On Behalf Of
>>> [e-mail]
>>> Sent: 02 March 2012 10:30
>>> To: [e-mail]; [e-mail]
>>> 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: [e-mail] [mailto:[e-mail]] 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/pcn
>>> _______________________________________________
>>> PCN mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/pcn
>> _______________________________________________
>> PCN mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pcn
> 
> 
> _______________________________________________
> PCN mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pcn