RE: [dhcwg] DHCP Option for CableLabs Client Configuration

[Erik Nordmark <[e-mail]>]

> Are you suggesting that if folks in the cable world still believe that there
> is a requirement to communicate DNS port numbers to MTAs, then they should
> define an additional Internet draft that is published as Experimental or
> Informational?

Depends on the ellusive details.

It would be better if they could clearly communicate the requirement so that
the IETF can look at it and try to understand what type of reqirement it
is and whether or not it is a requirement specific to the cablelabs type
of environment. 

If the requirement is that for testing purposes or experimentation 
in the cablelabs environments it is useful to be able to use different port
numbers for DNS, then a separate info or experimental document would make
sense. But I can't yet tell whether this is the case.

> Note that the PacketCable specifications themselves, and the long-term
> intent of the CableLabs Config option, is to enable VoIP services beyond
> "walled garden" services. We are just talking about part of the DHCP option
> information in that draft, no?

Yes. Thomas had some issues with the other suboptions, but my concerns
is about the DNS.

> I don't quite understand the issue of non-interoperability. If an RFC
> explains the expected DNS behavior of the MTA, and there are multiple
> implementations that support that expected DNS behavior in DNS servers,
> then... what's the issue again?

There is in theory potential interoperability issues both for DHCP and DNS.
DHCP: will things operate correctly if the MTA receives a good ol' DNS
name server option instead of this suboption? If not you either get all
the DHCP servers on the planet to implement the cablelabs option or you could
end up with interoperability problems.
DNS: will things operate correctly if the MTA is using the standard DNS port?
If not you either get all the DNS resolvers on the planet to be configurable
to run on an alternate port, you could end up with interoperability problems.

Of course, by careful selection of parts (DHCP servers, DNS resolvers) for
a cablelabs environment one can avoid these problems. But part of the benefits
of the Internet interoperability story is that it doesn't require special
versions of protocols and software; things off the shelf just tend to
interoperate. This off-the-shelf aspect and the price of equipment that
results is often a key perceived benefit of using the internet protocols.
So let's think a bit before embarking on paths that break this.

> The biggest advantage is that a cable operator could run multiple DNS
> servers on the same hardware, with separate administrative tools, run by
> possibly independent operations folks. There would be no issues about the
> impacts of one DNS service configuration change on the other DNS service.
> Both DNS services could be verified independently, without the need of
> performing DNS queries "from the right location for the right test".

Thank you!!! It's something concrete like this that I've been looking for
all along.

Have people been thinking about this when there are only two DNS servers
on the box (one for the best-effort IP network and one for the VoIP network),
or have people also been thinking about outsourcing cases where a
single DNS box might provide DNS service for multiple VoIP networks run by
different operators? I think understanding whether it can be more than 2
in a box might be important.

  Erik




_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg