Re: [mdnsext] Discussion of BoF during Berlin IETF

[Michael Richardson <[e-mail]>]

{I have no travel budget to be in Berlin}

I think that the BOF proposal is very sane and very well thought out.
I question the need for a BOF at this point. I think our set of
requirements and goals is very well understood: I think that there is
enough material there to charter a WG already. 

I am pleased that the commercial enterprise networks and the
R&E campus network scenarios are broken out.  To repeat:

    a) Commercial enterprise networks ("Fortune500")
    b) Academic/educational/university campus networks (R&E)
    c) Multi-link home networks, such as those envisaged by the
       HOMENET WG 
    d) Multi-link/single subnet (mesh) networks, such as those
       described by the ZigBee Alliance Z-IP specification (LLN/LWIG)


I think that they are very different, and I think that we need to leave
the door open to that commercial enterprise networks might be ruled out
of bounds for mDNS.  That is, it might be that all that we wind up with
is a way to signal that mDNS is *not* to be used on a particular
network.   I do not believe that we have many operators of such networks
at IETF meetings to represent their point of view.  (I think about the
operators of the government networks near me... they have many
conflicting requirements, but few clues as to how to put them together)

I am unconvinced that (c)HOMENET and (d)LLNs are in the same problem
space, but I also have no evidence that they aren't.  I think that there
is a scaling of complexity problem that we need to deal with here.

I am very much sure that (a)Fortune500 and (b)R&E do not share very much
in common with (c)/(d), except that the things being plugged into these
networks are from the same vendors, and that some of the devices that get
plugged in tend to travel among all these various places.

I think that 

   3. To develop a BCP for the coexistence of zeroconf (mDNS) and
   unicast (global DNS) name services in such multi-link networks, which
   should include consideration of both the name resolution mechanism
   and the namespace.

may be incomplete or even mis-guided.   It's not that mDNS and global
DNS *services* or even protocols have difficulties co-existing.  They do
that just fine.   It is a question of them *interacting*.  The place 
where they interact is on the *host*.

We are not writing a network protocol!
We are creating a clear state machine that a host implements that takes
inputs ("replies"/"responses") from existing network protocols and acts
in deterministic and user-useful ways.

Our documents should not have time-sequence diagrams in it, assuming
that we are god and can control the other hosts.  Rather, it should have
inputs and state changes for a host, and yes, even messages to users
and/or applications about what is available.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [