Subject: [newtrk] wgs

From: Eliot Lear <[email-masked]>
Date: Fri, 26 Mar 2004 18:08:08 -0800

I largely concur with comments made by Eric Rosen.  Summary: If it looks 
like PS, it quacks like PS, and everyone except for a process wonk will 
treat it as PS.  Instead of lying to ourselves that it isn't PS, let's 
either call it PS or fix PS in some other way.

Cisco, like many other vendors, doesn't wait for documents to become PS. 
  BGP4 was probably the earliest example of this.  MPLS VPNs were 
another.  But it doesn't stop there.  Anyone who walks our enterprises 
MIB tree will see OIDs that look suspicously like various I-Ds.  We do 
this in particular when the market demands a solution.  Sometimes we 
don't get it perfectly right, and sometimes we do.

Were we to choose a good draft to code, it would likely be a WGS.  While 
that might sound like an endorsement of WGS, vendors will then scream 
holy hell when someone attempts to update the WGS.  They will behave 
identically to how one would behave if someone was attempting to update 
a PS.

There will be precisely one difference between WGS and PS: no IESG 
review.  Now it depends on your perspective as to whether you view this 
a good thing or a bad thing, but the result will be an end run around 
the IESG.

"Ah," you say, "but wait!  WGS I-Ds expire!"  Not unless someone invents 
disappearing ASCII ink and Google still exists.

I believe you are addressing the right problem at the wrong level.  The 
problem is that PS is broken.  The solution should be to fix PS.  PS 
itself must be shown to be just as ephemeral as your proposed WGS.  We 
(well, Lyman Chapin, really) got it right as far back as RFC 1310.  We 
just ignored our own good advice.

Not that we got it right all the way.  The motivations behind 
participants largely evaporate post PS.  That needs to be fixed.  Making 
PS ephemeral might do the trick.

Eliot
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 26 Mar 2004 19:02:53 -0800

I generally concur with the sediment that the Internet will
end up being ran on (expired) WGS instead of PSs.

I think if a WG has something they consider to be "stable"
that they want to publish quickly, they should simply submit
it for consideration as an Experimental RFC.  (And if
Experimental publication process is too slow, we should
address that.)

I am concerned that if we introduce WGS, WGs will generally
stop there (just as they generally stop at Proposed today).
And if they go the Experimental route, they will stop there.
But if WG do stop, I much rather have their last output
considered to be Experimental, an archived document, than
some "stable" but soon-to-expire snapshot.

I am also quite concerned that the WGS proposals do not
consider the need to produce same kind of snapshot for
individual I-D.  How can an WGS which normatively
references a individual I-D be labeled "stable" when
that individual I-D cannot be labeled in a like manner?
Can WG declare a WGS on a individual I-D (which hasn't
been submitted to the WG for consideration)?  If so, can
the individual change her I-D after such declaration by
a WG?

Kurt
 
At 06:08 PM 3/26/2004, Eliot Lear wrote:
>I largely concur with comments made by Eric Rosen.  Summary: If it looks like PS, it quacks like PS, and everyone except for a process wonk will treat it as PS.  Instead of lying to ourselves that it isn't PS, let's either call it PS or fix PS in some other way.
>
>Cisco, like many other vendors, doesn't wait for documents to become PS.  BGP4 was probably the earliest example of this.  MPLS VPNs were another.  But it doesn't stop there.  Anyone who walks our enterprises MIB tree will see OIDs that look suspicously like various I-Ds.  We do this in particular when the market demands a solution.  Sometimes we don't get it perfectly right, and sometimes we do.
>
>Were we to choose a good draft to code, it would likely be a WGS.  While that might sound like an endorsement of WGS, vendors will then scream holy hell when someone attempts to update the WGS.  They will behave identically to how one would behave if someone was attempting to update a PS.
>
>There will be precisely one difference between WGS and PS: no IESG review.  Now it depends on your perspective as to whether you view this a good thing or a bad thing, but the result will be an end run around the IESG.
>
>"Ah," you say, "but wait!  WGS I-Ds expire!"  Not unless someone invents disappearing ASCII ink and Google still exists.
>
>I believe you are addressing the right problem at the wrong level.  The problem is that PS is broken.  The solution should be to fix PS.  PS itself must be shown to be just as ephemeral as your proposed WGS.  We (well, Lyman Chapin, really) got it right as far back as RFC 1310.  We just ignored our own good advice.
>
>Not that we got it right all the way.  The motivations behind participants largely evaporate post PS.  That needs to be fixed.  Making PS ephemeral might do the trick.
>
>Eliot
>.

.

---

From: Keith Moore <[email-masked]>
Date: Sat, 27 Mar 2004 00:15:56 -0500

I don't agree with the proposed fix of making PS ephemeral, but I do 
agree that WGS is tantamount to an end-run around PS, and that it is 
not desirable to give the public the impression that a working group 
draft will be the basis of a standard.

I don't think making PS ephemeral will work for the same reasons that 
making WGS ephemeral won't work.

You can't make the document ephemeral.  What you have to do is make the 
early drafts of the _protocol_ ephemeral, in the sense that by design, 
they can't be expected to interoperate with the eventual standard.

My best idea so far for a fix is to eliminate PS, but add a Prototype 
stage.  Prototypes would be designed to demonstrate the features of the 
protocol being designed but to explicitly NOT interoperate with the 
eventual standard protocol.  (much like the IDN prefix was not chosen 
until the standard had been approved.)  Early Prototypes would not need 
to be complete designs, or to have resolved all known issues, or to 
have gained community consensus or peer review.  WGs could thus start 
experimenting with running code much earlier in the process than tends 
to be the case now, and hopefully they would identify more issues this 
way.

The purpose of the Prototype would be to get early implementation 
experience and interoperability testing - but with a disincentive to 
deploying the protocol in shipping product.  The first stable spec 
would then be fairly close to what is now Draft Standard - stable, 
resolved known design issues, no known technical omissions, community 
consensus, and multiple interoperable implementations of the last 
Prototype.  And instead of having Full Standard, it might be better to 
just review Draft Standards every few years to see if they're still 
applicable and/or they need updating.

Of course we couldn't stop vendors from shipping code that implemented 
Prototype specs.  And a vendor might be able to ship a single product 
(or upgrade) that could interoperate with both Prototype and approved 
standards.  But vendors shipping Prototype specs should design their 
products to be field-upgradable to the eventual standard, and should 
warn their customers that the products will need to be upgraded in 
order to interoperate with the future standard.  Ideally the Prototype 
protocol would be designed to facilitate phased migration by customers 
to the eventual standard (i.e. customers don't have to upgrade 
everything at once), but this is easier for some kinds of protocols 
than for others.

-Keith

On Mar 26, 2004, at 9:08 PM, Eliot Lear wrote:

> I largely concur with comments made by Eric Rosen.  Summary: If it 
> looks like PS, it quacks like PS, and everyone except for a process 
> wonk will treat it as PS.  Instead of lying to ourselves that it isn't 
> PS, let's either call it PS or fix PS in some other way.
>
> Cisco, like many other vendors, doesn't wait for documents to become 
> PS.  BGP4 was probably the earliest example of this.  MPLS VPNs were 
> Were we to choose a good draft to code, it would likely be a WGS.  
> While that might sound like an endorsement of WGS, vendors will then 
> scream holy hell when someone attempts to update the WGS.  They will 
> behave identically to how one would behave if someone was attempting 
> to update a PS.
>
> review.  Now it depends on your perspective as to whether you view 
> this a good thing or a bad thing, but the result will be an end run 
> around the IESG.
>
> "Ah," you say, "but wait!  WGS I-Ds expire!"  Not unless someone 
> invents disappearing ASCII ink and Google still exists.
>
> I believe you are addressing the right problem at the wrong level.  
> The problem is that PS is broken.  The solution should be to fix PS.  
> PS itself must be shown to be just as ephemeral as your proposed WGS.  
> We (well, Lyman Chapin, really) got it right as far back as RFC 1310.  
> We just ignored our own good advice.
>
> participants largely evaporate post PS.  That needs to be fixed.  
> Making PS ephemeral might do the trick.

.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 27 Mar 2004 11:31:21 -0800

Eliot,

EL> There will be precisely one difference between WGS and PS: no IESG
EL> review.

If working groups only use WGS for final declaration of completion,
then you are almost correct.  (IETF-wide Last Call is a non-trivial,
additional difference.)

Folks appear to view the intended use for _various_ snapshots along
the development process as being an important difference.

Working groups do lots of consensus assessments.  Apparently, formally
labeling any of them is now viewed as the same as PS.

This is not reasonable..

EL> "Ah," you say, "but wait!  WGS I-Ds expire!"  Not unless someone invents
EL> disappearing ASCII ink and Google still exists.

We regularly get this sort of claim about I-Ds, yet we still find that
the differences between I-D and RFC are substantial and useful.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 27 Mar 2004 20:55:19 -0600

Hi, Eliot,

> I believe you are addressing the right problem at the wrong level.
The
> just ignored our own good advice.

This may be true. I do have a couple of questions for the group, based
on your note.

As Eliot points out, every version of the IETF standards process that
we've had says that PS, and DS, is not a stable state. You either
advance, cycle based on an IESG review, or slide to historic (RFC
2026, Section 6.2).

If we've ever done a periodic review, it wasn't recently. We've
noodled on the IETF Discussion list about starting to do it now.

- Do we really think the IESG will do periodic reviews in the future?

The answer may be "yes, the IESG is dropping a significant review
burden - Allison said at the Plenary that half the documents they
reviewed since IETF 58 were non-IETF documents, and this work is
planned to drop off to a quick scan for end-runs". If somebody from
the IESG says "yes", I'll believe them, noting that this reverses a
ten-year trend, but some trends do change.

- Do we really think we'll be able to make "an IETF standard" count
for more than "a standards-track RFC"?

If the answer to this is "yes", I'll be thrilled, but also note that
this reverses a ten-year trend, and I'm a lot less sure of why this
change would happen.

Taking up the "What Standards" work couldn't hurt here. I happened to
query http://www.rfc-editor.org/rfcsearch.html for "SMTP" with the
search set to "STD" - you get four RFCs, and three of them have been
obsoleted by a PS document...

> participants largely evaporate post PS.  That needs to be fixed.
Making
> PS ephemeral might do the trick.

I can't find the reference, but I THOUGHT I've seen someone make the
point that in the few cases where we've moved documents to historic
status, we've been asked "with all the Proposed Standards that have
been Proposed Standard for longer than 2026 allows, why are you
picking on my document?" We're really, really used to PS that lives
forever, and this is orthogonal to RFCs that live forever.

Have a great weekend,

Spencer

p.s. I note that the lowest-number PS,
ftp://ftp.rfc-editor.org/in-notes/rfc698.txt, does not include an
author - if the author has forgotten writing it over the last 29
years, maybe we could evaluate that one safely? :-}

.

---

From: Eliot Lear <[email-masked]>
Date: Sat, 27 Mar 2004 22:54:59 -0800

Dave,

> then you are almost correct.  (IETF-wide Last Call is a non-trivial,

Forgive me, but I think I am correct, still.  Last call does not mandate 
  change before a document becomes a standard.  The IESG alone serves 
that function.  Indeed they may agree with certain comments received 
during last call, but ultimately it is the IESG that makes the decision 
about whether to advance a document, and that is what is at risk of 
being subverted.

> the development process as being an important difference.

My concern is not the intended use, but rather the unintended 
consequence.  By "unintended" I mean unintended by people advancing this 
idea.  WGs and WG chairs may intend to cirumvent the IESG.

> labeling any of them is now viewed as the same as PS.

Let's be clear as to what those consensus assessments are.  Typically 
they are on specific issues or features (should the text in Section 
3.4.1 be MUST or SHOULD, for instance).  I don't claim to have been at 
even a large minority of working groups, but what working group has 
called a consensus on an entire document that has not gone to Last Call?

> the differences between I-D and RFC are substantial and useful.

But Dave, you're changing both the denotation and the connotation of 
certain I-Ds making them more equal than others, to coin a phrase.

Again, I think you're working on the right problem but this is not the 
right solution (IMHO).  Fix PS and the need for such WGS docs goes away.

Eliot
.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 28 Mar 2004 09:18:51 -0800

Eliot,

>>   (IETF-wide Last Call is a non-trivial,
>> additional difference.)

EL> Forgive me, but I think I am correct, still.  Last call does not mandate
EL>   change before a document becomes a standard.  The IESG alone serves
EL> that function.

1. THere is a significant import is calling for an IETF-wide review
(ie., last call)

2. I now realize that the working-group level mechanism is not a Last
Call.  It is a regular working group consensus assessment, the same as
done for jillions of other _incremental_ working group decisions.

The more folks press for WGS to be have heavyweight overhead and
heavyweight import, the more we defeat its utility (or slide into
repeating the problem we have had with PS.)

EL> My concern is not the intended use, but rather the unintended
EL> consequence.  By "unintended" I mean unintended by people advancing this
EL> idea.  WGs and WG chairs may intend to cirumvent the IESG.

And they may not.

We all really need to stop treating abstract fears as if they were
historical imperatives.

We simply cannot anticipate or avoid all manner of problems.

We can be clear about our intent.  We can look for implications that
are certain or likely.  We can _not_ do anything reasonable with
implications that are "possible".

>> labeling any of them is now viewed as the same as PS.
...
EL> Let's be clear as to what those consensus assessments are.  Typically
EL> they are on specific issues or features

They are about every single thing the working group does. This
includes architecture, as well as components and features.

EL>  but what working group has
EL> called a consensus on an entire document that has not gone to Last Call?

I claim that any serious effort to solicit external reviews must get
some kind of working group consensus, first, or else the process is
too random and wasteful.

>> the differences between I-D and RFC are substantial and useful.

EL> But Dave, you're changing both the denotation and the connotation of
EL> certain I-Ds making them more equal than others, to coin a phrase.

We did that with the formal distinction between personal I-D and
"working group" I-D.  The impact does not seem to have been all that
terrible.

EL> Again, I think you're working on the right problem but this is not the
EL> right solution (IMHO).  Fix PS and the need for such WGS docs goes away.

The purpose of WGS is entirely different than PS (and yes, I mean the
original purpose of PS.)  Getting folks to understand that difference
seems to be the real challenge.

d/

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sun, 28 Mar 2004 15:22:50 -0600

To be fair, I saw WGS as pretty closely tied to the end of the
pre-standard process when we were writing
http://bgp.potaroo.net/ietf/old-ids/draft-dawkins-pstmt-twostage-00.txt
last June, so people might have this impression from talking to me a
long time ago.

We have been listening to feedback - what I'd heard so far had a major
impact on what I presented in Seoul, and on what's in our current
draft at
http://www.ietf.org/internet-drafts/draft-dawkins-newtrk-wgs-00.txt.

We are still listening - thanks to all for your comments.

Spencer

From: "Dave Crocker" <[email-masked]>

.

---

From: Eliot Lear <[email-masked]>
Date: Sun, 28 Mar 2004 14:20:27 -0800

Dave,

> 1. THere is a significant import is calling for an IETF-wide review

I agree, but its import is administratively enforced by the IESG. And it 

> repeating the problem we have had with PS.)

Right, but...

> We simply cannot anticipate or avoid all manner of problems.

I have posed you a problem that we CAN reasonably anticipate, and you 
haven't addressed it.  And it is not abstract.  Cisco and other vendors 
already implement Internet-drafts today.  The only case we have 
difficulty doing so is with MIBs that lack OIDs.  Once we implement we, 
like other vendors, don't want to changes.  Changes cost $$$.  If you 
provide vendors a mechanism to signify consensus, it will ossify.  This 
goes back to your earlier point about 'heavy weight overhead'.

Be mindful of John Wraclowski's comments in Minneapolis.  Understanding 
motivations is important.

> implications that are "possible".

That you speak with clear intent is important but irrelevant in as much 
as people will use the mechanism as they see fit within the limits of 
rules we set up.  They will take full advantage of those rules.

> includes architecture, as well as components and features.

Apparently I was unclear.  My point was and is that documents are not 
updated with every consensus call, but over some collection of features, 
components, etc.  Even when they are updated they do not reflect working 
group consensus because there are other components and features that 
have not been agreed to.

It is this fundamental skew that distinguishes I-Ds from candidates for PS.

> some kind of working group consensus, first, or else the process is

Today, that consensus is gotten only prior to going to the IESG.  But 
beyond that I otherwise disagree with you.  There's no reason why ANY 
version of an I-D should be excluded from external review.  They're out 
there to be reviewed, right!?  And this notion of "external" is a bit 
confusing.

> "working group" I-D.  The impact does not seem to have been all that

You're right, but let's look at the meaning of each change:

WG I-D:

This means that non-editorial changes would ideally be approved by 
consensus.  It does not mean that the document is ready for prime time. 
  Shockingly most people seem to understand this.

WGS I-D:

(Amongst others):
This marks the end of an iterative specification burst, to focus 
discussion or testing on a particular version.  That focus is what will 
bite.

> seems to be the real challenge.

Your purpose, yes.  Other peoples' purpose?  I'm concerned.

Eliot

.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 28 Mar 2004 18:13:43 -0800

Eliot,

EL> I have posed you a problem that we CAN reasonably anticipate, and you
EL> haven't addressed it.  And it is not abstract.  Cisco and other vendors
EL> already implement Internet-drafts today.

And there is nothing any of us can do to prevent that.

By an large, much of the difficulty in IETF process discussions seems
to stem from an inappropriate desire to be parental.

We need to be very clear in what we do and what we say we are doing.
And what we do needs to make sense.

Beyond that, efforts to anticipate other people's "abuse" of what we
do is simply not our problem.

Besides that, most of the concerns people express are about potential
difficulties, not actual ones.  The fact that someone does something
you or I might not want them to do is not necessarily an institutional
problem.  It becomes an institutional problem for the IETF when it
devalues IETF work or otherwise impedes IETF productivity.

EL> Be mindful of John Wraclowski's comments in Minneapolis.  Understanding
EL> motivations is important.

By and large, the IETF does very, very badly when it attends to
motivations.  It does much better when it attends to actual behavior
and direct effects of that behavior.

>> implications that are "possible".

EL> That you speak with clear intent is important but irrelevant in as much
EL> as people will use the mechanism as they see fit within the limits of
EL> rules we set up.  They will take full advantage of those rules.

Our stating our intent is helpful in guiding people who are
well-intentioned and helpful to our community when trying to resolve
boundary conditions.

EL> Apparently I was unclear.  My point was and is that documents are not
EL> updated with every consensus call, but over some collection of features,
EL> components, etc.

The timing and reasons for updating wg drafts varies enormously.

EL>  Even when they are updated they do not reflect working
EL> group consensus because there are other components and features that
EL> have not been agreed to.

Just FYI, the current -wgs- draft should not say "wg last call" in my
opinion.  As Spencer notes, the original idea for wgs was more in the
realm of "just before being submitted to the IESG".  The current
proposal is for a general-purpose, working group internal label.

It should say something like issuing the label is the result of a
working group consensus assessment.

As such, it should be a decision on a par with any other incremental
wg decision.

EL> WG I-D:

EL> This means that non-editorial changes would ideally be approved by
EL> consensus.  It does not mean that the document is ready for prime time.
EL>   Shockingly most people seem to understand this.

EL> WGS I-D:

EL> (Amongst others):
EL> This marks the end of an iterative specification burst, to focus 
EL> discussion or testing on a particular version.  That focus is what will
EL> bite.

Well, since the intended goal is to get people chewing on the
document, biting is good.

EL> Your purpose, yes.  Other peoples' purpose?  I'm concerned.

don't.

d/

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sun, 28 Mar 2004 21:16:28 -0600

Dear Eliot,

One of us may be confused. I'm not sure it's me... Please help me out!

Thanks, Spencer

