Subject: [Pesci-discuss] Hoping Pesci is still flopping around...

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 4 Jan 2006 08:37:40 -0600

Dear PESCI team,

The Gen-ART team tripped over a draft from some new authors this week with 
all kinds of problems, at least some of which result from the pile of 
process documents we are now using. (Don't worry, they had plenty of other 
problems - but our pile of process documents didn't help!)

"Problems" included things like missing normative references to other 
drafts, because they thought we weren't kidding when we said

>       ********************************************************
>       *                                                      *
>       *   Under no circumstances should an Internet-Draft    *
>       *   be referenced by any paper, report, or Request-    *
>       *   for-Proposal, nor should a vendor claim compliance *
>       *   with an Internet-Draft.                            *
>       *                                                      *
>       ********************************************************

... which would have been a whole lot easier to overlook, except it's IN A 
BOX FOR EMPHASIS... Of course, the following paragraph tells you a 
circimstance where you CAN reference an Internet-Draft, but perhaps the 
readers can be excused for thinking that "no circumstances" actually meant 
that there were less than one circumstance :-)

I also note that the IETF home page still points to RFC 2026, with no 
indication that "large parts of RFC 2026 are obsolete", if you click on "The 
Internet Standards Process", so it's not like we're helping anyone.

I also noticed this week that the RFC Editor home page ALSO points directly 
to RFC 2026 with no qualification as "The Internet Standards Process"...

Has PESCI resurfaced, post-Vancouver? I still think topics like 
http://www.ietf.org/internet-drafts/draft-carpenter-procdoc-roadmap-03.txt 
matter, but process doesn't evolve itself...

Thanks,

Spencer 

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 09 Jan 2006 14:28:00 +0100

Spencer,

The points you raise suggest territory that lies somewhere between
newtrk and pesci, plus a touch of web site maintenance.

Let me start by asking a question (and remember that this list
isn't a WG, so this question isn't constrained by a charter).

Should I do something with draft-carpenter-procdoc-roadmap?

I compiled it largely for my own education, but I do feel that
it may have (non normative) value.

If it did become an agreed guide to process documents, it could
well be used as a web site reference.

     Brian

Spencer Dawkins wrote:
> Dear PESCI team,
> 
> The Gen-ART team tripped over a draft from some new authors this week 
> with all kinds of problems, at least some of which result from the pile 
> of process documents we are now using. (Don't worry, they had plenty of 
> other problems - but our pile of process documents didn't help!)
> 
> ... which would have been a whole lot easier to overlook, except it's IN 
> A BOX FOR EMPHASIS... Of course, the following paragraph tells you a 
> readers can be excused for thinking that "no circumstances" actually 
> meant that there were less than one circumstance :-)
> 
> indication that "large parts of RFC 2026 are obsolete", if you click on 
> "The Internet Standards Process", so it's not like we're helping anyone.
> 
> I also noticed this week that the RFC Editor home page ALSO points 
> directly to RFC 2026 with no qualification as "The Internet Standards 
> Process"...
>

---

From: Pekka Savola <[email-masked]>
Date: Mon, 9 Jan 2006 17:42:54 +0200 (EET)

> Should I do something with draft-carpenter-procdoc-roadmap?
...
> well be used as a web site reference.

