Subject: Re: LLMNR interoperability with Rendezvous?

From: Paul Vixie <[email-masked]>
Date: Tue, 07 Oct 2003 04:39:22 +0000

> >You may remember that I was one of the people who argued for TTL=1 in the
> >first place, but I was swayed by the working group consensus, so we
> >shipped with TTL=255, and then the working group changed its mind back
> >again.
> 
> You shipped code against an uncompleted specification and as it goes
> there was development on the TTL issue and consensus changed. Some
> room has been provided to review the issue but the fact that there is
> code shipped against an uncompleted specification is not a valid
> argument in that review, only an argument to revisit the issue.
> 
> Thus you on your own and with known consequences decided to ship code
> against uncompleted specification.
> If your company wants interoperabilty they can update distributions,
> and possibly at the same time a put in a kludge to talk to the
> old implementations.

you cannot possibly be serious.  apple should have waited an extra two
years to deploy functionality necessary to its product/service technology
simply because the volunteers of namedroppers couldn't be bothered to do
a rigorous enough review to be able to figure out a ttl issue?

that's not just unlikely, it's insane.  it'll never happen and shouldn't
happen.  meanwhile the new products entering the field won't be compatible
with anything previously existing in the field.  if i were a hardware or
software vendor i'd either support both or support rendezvous, just to
make sure there was somebody to sell it to on day 1.

penalizing apple for trying hard to play well with others but launching
their best guess when the deadline loomed isn't going to be effective and
would not be ethical even if it was.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Paul Vixie <[email-masked]>
Date: Sat, 18 Oct 2003 18:03:56 +0000

> ... your system should see that when it reaches node *.b that there
> is a child node,or at least flag that this name has a child.
> 
> Thus the wildcard algorithm should be disabled for that *.b.

i agree.