From: "Eliot Lear" <[email-masked]>
To: "Dave Crocker" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, March 28, 2004 4:20 PM
Subject: Re: [newtrk] wgs

> It is this fundamental skew that distinguishes I-Ds from candidates
for PS.

It's my intention in our draft that we're talking about working group
I-Ds, and it's my understanding that working group I-Ds are supposed
to be under working group change control, with editors, not authors
typing new text and running it up the flagpole to see if anyone
salutes.

If this is not true in principle, please tell me - it's a pretty
important point for WGS.

If it's supposed to be true, but some WGs let editors write anything
that seems interesting for inclusion in revisions of working group
I-Ds, that's a different problem, it seems to me.

Spencer

.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 29 Mar 2004 06:23:30 -0800

Spencer,

In general I agree.  WG I-Ds are supposed to be under WG control. 
However, even if they are, they start out almost always as individual 
drafts with errors and omissions, and each such error or omission (save 
editorial) requires a consensus to get rid of.

That's my point below.

Eliot

Spencer Dawkins wrote:

>>Apparently I was unclear.  My point was and is that documents are
> 
> not
> 
>>updated with every consensus call, but over some collection of
> 
> features,
> 
>>components, etc.  Even when they are updated they do not reflect
> 
> working
> 
>>It is this fundamental skew that distinguishes I-Ds from candidates
> 
> for PS.
> 
.

---

From: Eric Rosen <[email-masked]>
Date: Mon, 29 Mar 2004 13:11:20 -0500

Dave> Beyond that, efforts to anticipate other people's "abuse" of what we
Dave> do is simply not our problem. 

I think this opinion is, well, peculiar. 

When putting into  place a process which is going to  govern the behavior of
an organization, it  is very important to understand  the motivations of the
participants, and to understand the  way in which the organization's outputs
will be used.  In  the absence of such an understanding, there  is no way to
judge the effect of the process. 

The big problem  with IETF discussions about process is  that we don't agree
on what we want to accomplish with the process.  

Dave> most of the concerns  people express are about potential difficulties,
Dave> not actual ones. 

I  think  the problems  being  cited are  actual  problems  based on  actual
people's actual experience  in the actual IETF.  Of  course, one could argue
that since  the document category  in question doesn't currently  exist, all
problems with it are merely "potential" :-)

.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 29 Mar 2004 10:44:51 -0800

Eric,

ER> When putting into  place a process which is going to  govern the behavior of
ER> an organization, it  is very important to understand  the motivations of the
ER> participants, and to understand the  way in which the organization's outputs
ER> will be used.  In  the absence of such an understanding, there  is no way to
ER> judge the effect of the process.

Actually this is quite wrong.  Motivations are internal.  Effects are
external.

As an expedient, I assume that all IETF participants are focused on
self interest and the interests of their sponsors. This assumption
simplifies things greatly. It saves debating fuzzy, unprovable
distractions about motivations.

Hence it requires focusing on the actual content of people's
statements.

A good idea is a good idea.  Sound logic is sound logic.  It does not
matter whose mouth such things come out of.

The IETF has no skill in judging people's motivations.

However, we often have pretty good skill at judging solid engineering arguments
and actual utility of the work.

We should focus on what we are good at.

d/

ps. No, I do not actually make the above assumption, but for process
discussions, I take that as the model. From a more theoretical base,
my view of how the IETF achieves "fairness" and "soundness" is by open
review and rough consensus, rather than by some sort of vetting
process on the motives of contributors. The IETF community of input
comprises highly diverse interests. It is this diversity that produces
a balancing effect on the potential bias of possibly self-serving
efforts.

.

---

From: Eric Rosen <[email-masked]>
Date: Mon, 29 Mar 2004 14:05:05 -0500

> matter whose mouth such things come out of. 

That's  true,  but  I  don't  see  the relevance  of  that  to  the  current
discussion, as we are speaking of  process, not of logic.  Process is run by
people, not by ideas,  and the output of the process is  used by people, not
by ideas.  A  process must be able to function  effectively in its political
environment.

> process on the motives of contributors. 

I don't recall  anyone having said that the process  itself should take into
account he motives  of contributors.  But these motives do  have to be taken
into account when creating the process. 

