RE: Implementation vs. the Standard

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

>From: Pekka Savola [mailto:pekkas@netcore.fi] 
>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
>
>
>
>