Re: [dhcwg] way forward for the mipshop-mos-dhcp document

["Bernie Volz (volz)" <volz at cisco.com>]

No reason not to post this to the list. Everyone is entitled to a mistake now and then and it benefits all to make sure things are clear.

Yes, "a." should be <1>, 'a', <0> which is 3 octets. And, perhaps they don't want to allow just a "." (<0> octet)?

Though they also violated their rule later when they stated (in section 6.1.2 and 6.2.2):

   In case that the server cannot find any Mobility Server satisfying 
   the requested Sub-opt Code, the server MUST return the MoS Option 
   with a sub-option by setting the Sub-opt Code to the requested
   Sub-opt Code and the length of the sub-option to 1.

And I suggested the sub-option length be 0, not 1.

This, they technically need to allow values of 0, 1 (for "."), and >= 3. I see little value in spelling this out and I'd just leave the text about the minimum encoding length out.

Thanks for correcting my error regarding "a." but I it really doesn't impact my comment about the minimum length.

- Bernie

-----Original Message-----
From: Alfred HÎnes [mailto:ah at tr-sys.de] 
Sent: Tuesday, March 10, 2009 10:00 AM
To: Bernie Volz (volz)
Cc: jari.arkko at piuha.net; draft-ietf-mipshop-mos-dhcp-options at tools.ietf.org; mipshop-chairs at tools.ietf.org
Subject: Re: [dhcwg] way forward for the mipshop-mos-dhcp document 

Hello Bernie,
in your recent posting in response to Jari's statement,
I fear there is a flaw that I do not want to post on the
full distribution list of your message.

You are pointing out:

> Section 3:
>
>    The Sub-option begins with a sub-option code followed by a length
>    and a sequence of labels that are encoded according to Section 8 of
>    [RFC3315].
>
>    [RFC1035] encoding was chosen to accommodate future international-
>    lized domain name mechanisms. The minimum length for this encoding
>    is 3.
>
> I don't understand why the minimum length of RFC 1035 encoding is 3? If
> you wanted to send "." it would be 1 octet (or a. which would be 2).
> Perhaps "this encoding" refers to the suboption/suboption-length/data
> but it is not clear in this text. Also, the switch between RFC 3315 to
> RFC 1035 is a bit odd unless one actually looks at RFC 3315, Section 8.

Well, IIRC, the 2nd paragraph to some degree is an 'exploded' version
of the first one.  RFC 3315 requires RFC 1035 (DNS wire format)
encoding of domain names, and a DHC document is perhaps well advised
to follow rules in the basic DHC specification(s), and to document
that it does so.

In DNS wire format (neglecting shortcuts only possible within DNS
messages), FQDNs are encoded as a series of labels, with the last
label being the Root label; labels are encoded as 'counted strings'.
Thus indeed the FWDN "a." is encoded as  0x01 0x61 0x00 -- 3 octets,
nor 2 !!! --, and the lower limit, 3, *does* make sense:
The 'count' octets are restricted to 0x01..0x3F (1..63) because the
high order bits are used to indicate other encodings, and 0x00 is
only admitted in the root label; this is the reason why DNS labels
are limited to 63 bytes; the 255 octet total limit on FQDN length
in RFC 1035 applies to any encoding of an FQDN, in particular this
primary ASCII encoding.
Altogether, a legal encoded FQDN can never be comprised of 2 octets;
1 octet for the root (0x00), or 3..255 octets for 'real' domain names.


Kind regards,
  Alfred HÎnes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah at TR-Sys.de                     |
+------------------------+--------------------------------------------+