Subject: RE: OPEN ISSUE: Standards Track

From: <[email-masked]>
Date: Fri, 16 May 2003 09:39:33 +0300

More mumbles ...

> there's another issue here, but I don't know if it is 
> possible to untangle it......
> 
> *what sort of bugs, if detected, would make a protocol unsuitable for 
> Proposed Standard?*

Bugs that cause interoperability failures.

> If there are 2 reasonable interpretations of a statement, which could lead 
> to 2 noninteroperable interpretations? (Happened with BGP, I believe..... 
> common practice now is only one, and there is a new spec 
> being written that clarifies the point)

That would be a red flag, in my opinion.

> If there is part of the overall function that is not specified, so that you 
> can implement it, but it can do nothing useful without further 
> specification? (my favourite example is TIP, if anyone remembers that)

This, in my opinion, shouldn't be a show-stopper.

> If there are issues that you know will arise when people try it, for 
> instance "what is an alphabetic character"? (one of the 
> recent specs out of PKIX)

Most likely a showstopper.

> It's fairly obvious that we invented the 3-step process so that we could 
> fix bugs. And that implies that we think there are bugs that will only be 
> flushed out after people try it out in practice.

I always thought that the 3 step process was used because we wanted to get
deployment experience sooner rather than later.  In a past life, I implemented
some Intelligent Network protocols.  If anyone has a spare month, take a look
into some CoreINAP specifications. Suffice it to say that 90% of the spec is
probably unimplementable - forget about deployment issues.  I don't think
that we want to go down that road.

We should make good proposed standards, which may have some flaws or some
open issues, things that need refinement - but getting implementation,
deployment & real-world use is key.

> But - does that mean that we should let known bugs pass into Proposed?
> Or will this be forever a judgment call?

Bugs can be in the eye of the beholder, that is why I think focusing on
known interoperability problems should be something not passed into
Proposed Standards.  SOme other issues are more judgement calls, in my
mind.

> A related issue is whether or not the restrictions on going to Draft from 
> Proposed are really appropriate; currently, we say that *only* deletion of 
> features is appropriate, and that any change or extension, no matter how 
> worthwhile the purpose or how sure we are that it makes no problems, 
> requires another round through Proposed. Is this really best for the 
> Internet?

I can't say - anyone have examples?

John

---

From: <[email-masked]>
Date: Fri, 16 May 2003 14:41:38 -0500

> > For example, I think that it should be possible for several
> different
> > proposals that solve the same problem to be published in an enduring
> > form by the IETF, and for a subsequent process to determine which
> > one(s) will advance on the standards-track.  This would solve some
> > of the problems that we have in the v6ops WG, for example.  But, we
> > have no tools to do this in a way that makes the status of these
> > documents visible to our "customers".
> >
> 
> My understanding is that that is one purpose of the Experimental
> designation.

Which unfortunately I believe is not done as much by WGs in the
IETF. 
>         jak

-bp

---

From: "Bilel Jamoussi" <[email-masked]>
Date: Fri, 16 May 2003 16:16:54 -0400

This highlights the need for 'mandatory' training that new ADs and WG chairs
have to go through before they assume their duty.

--------------------------
bnj

-----Original Message-----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>;
[email-masked] <[email-masked]>;
[email-masked] <[email-masked]>
Sent: Fri May 16 15:41:38 2003
Subject: RE: OPEN ISSUE:  Standards Track

-bp

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 20 May 2003 17:40:10 +0200

Maybe this is just me... but I have difficulty keeping up with
this mailing list... (In fact I am some 500 postings behind).

So when I see postings like below... I wonder....
Is this really the task of this WG?
It seems a problem, but are those core problems or 
root causes of problems that we need to get on the table?

Thanks,
Bert 

> From: Spencer Dawkins [mailto:[email-masked]]
> Sent: dinsdag 20 mei 2003 17:18
> To: [email-masked]
> Subject: Re: OPEN ISSUE: Standards Track
> 
> 
> Dear Margaret,
> 
> Well, now that you mention it, I believe these items would 
> help people find
> things:
> 
> - actual use of the STD maturity level, so that many 
> questions could be
> answered by "look at STD n", no matter what has happened to 
> the underlying
> RFCs and errata sheets lately,
> 
> - a severe pruning to Historical of protocols that aren't 
> still widely used,
> 
> - possibily even a severe pruning to Historical of protocols 
> that aren't
> still being deployed (even if they are still in use),
> 
> - decent STF organization (note that STD 5 includes SIX RFCs 
> on IP and ICMP.
> Conversely, how many Telnet options are there? they're spread 
> across SIX
> STDs).
> 
> - I really like the Updated By/Obsoleted By information you 
> get when you
> SEARCH for a document at 
http://www.rfc-editor.org/rfcsearch.html, but this
information could appear other places, too (in document bodies would be
nice, but I know we don't change RFCs without changing RFC numbers).

Others?

Spencer

----- Original Message -----
From: "Margaret Wasserman" <[email-masked]>
To: "Keith Moore" <[email-masked]>
Cc: <[email-masked]>; "Brian E Carpenter"
<[email-masked]>
Sent: Tuesday, May 20, 2003 9:42 AM
Subject: Re: OPEN ISSUE: Standards Track

>
> Hi Keith,
>
> At 10:36 AM 5/20/2003 -0400, Keith Moore wrote:
> >one thing I'd like to see us consider is to issue more applicabliity
> >statements, errata documents, and implementation notes, rather than
> >revising an entire document to accomodate minor changes.  we could do
that
> >even for Standard documents.
>
> I would agree, if our existing document set was organized to make
> it easier for people to find associated documents.  Maybe that
> is something we can change/fix?
>
> Margaret

---

From: Melinda Shore <[email-masked]>
Date: Wed, 21 May 2003 13:30:52 -0400

The question was this:

>There is also a more fundamental issue with the IETF's engineering
>practices.  Although our current standards track contains three
>levels of maturity (Proposed Standard, Draft Standard and Full
>Standard), we do not have sufficient differentiation regarding the
>quality and completeness of documents required at each stage.  The
>bar is set very high for publication at Proposed Standard, and very
>few documents advance beyond this stage. [OPEN ISSUE: Do we have
>IETF consensus that this is a problem?]

There appears to be clear consensus that we have a problem
with standards maturity levels.  However there isn't
consensus beyond that about the extent to which internet
draft categories (wg draft, etc.) are a part of that
problem, and the possibility was raised that there may be
some sloppiness in how we (the IETF) move documents along as
protocols mature.  Some of the discussion was implentation-y
and nature and therefore out of scope.  If people feel that
something needs to be said beyond what Margaret included in
the draft, please speak up.

Melinda

---

From: <[email-masked]>
Date: Thu, 22 May 2003 13:55:40 -0500

> Early review from IPsec folks might have been useful; I'm not 
> sure how much of that did indeed happen before the IESG noticed the issue.

This is the key issue. If there had been a review by some of
the IPsec experts or cross-exchange of views between the Mobile
IP and IPsec WGs, we may not have ended up in the sticky situation
of being rejected by the IESG after WG LCs etc. and a few years
in the development of the protocol.

The problem that resulted in resetting the clock on Mobile IPv6
is the fact that a detailed review by the security folks was only
done at the very end by the IESG (far too late in the game). The
issue related to early reviews and feedback to WGs from other
areas has been captured by the PS WG docs. 

> 
> IMO the problem was very real, and the action being the only 
> responsible thing to do.  Looking back, maybe MIPv6 could have been 
> published as Experimental (or the like) as is, but definitely not PS.
> 

Maybe. But the key lesson to be learn here is that the Mobile IP WG
spent about 3 years or more before the IESG said that the security
solution based on IPsec was broken. The timeline to arrive at such
a conclusion is a serious problem for any standards work.

-Basavaraj

> 
> 
> -- 
> 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: <[email-masked]>
Date: Thu, 22 May 2003 17:31:48 -0500

> 
> > It's equally well an illustration that we can't boil
> > the ocean over and over again -- especially with new
> > people every time.  We need to boil a few gallons first,
> > and then a few truckloads.
> 
> This is a _really_ good point.   One of the things that I've 
> seen cause major hassle and pain for people who've been working on a draft for a 
> while is that someone new comes along (it's been me! :') and asks the 
> same damned questions that got answered *last* year.   And 
> then someone else comes along a week later and does the same thing.   :'}
> 
> Incremental steps would really help with this (although of 
> course in my case the questions I was asking were extremely pertinent. :')
> 

This is bound to happen when you have documents that take a couple of
years or more and umpteen revisions. Obviously churn among WG members
participating is also a fact. The only effective way is to track
issues and maintain that. Asking the newbies to go and read the archives
is not the most effective (especially when you have extemely active MLs). 
But a list of issues that have been dealt with by the WG during the course 
of n revisions over time will alleviate the pain ;) of revisiting the issue(s).

-Basavaraj