Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18

[神明達哉 <[e-mail]>]

At Fri, 30 May 2014 20:47:12 -0400,
Ted Lemon <[e-mail]> wrote:

> > I think it is important to add a section that enumerates those and
> > similar use cases. Otherwise you risk that this work will be stalled
> > and you'd be asked to write a separate problem statement document.
>
> A use case can't be theoretical.   You should have an actual use for it.

I fully agree, but then I'd wonder if all we can come up with
is theoretical use cases how we can define an effective solution to
them.

> So I think documenting use cases like a "high security network" is pointless.   The point of this mechanism is to authenticate DHCP transactions in both directions using public keys.   Why do we need a list of use cases for this?   This is something we've been asked for for over a decade.   Does someone seriously think there's a different way to do this that's more appropriate?   If so, please explain!   Does someone think that the actual uses documented in the draft won't work?   If so, please say why.

I didn't know if this (= "authenticating DHCP transactions in both
directions using public keys", correct?) is something people have
asked for over a decade, but if so, I'd like to know why they've been
asking for it, since, once I read this particular draft carefully I
realize that's not clear to me at all.  Defining a mechanism simply
because someone(s) asked for it without clear understanding of "why"
doesn't make sense to me.

One possibility is that I'm too dumb and can't just understand
something so obvious to others, in which case I'll simply shut up.

But, the fact that at least two others wanted to have use cases seems
to suggest that at least it's not only me who can't fully understand
why we need it.  And, if at least three people have difficulty in
understanding it, that probably means there are potentially may more.
So, I think this has to be documented somewhere explicitly.  Whether
it should be in the protocol document is a different question, though,
so...

> I certainly think that if people want to suggest ways of clarifying the document, that would be beneficial, but let's not get carried away throwing the kitchen sink into the document for no good reason.   That makes it slower to review and is as likely to generate controversy as quell it.

...this is fine, but in that case I'd like to see the separate
discussion and documentation first, as I already said in an earlier
message of mine:
http://www.ietf.org/mail-archive/web/dhcwg/current/msg15520.html
It doesn't make sense to me to defer the clarification of "why"
because it slows to review the "solution".

But you don't seem to like this idea either, presumably due to the
processing delay.  My understanding is, hence a brief summary of use
cases in this draft as a kind of compromise.  If the use cases are so
obvious to some people, this can be pretty simple and avoid making the
document a kitchen sink.  I actually showed one possible outline of
this addition: http://www.ietf.org/mail-archive/web/dhcwg/current/msg15526.html
We can then answer the question that many future readers of this
document (i.e., why we need this?) would have at the time of its
publication.  And, we can still minimize the processing delay by
avoiding to require a completely separate document to explain the use
cases as a prerequisite of the protocol document.

I thought it was a reasonable and pragmatic suggestion.  But if the
majority of the wg still doesn't think it worth doing, we should
probably just agree to disagree, and in which case I'll stop at that
point; I don't have a strong motivation to prevent its publication.

--
JINMEI, Tatuya