Subject: Re: ion-ion-store open for public comment

From: Marshall Eubanks <[email-masked]>
Date: Fri, 15 Dec 2006 08:43:42 -0500

Dear Brian;

On Dec 15, 2006, at 5:03 AM, Brian Carpenter wrote:

> An ION (IETF Operational Note, see RFC 4693) is open for public  
> comment
> on the [email-masked] list. Comments should be sent by 2006-12-31.
>

You don't say to where comments should be sent, so I am sending this  
to the IETF list.

In this ION, there is
HTTP Access to IONs

The IONs can be found at:
http://www.ietf.org/IESG/content/ions
The standard HTTP URL for the current version of this document would  
then be "http://www.ietf.org/IESG/content/ions/ion-ion-store.html",  
and the stable URL to the dated version would be "http://www.ietf.org/ 
IESG/content/ions/dated/ion-ion-store-2006-07-23.html".
HTTP Access to Drafts
Drafts open for public comments can be downloaded with HTTP at:

http://www.ietf.org/IESG/content/ions/drafts

Both of these URLs point to "naked" directory lists, which only give  
the file name and the date. This means of
archiving  documents does not scale; I would recommend at least a  
small index.html file at those sites, with at least

- the link to the file
- a brief description of each ION
- its date

and probably an IPR statement or link to the Note Well at the bottom.  
This would scale up to a few dozen IONs, which would take a
while.

If you want, I could prepare a mock-up of this for the 3 existing  
drafts.

Regards
Marshall

> Please see
> http://www.ietf.org/IESG/content/ions/drafts/ion-ion-store.html
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 Dec 2006 16:27:42 +0100

Marshall Eubanks wrote:
>> An ION (IETF Operational Note, see RFC 4693) is open for public  comment
> You don't say to where comments should be sent, so I am sending this  to 
> the IETF list.

Um, that is why the note refers to this list.

> then be "http://www.ietf.org/IESG/content/ions/ion-ion-store.html",  and 
> the stable URL to the dated version would be "http://www.ietf.org/ 
> archiving  documents does not scale; I would recommend at least a  small 
> index.html file at those sites, with at least
> 
> - the link to the file

Possibly, but we want to stay informal (see the last but one sentence
in ion-ion-store).

> This would scale up to a few dozen IONs, which would take a

Well, my thought is that the plain directory does scale for a few dozen,
but not beyond. I agree that at some point an index is needed. I built an
index manually at http://www.ietf.org/u/ietfchair/opNotes.html for
the pre-existing notes. Is that the sort of thing you mean?
> 
> If you want, I could prepare a mock-up of this for the 3 existing  drafts.

What we would need is a tool to update it automatically. And I'm not sure
we want to do that for an experiment (but if you feel the coding urge,
don't hold back ;-).

Thanks

     Brian

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 15 Dec 2006 11:21:38 -0500

On Dec 15, 2006, at 10:27 AM, Brian E Carpenter wrote:

>> You don't say to where comments should be sent, so I am sending  
>> this  to the IETF list.
>

Sorry, I didn't parse it that way when I first read it, but I see it  
does now. Must have
been too little coffee.

Of course, at first glance I thought this message was some sort of  
spam selling ION-IONs...

Regards
Marshall

>> The standard HTTP URL for the current version of this document  
>> would  then be "http://www.ietf.org/IESG/content/ions/ion-ion- 
>> store.html",  and the stable URL to the dated version would be  
>> "http://www.ietf.org/ IESG/content/ions/dated/ion-ion- 
>> store-2006-07-23.html".
>> HTTP Access to Drafts
>> Both of these URLs point to "naked" directory lists, which only  
>> give  the file name and the date. This means of

---

From: Fred Baker <[email-masked]>
Date: Fri, 15 Dec 2006 15:17:57 -0800

This document describes a process for managing a set of documents.  
IMHO, it is a bit onerous; I may be ignorant, but I don't know how to  
get an account on tools.ietf.org, and I'm not sure that having ssh  
access to the machine is necessary. Approaches used by common  
blogging and wiki software seem sufficient for most practical purposes.

Also, I seem to have managed to miss the fundamental set of reasons  
that this is set up. RFC 4693 discusses having something less  
permanent than and RFC and more referenceable than an internet draft.  
Well, ok, but for what purpose? http://tools.ietf.org/html/<draft  
name> gives us a permanent record of the most recent and each step in  
an internet draft's development. For example, you might check

http://tools.ietf.org/html/draft-baker-tsvwg-mlpp-that-works-00
http://tools.ietf.org/html/draft-baker-tsvwg-mlpp-that-works-01
http://tools.ietf.org/html/draft-baker-tsvwg-mlpp-that-works-02
http://tools.ietf.org/html/draft-baker-tsvwg-mlpp-that-works

http://tools.ietf.org/html/draft-ietf-tsvwg-mlpp-that-works-00
http://tools.ietf.org/html/draft-ietf-tsvwg-mlpp-that-works-01
http://tools.ietf.org/html/draft-ietf-tsvwg-mlpp-that-works-02
http://tools.ietf.org/html/draft-ietf-tsvwg-mlpp-that-works-03
http://tools.ietf.org/html/draft-ietf-tsvwg-mlpp-that-works-04
http://tools.ietf.org/html/draft-ietf-tsvwg-mlpp-that-works

http://tools.ietf.org/html/rfc4542

So internet drafts, however ephemeral we claim them to be, are  
versioned and referenceable. I don't know that the final step (the  
RFC) is any less permanent than the history we maintain of the drafts  
leading up to it.

The great value I see mentioned is that it is in HTML and can  
reference images. Personally, expanding our rules on internet drafts  
to allow for these seems sufficient to me. Or asserting that posting  
of a PDF that allows for "grabbing" of text, which we in fact already  
do, would be a good thing. I am very much in favor of xml2rfc- 
generated HTML files, which I find easier on the eyes than text format.

In short, under what circumstances would I post an ION instead of an  
internet draft? Why would I refer to an ION rather than an internet  
draft? This looks like a solution in search of a problem, but I'm  
willing to be told I'm missing something.

/lost in a maze of twisty passages, all of them different but looking  
remarkably similar...

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 16 Dec 2006 16:42:15 +0100

Fred Baker wrote:
> get an account on tools.ietf.org,

Really? I thought most WG chairs had one by now. There is a button to
click on the tools web site.

> and I'm not sure that having ssh  
> access to the machine is necessary. Approaches used by common  blogging 
> and wiki software seem sufficient for most practical purposes.

SFTP with a key pair is for protecting the main IETF web site. That is for
a very small club of people. As for tools server security, we just do what
Henrik tells us :-) But really, I found installing all this stuff trivial,
even on Windows.

> that this is set up. RFC 4693 discusses having something less  permanent 
> than and RFC and more referenceable than an internet draft.  Well, ok, 
> but for what purpose? 

For things like those currently held at
http://www.ietf.org/u/ietfchair/opNotes.html
(and that is a discusion of whether the RFC 4693 experiment
is useful; that discussion comes a year from now).

> http://tools.ietf.org/html/<draft  name>

<snip>

> versioned and referenceable. I don't know that the final step (the  RFC) 
> is any less permanent than the history we maintain of the drafts  
> leading up to it.

That's beside the point. This is nothing to do with RFC development.
This is for stuff that will (almost certainly) never be an RFC.

<snip>
> internet draft? 

If you were, for example, the maintainer of 1id-guidelines.

Anyway - again, this is an experiment, and yours are the questions
to be asked at the end of the experiment.

     Brian

---

From: Dave Crocker <[email-masked]>
Date: Sun, 17 Dec 2006 18:05:45 -0800

> to be asked at the end of the experiment.

Brian, et al,

The basic desire to collect together the documents that the IETF uses for its 
"internal" operations strikes me as simple and entirely pragmetic. (I have to 
note that until this latest set of postings, I thought that ION's somehow 
competed with BCPs, by virtue of being related to operations.)

One might want to wonder, a bit, about the IETF's having a growing number of 
such documents, and that this might make it more difficult to know enough about 
IETF procedures and the like, but it is clear that the body of documents are 
better collected under one reference roof than being strewn around.

As for you last sentence, perhaps it should give some pause.  The idea that we 
do not already have a pretty clear idea of what should distinguish an I-D from 
an ION ought to engender concern.  Like any other project consuming significant 
resources, an "experiment" is supposed to have reasonably clear statements of 
differentiation and expected benefit.

On reflecting about the forces that seem to have led to the creation of the ION 
"experiment", I suspect that there are two concerns:  1) Needing a label that 
collects together internal operating notes and distinguishes them from other 
IETF documents, and 2) the overhead of getting an RFC published.

