Subject: Re: Application software needs to be "zeroconf-aware"?

From: Keith Moore <[email-masked]>
Date: Wed, 08 Jan 2003 11:11:00 -0500

> > So you are admitting that v4LL does not meet the IETF criteria for
> > proposed standard, which say nothing about "not treading new ground"
> > but do say "no known technical omissions".
> > 
> > Or are you trying to use other people's mistakes - which were never
> > standardized - as a justification for zeroconf making even more
> > mistakes and insisting that IETF standadize those mistakes?

> Keith, you and I had a month long running battle on this off list.
> I think NAT, like any other tool has it's place, you evidently wish
> for severe corporal punishment for anyone not spitting at the sound
> of its name.

NAT is of course a useful tool if you respect its limitations.  But it
has such severe limitations that it's not suitable for IETF
standardization.

> However, my point was, that this problem exists *now*, is handled 
> *now*, so is not some 'new, unseen issue'.

and you are simply wrong.  or at the very least, it is a gross
over-generalization to say that because NATs exist and are widely
deployed in some environments, that it's acceptable under IETF
standardization criteria to impose NAT-like problems on *all* IP
networks.  for instance, networks that use NATs tend to be heavily
client-oriented, because the workarounds necessary to support
significant numbers of servers/listeners behind a NAT are infeasible.

> This means that there are ways to deal with
> it in an intelligent, calm, rational manner.

I don't see how being intelligent and rational is consistent with
ignoring the criteria in 2026 or with ignoring evidence that v4LL
causes problems.

> If the  Internet can handle the silliness that it handles now, I fail
> to see how v4LL will collapse it. 

whether the Internet will collapse is not the question at hand.
the question is whether v4LL meets the criteria in 2026, which 
set a much higher bar than "whether the Internet will collapse".

> As well, if you wish to offer hard, happening evidence, that can be
> reproduced by all, well documented, etc., I welcome it. 

download netsolve and install it, and try to run it with some mixture
of clients, servers, and agents, inside and outside of a NAT.
see http://icl.cs.utk.edu/netsolve/

--
Keith Moore                              http://www.cs.utk.edu/~moore/
27 February 1933                                     11 September 2001

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 08 Jan 2003 14:44:35 -0800

> has such severe limitations that it's not suitable for IETF

This has nothing to do with anything. I happened to use it for an example,
and nothing more. It was in no way intended as anything else. I could have
used anything else as an example. Let's drop that.

> significant numbers of servers/listeners behind a NAT are infeasible.

This has nothing to do with NAT whatsoever. There are other ways to have to
deal with scope limitations in a single - link multihoming configuration.
Personal feelings on NAT are inappropriate, since NAT is not a part of
Zeroconf, and I didn't indicate that it was.

> ignoring the criteria in 2026 or with ignoring evidence that v4LL

Well, so far, I haven't seen an example of a problem that v4LL causes that
isn't caused by other things. When I do see one, then we all can procede
logically and calmly to see how to fix it.

> see http://icl.cs.utk.edu/netsolve/

This isn't a NAT working group, so I fail to see how an app that doesn't
like NAT applies. 

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Jan 2003 16:50:17 -0600

Maybe the FTP PORT command would be a good example that we could use to 
analyze the problem?