Subject: [dhcwg] New ID for downloading URIs via DHCP

From: "James M. Polk" <[email-masked]>
Date: Mon, 12 Sep 2005 22:32:10 -0500

DHC WG

To let folks know - a new individual submission Internet Draft has been 
announced regarding using DHCP for downloaded (or requesting for, then 
downloading) URIs to a DHC client here:

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

with this abstract

    This document defines a new Dynamic Host Configuration Protocol
    (DHC) Option to allow one or more URIs to be transmitted from a
    server to a client within one or more messages, and for one or more
    URIs, each with a unique purpose, to be specifically requested by a
    client of a server.  Included in this Option is a purpose field to
    identify the type of URI being requested by the client, or the type
    of URI in the DHCP message from the server.

Of interest, I hope, to the DHC WG is that this proposed Option requests 
the use of a single DHCP Option to be used for URIs of multiple purposes, 
each identified by a sub-option code called a "purpose". This is done a 
little differently than in RFC 3396 where the sub-options are smaller.  I 
don't believe I violated any length rules of 2131 or 3396, and I believe I 
articulate how to address lengths and concatenation in this document for 
longer URIs, and for how to include more than one URI - each of a different 
purpose - in the same DHCP message, or in the same IP datagram (with the 
same Option value - but different purposes).

The focus of the proposed URIs are primarily surrounding the Geopriv and 
ECRIT WGs

There are 11 URIs currectly defined in this ID (acronym explosion and 
definitions are in the ID):

    Purpose = 1  (Primary PSAP URI)
    Purpose = 2  (Secondary PSAP URI)
    Purpose = 3  (Location By-Reference of Client)
    Purpose = 4  (ESGW URI of Client)
    Purpose = 5  (ESRP URI of Client)
    Purpose = 6  (Organization Providing Location for Client)
    Purpose = 7  (URI of Geocoding/Reverse Geocoding)
    Purpose = 8  (Primary URI of Geo Mapping Service)
    Purpose = 9  (Secondary URI of Geo Mapping Service)
    Purpose = 10 (Primary URI of Civic Mapping Service)
    Purpose = 11 (Secondary URI of Civic Mapping Service)

Others can be added based on consensus discussion of this document

I just spoke with the Ralph Droms, and open discussion of this ID on the 
ECRIT list is fine with him.  The formal syntax and encoding of the option 
proposal is to be discussed on the DHC list for those interested here, but 
the URI meanings don't need to be discussed on this list where emergency 
calling and location conveyance/conversion is of fairly little concern, as 
ECRIT is the primary WG of interest for this effort initially.

That said, newly proposed URIs with completely different purposes can be 
included in this document. I am not suggesting a limitation (other than the 
one byte purpose length field of 255  ;-)

BTW - I have no range set aside for private purposes. Is this needed?

Reviews and comments are 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: Mark Stapp <[email-masked]>
Date: Fri, 16 Sep 2005 10:34:59 -0400

James,

this proposal binds this ECRIT/geo data pretty tightly to dhcp 
configuration. the entire catalogue of 'purposes' is exposed in the 
option, and in the dhcp configuration details. is that really desirable? 
to me, it seems as if this data is pretty domain-specific, and coupling 
it so tightly to dhcp could be a limitation going forward.

1. adding, deprecating, or changing a 'purpose' means another 
interaction with dhcp or iana.

2. as proposed, some entities have to get this information via dhcp. are 
there other entities in a real system who will have to get the same data 
some other way? if some of the parts of a system have to get critical 
data by dhcp, and some other parts have to be configured some other way, 
it becomes harder for the whole system to undergo coordinated changes. 
could that be an issue?

3. getting an initial version of this info to dhcp clients will be easy. 
but there's no good way to signal clients if there are changes. the 
clients can only find out if something changes as they renew, and the 
dhcp server of course doesn't control that very tightly, without 
resorting to micro lease times anyway.

would it be more useful to the ecrit or geo folks if dhcp were used to 
tell client about some other server or point of contact where the client 
could learn this information? that would de-couple this info from dhcp 
and the dhcp protocol, and make it possible to change what info is 
distributed and to signal changes independently of dhcp interactions 
(and limitations).

my apologies if this has already been resolved on one of the other lists.

Regards,
Mark

James M. Polk wrote:

> DHC WG
>
> To let folks know - a new individual submission Internet Draft has 
> been announced regarding using DHCP for downloaded (or requesting for, 
> then downloading) URIs to a DHC client here:
>
> Of interest, I hope, to the DHC WG is that this proposed Option 
> requests the use of a single DHCP Option to be used for URIs of 
> multiple purposes, each identified by a sub-option code called a 
> "purpose". This is done a little differently than in RFC 3396 where 
> the sub-options are smaller.  I don't believe I violated any length 
> rules of 2131 or 3396, and I believe I articulate how to address 
> lengths and concatenation in this document for longer URIs, and for 
> how to include more than one URI - each of a different purpose - in 
> the same DHCP message, or in the same IP datagram (with the same 
> Option value - but different purposes).
>
> The focus of the proposed URIs are primarily surrounding the Geopriv 
> and ECRIT WGs
>
> I just spoke with the Ralph Droms, and open discussion of this ID on 
> the ECRIT list is fine with him.  The formal syntax and encoding of 
> the option proposal is to be discussed on the DHC list for those 
> interested here, but the URI meanings don't need to be discussed on 
> this list where emergency calling and location conveyance/conversion 
> is of fairly little concern, as ECRIT is the primary WG of interest 
> for this effort initially.
>
> That said, newly proposed URIs with completely different purposes can 
> be included in this document. I am not suggesting a limitation (other 
> than the one byte purpose length field of 255  ;-)
>