Re: [mdnsext] Discussion of BoF during Berlin IETF

["Albrecht, Harald" <[e-mail]>]

> -----Ursprüngliche Nachricht-----
> Von: [e-mail] [mailto:[e-mail]] Im
> Auftrag von Michael Richardson
> Gesendet: Dienstag, 4. Juni 2013 15:46
> An: [e-mail]
> Betreff: Re: [mdnsext] Discussion of BoF during Berlin IETF

> 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)

My understanding of the ongoing discussion so far is, that the charter is not focusing solely on mDNS as the underlying technology only, but with a somewhat broader scope of service discovery; thus, also including DNS for those scenarios (use cases) where an IT infrastructure is present. At least to some extent. My impression was that the (pending?) renaming of the upcoming WG reflects this situation. Or did I misunderstand this?

If we talk about the scenario a), we are most probably talking about what is also termed "IT networks", right? That is, a network for office IT? At least with respect to network policies, I know that there are quite some differences compared to networks used in production plants (manufacturing) or control networks.

> 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*.

How true, that's where the devil is in the details. mDNS uses UTF-8 encoding on the wire and DNS uses (at least for host domain names) ASCII/IDNA-2008. Throw in different resolver libs and IDNA support and you are ready for an instant recipe disaster.

-- Harald

> -----Ursprüngliche Nachricht-----
> Von: [e-mail] [mailto:[e-mail]] Im
> Auftrag von Michael Richardson
> Gesendet: Dienstag, 4. Juni 2013 15:46
> An: [e-mail]
> Betreff: Re: [mdnsext] Discussion of BoF during Berlin IETF

> 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    [
>