Hi Ted, Thanks for the comments. There was a question on this on the softwires list also, so I'm cross-posting:
> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Ted > Lemon > Sent: Monday, November 23, 2009 8:42 PM > To: Fred Templin > Cc: dhc WG > Subject: [dhcwg] Comments on draft-templin-isatap-dhcp-03.txt > > Section 1, Section 3: don't abbreviate "Potential Router List" as > "PRL" - it clashes violently with the existing DHCP "PRL", which is > the parameter request list. Better to just spell it out - it appears > four or five times in the document, which is a pain, but not too bad. Thanks for catching that; I'll fix it. > Put the IP address and FQDN counts right before the data being > counted, not at the beginning of the option - the way the draft > currently does it violates common practice and will require a special > code path in conforming implementations. So it should be option code, > len, anycast address, ip-addr-count, ip-addr-1, ..., ip-addr-n, > fqdn-count, fqdn-1, ..., fqdn-n. Got it, and I'll fix this. > Why are you specifying both IP addresses and FQDNs? Standard practice > in DHCP is to just send FQDNs and let the DHCP server do name > resolution. Sending both makes the implementation more complex - is > there some reason why this complexity is necessary? It's going to be > difficult to specify in the DHCP server configuration, since most > existing DHCP servers accept FQDNs in any configuration field where an > IPv4 address is expected - how is the parser supposed to tell which > FQDNs to resolve and which to send to the client unresolved? The way ISATAP is currently specified, it expects to get a connection-specific DNS suffix from the DHCP server (i.e., from a domain name option) and then self-constructs an FQDN by prepending the well-known string "isatap" (e.g., as "isatap.example.com" when the suffix is "example.com"). The ISATAP client then resolves the FQDN itself by consulting the DNS. So, I want to preserve backward compatibility and maintain the same administrative profile whereby the client gets some information from DHCP and then consults the DNS on its own behalf. The client then uses the DNS TTLs as an indication of when it should re-resolve the FQDN. So administrative changes normally touch only the DNS resource records and only very rarely need to touch the DHCP config's, and clients discover the updates via DNS. > If you do actually need FQDNs for some reason, you need to specify how > they are encoded. The standard practice for DHCP options would be to > have some text similar to section 8 of RFC3315. RFC3315 cites Section 3.1 of RFC1035. That is the same normative reference I am citing in the current draft. (Actually, it looks like I cited RFC1035 twice; I'll fix that.) > The sample data for the FQDN option has a leading '.' fqdn before the > isatap.com fqdn, which makes the count wrong. Good catch; I'll fix this. > Why is this an informational draft? No particular reason; should I try for PS? Thanks - Fred [email protected] > _______________________________________________ > dhcwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