The first could be solved easily by adding a new, non-standard-track sub-label 
to the RFC series and I suspect the latter could be resolved by making an 
arrangement with the RFC Editor to have IONs go through less handling and 
proofing overhead. (And, gosh, this might even give a basis for reviewing why 
RFC publication has become high overhead...)

Although probably warranting an entirely separate thread, it might again be 
worth revisiting the question of archival access to expired I-Ds.  The number of 
times that folks suffer from not being able to easily get access to old copies 
is growing. The most obvious of these is for intellectual property research, but 
one that is closer to home is to be able to aid in assessing the sequence of 
changes that a document went through, by way of responding to improvements in 
working group discussions.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 18 Dec 2006 10:05:01 +0100

Dave Crocker wrote:
>>> RFC) is any less permanent than the history we maintain of the 
>>> drafts  leading up to it.
>>
>>
> The basic desire to collect together the documents that the IETF uses 
> for its "internal" operations strikes me as simple and entirely 
> pragmetic. (I have to note that until this latest set of postings, I 
> thought that ION's somehow competed with BCPs, by virtue of being 
> related to operations.)
> 
> One might want to wonder, a bit, about the IETF's having a growing 
> number of such documents, and that this might make it more difficult to 
> know enough about IETF procedures and the like, but it is clear that the 
> body of documents are better collected under one reference roof than 
> being strewn around.
> 
> As for you last sentence, perhaps it should give some pause.  The idea 
> that we do not already have a pretty clear idea of what should 
> distinguish an I-D from an ION ought to engender concern.  Like any 
> other project consuming significant resources, an "experiment" is 
> supposed to have reasonably clear statements of differentiation and 
> expected benefit.

I personally believe that it is clear in RFC 4693. (I also believe
we have a number of process BCPs that contain operational details
that don't really belong there, but pre-ION we had no systematic
way to handle such details.)

> On reflecting about the forces that seem to have led to the creation of 
> the ION "experiment", I suspect that there are two concerns:  1) Needing 
> a label that collects together internal operating notes and 
> distinguishes them from other IETF documents, and 2) the overhead of 
> getting an RFC published.
> 
> The first could be solved easily by adding a new, non-standard-track 
> sub-label to the RFC series and I suspect the latter could be resolved 
> by making an arrangement with the RFC Editor to have IONs go through 
> less handling and proofing overhead. (And, gosh, this might even give a 
> basis for reviewing why RFC publication has become high overhead...)

Again - this is exactly what we should discuss at the *end* of the
experiment, by which time we'll also have significant experience
with the new RFC Editor contract.

> Although probably warranting an entirely separate thread, it might again 
> be worth revisiting the question of archival access to expired I-Ds.  
> The number of times that folks suffer from not being able to easily get 
> access to old copies is growing. The most obvious of these is for 
> intellectual property research, but one that is closer to home is to be 
> able to aid in assessing the sequence of changes that a document went 
> through, by way of responding to improvements in working group discussions.

Indeed it's a separate topic...

    Brian

---

From: Dave Crocker <[email-masked]>
Date: Mon, 18 Dec 2006 09:49:53 -0800

Brian E Carpenter wrote:
> I personally believe that it is clear in RFC 4693. 

That's fine, Brian, but at least some of us were confused.

That ought to cause some concern.

I suspect concern divides between folks like me, who really didn't even 
understand the scope of the documents intended for this series, and others who 
remain unclear why the overhead of an entirely new publication mechanism is 
required.  Better writing -- an maybe better labeling -- will fix the former 
concern.  The latter concern is deeper.

> (I also believe

Sure.  And I wasn't commenting about prior publications.

>> On reflecting about the forces that seem to have led to the creation 
>> of the ION "experiment", I suspect that there are two concerns:  1) 
>> Needing a label that collects together internal operating notes and 
>> less handling and proofing overhead. (And, gosh, this might even give 
>> a basis for reviewing why RFC publication has become high overhead...)
> 

So you want to develop a community history with a new class of documents called 
ION that are published independently from any existing mechanism and then later 
consider re-homing them?

This highlights why the term "experiment" can be misleading.

If this sort of experiment is successful, then there will be significant 
disruption to the user base if the mechanism is moved to a new hosting mechanism.

(The irony, here, is that the Arpanet suffered this same problem.  Intended and 
used as an "experiment" it also immediately became so thoroughly useful as an 
operational communications infrastructure so that scheduling real experiments 
became problematic.)

d/
-- 

   Dave Crocker

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 18 Dec 2006 18:20:10 -0500

On Sunday, December 17, 2006 06:05:45 PM -0800 Dave Crocker 
<[email-masked]> wrote:

> One might want to wonder, a bit, about the IETF's having a growing number
> of such documents, and that this might make it more difficult to know
> enough about IETF procedures and the like

On the contrary, I don't think the process has gotten any more complex; we 
just have more documentation about it.  Whether that makes it easier or 
harder to know enough about IETF procedures would seem to depend on the 
accuracy and currency of that documentation.

> a label that collects together internal operating notes and distinguishes
> them from other IETF documents, and 2) the overhead of getting an RFC
> published.
>
> sub-label to the RFC series and I suspect the latter could be resolved by
> making an arrangement with the RFC Editor to have IONs go through less
> handling and proofing overhead. (And, gosh, this might even give a basis
> for reviewing why RFC publication has become high overhead...)

I don't think it's just about the overhead of getting an RFC _published_; 
it's about the overhead of achieving IETF consensus on one.  Process BCP's 
should be about IETF-level policy, not the operational practices of the I* 
or of any other entity that implements those policies.

Recently, the Federal Communications Commission in the US adopted a number 
of changes to regulations governing the Amateur Radio service.  The changes 
were "officially" published on November 15, and went into effect 30 days 
later.  In between, someone noticed an error which inadvertently made 
certain operations illegal that should not have been, and asked the FCC to 
fix it.  The fix was approved on December 15, the same day the new 
regulations became effective, and will probably become effective sometime 
in February.

The same sort of correction would have taken the IETF six months to a year 
plus a lot of arguing and reopening old issues.  A similar correction to an 
ION would have taken days, at most.  And that's sort of the point - overall 
policy should be set by IETF consensus, but operational details should not.

-- Jeff

---

From: Dave Crocker <[email-masked]>
Date: Mon, 18 Dec 2006 22:41:56 -0800

Jeffrey Hutzelman wrote:
> On the contrary, I don't think the process has gotten any more complex; 
> we just have more documentation about it.

1. We used to have far more flexibility about wg process than we now do. Small 
tasks required small effort.  The substantial procedures for creating and 
running a working group and producing documents that are today typical used to 
be reserved for larger and more difficult efforts. This includes now tending to 
require BOFs and tending to require Requirements documents, and so on.

2. The requirements for the form of wg documents have also changed, notably with 
respect to required boilerplate.  In addition, the boilerplate changes with some 
regularity and the enforcement of the requirements is substantially more stringent.

I'm sure the list is longer, but the above seem sufficient for making the point.

> I don't think it's just about the overhead of getting an RFC 
> _published_; it's about the overhead of achieving IETF consensus on 
> one.  Process BCP's should be about IETF-level policy, not the 
> operational practices of the I* or of any other entity that implements 
> those policies.

Yes, the rules are different, just as the rules for Informational RFCs are 
different from standards track RFCs.  That's why the idea of a new RFC 
sub-category make sense.

> The same sort of correction would have taken the IETF six months to a 
> year plus a lot of arguing and reopening old issues. 

And then there is the possibility that you are describing a deeper IETF problem 
that needs its own focus...

d/
-- 

   Dave Crocker

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Dec 2006 10:06:02 +0100

Dave Crocker wrote:
> 
> 
> Brian E Carpenter wrote:
> 
>>> As for you last sentence, perhaps it should give some pause.  The 
>>> idea that we do not already have a pretty clear idea of what should 
> understand the scope of the documents intended for this series, and 
> others who remain unclear why the overhead of an entirely new 
> publication mechanism is required.  Better writing -- an maybe better 
> labeling -- will fix the former concern.  The latter concern is deeper.

I hate to sound like a cracked record, but let's run the experiment
that was approved quite some time ago and find out at the end if
it works.

>>> sub-label to the RFC series and I suspect the latter could be 
>>> resolved by making an arrangement with the RFC Editor to have IONs go 
>>> through less handling and proofing overhead. (And, gosh, this might 
>>> even give a basis for reviewing why RFC publication has become high 
>>> overhead...)
>>
>>
> So you want to develop a community history with a new class of documents 
> called ION that are published independently from any existing mechanism 
> and then later consider re-homing them?
> 