Frankly,  I'd  have  thought  that  everyone would  agree  that  the  proper
"logical" outcome can be derailed by special interest groups. 

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 29 Mar 2004 13:32:12 -0600

Hi, Eliot,

That's fair. I'd expect that a WG would either not declare a WGS for
an I-D it didn't agree with or would declare a WGS including a
declaration that they want feedback on Section 2 but were still
working on Section 4, so all bets are off in Section 4.

But I wouldn't mind adding a note about this to the draft.

Spencer

From: "Eliot Lear" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 29, 2004 8:23 AM
Subject: Re: [newtrk] wgs

.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 29 Mar 2004 16:36:48 -0800

Below are some review comments.  At this point, I remain
opposed to this proposal.  I think it will, at worse,
lead to end-runs around the Standards Process, and at
best, only provides a redundant passive communication
mechanism.   Below are my review notes.

Aside from these comments, I'd like to see discussion
on precisely where such labels would appear?  (In emails?
On WG webpage?  In the I-D tracker? In I-D search results?)
This would help readers understand the authors intent
with regards to these labels.

Kurt

---

The ABTRACT says WGSs are for "working group internal synchronization"
but the INTRODUCTION says "Working group document development
often requires coordination among participants and coordination
with those outside the working group".  This, Internal v
outside, doesn't jibe.

The label here, despite Dave's comments to the contrary,
is being used for WG external communication.  If in fact
the label was limited to "internal synchronization", a
WGS could be simply be implemented using a email to the
WG list.

>     Current difficulties include:
>     
>     *    The version of the specification that is used may be        
>          immature,

As are Proposed Standards.

>          and may change markedly between revisions.  

As do Proposed Standards.
    
>          This can cause confusion about the choice of version       
>          subject to common review, testing, or the like. 

Just implement the latest Proposed Standard (or the
latest I-D, if you are an early adopter).  But then
you accept the risk outlined in RFC 2026.

>     *    Different implementers may choose different                 
>          revisions of the specification as a basis for
>          development.

That is, I really don't see this as anymore than an endrun
around the Standands Track.  You are effectively saying a WG
can declare a specification to be mature enough to be
for a basis for development.  However, isn't this the
same basic implication of a Proposed Standard?  (Suitable
for development, but deployment in disruption-sensitive
environments is not recommended.)
  
>     *    The "running code" component of the IETF culture
>          clearly means that it is good to base a standard on
>          implementation history.  The implementation results
>          need to be discussed and documented in order for
>          this history to have its greatest value.

Yes, but "running code" doesn't require a WGS.  The process
has been running for years, driven by running code, without
WGS.  If "running code" is important to a particular
specification, the IESG can (as RFC 2026 indicates) require
implementation and/or operational experience.  And, of course,
a chair can insist on "running code" before considering
"rough consensus" as he thinks is necessary.

>     WGS can be assigned for any use the a working group finds
>     helpful. Example uses include:
>     
>     *     Marking which version of a working group document is
>           now felt to be appropriate for reviewing

For internal review, an email to the WG list will suffice.
For external review, simply marking a version for review is
insufficient to actually get it reviewed.  The WG has to
proactively obtain that review.  And, to do so, a WGS is
not needed and is somewhat dangerous (as WGs will rely
on this passive form of communication).

>     *     Marking the end of an iterative specification burst,
>           to focus discussion or testing on a particular    
>           version

An email to a WG list will suffice.  Again, a passive communication
such as labeling an I-D only communicates to those who see it.
WG management needs to be active.  The only way to reach every
member of the WG is by sending email to the WG list (which by
definition is the WG).
 
>     *     Defining a charter milestone for particular document
>           writing efforts

Not sure you are saying "creating a WGS" would be a particular
useful milestone or if you're saying that when a particular
milestone is met, that fact could be communicated by creation
of a WG.

In regards to the former, since a WGS can mean just about
anything, I don't see how "Mark WG I-D as a WGS" is a reasonable
milestone.  Specificity should be required in milestones.

