Subject: Re: Summary of alternatives

From: Stuart Cheshire <[email-masked]>
Date: Fri, 29 Nov 2002 11:30:20 -0800

At 6:21 pm 27th Nov 2002 Keith Moore wrote:
>Checking TTL==1 || TTL==255 || TTL==128  would allow receivers to 
>accept LL packets from both legacy Windows and legacy MacOS 
>implementations.  You could do away with the TTL check entirely,
>but there's probably some value in doing a minimal TTL check

Having three allowable TTL values instead of just one complicates and 
confuses the specification and gives no technical benefit. The *only* 
reason to do that would be for the benefit of vendors who have already 
shipped code.

Just 38 minutes earlier, at 5:43 pm, Keith Moore wrote:
>I find it entirely inappropriate that you have been attempting to force
>the WG to conform to a specification that has serious technical flaws,
>and dismmissing significant technical objections out-of-hand, in order
>to protect your employer from the risk that it exposed itself to by
>shipping code that implemented a preliminary version of the spec.

So, which is it to be Keith? Is it appropriate to modify the spec for the 
benefit of existing implementations, or not?

My position is, and has always been, and will continue to be, that 
arguments concerning technical merit should be given significantly 
greater weight than arguments concerning compatibility with existing 
deployed implementations.

Now let me move to the second part of what Keith said:

>You could do away with the TTL check entirely,
>but there's probably some value in doing a minimal TTL check

Is everyone clear on that?

Keith says: THERE'S PROBABLY SOME VALUE IN DOING A MINIMAL TTL CHECK

Keith, I hope you can stick to this position and not reverse it later.

This appears to be in agreement with the overall consensus of the rest of 
the working group.

The question now is what value the TTL check should be checking for,
in order to deliver the greatest benefit.

What does the receiver learn by checking TTL=1?
What does the receiver learn by checking TTL=128?
What does the receiver learn by checking TTL=255?

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * Chairman, IETF Zeroconf
 * www.stuartcheshire.org

---

From: Keith Moore <[email-masked]>
Date: Fri, 29 Nov 2002 15:20:20 -0500

> confuses the specification and gives no technical benefit. 

uh, it's one line of prose that directly and unambiguously translates 
to source code in every programming language with which I'm familiar.
if that one line confuses the implementors then I have little faith
that they'll implement the rest of the specification correctly.
maybe we should just drop the whole thing for the sake of these poor
programmers.

> The *only* reason to do that would be for the benefit of vendors who 
> have already shipped code.

of course it is useful to be able to be compatible with existing 
implementations if that can be done without seriously harming
the end-state of protocol deployments.  and yes, this is a "technical"
consideration.

> benefit of existing implementations, or not?

as far as I'm concerned, the spec is still on the table to be modified,
there are several reasons why the spec needs modification, and there are 
a number of factors that need to be considered.  compatibility with
existing implementations is IMHO a minor factor, but it is a factor.

> Keith says: THERE'S PROBABLY SOME VALUE IN DOING A MINIMAL TTL CHECK

The question is whether it's enough value to outweigh the disadvantage
of doing so.

As I see it there are three reasonable options:

You can check for the single specific value that the standard says
to emit, and then the receiver will accept only packets that 
happen to have that value.  Depending on what value you pick, this
either favors Apple, favors Microsoft, or ensures that routers will 
automagically filter LL packets going off the net.  I think you have
a good point that hosts shouldn't be sending LL packets through routers 
anyway, so maybe that argument for TTL=1 isn't compelling.

You can check for any of two or three discrete values, one of which 
is the 'standard' TTL value, with the others chosen to be compatible 
with existing implementations.  It's a simple check, and provides some
filtering.

You can omit the check entirely, and then the receiver will accept
all packets and pass them to applications.

What I'm still trying to understand is *how much* value is provided
by each kind of TTL check.

Keith