As stated in 4693, we'd simply keep them as web pages at www.ietf.org.
This isn't rocket science.

    Brian

> 
> (The irony, here, is that the Arpanet suffered this same problem.  
> Intended and used as an "experiment" it also immediately became so 
> thoroughly useful as an operational communications infrastructure so 
> that scheduling real experiments became problematic.)
> 
> d/

---

From: Dave Crocker <[email-masked]>
Date: Tue, 19 Dec 2006 06:55:42 -0800

Brian E Carpenter wrote:
> As stated in 4693, we'd simply keep them as web pages at www.ietf.org. This
> isn't rocket science.

Thanks for making clear that my concern about developing entrenched behavior is
correct.

In other words, Brian, by running the experiment, in its current form, you are
ensuring that meaningful changes can't be made without disruption.

So it is not an 'experiment', in any normal sense of the word.

d/
-- 

   Dave Crocker

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Dec 2006 16:12:09 +0100

> ensuring that meaningful changes can't be made without disruption.

I truly don't get your concern. We have mechanisms today to get
operational material onto the IETF web site. We won't be siwtching
those mechanisms off while running the ION experiment. If, which
I doubt, we decide IONs aren't a success, we will simply post the
ION material to the web site in the current way. If they are a success,
we'll consolidate the ION mechanism in the light of experience.
I don't see disruption either way.

    Brian

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 19 Dec 2006 14:32:22 -0500

On Monday, December 18, 2006 10:41:56 PM -0800 Dave Crocker 
<[email-masked]> wrote:

>>> know enough about IETF procedures and the like
>>

> [...]

OK; I stand corrected - the process has gotten more complex, and in many 
cases less flexible.  But the documentation has improved, too.  We can 
argue forever about the advantages and disadvantages of the former and how 
to fix what's wrong without making it more broken, but I hope we can agree 
that having good documentation is helpful.

> Yes, the rules are different, just as the rules for Informational RFCs
> are different from standards track RFCs.  That's why the idea of a new
> RFC sub-category make sense.

Maybe.  But it seems sort of heavyweight to me.

> And then there is the possibility that you are describing a deeper IETF
> problem that needs its own focus...

I'm probably describing a symptom of such a problem.  But I've been unable 
to figure out what the real problem is, and I'm starting to get weary of 
the effort, and of band-aids that promise to make everything all better 
without such understanding.

-- Jeff

---

From: Dave Crocker <[email-masked]>
Date: Wed, 20 Dec 2006 07:22:33 -0800

> those mechanisms off while running the ION experiment. If, which

Then I can't figure out what goes into the 'experiment' and what doesn't. It 
sounds as if this becomes redundant -- ie, extra -- effort.  That reduces the 
incentive to use it.

> I don't see disruption either way.

"consolidate" does not mean making changes, or "changes" doesn't mean disruption?

d/
-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Wed, 20 Dec 2006 07:22:33 -0800

d/
-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Wed, 20 Dec 2006 07:25:16 -0800

> cases less flexible.  But the documentation has improved, too.  We can 

It has improved massively.  I wasn't commenting on that.

> argue forever about the advantages and disadvantages of the former and 
> how to fix what's wrong without making it more broken, but I hope we can 
> agree that having good documentation is helpful.
> 
> 

ION is a brand new publication mechanism.

That makes it the most heavyweight alternative possible, in terms of total cost. 
Whether it imposes more or less 'weight' onto the users is only one of the 
issues, and my point about defining a new RFC category specified a lighterweight 
overhead than for, say, a standards-track RFC.

d/

-- 

   Dave Crocker

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Dec 2006 11:35:10 +0100

Dave,

Dave Crocker wrote:
> Then I can't figure out what goes into the 'experiment' and what 
> doesn't. It sounds as if this becomes redundant -- ie, extra -- effort.  
> That reduces the incentive to use it.

As the person who created the existing "Operational Notes" page, and
submitted one of the two draft IONs, I found the very minor extra effort
to use a decent shared-authoring version management system well worth
it. Kudos to the SVN people and to Henrik, of course.

> "consolidate" does not mean making changes, or "changes" doesn't mean 

Well, if change means disruption, I experience disruption most days of
the week ;-). My point is that the changes involved will all be at noise
level.

Enough. Happy holidays to all!

     Brian