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

Hi David, thanks your good comments on that. However I am so confusing how we (dhc) treat on this kind of option format. I was referring to the dhc document below
http://www.ietf.org/internet-drafts/draft-ietf-dhc-paa-option-00.txt 

It is also defining encoding fields on their submission and, it is a dhc WG item. That is why I am referring to that. Suboption works for me also, so I can rearrange it following the dhc opinion. 

Thanks, 

Daniel (Soohong Daniel Park)
Mobile Platform Laboratory. SAMSUNG Electronics

------- Original Message -------
Sender : David W. Hankins<David_Hankins@isc.org>
Date   : Jan 31, 2006 04:18
Title  : Re: [dhcwg] Fwd: I-D ACTION:draft-daniel-dhc-mihis-opt-00.txt
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&#39;t sound like a lot, but in practice it&#39;s a significant
hurdle for adoption, and I think it&#39;s one you can avoid easily.

So, I have two questions,

1) Are you sure you need this variable option encoding method you&#39;ve
documented?

Are ipv4 addresses (easily the smallest and easiest to encode of the
three you&#39;ve chosen) not enough for some purpose?  Are FQDN&#39;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&#39;t have to implement decoding of all three encodings.
A server doesn&#39;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&#39;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 &#39;proper
support&#39; 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&#39;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&#39;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&#39;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&#39;re already intimately familiar with would be helpful should it
become a "de facto" standard.

-- 
David W. Hankins        "If you don&#39;t do it right the first time,
Software Engineer            you&#39;ll just have to do it again."
Internet Systems Consortium, Inc.        -- Jack T. Hankins