Subject: [dhcwg] Review of "DHCP-based LoST Discovery Procedure"

From: "Tschofenig, Hannes" <[email-masked]>
Date: Fri, 27 Apr 2007 14:44:14 +0200

Hi all, 

In the ECRIT working group we have discovered the need to define a
discovery mechanism based on DHCP for LoST servers. Please find the
document here:
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-dhc-lost-discovery-
01.txt

We would appreciate the review of this document. 

Ciao
Hannes

PS: Marc has contacted the DHC chairs when we did the WGLC in ECRIT
already but I couldn't find the message anymore. Hence, I just want to
make sure that the document receives adequate review. 

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

---

From: Mark Stapp <[email-masked]>
Date: Fri, 27 Apr 2007 10:39:01 -0400

Hannes, Marc,

just a couple of comments:

section 3: do you think it's better to spell this out, or would it be 
better to just reference DNS encoding?

section 4: there's a v4 analogue to the v6 "Option Request Option": the 
"Parameter Request List" option. you mention the v6 option in section 5, 
but don't mention the v4 option here.

section 7: you're using the mnemonic OPTION_LOST for both the v4 and v6 
option codes. would it be clearer to use OPTION_V6_LOST or something 
like that?

section 10: I think the RFC3396 ref should be 'normative', since you're 
making it mandatory.

I think you should include 1034 in the 'normative' section, since 
there's no way for the client to use the info in the option without it.

the 'LoST' protocol draft is in the 'normative' section, but I don't 
think it's needed there. you're just specifying options that point a 
client at a server: you're not requiring any LoST behavior in this 
draft, so I think the LoST reference could be informative.

the draft doesn't appear to reference 3319 or 3361, but they are 
included in the 'informative' section?

Thanks,
Mark

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 27 Apr 2007 09:12:24 -0700

> better to just reference DNS encoding?

We just had a document returned to the DHC WG from the IESG due
to recursive references, which also condemned RFC3315's RFC1035
reference as being too vague, I think?

I remember Ralph said a new document that described "dhcp wire format
for domain names" without any normative recursive references would
come into existence, so I'm just wondering if that can be used here
directly.

> option codes. would it be clearer to use OPTION_V6_LOST or something 

I'd actually lean towards dropping the symbolic name on the DHCPv4
option definition, placing just the code in the appropriate field.
This is more consistent across DHCPv4 option definitions, as none
of them to my memory have included a symbolic name.

More to the point, the IANA registry uses the OPTION_ symbolic
names in DHCPv6, whereas in DHCPv4 the 'Name' column appears
to look like the section title for each option definition
("NIS Servers").

My own comments;

   Only a single domain name MUST be present in the DHCPv4 option.

This reads weird to me.  That is, although it uses normative MUST,
the word 'Only' in my english dialect leads me into a weird corner
where it's saying "1 is the minimum number of domain names allowed."

I think the author meant the option should only include one domain
name.  I suggest:

  This option contains a single doamin name, and as such MUST contain
  precisely one root label.

Possibly also (but this is getting a bit verbose):

  Clients SHOULD stop processing the option at the first root label,
  ignoring any trailing data.

Which is different from "asserting an error" and discarding the
packet or similar.

   For DHCPv4 only:  If the length of the domain name exceeds the
   maximum permissible within a single option (i.e., 254 octets), then
   the domain name MUST be represented in the DHCP message as specified
   in [RFC3396].

254?  255.  In DHCPv4 it's quite a bit more complicated than that,
since the option also might not fit in the options field even if it
is less than 255 octets in length...in which case option overloading
comes into play.

I would probably drop this paragraph entirely since the largest
legal option is already described as being 255 octets in length,
and that's how many octets you can describe with the 8-bit length
field.

Although that's a bit surprising to people who don't know
about option overloading (RFC2132 I think), that even options
smaller than 255 might appear multiple times and have to be
fragmented.  This is a core protocol feature however, so if
someone is already "doing" DHCPv4, then they either support
this generally for all options or not.

-- 
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