Subject: [Geopriv] DHCP lbyr extensibility additions

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 29 Apr 2011 10:15:03 +0800

draft-ietf-geopriv-dhcp-lbyr-uri-option claims that it is "highly extensible".  In order to make that claim more plausible, I think that two things need to be done.

1. The sub-option length could use a fixed unit.

The current definition is:

      LuriLength: The length of the LuriValue, not including the
                  LuriLength field itself, up to a maximum of 255
                  units. The unit of measurement is defined by the
                  LuriType field definition. The LuriLength itself is
                  always a one-byte unsigned integer.

Defining length as being dependent on extension type makes this a lot less extensible.  Any LuriType that follows an unsupported LuriType cannot be interpreted because the length of the unsupported LuriType is unknown.

I suggest changing this to use bytes:

      LuriLength: LuriLength is a one-byte unsigned integer
                  containing the length of the LuriValue in bytes,
                  up to a maximum of 255 bytes.

2. The rules for handling multiple sub-options with the same LuriType need to be defined.

This is less important, because extensions can make their own rules about how multiple sub-options with the same LuriType, but the rules need to be defined for LuriType=1 at least.

I suggest something like:

   Unless specified in the definition of a LuriType, multiple
   values for the same LuriType are invalid.  Multiple values for
   an unknown or unsupported LuriType MUST be ignored.

Followed by either:

   Multiple values for a LuriType of 1 (location URI) are allowed.
   Each LuriValue for LuriType=1 represents a different location URI.

Or:

   Multiple values for a LuriType of 1 (location URI) are concatenated.

I prefer the former, but understand that restricting URI length to 255 bytes is potentially troublesome.

On a related point, the following text is inaccurate and should be removed:

   Per [RFC2131], subsequent LocationURI Options, which are
   non-concatenated, overwrite the previous value.

RFC 3396 is pretty clear on this point:

   [...]  RFC 2131 [3] specifies that when more than
   one option with a given type code appears in the DHCP packet, all
   such options should be concatenated together.

--Martin