Subject: [dhcwg] Updated ID notice: draft-polk-dhc-uri-01

From: "James M. Polk" <[email-masked]>
Date: Thu, 29 Sep 2005 12:06:02 -0500

DHC WG

For those interested...

http://www.ietf.org/internet-drafts/draft-polk-dhc-uri-01.txt

I've updated this ID to -01 with the following changes:

    - added a second URI to the main bit format in Figure 1.

    - Added several requirements

    - Deleted several rules surrounding how to get around RFC3396 (silly 
me!), which are no longer necessary, because I...

    - brought this document in line with RFC3396, including the sub-option 
length parameter per URI

    - removed the ability to concatenate fields

As a result of the above bullet, I don't like the side effect of limiting 
the total Option field length to 253 bytes. I'd like to be able to have 
more than one URI in a message (up to 576 bytes - if there is room), but 
3396 limits more than one instance of a Option to being a concatenated 
field. Any suggestions on getting around that would be helpful.

    - modified the doc to limit the size of a URI to 253 bytes max

    - Added a section on how multiple URIs are derived

    - Added a section on how a client requests one or more URIs

    - Edited terms to be more consistent with the ECRIT Reqs ID

    - Added new concerns to the Security Considerations

Comments area appreciated

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

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

---

From: Andre Kostur <[email-masked]>
Date: Thu, 29 Sep 2005 10:15:24 -0700

James M. Polk wrote:

>    - Deleted several rules surrounding how to get around RFC3396 
> (silly me!), which are no longer necessary, because I...
>
>    - brought this document in line with RFC3396, including the 
> sub-option length parameter per URI
>
> As a result of the above bullet, I don't like the side effect of 
> limiting the total Option field length to 253 bytes. I'd like to be 
> able to have more than one URI in a message (up to 576 bytes - if 
> there is room), but 3396 limits more than one instance of a Option to 
> being a concatenated field. Any suggestions on getting around that 
> would be helpful.

How does this limit the total Option field to 253 bytes?  You can just 
keep re-specifying your uri option over and over again, each one 
supplying an URI.  The client concatenates all of the URI options 
together (for a total length of up to n * 253 bytes), and uses the 
individual uri lengths to break out the individual URIs...

---

From: Andre Kostur <[email-masked]>
Date: Thu, 29 Sep 2005 10:32:26 -0700

> http://www.ietf.org/internet-drafts/draft-polk-dhc-uri-01.txt
Other more general comments:

Section 1:

   A client may request more than one URI be sent to it within the same
   DHCPDISCOVER or DHCPREQUEST message.  Each URI will be inside its 
   own payload container with an Option number, a length field and a 
   purpose field.  This means that if more than one URI is being 
   requested or downloaded, there can be more than one DHCP Option XXX 
   (this document's option number) in the same IP message.  Each URI 
   will be inside the DHCP Option payload shown in section 2 of this 
   document.  There is no meaning to the order of URIs in a message.  

Why does this imply that there is a mapping of 1 URI to 1 DHCP Option XXX?
If one has 4 10-byte URIs, why can't all 4 be in the same instance of the Option?

Section 2.1:

   - [RFC2131] limits the size of an Option to 255 bytes, and this 
     Option is no different.  If there are more than one URI to be sent
     to a client, and the aggregate byte count is greater than 255 
     bytes, the URIs will be sent in more than one message to the 
     client.

You don't get multiple messages.  Only 1 message.  This statement seems to imply
that if the server wanted to send many URIs to the client, it could send multiple
DHCPACKs to the client to transmit them all.  You probably mean to say:
"the URIs will be sent in more than one instance of the URI option" (or something similar).

Section 2.1:

   - Server responses to a request for more than one URI MAY be in 
     separate messages (i.e. one URI per message), at the server's 
     discretion 

Same as above.

Section 2.3:

   Conceivably though, each available URI purpose MAY be in a DHC 
   message.  The client MUST be prepared to receive each URI requested,
   even in separate messages from the server.  The client MUST NOT 
   request the same URI purpose more than once in the same message.

Same as above.

Also, this specification doesn't say what format URI's are in.  And perhaps it 
should carry a reference to RFC 3986 - "Uniform Resrouce Identifier (URI): Generic Syntax"?

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 29 Sep 2005 12:34:58 -0500

At 10:15 AM 9/29/2005 -0700, Andre Kostur wrote:
>keep re-specifying your uri option over and over again, each one supplying 
>an URI.  The client concatenates all of the URI options together (for a 
>total length of up to n * 253 bytes), and uses the individual uri lengths 
>to break out the individual URIs...

Really?

I didn't read this facet/flexibility from 3396 so, I have to admit, I had 
no idea this was possible.

This is great if true - and I have no reason not to believe you.

I see an -02 coming very soon then with this clarification.

Thank you, Andre!

cheers,
James

                                 *******************

---

From: Andre Kostur <[email-masked]>
Date: Thu, 29 Sep 2005 10:55:48 -0700

James M. Polk wrote:

>>> there is room), but 3396 limits more than one instance of a Option 
>>> to being a concatenated field. Any suggestions on getting around 
>>> that would be helpful.
>>
>>
>> How does this limit the total Option field to 253 bytes?  You can 
>> just keep re-specifying your uri option over and over again, each one 
> I didn't read this facet/flexibility from 3396 so, I have to admit, I 
> had no idea this was possible.
>
Take a look at RFC 3396, section 8.  It shows an example of a 13-byte 
Option 67 being split into two instances of option 67, one with 7 bytes, 
one with 8 bytes.  On the client side, it would reassemble that into a 
single Option 67 with an aggregate length of 13 bytes.  In your case you 
could have an URI Option of length 500 bytes. The server would need to 
split it into one of 255 bytes, and one of 245 bytes (or split it into 3 
options of 200, 200, and 100 bytes... as long as it adds up to the 500 
bytes, and no single instance is longer than 255, it's fine).  On the 
client side, it would need to reassemble all of the pieces back into the 
aggregate 500 byte option.  Then it can parse through it to recover the 
individual URIs as necessary.  (Oh.. also assuming that the client can 
accept that large of a DHCP packet... but that's a different 
consideration.  Recall that clients may negotiate a larger DHCP packet 
side.... see RFC 2132, section 9.10).