Subject: comments on draft-ietf-zeroconf-reqts-11.txt

From: Keith Moore <[email-masked]>
Date: Tue, 03 Sep 2002 16:52:52 -0400

these comments are intended as input into IESG decision-making 
about whether to publish draft-ietf-zeroconf-reqts-11.txt as
Informational, and also to the zeroconf WG as input to a possible
future revision of this document.

I see this document as somewhat more important than the typical WG
requirements document since zeroconf technologies have the potential
to have wide-ranging effects on internet applications and networks,
and presumably the linklocal document will be evaluated for 'known 
technical omissions' with respect to these requirements.  so if these 
requirements are incomplete or poorly-founded, they don't serve as a 
good basis for judging linklocal.

it does seem odd that the requirements document hasn't been formally
reviewed by a wider community before now, and even now is not subject
to IETF-wide last call.  even if they're just informational from the
standpoint of standardization they're being used to justify features
of standards-track protocols - so we should probably give them more 
scrutiny than typical 'informational' documents.

then again, I'd vastly prefer that we call these things 'design goals'.
somehow the word 'requirements' keeps sticking in people's minds even
though these documents are rarely either prescient or robust enough
to actually be considered 'requirements'.

----------------------------------------------------------------------

executive summary:  

- the requirements seem incomplete.  important considerations - such as 
  the impact of zeroconf technologies on existing applications and 
  existing networks - are omitted.

- a few of the requirements seem dubious

details:

section 1.3

the document doesn't say that there are absolutely no dependencies 
between zeroconf technologies, so perhaps this is just a nit.  

but if you expect the name-to-address translation service to be able to
return limited-scope addresses in response to queries (and you clearly
do) then there is a dependency between the name-to-address translation
service and the scope of such addresses - namely, the service needs to
be aware of the scope boundaries of its clients.  otherwise it will
return addresses that are unusable by its clients and may in fact point
to completely different hosts.

concrete example: if the scope of LL v4 addresses and LL v4 multicast
are not the same (and they could easily differ) then an mDNS/LLMNR lookup
can easily return an address that isn't usable by the client.   of course
if you put such addresses in DNS then you have even more problems.

so I think there are unstated requirements that 

- the zeroconf technologies coexist with each other in a useful way, 
  which is to say that they can be consistent with one another

- the zeroconf technologies coexist with similar services that 
  are used in managed networks - either by providing consistent
  (or non-conflicting) results or by arranging that the zeroconf
  service is not used when the managed service exists.
  (even then you still have consistency issues, since the ability
  to access the 'managed' services may differ from one node to
  another).
 
and *those* translate into more specific requirements which I can't 
enumerate off the top of my head.

section 1.4

it's reasonable for scalability to be a secondary goal for truly 
ad hoc networks - there seems little point in trying to support 
ad hoc networks that consist of thousands of hosts.  OTOH, if
zeroconf technologies are to be used on existing networks, scaling
_on those networks_ becomes considerably more of a concern.

it's been argued on the mailing list that some zeroconf technologies 
should be usable on managed networks in addition to ad hoc networks.  
indeed, it's been forcefully argued that linklocal should be enabled
by default on all hosts so that it can be used to communicate with 
appliances without having to configure such appliances.

if this is a goal, it needs to be explicit, and the scalability 
concern needs to be reconsidered.  

regardless, there needs to be a requirement that zeroconf technologies 
not interefere with operation or security on managed networks.  

section 1.6

it's not clear what it means for zeroconf protocols to "restore
the network to a consistent state", especially when all of the
relevant state that I can see is maintained in the hosts and 
applications rather than in the network.  zeroconf may be able
to resolve address conflicts, but it cannot transparently recover 
applications from such conflicts.  

there needs to be a requirement that zeroconf minimize impact on 
applications.  actually there's little mention of applications 
in the document, even though the effect on some kinds of applications 
is significant.  this seems like a major omission.

it's not clear that names, or name-to-address mappings, are properly 
considered 'network' resources if they are similar to DNS names 
or have the potential to overlap with the DNS name space - either as a 
matter of on-the-wire protocol or via APIs that applications use to
look up such names.

section 2.1

again, the document talks about what "hosts" should or should not
assume regarding stability of "network resources" but does not mention
what "applications" may assume or whether zeroconf creates new burdens
for applications.

section 2.2 (middle of page 6)

the document talks about "increased robustness" of _zeroconf_ protocols
but says nothing about the effect on the robustness of applications 
hosted on hosts that use zeroconf.

section 3.1 (3rd bullet) [nit?]
 
"MUST allow configuration of zero or more gateways (for the internetwork
scenario)".  perhaps this is trivially satisfied (because allowing 
zero gateways suffices) and it can therefore be omitted. or perhaps it
needs rewording for clarity.

please remind me of how v4 linklocal facilities connection of gateways?

(last bullet list of requirements on middle page 8)

it seems like nomadic hosts are likely to connect to multiple networks
in the course of a day.  is such a host better off using the same
address each time it connects to a particular network, or better off 
trying to claim/defend the same address on every network to which it
connects?  would large numbers of nomadic hosts (as seems likely)
seriously affect the stability of linklocal addresses even though the
hosts try to maintain their addresses as they migrate?

also, given that apps on nomadic hosts might need to keep some connections
open as they move, has any thought been given to interaction between 
zeroconf technologies and mobile IP?  are there requirements along these 
lines waiting to be discovered?

section 3.2

I keep being told that the name-to-address issue is out of scope for this 
group.  maybe dnsext should review this portion of the document?  or maybe 
it should be omitted?  especially since mDNS/LLMNR still seems to be in
flux with fundamental problems still unresolved?

nit: s/quite likely to use a different IP/quite likely to use different IP/
                           ^

I realize this isn't the only group using the term, but the emphasis on 
"host names" seems a bit archaic.  these days users rarely  care about
accessing "hosts", they care about accessing "services". (sometimes
the host *is* the desired service, but that's the exception rather than
the rule).  of course, it's not the use of the term that's important
so much as the assumptions that go along with it.   for instance, should
service lookups map to host names and host names to addresses, or should
service lookups map directly to addresses?

nit: "for applications like web browsers...the use of names rather than
IP addresses is beneficial".  only if the names are more stable
and more mnemonic than the addresses :)  not that they're being
proposed by this WG but temporary names aren't very useful for
such purposes.  I would say "may be beneficial" rather than "is".

(page 9, bullets)
if "host names" are or aren't DNS names then it would be good to say that
in the first bullet in the Terms section.  that's the first thing a
reader would want to know.

there's no statement about the effect of the name resolution protocol
on APIs that are currently used to look up DNS names.  it's an important
question because it will affect apps.  there's a desire to have these
things "just work" with existing apps, but at the same time if the
results are inconsistent with DNS then it will cause problems.

there's also no statement about the consistency of results of the 
lookups using name resolution protocol across different locations.
if the results are inconsistent at different places this will also
break apps that want to use these names to do referrals.

there needs to be a requirement that lookups of DNS names are consistent
with lookups using DNS.

"probing a desired host name...must not prevent the desired hostname
from being resolved".  

I'm not sure what this means.

- "from being resolved...at a later time" ?
- s/must not/MUST NOT/ ?

again, it is not at all clear that host names are properly treated
as "network resources", i.e. resources that belong to the network.
traditionally DNS names are not related to network topology.

this might imply that the network and/or protocols for looking up
such names should be able to detect naming conflicts between DNS-style 
names but NOT to adjucate between such conflicts - because the network 
is not authoritative for any portion of DNS name space.  (individual
hosts might have been assigned such authority - just as they might
be running DNS servers that are authoritative, but the "network" is
not authoritative) 

"local" names (that don't look like FQDNs) might be a different matter.

(I realize that this document says that they aren't DNS names but
mDNS/LLMNR seems to act as if they are DNS names or at least the
spaces can overlap - then consistency becomes an issue)

"zeroconf name resolution protocol MUST support resolution of
names on multiple IP subnets connected by a router".

I'm not sure what this means - it seems like a network-centric
definition but the hosts/apps are what are implementing the protocol.
Do you mean that the protocol MUST enable resolution of names on
other IP subnets that those to which the host supporting the 
querying application is attached? 

again, is there a potential conflict between the use of limited-scope
addresses in this name-to-address lookup service and having the lookup
service work across a larger area than such addresses?

"zeroconf name resolution protocols MUST allow timely re-use of hostnames"

again this seems misstated, at least for FQDNs - such names are not
delegated to the network or to zeroconf protocols to manage.

section 3.2.2

"host names ...are inherently locally scoped".  not from the examples
envisioned in the current mDNS/LLMNR draft.

"a DNS server supporting dynamic updates can provide automatic configuration
of a DNS name space in a network".  I'm not sure what this means.
Are you saying that such a server could (or perhaps should) be used instead 
of the zeroconf name lookup service?  Are you saying that this mechanism
should be used (when available) to ensure consistency between the zeroconf
service and DNS?

"The zeroconf namespace is orthogonal to the DNS class IN namespace"
seems irreconcilable with "It is RECOMMENDED that zeroconf host names 
conform to the character set and formatting of DNS host names".
(and the latter seems to me to need strong justification)

EITHER the two services share a common namespace (and need to produce
consistent results with one another) OR they need to be clearly
distinguished from one another - different syntax, different APIs, etc.
so that apps don't get confused and try to treat zeroconf host names
as if they had the same properties of DNS names.

several requirements seem to be omitted here.

"...MUST NOT allow zeroconf names to mask DNS names".  this is not 
a sufficient restriction.  in general it is necessary to produce 
consistent results when different hosts in different parts of the network 
look up the same DNS-like name, even if those hosts have different
local scopes or if some of those hosts are using zeroconf and others
are using DNS.  that's not to say that all RRs for all names need to 
be visible to all hosts at all times - that's not even true for pure DNS -
but that (for reasons similar to those given in RFC 2826) the name lookup
service needs to provide a uniform view of DNS-style names from everywhere. 

local (unqualified) names are a different matter - we do expect
their meanings to differ from one place to another.

---

since I'm busy and I'm mostly concerned about names and addresses, I 
didn't review the remainder of the document. 

again, attention to important considerations that were omitted from the
requirements in the document are probably more important than
most of the tweaks suggested above.  e.g. compatibility with existing apps,
effects of introduction of zeroconf on the operation of existing/managed
networks.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 03 Sep 2002 18:00:35 -0400

> to completely different hosts.
 
further comment to my earlier comment -

the major problem with limited scope addresses in general is that hosts
and apps usually have no way to know whether an address is valid in a 
particular context.   this is true whether or not the limited scope address 
is initially obtained by using a DNS or an LLMNR lookup (it's not necessarily 
the case that they are).  the server providing the lookup typically has 
no idea about the networks to which the lookup client has access, and 
there's no assurance that the client that's doing the query is the same 
party that will actually try to communicate with that address.

so trying to have the name-to-lookup service return limited scope addresses 
only when the client that's doing the query is within the proper scope for
that address is at best only a partial solution - addresses will still leak
out of the scopes in which they are valid.

Keith

---

From: Joshua Graessley <[email-masked]>
Date: Tue, 3 Sep 2002 16:46:56 -0700

I'm not sure I understand how the scope of the two could differ. Both 
are defined as link-local scope. In the case of ethernet, an ethernet 
broadcast and an ethernet multicast should be just as effective in 
reaching all nodes, right? I think that any equipment that handles the 
two differently would break many applications. Is there another media 
where the definition of link-local changes if an address is multicast?

-josh

---

From: Keith Moore <[email-masked]>
Date: Tue, 03 Sep 2002 20:15:43 -0400

> two differently would break many applications. 

that sounds like an argument that I would make :)

as it turns out the local ethernet in my building at UTK doesn't
(yet) support multicast because it's not really an ethernet - it is
actually based on some kind of cisco switches that don't do multicast
unless you enable a proprietary cisco protocol on them.  and our
network guys have it disabled (last I checked) because they don't 
understand it.  yes, it's prevented us from running several apps.
we've been wanting multicast ever since we moved into this building 
two years ago.  (the last building we were in was one of the first 
on campus to be wired so it had a *real* ethernet, complete with 
vampire taps.  those were the days...)

somehow I doubt we're the only ones in that situation.  just as
there are folks who don't understand that IP is designed to have
global addresses and that failure to provide global addresses breaks
apps that quite reasonably expect them, there are also folks who 
don't understand that ethernets are designed to support multicast and
that failure to support multicast breaks apps that quite reasonably
expect it (at least on the LAN).

Keith

p.s. will respond to your other message after doing a detailed  
review of the latest linklocal draft.  today is my day to do
detailed reviews...

---

From: Aidan Williams <[email-masked]>
Date: Wed, 11 Sep 2002 10:32:59 +1000

Firstly, thanks for your comments.  I appreciate the time
and care you have put into them.  I have been away, so it
has taken me a little time to get around to replying.

  > to actually be considered 'requirements'.

"Requirements" documents are currently 100% buzzword compliant
in the IETF at the moment... ;)

  >   existing networks - are omitted.

I'm happy to add two requirements:

  1. that zeroconf technologies not interefere with operation or
     security on managed networks

  2. that zeroconf minimize impact on existing applications

  > - a few of the requirements seem dubious

Not sure I follow exactly what you are referring to.

  > enumerate off the top of my head.

Maybe this is just a requirement that the name service lookup
and address scope boundaries should match?  The managed network
comments seem more relevant to later sections -- where you cover
it again..

  > not interefere with operation or security on managed networks.

Yes, I agree.  Non-interference is a desirable goal.  I think people
may have disagreed about the presence or seriousness of disruption
to current networks in particular proposals but I think everyone
agrees that breaking peoples existing networks isn't a win.

  > matter of on-the-wire protocol or via APIs that applications use to

Again, I'm happy with a "requirement that zeroconf minimize impact on
applications".

Regarding the discussion about "network resources" and the like: the
text is intended to get the idea across.  Some things don't fit the
category that well, and right at the moment I'm not seeing a burning
need to change the text.

  > hosted on hosts that use zeroconf.

Covered by the above general "requirement that zeroconf minimize
impact on applications"?

  > please remind me of how v4 linklocal facilities connection of gateways?

Sigh.  Charter says single router.  One needs routing information to
send packets in that case.

  > lines waiting to be discovered?

Scope creep?  Seems to me that identifying the network you had just
plugged into isn't trivial.

Before leaping into the next set of comments I should summarise what
I believe the state of play is with zeroconf naming.  I have been
following the discussion in dnsext, and my understanding was that
there was general agreement on the following points:

   - mDNS/LLMNR was *not* DNS,
     rather it was a seperate protocol, seperate port,
     seperate cache, etc

   - there was agreement that mDNS/LLMNR should not be used
     as a substitute for DNS -- ie should not be used for
     looking up "one true DNS names"

   - that mDNS/LLMNR should not be used to transport DNS requests
     to a "back end resolver"

These comments also apply to the IPv6 Node Information Query
proposal as well.

Right now, the -12 LLMNR document has examples with FQDNs in them.
Unless there have been conversations that I am unaware of, I
believe it was the intent of the working group *not* to support
the resolution of names such as mylaptop.microsoft.com using LLMNR.

  > service lookups map directly to addresses?

Service lookups could do either and one could "name" services.
Right now the world doesn't divide neatly down those two lines --
e.g. browser bookmarks contain names.

  > reader would want to know.

Sure..

  > results are inconsistent with DNS then it will cause problems.

If zeroconf name resolution is orthogonal to DNS name resolution,
then people can turn it on and use it (it also may be enabled in
some situations by default -- for example when there is no DNS server).
I don't see a problem for these cases.

I also believe that it *is* possible to do implementations where
both co-exist quite well.  One example is Microsoft's NetBIOS name
lookup protocol.  My win2k box seems to cope just fine providing
you understand that netbios names don't have dots in them.
Interestingly, various dialogue boxes that used to only accept
netbios names now accept DNS names too.

  > there needs to be a requirement that lookups of DNS names are consistent

If the zeroconf name resolution protocols were orthogonal to the DNS
then this sort of consistency isn't required.

  > traditionally DNS names are not related to network topology.

Host wants to test uniqueness of a name it would like to use and
will respond to mDNS/LLMNR lookups for.  Negative caching of the
probes should not prevent the name being looked up for 5 minutes
just because the host was testing uniqueness.

  > be running DNS servers that are authoritative, but the "network" is

Orthogonal => no problem?

  > spaces can overlap - then consistency becomes an issue)

see above comments about what I take to be the dnsext position
on this stuff.

  > service work across a larger area than such addresses?

Well... the charter has this router.  The language might be a bit
unclear, but I think you got the basic point.

In general I believe we would be short-sighted in coming up with a
protocol which was not in principle usable within a small routed
network.

  > delegated to the network or to zeroconf protocols to manage.

Orthogonal => no problem.

  > should be used (when available) to ensure consistency between the zeroconf

Such a server doesn't really fit the zeroconf picture, however it
would work in one place where many people see zeroconf protocols
as being useful: the home network.

No, I was not suggesting that it was some kind of conflict resolution
between the DNS and ZNS.

  > several requirements seem to be omitted here.

One possibility is to corral all the zeroconf names into a
single part of the DNS namespace, for example inside a domain
suffix such as "local.arpa".

It would be a failure if all existing applications had to
be re-written to use ZNS names where they currently use DNS
names.  From a user point of view, it is important that
someone can use a ZNS name in a URL:  http://linksys-box/

  > service needs to provide a uniform view of DNS-style names from everywhere.

I think this is well put.  Again, I think most of the problems
go away if we are just clear on the orthogonality of DNS and ZNS.

Clearly, ZNS names need to be consistent within a site.
A site may be a single broadcast domain, or in general a
small routed network.

Since a ZNS name is not global, it cannot have the same
semantics as a global DNS name.

Interestingly, although the main point of RFC 2826 seems to
be to debunk alternate DNS roots, it also says:

    This does not preclude private networks from operating their own
    private name spaces, but if they wish to make use of names uniquely
    defined for the global Internet, they have to fetch that information
    from the global DNS naming hierarchy, and in particular from the
    coordinated root servers of the global DNS naming hierarchy.

I think we're talking about a private namespace.

I also think it would be prudent to ensure that the labels used
in the private namespace and the DNS do not conflict, which
is why I'm keen on the local.arpa/private.arpa fixed domain
suffix for private names.  btw, that isn't the same as saying
that I'm keen on using the suffix to trigger mDNS lookups.

  > their meanings to differ from one place to another.

However it is done (no suffix, known suffix, whatever) ZNS names
are not globally unique.  Their unqiueness can only be guaranteed
within the scope of the lookup protocol.

-- 

regards
	aidan
____
:wq!

Sydney Network Research Lab             [email-masked]
Motorola Australian Research Centre          phone: +61 2 9666 0649
Locked Bag 5028, Botany NSW 1455              phax: +61 2 9666 0501
Australia                            http://marc.labs.mot.com/snrl/

---

From: Brad Hards <[email-masked]>
Date: Wed, 11 Sep 2002 11:03:25 +1000

On Wed, 11 Sep 2002 10:32, Aidan Williams wrote:
<snip>
> comments seem more relevant to later sections -- where you cover
My mind is not 100% at the moment, but one idea that keeps coming back to me 
is that perhaps the only thing that should ever appear in LLMNR is LL 
addresses.

So rather than being orthogonal, zeroconf name resolution and DNS name 
resolution are exclusive. It should always be clear which one you are using.

Now when I go to implement this problem, I thinking of hacking the back-end 
resolver libraries, and adding another option to the name service switch, so 
my /etc/nsswitch.conf looks like:
#hosts:      files nisplus nis dns
hosts:      files nisplus nis dns llmnr

Then the dns entry means "DNS only if not in 169.254/16, otherwise fall 
throught". And when Keith is proved right and some applications fail, getting 
back to a working arrangement is trivial.

Or am I missing something?

Brad
- -- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.

---

From: Keith Moore <[email-masked]>
Date: Tue, 10 Sep 2002 22:14:23 -0400

Thanks for the reply.  I think I agree with most of it, will 
probably respond on a few details later.

But to immediately follow-up on probably the most significant issue: 
I agree that there are far fewer issues with LLMNR/mDNS/ZNS if it 
is clear that these names are separate from DNS names.  However the 
examples in mdns-12 make me think that they're not going to be separate 
(especially in contrast to an earlier version of that document where 
the names were in a private local.arpa space).  

So it might be a good idea for the requirements document to separately
cover both private names and public names because the requirements for 
the two cases seem to differ considerably.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 10 Sep 2002 22:48:50 -0400

> is that perhaps the only thing that should ever appear in LLMNR is LL

There are several approaches that could minimize the potential for conflicts 
between LLMNR and DNS:

one is to say (as I think you were suggesting) that LLMNR is where you look
up LL addresses and DNS is where you look up global addresses.  so they
would share a common name space but there would be a more-or-less clear separation 
of function between the two services, so you never have the services giving
conflicting information.  (there are still potential issues if the same API 
is used to access both, and it's not immediately clear how you handle
separation of function for non-address RR types)

another is to say that LLMNR is for a separate set of names than DNS names -
so you use LLMNR to look up "local" names and DNS to look up "non-local"
names.  the thing is, for some (not all) hosts we would really like them
to be able to keep their DNS names even in an ad hoc environment - e.g.
as a backup for loss of external connectivity.

another is to say that LLMNR only acts as a cache for DNS.  that minimizes
conflicts but makes it difficult for a host to update its own information
if it is disconnected from the DNS server for its zone, so I don't consider
it a viable alternative and I mention it only for completeness.

another is to say that LLMNR and DNS are just two different ways of getting
to the same information (at least for nonlocal names), and we insist that
they be consistent with one another to the same degree that we insist that
DNS servers for the same zone be consistent with one another.  so a host
answering LLMNR queries would be required to EITHER act as a DNS cache
and return data consistent with the last known data from an authoritative
DNS server (and even then, probably only for its "own names") OR be delegated 
the authority to run its own zone (perhaps consisting of only a single name) 
and serve as the authoriative master for that zone.   as far as DNS were 
concerned, the parent zone would have an NS record pointing to that host 
whenever it knew that the host had an externally-accessible address;
the host would need to update that NS record whenever it got a new address.
I don't think anything would prevent the parent zone from acting as either 
a secondary or a cache for the child zone, avoiding the extra referral for 
most queries.  so instead of having LLMNR be a separate name service from DNS, 
it would be just an extension of DNS - a way to get the same information 
via a slightly different access protocol (and with somewhat less confidence
in the LLMNR result due to the absence of an NS chain from the root).  It 
might even be reasonable to put the two under the same API, modulo some
concerns about security and differences in error conditions.  presumably 
LLMNR could still handle queries for local (non-dotted) names without having 
to worry about consistency issues for that case).  one interesting consequence
of this would be that hosts would need to stop advertising LL addresses 
whenever they had "real" addresses, so as to not leak LL addresses into DNS.

But I suspect the last case can actually be made to work well and would allow 
LLMNR to produce results as consistent as DNS does now.  but I need to analyze 
it some more to be confident about it.  then I will feed it to the lions in 
dnsext who will no doubt rip it to shreds if it fails some important criterion :)

Keith

---

From: "Adam MacBeth" <[email-masked]>
Date: Wed, 11 Sep 2002 10:33:21 -0700

There are some very important issues to be resolved here.  If LLMNR and
DNS are used to resolve names from two different and exclusive
namespaces, then a lot of applications will break.

Take a scenario where I have 2 devices in a home network not using
zeroconf.  Device A has a URL referring to Device B which is resolved
just fine using DNS when the 2 devices are in the home network.  If I
then take these (mobile) devices out of the managed environment and they
form an adhoc network and start using zeroconf, Device A can no longer
resolve its URL pointing to Device B, because that URL includes a global
name and LLMNR would only allow resolution of local names.  

So we have a case here where 2 devices which know the names of one
another cannot communicate.

This was one of Keith's points but struck me as an example of breaking
applications which should be reinforced.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Keith Moore
> Sent: Tuesday, September 10, 2002 7:49 PM
> To: Brad Hards
> Cc: Aidan Williams; Keith Moore; Zeroconf
> Subject: Re: comments on draft-ietf-zeroconf-reqts-11.txt
> 
> > My mind is not 100% at the moment, but one idea that keeps coming
back
> to me
> would share a common name space but there would be a more-or-less
clear
> separation
> conflicting information.  (there are still potential issues if the
same
> API
> another is to say that LLMNR is for a separate set of names than DNS
names
> -
> most queries.  so instead of having LLMNR be a separate name service
from
> DNS,
> whenever they had "real" addresses, so as to not leak LL addresses
into
> DNS.
> 
> But I suspect the last case can actually be made to work well and
would
> allow
> it some more to be confident about it.  then I will feed it to the
lions
> in

---

From: Keith Moore <[email-masked]>
Date: Wed, 11 Sep 2002 13:39:46 -0400

I probably would not call this "breaking" an application because it
is something that doesn't work before introducing zeroconf - so the 
fact that it doesn't work after introducing zeroconf doesn't sound
like breakage to me.  

However I think it's a good example of something that we would very
much like to work - we will be very disappointed if zeroconf does
not handle this case.

My own best intiution is that zeroconf name lookup needs to handle
both globally-scoped and locally-scoped names, but it needs to handle
globally-scoped names in a way that is consistent with DNS, and 
the rules for looking up locally-scoped names may need to be different 
from those for globally-scoped names.

---

From: Thomas Narten <[email-masked]>
Date: Wed, 11 Sep 2002 15:06:52 -0400

Keith,

Having just reread this document, here are some thoughts on your
comments.

> future revision of this document.

It would be helpful if more of your comments were along the lines of
change the following text to <your suggestions>. For some of your
comments, its hard to say what sort of wording change you are asking
for or if you are just saying the idea is so broken there is no way
forward.

> good basis for judging linklocal.

The linklocal document is basically done and even implemented. Those
that have implemented seem to think it is useful. As is the case with
many requirements-type documents (unfortunately), the wish list isn't
perfect and one can imagine additional desirable-to-have things that,
if included, would result in change in a subsequent protocol
document. At this point in time, I think issues you might have with
the requirements relating to the linklocal document should also come
with a clear indication of what changes you think are necessary in the
LL document.

> scrutiny than typical 'informational' documents.

Most requirements-type documents are not IETF-wide last called.

> to actually be considered 'requirements'.

I am sympathetic to this, as they are recommendations in the end after
all.

>   existing networks - are omitted.

The problem I see with this is that I suspect you are asking for
something like: "zeroconf technologies MUST NOT have impact on
existing applications", and your view appears to be that use of
link-local addresses by applications will break them. Thus, the entire
LL document should not go forward.

Is this an accurate reflection of your position? If not, what impacts
are you concerned about and what would the corresponding general
requirements be (and can those requirements in fact even be met)?

> - a few of the requirements seem dubious

Specific text please...

> between zeroconf technologies, so perhaps this is just a nit.

Are you asking for specific text be added? If so, please indicate
what.

>   which is to say that they can be consistent with one another

Again, send text. I think what you may be wanting the requirements
document to say is that the different pieces of zeroconf technology
must work together consistently/coherently. Or something like
this. This make sense to me, but I'm sort of assuming that.

> enumerate off the top of my head.

My recollection is that earlier versions of the draft included more
text about coexistance between managed and unmanaged resouces. I do
wonder if more text should be added back in. But this is a fairly
hard/subtle issue.

For example, do we really understand how we want zeroconf name
resolution to coexist with managed name resolution? If so, how does
one ensure that one doesn't get confused about a particular name (use
the zeroconf name or the managed/DNS one?) What if one service is
temporarily down?  There is some existing wording in the document that
is probably too cryptic on this issue:

   equivalent to using the DNS protocols to query the same name.  A host
   using DNS and zeroconf name resolution protocols at the same time
   MUST NOT allow zeroconf names to mask DNS names.

and later

   configured network protocols.  Locally allocated zeroconf network
   resources must not mask global assigned resources.

> _on those networks_ becomes considerably more of a concern.

Seems like a valid point. *If* there is no way to easily disable the
use of zeroconf technologies on managed networks, they will have
(possibly negative) problems when used on managed networks that don't
make the same assumptions as a pure zeroconf-only network.

> not interefere with operation or security on managed networks.

Again, I thought there was more along this lines in an earlier version
of the document.

> applications from such conflicts.

I wonder if you are asking for something that isn't doable. If two
networks merge, and nodes find they are sharing addresses, there is a
real problem that two nodes might now share an address. This isn't a
zeroconf problem per se, but zeroconf is trying to say when those
things happen it needs to try and fix them to make the better (as
opposed to doing nothing with things staying broken forever).  This
can't always be doing in a way that is transparent to applications
(e.g., if a node has to change addresses). Surely you agree with
this. So I'm having trouble translating the above into a concrete
suggestion for this document. In the absence of a specific suggestion,
we probably need to move on.

> is significant.  this seems like a major omission.

What does "minimize impact" mean? Totally unquantifiable, and as
mentioned above, can be used to essentially say (e.g.) LL is too
broken to use.

> matter of on-the-wire protocol or via APIs that applications use to

Is your issue with the wording calling them "resources"? Can you
suggest alternative wording?

> hosted on hosts that use zeroconf.

see previous comments.

> needs rewording for clarity.

Almost certainly a nit.

> please remind me of how v4 linklocal facilities connection of
  gateways?

there is a valid point buried here. The requirements document talks
about multiple gateways, but doesn't have any requirements about
addressing beyond link local. But if one only has link-local, then
one doesn't need routers.

I wonder if the real problem here is that parts of the document were
written before it was settled that link-local meant "stays on the
link" and doesn't go through a router. Earlier versions talked a about
a single router with multiple subnets (and possibly a connection to
the internet), but I think this wording is gone now. Note that there
is also wording in the document that says:

   o  A zeroconf name resolution protocol MUST support resolution of
      names on multiple IP subnets connected by a router.

It is not quite clear what this means in light of link-local addresses
are currently defined. (this also gets back to an earlier point about
the different parts of zeroconf being coherent with each other).

> hosts try to maintain their addresses as they migrate?

Not clear how one would even notice that one is on a "different"
network as one moved around. So saying "try to use the same one again
(but be prepared to use a different one if you can't)" seems about
right.

> lines waiting to be discovered?

One generally needs a global address to use MIP. When using  zeroconf,
I think one is not generally using global addresses, as having them
implies some sort of configuration beyond zeroconf being possible.

> group.

More specifically, discussing specific solutions is.

> maybe dnsext should review this portion of the document?  or maybe 

                       ^
> service lookups map directly to addresses?

host names still seem too useful to drop. How else to you ssh to
another machine (something I still do, even at home).

> results are inconsistent with DNS then it will cause problems.

I think there is a findamental issue here. One of the questions that
needs to be dealt with (if not here, at some point) is does the API
change when looking up zeroconf names. There are important security
questions lurking here, as you don't ever want an application to be
fooled into thinking it is using the dns to look up "mybank.com" but
instead connect to some rogue server that is spoofing that name
through zeroconf technologies. The clearest way to do this is to have
a differnet API for locating zeroconf names. But that obviously has
ease-of-deployment issues.

> break apps that want to use these names to do referrals.

Sounds a bit like you are arguing for a global name space, even if
zeroconf is used. Not sure how to do this...

> I'm not sure what this means.

Don't know either.

> querying application is attached?

I was unclear about this wording too.

> delegated to the network or to zeroconf protocols to manage.

is this just a wording issue? I think I  know what is meant. If you
stop using a name, someone else should  be allowed to start using it
for itself -- after some period of time.

> (and the latter seems to me to need strong justification)

I don't see this as being an inherent conflict.

> Keith

Thomas

---

From: Keith Moore <[email-masked]>
Date: Wed, 11 Sep 2002 16:32:02 -0400

> for or if you are just saying the idea is so broken there is no way

if I see a way to solve a problem with a simple textual change,
I usually suggest it.  

sometimes I cannot come up with a simple textual change off the top 
of my head, and it takes so long to do these reviews that I'd rather 
forward the review sooner without suggested text than delay it until 
I think I have good wording for everything.

in some cases it seems counterproductive or at least premature to argue 
about the actual text when the problem seems to me to be the assumptions 
underlying the text - and often these assumptions are not made explicit.  

sometimes I simply can't fathom what is intended.

> The linklocal document is basically done and even implemented. 

those two attributes are orthogonal - "implemented" certainly doesn't 
imply "done".

I *hope* the problems with the previous versions of linklocal have been 
addressed.  I'm still trying to come up with a useful review of LLMNR,
so I haven't had time to get back to LL yet.

> Those that have implemented seem to think it is useful. 

there's little doubt that it's useful.  that doesn't mean that meets
the 2026 requirements for PS status.  a related question is - are the
requirements reasonable and reasonably complete?

> As is the case with

my review of the current LL document will follow, and I'll do my
best to get it in before the Last Call deadline.  but if the LL 
document is to be judged according to the requirements listed in
the requirements document, then it does seem worthwhile to look
over those requirements also.

> Most requirements-type documents are not IETF-wide last called.

true, but IMHO it would be a good idea of requirements documents were
subject to wider review - particularly for technologies such as
this one that have the potential to have a wide impact, early review
of the requirements/goals document would provide a chance for early
feedback from affected interests.

so by "odd" I didn't mean statistically odd, I meant that by not
getting wide review of such things we're missing out on valuable 
opportunities to fix things well before it's widely assumed that 
those things are stable.

> requirements be (and can those requirements in fact even be met)?

My position is that zeroconf technologies 
SHOULD minimize the impact on existing applications,
SHOULD minimize the impact on operation of managed networks,
MUST minimize the degree to which they impair the ability of the
network to support a wide range of applications.

That is, we can tolerate some small degree of disruption to existing
applications and networks provided there is a reasonable workaround 
which allows the functionality to be restored - but impairing the
ability of the network to support a wide range of applications 
(including distributed and p2p apps) is not an acceptable tradeoff.

Off the top of my head, impacts that I'm concerned about include:

- effect on existing applications that assume or require stable 
  addresses, including their use in referrals,

- effect on existing applications that assume or require addresses
  that are unique within the application,  

- effect on existing applications that assume or require addresses
  that are routable throughout all present and future hosts supporting 
  a component of the application, including the use of such addresses 
  in referrals

- effect on existing applications that assume or require the level of 
  consistency and location-independence of name lookup service that is  
  provided by the design of DNS 

- effect on existing applications that assume or require unique names

- effect of the introduction of zeroconf-supporting hosts on the operation 
  of existing managed networks, including security and user support 
  (e.g.  problem diagnosis) issues

> Are you asking for specific text be added? If so, please indicate

I was asking a question about the assumptions being made, and wondering
whether there was not an actual requirement that was not stated.

I don't know what text to suggest here because I haven't been able
to come up with a solution that doesn't cause problems.

There appear to be problems with assuming that unicast LL scope and 
multicast LL scope are the same, especially in a bridged environment.
There are problems if the unicast LL scope is a proper subset of the 
multicast LL scope (LLMNR will advertise addresses that are not valid); 
there are problems if the unicast LL scope is a proper subset of the 
multicast scope (LLMNR will fail to make hosts visible through their 
names even though they are reachable), and there are problems in 
general with expecting addresses obtained via LLMNR to be used only 
from the host making the query and only within a short time after 
making the query (this breaks apps that do address referrals).

So I didn't suggest text because frankly I don't see how to solve
the problem, and in order to even suggest a compromise I'd need to
know more about other people's assumptions.

> resolution to coexist with managed name resolution? 

It's fairly clear to me from looking at various versions of the mDNS
document that we don't understand this yet - but it seems important
to get it right, and one useful approach might be to take a step
back and look at how we'd state this from a goals/requirements 
perspective.

> we probably need to move on.

well, what I'm asking for here is clarification.  I don't think 
"restore the network to a consistent state" is sufficiently well
defined to understand what it means.  I can't suggest text here
because I simply don't know what the authors have in mind.

I certainly don't expect v4 LL to ensure uniqueness or stability
of addresses chosen at random from ~2**16 possibilities.  Nor do
I expect v4 LL to solve the problems that will result from apps 
that try to treat v4 LL addresses as if they were routable addresses.
Clearly they will work with some apps better than others, but we
want to take advantage of those that do work with LL while minimizing
harm to the others.  What I do think is reasonable to expect is 
that LL will try not to get in the way of things that already work -- 
so e.g. hosts and apps should not require LL addresses or assume 
that LL addresses will suffice to reach all hosts of interest, they 
shouldn't use LL addresses if routable addresses are available, 
hosts and apps should be discouraged (if possible) from using LL
addresses in referrals and advertising them in DNS, etc. 

> mentioned above, can be used to essentially say (e.g.) LL is too

yes, it's unquantifiable, but so is most of the rest of this document.  

one interpretation of "minimize impact" is that if there are reasonable
measures which zeroconf could take which would avoid adverse impact
on existing applications while still providing most of the potential
gain from zeroconf, such measures deserve serious consideration.

another would be to "maximize flexibility" of the network to support
a wide range of applications and application behaviors.  again, this
means that we try to find a way to get the extra flexibility that
zeroconf would add while minimizing the amount of flexibility that
exists in the current network that would be removed by adding zeroconf.

but I don't think there's anyway to assign a value to each kind of
flexibility to determine the optimum design point -  it has to be a 
judgement call.

> suggest alternative wording?

my issue is with the adjective "network".  to me DNS names are 
not a property of the network - certainly not of the local network -
since they are intended to be location-independent and they exist 
(and have uses) independently of the network.

> > needs rewording for clarity.

perhaps, but it seems like some clarification is in order.

> another machine (something I still do, even at home).

as do I.  the point is not to drop DNS-like names, or even the use of 
DNS-like names to name hosts - the point is that in many (perhaps most) 
cases these days, what is being named is not a "host" in the traditional
sense of a box with network interfaces, local memory and disk,
logins, etc.  Often what is being named is a "resource" (like a POP 
server, or a collection of web documents) which might correspond
to one or more hosts (which might or might not share a set of IP 
addresses).  Due to multiple hosts being used to implement a single
"resource", along with "virtual" hosts that give the appearance of multiple
"hosts" (really, multiple addresses with separate port # spaces) on a 
single box, the mapping between names and hosts has become fairly arbitrary.  

But if we are thinking "host" names when apps are thinking "resource"
names, we may end up with a zeroconf solution that doesn't support
the needs of those apps.  

Most people's computers are for practical purposes anonymous - they
don't need "host" names because people rarely refer to those hosts
from elsewhere in the network.  nobody expects to log into those hosts 
because they're windows boxes or mac boxes for which the concept of 
"remote access" is fairly foreign.  (IOW, we've regressed to the days 
before ARPAnet :)

I don't know whether zeroconf will change this, but I do expect that
people might be more interested in making "resources" accessible
over ad hoc networks (e.g. game servers, file sharing servers,
local IM servers, conferencing servers) than in making their "hosts" 
accessible over ad hoc networks (in the sense of logging into the hosts, 
or making all of the host's files accessible) and a single host might 
want to make multiple kinds of resources accessible under multiple names.

offhand I don't see anything in LL or MMLNR that precludes this,
but the assumption of "one host - one name" seems to be  fairly
prevalent in all these documents, and it seems anachronistic to me.

> ease-of-deployment issues.

right, and I'd like to see this addressed explicitly *somewhere*.
at least a mention in the requirements doc seems appropriate.

> zeroconf is used. Not sure how to do this...

I think we will need LLMNR to support both global names (including
consistency with DNS) and local names (which don't have to be 
consistent with anything) and we'll need to treat the two cases
separately from a requirements standpoint. 

> for itself -- after some period of time.

What you stated sounds reasonable - I'm not sure whether this is what
was intended.

> I don't see this as being an inherent conflict.

it boils down to the degree to which "formatting" means "look like DNS 
host names".  I would argue that existing apps expect a name that contains
one or more dots to be fully-qualified, globally-scoped, etc.  (some 
existing apps expect that a name that doesn't contain a dot can be 
transformed into a fully-qualified, globally-scoped name by appending
some host-specific suffix, but we have to accept that we can't fix those).

Keith