Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02

[Andre Kostur <[e-mail]>]

Leaving aside the issue of whether this "prefix announcement" should
be carried over DHCPv6, I wonder if trying to fit this into an
Identity Association isn't quite right since there is no identity to
be managed?   Perhaps a cleaner solution would be for the device to
ask for an IAPREFIX in an ORO in an Information-Request, and the
server can reply with an IAPREFIX (that isn't in any IA_* option).

Having said that, I'm with Ted in that I don't quite grasp why we're
trying to do this.  It the network is "fully DHCPv6-managed", wouldn't
that mean that the administrators would want to control the address
generation instead of leaving it up to the client to do with it as it
will?

On Wed, Aug 15, 2012 at 5:49 PM, Sheng Jiang <[e-mail]> wrote:
>
> Hi, Bernie,
>
>
>
> Thanks for your comments. See my reply in lines.
>
>
>
> Sheng
>
>
>
> I’d also suggest the following be clarified (section 4, bullet 2):
>
>
>
>        If there is not a proper prefix available, a status-
>
>        code is returned to the host and the procedure is terminated.
>
>
>
> What status code and where is this status code returned. Let’s hope it
> follows the IA_PD conventions (especially if we keep the IAID in the IA_PA).
> There is no new status code requested, do apparently it is one of the
> existing codes (RFC 3315/3633)?
>
>
>
> <Sheng> It is the existing NoPrefixAvail status code, defined in RFC 3633.
> I have just added an explicit explanation for this.
>
>
>
>
>
> This work also seems to be to replacing Router Solicitation/Router
> Advertisement messages to advertise the prefixes (for stateless
> autoconfiguration). Do we really want this. And, might not this be something
> to discuss in a slightly wider IETF audience. Perhaps it has already been (I
> haven’t followed this work that closely).
>
>
>
> <Sheng> It is the assumption we take. I believe we had the WG consensus,
> by adopting as WG document. Because this only happens in a fully
> DHCPv6-managed network, does not impact any other network that use RA for
> SLACC, so I think discussion in DHC is enough.

--
Andre Kostur