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

On Tue, Jan 31, 2006 at 10:49:26AM +0000, Daniel Park wrote:
> 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 

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