RE: Implementation vs. the Standard

[Pekka Savola <pekkas@netcore.fi>]

On Sat, 1 Nov 2003, Bound, Jim wrote:
> Not at all.  I am saying any standard that is implemented can be broken
> by bad implementation or bad operational management.  The trade off as
> to what the standard does to help alleiviate potential problems is a
> fine line.  For example, it is not the IETF's business to state if an
> implementation has IPv4 or IPv6 on or not on by default.

Totally agree here.  But I'm not sure what you consider to be bad 
implementation (failure to implement additional safeguards, not 
mentioned in the spec?) or bad operational management (enabling IPv6 on 
nodes before the network supports IPv6, or enabling IPv6 by default in 
general, ....)?

If we agree that we should work towards being able ensure that vendors and
users would feel safe(r) to turn on IPv6 by default (of course, we still
wouldn't mandate anything about it in a standard!), we get to these
problems we've been discussing here .. and then, it seems to me, they
should be addressed somewhere, somehow.

But if folks disagree that turning v6 on by default is not a useful goal,
or that v6 should only be enabled on nodes which do in fact have full IPv6
connectivity as well, we might end up with a different kind of conclusion.

> ND is widely deployed and also highly tested with 3 separate test suites
> to verify interoperability, in addition to running in many networks I am
> aware of intimately.  None of the issues in the afforementioned specs
> about v6onbydefault or onlink issues have ever occurred I am aware of
> except in an analysis lab and that is good. 

That may be because when v6 is turned on, you also typically enable the v6
connectivity, and because v6 is used by pretty knowledgeable folks. I'm
not sure if they've even tested these transitionary phases.

> That does not mean those are
> not important to document.  But, we have new specs to get out the door
> like the scenarios and those documents require a lot of discussion to
> complete.  That should be the WG priority from your view as Co-Chair
> that is all I am saying. And I am not saying we should not document
> potential problems in current specs. It's a matter of priority.  

The scenarios/solutions are our priority item.  We're just working on them
in parallel.  Of course, a good question is how much we can do things in
parallel so that the work on our priority items does not slow down.  But
it seems to me that the work was not much faster years ago when we only
had these scenarios and analysis..

>                      But, if most of us only worked on the IETF work and
> did not deliver in our others job functions we would be fired.  Likewise
> if we only deliver BCPs or "advice" and no stanards we will be fired by
> the IESG or the Chairs :--)

We're IPv6 Operations WG, and our primary function (as I see it) is
certainly *NOT* to produce standards.  

Actually, the only standards activity (excluding BCPs which are in fact
standards track) we've been chartered *at the moment* to do is advancing
or deprecating transmech, SIIT, NAT-PT and 6to4 if their usefulness is
demonstrated in the scenarios/analysis work. (Charter item #6 also lists a
possibility for standardizing transition mechanisms if the problems are
demonstrated, cannot be solved otherwise or in some other WG.)

> All standards from the IETF since inception are subject to that market
> test.  If you believe we permitted specs to go to DS and those specs are
> broken and have flaws then [...]

I'm not sure if you're referring to IETF specs in general or Neighbor 
Discovery in particular.

In general, the IETF has raised the bar for PS so that specs should have
fewer problems when they go to DS.  That's good.  However, it's pretty
easy to go to Draft Standard, if you just want to do the paperwork and
interop testing -- you just need to have a couple of implementations which
interoperate and implement all the features of the spec. In theory,
"sufficient operational experience" is also required, but that is
subjective.

In particular, however, Neighbor Discovery spec had not been extensively
deployed in different kinds of environments five years ago that it was
published as DS.  It would be unnatural to assume it would NOT have any
issues, which would be exposed later on, with wider and different kinds of
deployments.

That is, just because a specification goes to Draft Standard especially
before it's very widely deployed doesn't mean it can't have problems :-)

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