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

Hi,

I hope I parsed your  double negatives appropriately.
I was suggesting that having a normative reference to an expired draft
could be problematic.

I see that one of the drafts was revised as Historic .
Is the WG decision to publish these as Historic or let them disappear?
The IESG needs to know.

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

On 3/8/12 12:14 PM, "Bradner, Scott" <sob@harvard.edu> wrote:

>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)
>> 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
>> 
>> 
>> _______________________________________________
>> PCN mailing list
>> PCN@ietf.org
>> https://www.ietf.org/mailman/listinfo/pcn
>