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

From: Daniel Park <[email-masked]>
Date: Tue, 31 Jan 2006 10:49:26 +0000 (GMT)

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<[email-masked]>
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

 

 

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

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 31 Jan 2006 08:35:12 -0800

> http://www.ietf.org/internet-drafts/draft-ietf-dhc-paa-option-00.txt 

We last talked about this draft at IETF Paris (was that 63?).  It's my
memory that "we" gave identical feedback (although somewhat out of order
and in different voices, and I've tried to condense all the best ideas
out of that into one message).

There were a few other drafts (three?) with nearly identical schemas, we
gave the two or three of them (my memory is pretty fuzzy) the same
feedback altogether.

I volunteered to write a draft to describe a consistent method for all
drafts involved, utilizing "sub-options".  Since then, one of the drafts
that were trying this method of encoding produced a revision that already
contains that.

And I'm perfectly content with that definition; he does a good job of
presenting sub-option formats in abstract and then in his own specific
case.  I see no need to duplicate that effort unless he abandons it
for one-encoding after all.

So I've shifted my effort into trying my best to describe ISC's
option-handling implementation (written by Ted Lemon), and suggest how
an option can be best designed to be easily adopted by ISC's current,
deployed code.  The hope being that other implementations are at least
similar in their ability to reuse code from earlier option formats, if
not hopefully we can get comments or contributions to those ends.

And that's our DHC short-term history lesson for the day.

> 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. 

This is the draft that had a revision (we saw -00 at IETF 63) which
switches to sub-options:

http://www.ietf.org/internet-drafts/draft-lijun-dhc-clf-nass-option-01.txt

I like this revision for what it's trying to do, so if you take hints
from that about how to format your draft I probably won't argue much.

I think the criticism that the author needs to justify the need for
having multiple encodings at all is still valid.  I'd like you to
explore this a little more than is presently written in your draft
(which presently leaves me with the feeling that IP-addresses were all
that was required, and the other encodings are only there "because we
can", or possibly "because IEEE is having trouble reaching consensus on
one format").

-- 
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