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 RAA11480 for ; Wed, 6 Mar 2002 17:29:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA23896 for dhcwg-archive@odin.ietf.org; Wed, 6 Mar 2002 17:30:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23808; Wed, 6 Mar 2002 17:28:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23779 for ; Wed, 6 Mar 2002 17:28:02 -0500 (EST) Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11334 for ; Wed, 6 Mar 2002 17:27:57 -0500 (EST) Received: from BarrH63p601 ([63.193.193.26]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GSK007DTP2NCY@mta7.pltn13.pbi.net> for dhcwg@ietf.org; Wed, 06 Mar 2002 14:28:01 -0800 (PST) Date: Wed, 06 Mar 2002 14:27:24 -0800 From: Richard Barr Hibbs Subject: RE: [dhcwg] Host Name option considerations draft In-reply-to: <66F66129A77AD411B76200508B65AC69B4D07B@EAMBUNT705> To: dhcwg@ietf.org Reply-to: rbhibbs@pacbell.net Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: multipart/alternative; boundary="Boundary_(ID_GvsEqDyvksLEk/ylTNElAg)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_GvsEqDyvksLEk/ylTNElAg) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT RE: [dhcwg] Host Name option considerations draft -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Tuesday, March 05, 2002 12:30 Barr, I believe regarding your issue: >In (3), the Host Name *is* the FQDN, but how do I parse it properly into a >"DNS domain name" given that simple rules such as "use the last two parts of >the name" (which works for things like "dot.com") renders the DNS domain >name as "co.uk" which I don't think is what you intend. The host would remove the first label to produce the Domain Name, hence "inside.sales.bluebear.co.uk". That's all it can and should do. Bernie: of course, that is a simple way to parse the name, but it ignores multi-part host names (such as "mike.inside.sales") -- I'll agree that it is probably the only way that a server or client could parse the name, absent much additional information --- > "a client SHOULD check for the presence of both Host Name > and Domain Name options, forming the FQDN by appending the > Domain Name to the Host Name. A client MAY wish to compare > the Host Name option to the Domain Name option to verify > that the Host Name option does not include the Domain Name > part before concatenating the parts." I like this better than what Mike was suggesting because I could easily see a case, such as your (2) below that should work and thus the client can not simply see if the Host Name has one or more dots to determine whether it is fully qualified. I would suggest that (a) if the host name has NO dots, the client should add the domain name. If the host name has one or more dots, the client should only add the domain name if the host name does not end in the domain name. >2. Host Name: "mike.inside.sales" > Domain Name: "bluebear.co.uk" Bernie-- examples always help: suppose a client receives my example (2) -- the correct FQDN should be "mike.inside.sales.bluebear.co.uk" if the client were to receive Host Name: "mike.inside.sales.bluebear.co.uk" and Domain Name: "bluebear.co.uk" then a simple string comparison yields the same result by preventing duplication of "bluebear.co.uk" but what if the client were to receive Host Name: "mike.inside.sales.bluebear" and Domain Name: "bluebear.co.uk" -- in this contrived example, we know the correct result, but in general, I don't think you can assert that two sequential parts of a name cannot be duplicated. It really depends entirely on how the RR's for the domain "bluebear.co.uk" are recorded in DNS. I'll defer to the experts on name matching for DNS as to whether names like "bluebear.bluebear.co.uk" are permitted. --- Perhaps I missed it, but can we be clear about whether the trailing dot MUST NOT be included. And, for backwards compability, a client (and server) should remove any trailing dot if it does exist (this applies to the Host Name, Domain Name, and FQDN options). your comments also suggested that clients should be prepared to deal with malformed host names, such as names ending with a separator (dot) or two consecutive separators -- they don't have to correct malformed names, but should be prepared to handle them in a predictable way. --- One thing that wasn't clear to me (and perhaps it is specified in RFC 2131?), but for a client REQUEST, does (MUST) a client send the Host Name and FQDN options the server sent in the OFFER, or MUST it send what it originally sent in the DISCOVER? From this draft, it would appear it MUST send what was in the DISCOVER and not what the server may have sent back. This raises the questions of what should the client do if it "requests" a host name by sending one in the discover message, but the server responds with a name the client doesn't like? Who owns the name (Carl tried to cover that point) and what recourse is there for a client who doesn't like an offered option value? Some additional discussion may be needed. --Barr --Boundary_(ID_GvsEqDyvksLEk/ylTNElAg) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT RE: [dhcwg] Host Name option considerations draft
 
-----Original Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Tuesday, March 05, 2002 12:30

 Barr, I believe regarding your issue:

>In (3), the Host Name *is* the FQDN, but how do I parse it properly into a
>"DNS domain name" given that simple rules such as "use the last two parts of
>the name" (which works for things like "dot.com") renders the DNS domain
>name as "co.uk" which I don't think is what you intend.

The host would remove the first label to produce the Domain Name, hence
"inside.sales.bluebear.co.uk". That's all it can and should do.

Bernie:  of course, that is a simple way to parse the name, but it ignores multi-part host names (such as "mike.inside.sales") -- I'll agree that it is probably the only way that a server or client could parse the name, absent much additional information

 ---

>      "a client SHOULD check for the presence of both Host Name
>      and Domain Name options, forming the FQDN by appending the
>      Domain Name to the Host Name.  A client MAY wish to compare
>      the Host Name option to the Domain Name option to verify
>      that the Host Name option does not include the Domain Name
>      part before concatenating the parts."

I like this better than what Mike was suggesting because I could easily see a
case, such as your (2) below that should work and thus the client can not simply
see if the Host Name has one or more dots to determine whether it is fully qualified.
I would suggest that (a) if the host name has NO dots, the client should add the
domain name. If the host name has one or more dots, the client should only add
the domain name if the host name does not end in the domain name.

>2.  Host Name:  "mike.inside.sales"
>    Domain Name:  "bluebear.co.uk"  

Bernie-- examples always help:

suppose a client receives my example (2) --  the correct FQDN should be "mike.inside.sales.bluebear.co.uk"

if the client were to receive Host Name: "mike.inside.sales.bluebear.co.uk" and Domain Name: "bluebear.co.uk" then a simple string comparison yields the same result by preventing duplication of "bluebear.co.uk"

but what if the client were to receive Host Name: "mike.inside.sales.bluebear" and Domain Name: "bluebear.co.uk" -- in this contrived example, we know the correct result, but in general, I don't think you can assert that two sequential parts of a name cannot be duplicated.  It really depends entirely on how the RR's for the domain "bluebear.co.uk" are recorded in DNS.  I'll defer to the experts on name matching for DNS as to whether names like "bluebear.bluebear.co.uk" are permitted.

---

Perhaps I missed it, but can we be clear about whether the trailing dot MUST NOT
be included. And, for backwards compability, a client (and server) should remove
any trailing dot if it does exist (this applies to the Host Name, Domain Name,
and FQDN options).

your comments also suggested that clients should be prepared to deal with malformed host names, such as names ending with a separator (dot) or two consecutive separators -- they don't have to correct malformed names, but should be prepared to handle them in a predictable way.

---

One thing that wasn't clear to me (and perhaps it is specified in RFC 2131?), but
for a client REQUEST, does (MUST) a client send the Host Name and FQDN options the
server sent in the OFFER, or MUST it send what it originally sent in the DISCOVER?
From this draft, it would appear it MUST send what was in the DISCOVER and not
what the server may have sent back.

This raises the questions of what should the client do if it "requests" a host name by sending one in the discover message, but the server responds with a name the client doesn't like?  Who owns the name (Carl tried to cover that point) and what recourse is there for a client who doesn't like an offered option value?  Some additional discussion may be needed.

 
--Barr
 


--Boundary_(ID_GvsEqDyvksLEk/ylTNElAg)-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg