RE: Implementation vs. the Standard

["Bound, Jim" <jim.bound@hp.com>]

Pekka,

There are over 100,000 nodes that have deployed ND and across every
geography in the world and it is shipping from at least 20 well known
products that all did QA Testing which often includes interoperability.
That is widely deployed enough.

I think you are not informed about how widely IPv6 has been deployed for
the purposes of banging on our specs.  I am not talking about revenue
streams.

Our views simply are divergent on many many issues.  That is why we have
a working group and why we have discussion.  It is not up to YOU or I
but the IETF what the final answers are and I welcome the challenge and
battle to defeat most of your ideas in public, that I feel are
completely not valid or the IETF's concern regarding what products do or
don't do.  I choose logic and tehnical depth for this battle :--) Not
emotion and what we call in U.S. Legal Court Proceedings as here-say.
Mercy does not exists in my character for such battle of technology for
such an important matter :--) 

I would suggest the root of our disagreements time after time for me is
your "assumptions".  You have just become a focus in my technical life
congratulations, as a major problem for IPv6, not a helpful partner.

Respectfully,
/jim

> -----Original Message-----
> From: Pekka Savola [mailto:pekkas@netcore.fi] 
> Sent: Tuesday, November 04, 2003 3:58 AM
> To: Bound, Jim
> Cc: v6ops@ops.ietf.org
> Subject: RE: Implementation vs. the Standard
> 
> 
> 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
> 
>