Subject: [dhcwg] Fwd: I-D ACTION:draft-daniel-dhc-mihis-opt-00.txt

From: Daniel Park <[email-masked]>
Date: Sat, 28 Jan 2006 00:20:58 +0000 (GMT)

FYI

Daniel (Soohong Daniel Park)

Mobile Platform Laboratory. SAMSUNG Electronics

------- Original Message -------
Sender : [email-masked]<[email-masked]>
Date : Jan 28, 2006 08:50
Title : I-D ACTION:draft-daniel-dhc-mihis-opt-00.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories.

Title        : DHCPv4 Option for Discovering IEEE 802.21

Information Service Location

Author(s)    : S. Park, et al.

Filename    : draft-daniel-dhc-mihis-opt-00.txt

Pages        : 8

Date        : 2006-1-27

In IEEE 802 Standard, the Media Independent Handover (MIH) Services

are under work through IEEE 802.21 Working Group.  It is consist of

three services, Media Independent Event Service (MIES), Media

Independent Command Service (MICS) and Media Independent Information

Service (MIIS).  This document provides a mechanism by which the DHCP

can provide information about the MIIS Location.

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-daniel-dhc-mihis-opt-00.txt

To remove yourself from the I-D Announcement list, send a message to

[email-masked] with the word unsubscribe in the body of the message.

You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce

to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username

"anonymous" and a password of your e-mail address. After logging in,

type "cd internet-drafts" and then

"get draft-daniel-dhc-mihis-opt-00.txt".

A list of Internet-Drafts directories can be found in

http://www.ietf.org/shadow.html

or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:

[email-masked].

In the body type:

"FILE /internet-drafts/draft-daniel-dhc-mihis-opt-00.txt".

NOTE:    The mail server at ietf.org can return the document in

MIME-encoded form by using the "mpack" utility.  To use this

feature, insert the command "ENCODING mime" before the "FILE"

command.  To decode the response(s), you will need "munpack" or

a MIME-compliant mail reader.  Different MIME-compliant mail readers

exhibit different behavior, especially when dealing with

"multipart" MIME messages (i.e. documents which have been split

up into multiple messages), so check your local documentation on

how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader

implementation to automatically retrieve the ASCII version of the

Internet-Draft.

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

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 30 Jan 2006 11:18:01 -0800

The option format described here is fairly hard to adopt.  Let me
clarify that.  I mean I would actually have to write trivial code
and release a new version of the server software (and that would then
need to be adopted by network operators) in order to give this option
proper support (support that does not require the user to read the
RFC to encode the option correctly).

Our existing server and client would not be able to carry this option
unless the administrators of both read the RFC.

That doesn't sound like a lot, but in practice it's a significant
hurdle for adoption, and I think it's one you can avoid easily.

So, I have two questions,

1) Are you sure you need this variable option encoding method you've
documented?

Are ipv4 addresses (easily the smallest and easiest to encode of the
three you've chosen) not enough for some purpose?  Are FQDN's not
enough for some purpose?

No matter how you answered these two questions, since each of your
encoding types is a superset of the previous (a URI contains an FQDN
which references an IP address), only one is truly necessary.

Choosing only one encoding means client and server simplification.
A client doesn't have to implement decoding of all three encodings.
A server doesn't have to try and judge which encoding is necessary.

Choosing multiple encodings encumbers clients to implement decode
methods of all known encodings.  It encumbers servers to deal with
the potential clients that implement only a subset of the encodings
(because that's how it comes from their "favorite server" most of
the time).

2) If multiple encodings are necessary, why not sub-option format?

Sub-options are well understood by server implementors, so 'proper
support' would not need any code changes.  In brief;

	[DHCP-option-code] [len] [sub-option-code] [len1] [len1 bytes]
		[sub-option-code] [len2] [len2 bytes] ...

But understand that there are IANA considerations - this option's
sub-option space becomes territory IANA needs must allocate from
uniquely.  Is this time/work expense justified by the need for
multiple encoding types?

It's my feeling that the encoding methods are not necessary, and that
ipv4 addresses are sufficient.  I recommend based upon this that
you adopt what you've marked "encoding 0" and delete the encoding
byte.

This is immediately adoptable without code changes or requiring
users to read RFCs, by what I assume would be all DHCP server
software (it at least would be trivial for ours).

If however you want to experiment with multiple encodings, I suggest
you take the "sub-option" approach.  Field tests have a tendency to
become field practice, which then tends to haunt us.  Doing this in a
way we're already intimately familiar with would be helpful should it
become a "de facto" standard.

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg