Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt

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

At Wed, 15 Feb 2017 18:51:26 +0000,
"Templin, Fred L" <[e-mail]> wrote:

> > > > It's probably better to describe the issue in
> > > > sedhcpv6 with a reference to the RAAN draft as a possible future
> > > > solution to it if and when it's adopted and standardized.
> > >
> > > If sedhcpv6 will not support an authentication-only mode, then it
> > > can' t go forward until RAAN is adopted as a wg item. Otherwise,
> > > an encryption-only sedhcpv6 w/o RAAN would break DHCPv6 PD.
> >
> > I personally don't think it a blocking issue for sedhcpv6, but, of
> > course, the wg should decide it.
>
> Some uses of DHCPv6 PD require a secure exchange between the client and
> server supported by an LDRA [RFC6221] that is in the same physical stack as
> the server. The LDRA needs to peek into the server's Reply in order to discover
> the delegated prefixes for the purpose of configuring routes. This all needs to

Where in RFC6221 is that need described?  From a quick re-read of the
RFC I can't find it.  But in any case,

> work with a standards-compliant DHCPv6 server that implements both
> sedhcpv6 and RAAN. Meaning that sedhcpv6 and RAAN would need to be
> advanced together as standards.

I don't follow the logic of the final sentence.  I see this means
sedhcpv6 at least initially wouldn't work for a particular scenario
without RAAN.  But I don't think it automatically means sedhcpv6 can't
be standardized with that limitation.  It would depend on how this
incompatibility is critical for the overall purpose of sedhcpv6, and
it doesn't seem to be that substantial - we can eventually standardize
RAAN, and then update sedhcpv6 to fill the incompatibility.  I
understand you have a different opinion, but to me it's a matter of
opinion, not an only possible interpretation of this situation.  I'm
not insisting my opinion should win, of course, and that's why I said
the wg should decide it.

> Maybe better yet would be to bring the RAAN option into the sedhcpv6
> spec itself?

For the same reason I don't think so, but, again, it should be up to
the wg.

--
JINMEI, Tatuya