Subject: [dhcwg] Comments on the fqdn drafts

From: Stig Venaas <[email-masked]>
Date: Fri, 7 Jan 2005 18:18:31 +0100

I've been reading through the FQDN drafts and have some comments.
That is, I've looked at draft-ietf-dhc-fqdn-option-08.txt and
draft-ietf-dhc-dhcpv6-fqdn-00.txt. I'll be referring to these as
fqdn4 and fqdn6.

In fqdn4, the format diagram doesn't make it clear what the size
is, although it might be inferred by knowing that some fields are
8 bits. In particular one might think that the rcode fields are 4
bits, since rcode is 4 bits in the DNS protocol. In the rcode
section it is pointed out that they are one byte each though.

In fqdn6 I think perhaps the "4.1  The Flags Field" section could
be improved by defining the bits more explicitly. Like what is
done in fqdn4. fqdn6 talks more about how the bits are used than
what their meaning is.

In fqdn4 in description of N-bit it says:
   The "N" bit indicates whether the server SHOULD NOT perform any DNS
   updates.  A client sets this bit to 0 to request that the server
   SHOULD perform updates (the PTR RR and possibly the A RR based on the
   "S" bit) or to 1 to request that the server SHOULD NOT perform any
   DNS updates.  A server sets the "N" bit to indicate whether it SHALL
                                                              ^^^^
I assume "it" here mans server, but since previous sentence talks
about the client, I at least was slightly in doubt whether "it" here
is the server or the client. I had to look at the other text to be
sure.

   (0) or SHALL NOT (1) perform DNS updates.  If the "N" bit is 1, the
   "S" bit MUST be 0.

fqdn6 talks about IDN and canonicalization. I don't find any mention
of it in fqdn4, but it's an issue there as well, right?

In fqdn6 it says:
   not necessarily know the zone in which the name is to be embedded.  A
   client which wants to convey part of its FQDN sends a non-terminal
   sequence of labels in the domain name field of the option.  Clients
   and servers should assume that the name field contains a
   fully-qualified name unless this partial-name format exists.

I think the wording in the v4 draft about "terminating zero-length
label" is clearer.

In fqdn4 it says:
   A client MAY also leave the Domain Name field empty if it desires
   the server to provide a name.

Is there a reason for this not being in fqdn6 as well?

In fqdn6 in the "6.  DHCPv6 Server Behavior" section, it doesn't
say anything about flags. Perhaps it should be expanded a bit? I think
the fqdn4 text is better here.

Finally, at last meeting when discussing
draft-yan-dhc-dhcpv6-opt-dnszone, Ted said that fqdn option in
information request could be useful. Perhaps DHCPv6 fqdn shouldn't
be restricted to IA_NA/IA_TA suboptions? Might it not be useful as
a "top-level" option or as IA_PD suboption?

I don't know what the best solution is, but I wonder if we should
consider this further now, or if we prefer to update this later if
it becomes useful.

I haven't seen much comments from anyone else on the drafts during
the last call. I myself am guilty of not reading and posting this
earlier...

Stig

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

---

From: "Bernie Volz" <[email-masked]>
Date: Sun, 9 Jan 2005 13:23:02 -0500

Stig:

The dhcpv6-fqdn draft is "old". The changes recently made to the dhcpv4 fqdn
draft will be made to the dhcpv6. So, best to ignore the dhcpv6-fqdn draft.

See additional comments below.

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Stig Venaas
> Sent: Friday, January 07, 2005 12:19 PM
> To: [email-masked]
> Subject: [dhcwg] Comments on the fqdn drafts
> 
> 
> I've been reading through the FQDN drafts and have some 
> comments. That is, I've looked at 
> draft-ietf-dhc-fqdn-option-08.txt and 
> draft-ietf-dhc-dhcpv6-fqdn-00.txt. I'll be referring to these 
> as fqdn4 and fqdn6.
> 
> 
> In fqdn4, the format diagram doesn't make it clear what the 
> size is, although it might be inferred by knowing that some 
> fields are 8 bits. In particular one might think that the 
> rcode fields are 4 bits, since rcode is 4 bits in the DNS 
> protocol. In the rcode section it is pointed out that they 
> are one byte each though.

Wow, this has been this way for as long as I've known the draft and this is
the first time someone has pointed this out. I guess most people have
assumed that the first two fields are byte fields that the remaining are as
well.

> 
> In fqdn6 I think perhaps the "4.1  The Flags Field" section 
> could be improved by defining the bits more explicitly. Like 
> what is done in fqdn4. fqdn6 talks more about how the bits 
> are used than what their meaning is.
> 

This will be done when the fqdnv6 draft is revised later this month.

> ^^^^ I assume "it" here mans server, but since previous 
> sentence talks about the client, I at least was slightly in 
> doubt whether "it" here is the server or the client. I had to 
> look at the other text to be sure.
> 

Yes, it does mean server. I'm not sure why that is confusing. But if clarity
is improved I can change this to read "A server sets the "N" bit to indicate
whether the server SHALL...".

> 
> 
> fqdn6 talks about IDN and canonicalization. I don't find any 
> mention of it in fqdn4, but it's an issue there as well, right?

Olafur told me to drop the IDN and canonicalization stuff out of the dhcpv4
draft; it will disappear from the dhcpv6 one as well.

> I think the wording in the v4 draft about "terminating 
> zero-length label" is clearer.

Again, the fqdnv6 draft is "old".

> In fqdn6 in the "6.  DHCPv6 Server Behavior" section, it 
> doesn't say anything about flags. Perhaps it should be 
> expanded a bit? I think the fqdn4 text is better here.
> 
> 
> draft-yan-dhc-dhcpv6-opt-dnszone, Ted said that fqdn option 
> in information request could be useful. Perhaps DHCPv6 fqdn 
> shouldn't be restricted to IA_NA/IA_TA suboptions? Might it 
> not be useful as a "top-level" option or as IA_PD suboption?

I can't see any value in this since this would not be a FQDN but instead a
domain name. We don't have a mechanism for communicating that it is just the
domain name portion, not the FQDN. If this becomes important in the future,
we can revisit it.

> 
> I don't know what the best solution is, but I wonder if we 
> should consider this further now, or if we prefer to update 
> this later if it becomes useful.
> 
> 
> I haven't seen much comments from anyone else on the drafts 
> during the last call. I myself am guilty of not reading and 
> posting this earlier...
> 

I did have some additional comments, mostly minor. It is odd that it hasn't
made it to the IETF repository and I will check with internet-drafts to see
what may be the hold up.