RE: [dhcwg] DHCP Option for CableLabs Client Configuration

"Cosmo, Patrick" <Patrick@incognito.com> Thu, 08 August 2002 15:02 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14895 for <dhcwg-archive@odin.ietf.org>; Thu, 8 Aug 2002 11:02:35 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07491 for dhcwg-archive@odin.ietf.org; Thu, 8 Aug 2002 11:03:49 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07322; Thu, 8 Aug 2002 11:02:43 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07291 for <dhcwg@optimus.ietf.org>; Thu, 8 Aug 2002 11:02:41 -0400 (EDT)
Received: from portal.incognito.com (PORTAL.INCOGNITO.COM [207.102.214.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14744 for <dhcwg@ietf.org>; Thu, 8 Aug 2002 11:01:26 -0400 (EDT)
Received: from homerdmz.incognito.com ([207.102.214.106] helo=homer.incognito.com.) by portal.incognito.com with smtp (Exim 3.33 #1) id 17coTU-0006oH-00; Thu, 08 Aug 2002 07:41:16 -0700
Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id <PWXWML77>; Thu, 8 Aug 2002 08:11:34 -0700
Message-ID: <4FB49E60CFBA724E88867317DAA3D198692F6D@homer.incognito.com.>
From: "Cosmo, Patrick" <Patrick@incognito.com>
To: "'Woundy, Richard'" <RWoundy@broadband.att.com>, dhcwg@ietf.org
Cc: Thomas Narten <narten@us.ibm.com>, 'Erik Nordmark' <Erik.Nordmark@sun.com>, Matt Osman <M.Osman@cablelabs.com>
Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration
Date: Thu, 08 Aug 2002 08:11:32 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23EED.E13B0CF0"
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org

>For a concrete instantiation of this 
>assumed functionality, please consider
>the BIND documentation for the "listen
>-on" configuration option, e.g.
>section 6.2.14.4 of
><http://www.nominum.com/resources/documentation/Bv9ARM.pdf>. 
>It would be helpful to hear about 
>other DNS servers with this capability.

Incognito's DNS Commander has this capability (www.incognito.com)




-----Original Message-----
From: Erik Nordmark [mailto:Erik.Nordmark@sun.com]
Sent: Wednesday, August 07, 2002 5:04 AM
To: Woundy, Richard
Cc: 'Erik Nordmark'; Josh Littlefield; Paul Duffy; Thomas Narten; Bernie
Volz (EUD); 'Ralph Droms'; dhcwg@ietf.org; nrussell@cisco.com;
pgrossma@cisco.com; Matt Osman
Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration


> 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
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg