Re: [6lo] GHC plan

[Carsten Bormann <[e-mail]>]

Hi Abdussalam,

Ulrich was kind enough to trace back the emails and extract some questions for me that I can actually try to answer.

> 1) Why is there no applicability section, or use case section?

Because nobody wrote one.
If the WG wants one, they’d have to tell me what it wants in there.
Upon first reading your comment, I was waiting for other people in the WG to possibly chime in here with some specifics, but that hasn’t happened, so I didn’t see a need for action.

> 2) What is the draft main scope (there is mentioned some purpose of
> the draft contribution in introduction but not sure of the scope)?

I don’t know what the fine point between applicability and scope is here.
Anyway, we don’t usually have formal scope sections in IETF specifications (unlike, say, the scope sections in ISO documents).

> and
> is the solution proposed the best solution, or was it tested to be
> better solution for such problem?

I wouldn't usually try for the “best solution”.
There has been some discussion on protocol quality in the two mailing lists.
I’m not going to summarize that discussion in some simple text, because it is a complicated issue.
Imagine trying to answer to the exact same question for, say, RFC 793.

Keying on “better”, there are two things that probably are worth optimizing here:
1) the bit allocation in the byte code.  As the draft says, Sebastian Dominik has examined this (and, I might add, surprisingly my initial hunch turns out to have been better than a number of variations he tried).
2) the static dictionary.  As I said repeatedly, this is a bit haphazard, but it seems to work well the way it is with the corpus at http://svn.tools.ietf.org/svn/wg/6lowpan/packets

Thomas Björklund made another great suggestion for optimizing (by simplifying some more), which is in the recent draft.

So it seems simple to me:
— Author's view: good enough, and a number of reviewers seemed to agree.
— unless the WG wants to improve things (or decides the whole thing is no longer worth the effort), we are done.

> It mentions that it is a short draft, I don't think so. Please remove
> describing the size of the draft, because in future it may develop and
> become larger.”

The specification is short, not the entirety of the draft any more (it is interesting to look at the page count over time since 2010-10-18 for a spec that essentially has become *simpler* since the first draft!); as you can see I had already updated that word in the abstract of the most recent draft.

Grüße, Carsten