Subject: RE: Implementation vs. the Standard

From: "Bound, Jim" <[email-masked]>
Date: Sat, 1 Nov 2003 00:58:29 -0500

>From: Pekka Savola [mailto:[email-masked]] 
>Subject: Re: Implementation vs. the Standard
>
>A couple of comments inline.
>
>On Thu, 30 Oct 2003, Bound, Jim wrote:
>> It is important for us to separate implementation choice vs. the 
>> standard.  The onlink and v6bydefault discussions are mostly a focus 
>> on if you do this with IPv6 and don't think about this other aspect 
>> you can hurt yourself.
>
>I'm not sure how to read this.  Are you implying that the 
>specifications could (should) include harmful or dubious 
>features, which clever implementers could then ignore or work 
>around locally, as a means for product/vendor differentiation? 
> Probably not, but that's a way to interpret some of the 
>comments about why things like these are outside the scope of 
>the specs.

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.  It is
appropriate for example to not build one standard that is not
interoperable with another standard if that other standard has not been
deprecated.

>
>> There is nothing wrong with documenting issues for 
>implementers in an 
>> RFC and that work should be encouraged.  In that context I 
>agree with 
>> Pekka S.  But, for the IETF to tell vendors how they ship their 
>> products for customers is simply inappropriate and vendors will not 
>> listen to the IETF, hence this is not a good use of our 
>precious mail 
>> time. In that sense I agree with Tony 100%.
>>
>> Discussion of operational issues with our standards and how 
>they work 
>> with implementation is a good discussion.  But should not be a 
>> priority over the standards work we need to deliver as a working 
>> group.
>
>Personally, I disagree with the second paragraph.  It is 
>almost criminally 
>negligent to just push out standards, one after another, 
>without fixing or 
>documenting issues in the existing ones.

Not what I said at all your reading into the words subjectively and you
don't know me, we are not friends, and this is not the intention of the
words.  I will give you another example.  

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 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.  

Regarding being multitasked.  We must operate as a multitasking entity
not doing so and living in one pipeline is unacceptable to the market
and sooner or later they will simply ignore and replace us with a more
efficient body.  

>
>Our number one priority to ensure that the standards and the 
>supporting 
>advice we generate is accurate, has no known problems and is 
>interoperable.

The supporting "advice" cannot and is not to be in the standard and look
at all the trouble putting that advice of a "conceptual" algorithm has
caused for ND now (I think the issue is way overrated but that's my
view) and is a perfect example of not putting "advice" in a standard.

If you want to write down advice put it in Informational or BCPs. Now I
am not saying hints and guidelines are not to be in standards, but they
need to be minimal and left for other documents, and why we created BCPs
in the IETF.

Now to finish my argument.  If we are producing 8 BCPs and no standards
to the IESG we have not done our job as IETF WG.  It is the same for
many of us here in the IETF.  Most of us are not paid to come to the
IETF and are paid as engineers and other job codes I am sure, and we can
work on IETF stuff.  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 :--)

>
>From my point of view, broken standards are worse than no standards at 
>all, hence the need to focus to addressing the issues in the existing 
>standards.

I don't believe and most of us don't believe here that the standards I
think your speaking of are broken at all.

Would you like to be specific what standards are broken and first ask
yourself a question?  Is continuing this discussion a good use of this
WG's time?  You're a Chair.  This is a test..........

>
>> I would also add that topics which are standards we are working on 
>> that are needed and on standards track receive priority mail 
>> discussion. The Standards Track discussions are the ones 
>that may help 
>> improve time-to-market for the IETF to deliver their 
>product/solutions 
>> which are networking standards and the point of this body and forum.
>
>Exactly the reason why I believe these issues are critical.  
>I'm personally very worried about more than just 
>time-to-market -- rather, what kind of technology ends up in 
>the market, and if there are flaws in that technology, how to 
>fix it quickly that the market won't reject it.

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 your saying a lot of bright people were
broken in their deliberations and you and a couple of drafts about doing
very questionable things on a network that is highly suspect, then you
are challenging a rather large set of work and years of analysis, and
quite frankly "running code" that has shipped in many products in the
market, has not broken in real life, has not failed on Network Pilots
all over the world, I can go on and on.  And that all should be changed
and take up all our time because you believe it is broken?  Then please
begin to be specific and responding to those who have told you it is
guidelines needed not changes to the core protocols.  Using technical
depth response discourse and not words like "what if", "broken",
"criminal". 

Here is my subjective opinion.  Some new people to IPv6 will pick on
anything they can just to make themselves a name that they in fact had
something to do with the definition of IPv6.  If I am correct I ask them
please work on the new stuff, review the old stuff based on a real need,
and help us do the new stuff. 

Someone want something to be champion of how about taking the lead on
what are all the common application exact same issues across 3GPP,
Umanaged, ISP, and Enterprise Scenarios.  If someone took on this work
and lead it and did it I think they would be an IPv6 hero forever.

At the end of the day this is all our opinions on a thread like this and
I will not keep responding.  As a DI told me once "opinions are like
assholes, everybodys got one".

And I as one WG member appreciate your high energy and efforts in the WG
all I am saying is lets be careful how much we work on stuff that is
advice vs. the standards technical work that is required for IPv6.

Take Care,
/jim

>
>-- 
>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: Pekka Savola <[email-masked]>
Date: Tue, 4 Nov 2003 10:57:49 +0200 (EET)

On Sat, 1 Nov 2003, Bound, Jim wrote:
> 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.

> 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

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

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.)

> 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 :-)