In regards the latter, if a milestone was met, the chairs
should communicate (by email) to the secretariat the milestone
is now "Done" and, if appropriate, communicate this to the
WG by email.  That is, we already have reasonable means for
communicating that a milestone is done.

>     *     Marking a final working group stage, such as assigning
>           the label as part of a working group Last Call.

This can be communicating by having a milestone "initiate
WG Last call" and/or "WG Last Call completed" or simply by
email to the list (if its internal communication).  Of course,
the final stage of the WG process should be to progress the
I-D to the AD.  That's reflected in the I-D tracker.

I certainly hope creation of a WGs is not intended to be
necessary final step.  If so, then it clearly part of the
standards process.

>     A WGS is an Internet-Draft that achieves "rough consensus"
>     based on a Working Group Last Call.

Should this read:
        Marking of Internet-Draft as a WGS requires "rough
        consensus" of the WG for said purposes of the WGS.

That is, as worded, you are implying the WG has consensus on
the draft.  If it has that, then it should progress it to the
IESG.  So, I think what you intend is that the action of
marking an I-D as a WGS must be supported by WG consensus.
(And as an action, it appealable.)

>     A working group may assign WGS status at any time, for any
>     of its working group Internet-Drafts.

Except when that action is not supported by WG consensus.
Also, I think it wise to explicitly say which WGs cannot
take this action upon any document which is not theirs.

>     The document is subject to all normal I-D rules. When a WGS
>     specification needs more time, active effort on it will
>     usually result in changes to the specification being needed,
>     with a resulting new version of the document, and (possibly)
>     another working group decision to assign it WGS status.

I think this should more clearly state that WGS action is
taken with regards to a particular revision of an I-D and
when that I-D is revised or expired, the WGS status evaporates.
Another WGS action is needed to mark any subsequent revision.

>The label makes clear that the specification is a WG product,
>not an IETF product.

I don't see how this label adds clarification to who produced
the work.  Where is this label provided?  In the I-D tracker?
The tracker already has a field indicating WG ownership.
On the WG webpage?  Be listed on the WG page indicates WG
ownership.  Elsewhere?  where?

>     This proposal adds to the concept of of "working group
>     document", by enabling working groups to label stages of
>     internal specification efforts.

We already have this concept.

>     In particular, this will permit working group participants,
>     and the rest of industry, to coordinate their development
>     and testing efforts.

How?  Where would this label appear in IETF communications?
(e.g., mailings, web pages, tracker, etc.)

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 29 Mar 2004 19:24:38 -0600

Kurt,

Thanks for your review.

Spencer

.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 30 Mar 2004 15:49:38 -0500

I like the idea of a label representing some rough sense of the working 
group that this draft is more than just another in a long series.

However, as documented I do not think it achieves what we are after.

Firstly, because the proposal says that WGS can be used for X, Y, or Z, it 
means that a reader does not actually know what the WGS label means.  If we 
are going to define a label, I would suggest that we should agree on a 
specific meaning for the label.  Working groups can use the label in any 
context that matches that meaning.  (They may use internally choose 
additional conditions, but if the new reader is to know what the label 
means, it must have an agreed base meaning.)

Secondly, there is an odd interaction with document evolution.  When a 
given draft is "WGS", we presumably do not want to cause the working group 
to stop improving the documents.  And the next revision may not be 
"WGS".  This starts to lead us down the complexity of needing a separate 
"place" for the document, distinct from the base I-D.

Thinking about these issues leads to a conclusion along the lines of 
Harald's proposal that what is needed is a section in the document 
indicating what the status of parts of the document are.  This might be 
coupled with some mechanisms for saying ~draft-10 has material worth 
reviewing~ to the cross-area review that should be happening early.  It can 
also be coupled with clear notations on the working group web site about 
the status.  (I have come to believe that working groups need a web site 
distinct from the one generate from the secretariate data bases.)

One good thing about both Spencer's and Harald's proposals is that they can 
easily be tried out.  Working groups that want to can track "WGS" on their 
web page according to conditions they agree internally.  Working groups 
that want to can incorporate status sections into their I-Ds.  Some WGs 
could even do both.

Yours,
Joel

.