Re: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by April 24

[David Hankins <[e-mail]>]

Med, I believe the draft as written is consistent with the publishing of
RFC 6334, and summarizes most of the points you make in
dhc-address-name-encoding.

But your point in section 2.2.2 is hard to understand.  It's equivalent to
configure the regionalized FQDN in the DHCP server or client; the same name
will be resolved from the same (separate administrative domain) DNS server
which is authoritative.  That is to say, whereas Client A and Client B will
resolve separate names if given separate names, Server A will resolve
separate names for Client A and Client B and deliver to them the results of
those specific resolutions.  The only differences are that 1) regional
teams do not get a DNS packet with a source address specific to the client
which they can use to inform load balancing decisions, so this reduces to
be the same as your point in 2.2.3 and 2) the name can not be overloaded
(where e.g. "foo-server.orange.com." is resolved differently depending on
which recursive resolver is used - depending on something similar to what
BIND calls "views") - but this again reduces to your point in 2.2.3 as it
is simply a second level of domain name load balancing.

I can only guess one possible misunderstanding on your part; RFC 3315 FQDN
format options convey Fully Qualified Domain Names.  This is a name
including an explicit zero length label indicating the DNS Root.  DNS
search paths are not applied to names conveyed by RFC 3315 format names,
except as a non-standard extension of the protocol (or by this detail
simply being overlooked by implementers).

So one does not gain any additional ability to handoff between
administrative domains by the ability to configure a "foo-server" server
name in an DHCP option and "thoseguys.orange.com" in domain search path
separately.  There is no significant DHCP server configuration complexity
reduction since all servers I'm familiar with (excepting "embedded device"
/ zeroconf servers etc.) provide a means to concatenate names
hierarchically.


And one of the points you missed in your draft is that the server
performing the recursive resolution to populate an IP address option for
the client most likely locally caches the lookup internally (as opposed to
externally).  This changes the game from a zero-sum latency movement into a
latency net win, obeying DNS TTL semantics.


So in my opinion it remains superior to use a raw IP address format when
there's no compelling reason to promote the option under consideration to a
FQDN.  I believe, after some effort, the participants of the softwires wg,
yourself included, eventually justified that promotion for the publication
of RFC 6334.  Undertaking that effort to extract such requirements is
important; we need to produce the lightest and fastest protocols we can.

"Use What You Need."

It's my opinion that the current text conveys that message.  At some points
in the text, we also underscore that these are guidelines, and it is not
intended for the document to constrain future protocol development.

It's also my opinion that RFC's 3361, and 3319 are casualties of the
organizational failure to clearly communicate the constraints and
requirements.  I'm not familiar with the other RFC numbers, but I'm
guessing a similar problem prevailed.


On Fri, Apr 12, 2013 at 5:12 AM, <[e-mail]> wrote:

> Dear all,
>
> I read this version. Thanks for the work.
>
> IMHO,
> http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-11#section-8does not reflect the consensus of the WG on these matters. Especially, it
> does not reflect what has been discussed during the call for adoption for
> http://datatracker.ietf.org/doc/draft-boucadair-dhc-address-name-encoding/
> .
>
> Saying IP Address is superior to FQDN is just not that trivial to say. It
> is not a universal statement and it makes deployment assumptions. I don't
> want to reiterate what have been discussed for
> draft-boucadair-dhc-address-name-encoding, archives are there to extract
> the exact position of the wg.
>
> The text in Section 8 still assume DNS is the only available name
> resolution library; this is not anymore true. Section 2 of
> draft-boucadair-dhc-address-name-encoding provides a much more balanced
> comparison.
>
> Instead of picking a winner (IP Address vs. FQDN), it is more valuable to
> investigates ways to accommodates operational needs rather than imposing a
> deployment choice for entities deploying servers and making use of a given
> option.
>
> Cheers,
> Med
>
> >-----Message d'origine-----
> >De : [e-mail] [mailto:[e-mail]] De la part de
> >Bernie Volz (volz)
> >Envoyé : mardi 9 avril 2013 17:06
> >À : [e-mail]
> >Objet : [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by
> >April 24
> >
> >Folks, the authors of draft-ietf-dhc-option-guidelines-11,
> >http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-11, feel it's
> >ready for a WGLC.  There's been discussion and comment already, but more
> >eyes on and a "final" review of this work are required to advance it.
> >
> >This document is critical as it provides guidance to others in the IETF
> >that may not be DHCP "experts" when they need to write a DHCP option
> >internet-draft.
> >
> >At the time of this writing, there is no IPR reported against this draft.
> >
> >Please review the draft and indicate whether or not you feel it is ready
> >to be published. Your response matters to the process, so please do
> >respond.
> >
> >As Tomek is an author, I will evaluate consensus after April 24, 2013.
> >
> >Thanks!
> >
> >-      Bernie
> >
> >
> >_______________________________________________
> >dhcwg mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>



-- 
David W. Hankins
SRE - Systems Engineer
Google, Inc.
:x