OPEN ISSUE: Standards Track

[john.loughney at nokia.com]

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