Maybe it could go live somewhere on the IETF web pages, in the same 
manner the IESG has published some other, possibly changing documents 
(e.g., http://www.ietf.org/ID-Checklist.html) ?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Jan 2006 14:22:45 +0100

> (e.g., http://www.ietf.org/ID-Checklist.html) ?

That would certainly be the easiest way to keep it available as a living
document. Comments on the current version would be most welcome.

    Brian

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 11 Jan 2006 08:13:57 -0600

Not sure if this is in-scope for PESCI or not...

I had a coversation with Brian in the Vancouver timeframe about some process 
ID (doesn't matter which), during which Brian asked me, (paraphrasing) 
"given that publishing this process document as a BCP/RFC makes it harder to 
modify, and increases the expense of publishing it at all, should we just 
publish this process document on a website and declare victory?".

We already have some process specs (including some "rfcxxxxbis" process 
specs) that look like they will live forever as drafts, including drafts on 
websites. It might be lovely to figure out how to know whether a process ID 
should be published in archival form or not, and, if not, where it SHOULD be 
published, in a consistent way.

Thanks,

Spencer

----- Original Message ----- 
From: "Brian E Carpenter" <[email-masked]>

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 11 Jan 2006 15:46:48 +0100

> Not sure if this is in-scope for PESCI or not...

... but there are sensible people on this list, so let's just chat....

> I had a coversation with Brian in the Vancouver timeframe about some
> process ID (doesn't matter which), during which Brian asked me,
> (paraphrasing) "given that publishing this process document as a BCP/RFC
> makes it harder to modify, and increases the expense of publishing it at
> all, should we just publish this process document on a website and
> declare victory?".
>
> specs) that look like they will live forever as drafts, including drafts
> on websites. It might be lovely to figure out how to know whether a
> process ID should be published in archival form or not, and, if not,
> where it SHOULD be published, in a consistent way.

I'd LOVE to have a specification for a publication mechanism that allows:

- the leadership to publish a revised version "whenever they have to"
- me to get at the current version extremely easily
- me to be notified when it changes (announcement, RSS, changelog...)
- me to be able to get at any older version with a little dilligence

A set of web pages with CVS version control, links to previous versions and 
an open subscription "notification" mailing list would satisfy approx 95% 
of my needs....
(I run a CVS with a notifier script; I'm pretty sure the web interface part 
exists too).

SHOULD be easy to set up....

                        Harald

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 11 Jan 2006 09:00:39 -0600

From: "Harald Tveit Alvestrand" <[email-masked]>

> - me to be able to get at any older version with a little dilligence

As Harald says in the following text, I think the technical problems are 
solveable (now that we aren't in the CNRI vortex on tool development, 
especially - not that this would be trivial, but that it would be doable).

I suspect that there are some publications that should be revises 
frequently, and others that should not, and I'm not sure that I know the 
complete list of either. I suspect that this overlaps the principles versus 
procedures/mechanisms discussion that we need to have about the PESCI draft. 
But I'm pretty sure that if we can figure out what the right thing to do is, 
we can make it happen.

> A set of web pages with CVS version control, links to previous versions 
> and an open subscription "notification" mailing list would satisfy approx 
> 95% of my needs....
> (I run a CVS with a notifier script; I'm pretty sure the web interface 
> part exists too).
>

And would be better than the random collection of web pages that we point 
people to in the tutorials, to take one example (I have not a lot of 
confidence that I'm pointing to all of the useful ones, and only somewhat 
more confidence that I am pointing to the most current text in each case, 
since when we decide to start squirreling stuff away on websites, we don't 
pick a default "right location"...)

For an exercise for the reader - find a smart person at your company who 
doesn't participate in the IETF and ask them if there is an IETF policy on 
timing of interim meetings, and where it might be. And how sure they are 
that the one they find in Google represents current IESG practice in 
approving interim meetings :-)

---

From: "Lucy E. Lynch" <[email-masked]>
Date: Wed, 11 Jan 2006 20:29:03 -0800 (PST)

> SHOULD be easy to set up....

substitute subversion for cvs and you're there...
http://www.edgewall.com/trac/

for example - http://svn.nuxeo.org/trac/pub/wiki

I set it up under Fedora core 4 (.9.3 w/ webadmin) in under a day -
still struggling w/ a freeBSD .9.2 install (webadmin doesn't work
for me).

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Jan 2006 12:36:17 +0100

Just tell me what's missing or obsolete at
http://www.ietf.org/u/ietfchair/opNotes.html

No CVS or RSS there of course, but it is an attempt at
collecting such stuff in one place.

    Brian

Spencer Dawkins wrote:
> complete list of either. I suspect that this overlaps the principles 
> versus procedures/mechanisms discussion that we need to have about the 
> PESCI draft. But I'm pretty sure that if we can figure out what the 
> right thing to do is, we can make it happen.
> 
>> A set of web pages with CVS version control, links to previous 
>> versions and an open subscription "notification" mailing list would 
>> satisfy approx 95% of my needs....
> And would be better than the random collection of web pages that we 
> point people to in the tutorials, to take one example (I have not a lot 
> of confidence that I'm pointing to all of the useful ones, and only 
> somewhat more confidence that I am pointing to the most current text in 
> each case, since when we decide to start squirreling stuff away on 
> websites, we don't pick a default "right location"...)
> 
> doesn't participate in the IETF and ask them if there is an IETF policy 
> on timing of interim meetings, and where it might be. And how sure they 
> are that the one they find in Google represents current IESG practice in

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 12 Jan 2006 13:17:32 +0100

> collecting such stuff in one place.

"What changed, and when".