Subject: RE: [dhcwg] Use of FQDN vs IP address

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Wed, 7 Jun 2006 19:48:06 +0200

Hi Stig,

Thanks for the answer!

Refering to existing RFCs defining options to locate server, I was considering that the use of IP addresses and FQDNs was quite widespread, at least for the last ones.
I clearly understand your concerns and your suggestion. And I don't want to debate on this (I'm not a DHCP expert ;) even if I'm pretty sure that your comments also apply to other standard options using both IP addresses and FQDNs.

May I ask to the dhc wg if this view is shared and could be seen as a general guideline for the work on the definition of new options, despite existing standard counterexamples (which were maybe youthful indiscretions ;)? If it is the case, I will provide a revision to remove the FQDN option.

BR,

Lionel

-----Message d'origine-----
De : Stig Venaas [mailto:[email-masked]] 
Envoyé : mercredi 7 juin 2006 19:13
À : MORAND Lionel RD-CORE-ISS
Cc : [email-masked]
Objet : Re: [dhcwg] Use of FQDN vs IP address

MORAND Lionel RD-CORE-ISS wrote:
> During the dhc WG session, there was a couple of discussions about the 
> use of FQDNs in dhcp options to provide information to a dhcp client.
> We can all agree on the fact that using IP@ instead of FQDN makes life 
> easier. However, if we can recommend to use IP@, should we forbid 
> someone to use FQDN if possible?

Even if the protocol only supports IP, the DHCP server or some configuration tool could do a DNS lookup.
> 
> I'm not an expert on dhcp or dns but I think that this kind of choice 
> depends on how you want to configure your network. And if someone sees 
> some advantages to rely on DNS administration instead of dhcp 
> configuration when possible, is there any dhcp implementaton issue to 
> use FQDN based options, except maybe concerns about the total length 
> of the dhcp messages?

The length is the big reason, I think we need pay more attention to this. Using only IP rather than having suboptions for IP and FQDN also simplifies the option usage. Having both means that the clients need to be able to handle both.
> 
> For the dhc-paa-option draft in particular, I repeat that there is no 
> reason to mandate one or the other method from a pana specification 
> standpoint. The requirement is just to be able to use DHCP to locate 
> PANA agent, whatever the way to finally get the agent's IP@ (IP@ 
> retrieved from the DHCP or using DNS resolution). After it's a matter 
> of network configuration.

So I suggest we only use IP here. In general we should use only IP unless there are specific reasons for using FQDN. At least that's my view.

Stig

> 
> BR,
> 
> Lionel
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg

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

---

From: Stig Venaas <[email-masked]>
Date: Wed, 07 Jun 2006 20:45:30 +0200

> I clearly understand your concerns and your suggestion. And I don't want to debate on this (I'm not a DHCP expert ;) even if I'm pretty sure that your comments also apply to other standard options…

Yes, I understand this might seem strange, and that you probably used 
those as examples when you designed your option.

My comments apply to other cases as well, and I'm not so sure we did the 
right thing in all of those. In my opinion we should begin to be more 
cautious.

> May I ask to the dhc wg if this view is shared and could be seen as a general guideline for the work on the definition of new options, despite existing standard counterexamples (which were maybe yo…

At least for me you might call it youthful indiscretions, I haven't been 
involved with the dhc protocol details that long. I've only recently 
realized how little space we actually have.

I've also realized that there are a number of other considerations 
regarding designing new DHCP options where people tend to make mistakes. 
E.g. multiple encodings vs sub-options, and sub-options vs separate 
options. Maybe we as a group should try to write down considerations for 
designing new options?

Stig

---

From: Ted Lemon <[email-masked]>
Date: Wed, 07 Jun 2006 11:49:54 -0700

Stig Venaas wrote:
> regarding designing new DHCP options where people tend to make 
> mistakes. E.g. multiple encodings vs sub-options, and sub-options vs 
> separate options. Maybe we as a group should try to write down 
> considerations for designing new options?
>
Ooh, this is a good idea!

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 8 Jun 2006 09:31:55 -0700

> options. Maybe we as a group should try to write down considerations for 

I've slowly been making progress on a tangential input, describing
Ted Lemon's option processing system in ISC DHCP (or, my mangled version
of it on HEAD since it includes forward-looking statements) in as much
detail as possible.

The goal was to describe how the implementation operates, so that
the reader is better armed to produce easily adoptable options (remember
at the time, all these multi-format options had each invented their own
contrived formats, and my main concern was the nightmare this presented
me).

The goal wasn't to provide advice on how to write dhcp option drafts,
except where that was a side-effect.

I haven't quite gotten to the point where I'm ready to -00 it, but it's
not far off.  Maybe 75% done.  I took an internal-language centric view
to start with, and determined that was too hard to read - I'm rewriting
bits and pieces from a configuration-language centric view which is
much easier on the eyes.

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg