Subject: [Mip6] Recommendation for bootstrapping using DHCPv6

From: Basavaraj Patil <[email-masked]>
Date: Tue, 01 Aug 2006 14:35:24 -0500

Alper/Kuntal et al,

I have reviewed the drafts:
1. Problem Statement for bootstrapping Mobile IPv6
   (draft-ietf-mip6-bootstrap-ps-05)
2. MIP6-bootstrapping via DHCPv6 for the Integrated Scenario
   (draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt)

and
3. DHCP Option for Home Information Discovery in MIPv6
   (draft-jang-mip6-hiopt-00.txt)

My conclusion from the review is that the integrated scenario
bootstrapping via DHCPv6 is covering the cases when DHCP is the
preferred method by MNs.

The WG I-D draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt in
sections 3.5 and 3.8 explain how DHCP would work. Having the options
specified in a stand-along document will not add much value. I am also
concerned about the fact in draft-jang which states that:
"
   The availability of the requested information depends on the DHCP
   server having prior knowledge or dynamically discovering it.  While
   the specific details are outside the scope of this document, use of
   static tables and AAA-assisted discovery are possible options
"

Another concern that I have w.r.t bootstrapping with DHCPv6 is that
instead of having DHCP provide the HoA or the HL prefix to the MS, it
is better to only provide the address of an HA (or list of HAs) and
let the MS send a BU with unspecified address and obtain an address
from the HA. This will simplify bootstrapping and also reduce the
interaction between DHCP and the HA from an address management
perspective. Hence you may want to reconsider the DHCP option which
carry the HL Prefix or the HoA for the MS.

I recommend that the DHCP option specified in draft-jang be
incorporated into the WG I-D and progressed on standards track. As a
result the WG will have a mechanism for bootstrapping MIP6 with DHCP
that also includes the DHCP options in a single I-D.

-Raj

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Hugo Santos <[email-masked]>
Date: Tue, 1 Aug 2006 21:14:11 +0100

Hi,

   I have one question regarding the following:

> let the MS send a BU with unspecified address and obtain an address
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

   RFC 3775 states that the home address specified in Binding Updates
 must be unicast routable, would this work with current Home Agents? By
 splitting assignment (DHCP) from mobility management (HA) we would
 allow for better upgrade paths. I do understand how your suggestion
 would reduce comunication between a DHCP server and the HA, but it
 seems that it reduces to something in the line of DHCP but using MH
 messages, which involves modifying the Home Agent vs. installing
 policies. Would a full IKE exchange be made with the HA before sending
 these address-obtaining BUs?

   Best regards,

      Hugo Santos

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 01 Aug 2006 14:20:46 -0700

Hugo Santos wrote:
>  must be unicast routable, would this work with current Home Agents? 

bootstrapping specifications can "update" RFC 3775. RFC 3775
assumes the mobile node has a long lived home address that
does not change. RFC 3775 needs to be updated anyway.

> By

if IKEv2 is being used to setup security associations between
the MN and the HA, then the mechanism described in section 5.3
of 
http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split-02.txt
would apply. a BU with unspecified home address will not be
sent.

if RFC 4285 is used instead of IKEv2 and IPsec, then a BU with
a 0::0 home address and the MN-ID option (RFC 4283) can be
sent to obtain a home address from the home agent.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 01 Aug 2006 15:03:36 -0700

I guess I was hasty in my reply. :(

you are right. most of the bootstrapping mechanisms being
standardized currently in the MIP6 WG will not work with
home agents that implement only RFC 3775. but that was
never the goal anyway.

Vijay

---

From: Hugo Santos <[email-masked]>
Date: Tue, 1 Aug 2006 23:14:41 +0100

Hi Vijay,

> home agents that implement only RFC 3775. but that was

   Although i understand this position, i believe some solutions could
 in fact be able to use RFC 3775-esque Home agents (well, adding IKEv2
 would probably also be nice). My initial comments was exactly in this
 direction, if the Home agent already offloads the authorization to AAA,
 it might not require anything else. So, modifications should be well
 justified. But i may be missing pieces from the bigger picture.

   Hugo

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 3 Aug 2006 00:45:23 +0300

Hi Raj,

"Having the options specified in a stand-along document will not add much
value."

As we have been stating, draft-jang-mip6-hiopt-00.txt also has a use that
does not tie into the RADIUS-driven details -- the use where DHCP server can
be manually configured and has nothing to do with the AAA. 

Your above statement misses this point. 

Besides, while there is a standalone use for draft-jang-mip6-hiopt-00.txt,
there is none for the RADIUS and Diameter specs we expect to document
individually. Should we also merge those AAA documents with the others?

Also, I'm not sure what specific concern you are raising with respect to the
quoted text below.

Alper

> -----Original Message-----
> From: Basavaraj Patil [mailto:[email-masked]]
> Sent: Tuesday, August 01, 2006 12:35 PM
> To: [email-masked]
> Subject: [Mip6] Recommendation for bootstrapping using DHCPv6
> 
> 
> Alper/Kuntal et al,
>

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 03 Aug 2006 14:28:45 -0500

Alper,

Inline:

> be manually configured and has nothing to do with the AAA.

But why do you believe that the WG I-D which is using DHCP is RADIUS driven
only and nothing else? I mean it could just as well be used for the case
where the bootstrapping information is manually configured in the DHCP
server. What is needed are the DHCP options and the fact that the bootstrap
parameters are available in the DHCP server either as a result of some AAA
messages or manual configuration does not matter.

> Besides, while there is a standalone use for draft-jang-mip6-hiopt-00.txt,

What is the standalone use of draft-jang? The WG I-D needs to specify the
DHCP options anyway. Why would that not be sufficient for any deployment
scenario that you have in mind?

> individually. Should we also merge those AAA documents with the others?

Are you refering to the Radius/Diameter mechanisms for obtaining the
bootstrap parameters and storing them in the DHCP server? You could specify
those mechanisms independently of the fact that there is a specification
which explains how DHCP is used for bootstrapping and the DHCP options to
carry the bootstrap parameters between the MS and the DHCP server. So I
don't expect that those drafts also be merged with the current spec.

> Also, I'm not sure what specific concern you are raising with respect to the

The concern that I have is the fact that the I-D specifies the DHCP options
for boostrapping. The bootstrap parameters are somehow stored in the DHCP
server. The I-D is basically saying that how the parameters get into the
DHCP server are not in scope here except giving an example that manual
configuration or AAA can be used. So it is incomplete and unusable. What you
say above is that there will be additional I-Ds coming to specify how that
is done. The current WG integrated scenario with DHCPv6 I-D has more details
and explains at least how AAA is used. I guess manual configuration is
pretty straightforward and does not need secification. But in the case when
the MS is roaming and attached to some visited network, how does it
bootstrap with DHCP? My concern is the fact that the I-D is incomplete and
it simply sweeps the issue under the mat by saying it is out of scope.

-Raj

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 4 Aug 2006 02:27:07 +0300

Hi Raj,

> only and nothing else? 

AAA is integral to the current solutions designed by the MIP6 WG for MIP6
bootstrapping. 

> I mean it could just as well be used for the case

Yes, this is exactly what the draft-jang is saying.

> What is the standalone use of draft-jang? 

Standalone use is the one that does not require all that AAA plumbing. For
example, when you manually configure the DHCP servers with the MIP6
information. 

> The WG I-D needs to specify the

I think there is a misunderstanding. I was not saying that.

> don't expect that those drafts also be merged with the current spec.

You misunderstood me. Let me re-iterate what I had described on the list
earlier:

- The integrated bootstrapping solution depends on a number of protocol
design work (1. DHCP options for HA discovery, 2. RADIUS attributes for HA
discovery, 3. Diameter AVPs for HA discovery, 4. IKEv2 for HoA
configuration, 5. RADIUS attributes for MIP6 authentication, 6. Diameter
AVPs for MIP6 authentication) and description (7) of how all such protocols
plumb together to yield so-called "MIP6 bootstrapping." 

Now, item 7 is described in
draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. All the others are
currently described in separate documents, and that makes sense. Asking for
1 and 7 be merged does not make sense. If it did, my questions was, why not
merge the others as well. Do you see my point?

> configuration or AAA can be used. So it is incomplete and unusable. 

With the same token, documents 2..6 are also incomplete. Even 7 is
incomplete. It is the modular combination of these various protocol work
that makes a complete picture, no single one can make.

> What
> you

Alper

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 03 Aug 2006 17:56:49 -0700

Alper,

> merge the others as well. Do you see my point?

2), 3), 4), 5) and 6) have nothing to do with DHCP. if
tomorrow somebody comes with a bootstrapping solution
based on PANA for the integrated scenario, 2), 3), 4),
5) and 6) can be re-used.

there were in fact two other proposals, one based on
PANA and another based on EAP for integrated scenario
bootstrapping.

draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt
describes a solution for the integrated scenario
*using* DHCP. it is not a "plumbing" document for the
integrated scenario.

Vijay

---

From: "Junghoon Jee" <[email-masked]>
Date: Fri, 4 Aug 2006 10:04:31 +0900

Feeling hard to intervene...
However having looked at this issue over very long time again and
again,
eventually I spent sometime looking at this issue again and decided to
share my thought at this time.

Disclaimer: I don't have so strong opinion on this issue, just to
share my thought to try to resolve still unsolved issue.

> - The integrated bootstrapping solution depends on a number 
> of protocol design work (1. DHCP options for HA discovery, 2. 
> RADIUS attributes for HA discovery, 3. Diameter AVPs for HA 
> discovery, 4. IKEv2 for HoA configuration, 5. RADIUS 
> attributes for MIP6 authentication, 6. Diameter AVPs for MIP6 
> authentication) and description (7) of how all such protocols 
> draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. All the 
> others are currently described in separate documents, and 
> that makes sense. Asking for
> 1 and 7 be merged does not make sense. If it did, my 
> questions was, why not merge the others as well. Do you see my
point?

I also think above statements are reasonable. 
BTW, it is true that some concerns arise from the behaviors in the
draft-jang maybe throught the section 4.2.

Here is the section 4.2 for draft-jang.
--------------------------------------------------
4.2.  Mobile Node Considerations

   When a Mobile IPv6 Mobile Node finds itself with neither a home
   subnet prefix nor a home agent address, it may request the needed
   information with Option Request option.  For instance, a mobile
node
   connecting to a network for the first time may acquire a DHCP
address
   and solicit for home network information at the same time.

   A mobile node MUST identify the desired information with Home
Network
   Identifier option.  For example, a DHCP server may have information
   about home agents from several domains (and subnets).  It relies on
   the mobile node to select the domain for determining which ones it
   should provide in response to the client's request.

   When the mobile node gets more than one home agent address, it MUST
   have a selection mechanism to determine which one to use for
   establishing a Mobile IPv6 session.  In case it retrieves only home
   subnet prefix(es), it needs to perform dynamic home agent discovery
   to learn the IP addresses of the home agents.  Similarly, if FQDN
of
   a home agent is retrieved, the mobile node can use DNS to resolve
it
   to IPv6 address(es).
----------------------------------------------------------------

Vijay, could you pin-point out what specific texts are not comfortable
based on the protocol behavior from the
draft-ietf-mip6-bootstrapping-integrated-dhc-01?

Junghoon

---

From: Julien Bournelle <[email-masked]>
Date: Fri, 4 Aug 2006 13:12:41 +0200

Hi all,

> PANA and another based on EAP for integrated scenario

 FYI, we have in fact a proposal based on PANA who can fit for 1/.
 http://www.ietf.org/internet-drafts/draft-bournelle-pana-mip6-01.txt
 and for which 2/ 3/ 4/ 5/ and 5/ can be re-used.

 regards,

 Julien

-- 
julien.bournelle at int-evry.fr

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 04 Aug 2006 11:31:05 -0500

Alper,

>AAA is integral to the current solutions designed by the MIP6 WG for MIP6

BP: Yes. I think we agreed when this work began that the MN shared a
BP: security association with an entity such as the AAA in the home
BP: network and not the HA (which is what RFC3775 is based on). But
BP: I dont see how the fact that AAA is an integral part of the
BP: bootstrapping solution has anything to do with DHCP options other
BP: than the fact that AAA messages are used to obtain information
BP: such as the address of the HA and insert them in a DHCP
BP: server. But that should be dealt with in the Dime WG (I-D:
BP: draft-ietf-dime-mip6-integrated-00.txt) and the same with Radius
BP: as specified in I-D: draft-chowdhury-mip6-radius-02.

>Yes, this is exactly what the draft-jang is saying.

BP: I know. And my point is that the WG I-D:
BP: draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt is also doing
BP: the similar thing in section 3.5. What I am recommending is that
BP: the options that the I-D: draft-jang-mip6-hiopt-00.txt specifies
BP: in section 3 be included in section 3.5 of the WG I-D and be done.
BP: If you look at the title of the WG I-D, it says
BP: "MIP6-bootstrapping via DHCPv6..." which to me implies that it
BP: should specify how bootstrapping is done with DHCPv6 and the
BP: options that would be needed in DHCP to make this work. I know
BP: you would argue that if that were to be the case then the AAA
BP: aspects should also incorporated into the same. If it was a matter
BP: of only specifiying a couple of new AAA AVPs that could be a
BP: solution. However at the moment it appears that a more
BP: comprehensive AAA spec for Radius and Diameter are needed as seen
BP: from the AAA I-Ds mentioned above.

>example, when you manually configure the DHCP servers with the MIP6

BP: If you were to manually configure the DHCP server with the
BP: bootstrapping information, you could only bootstrap an MS when it
BP: is in its home network. But the manual configuration of the DHCP
BP: server scenario is not ruled out by incorporating these options in
BP: the WG I-D either. So I disagree that you need to specify the DHCP
BP: options separetely from the document that specifies the mechanism
BP: of  how bootstrapping is done with DHCP.

>I think there is a misunderstanding. I was not saying that.

BP: Okay... 

>merge the others as well. Do you see my point?

BP: I see your point... And I gave you my thoughts on the integration
BP: of AAA options as well in this document above. Elaborating:
BP: 2 & 3 are more than just specifying RADIUS attributes and Diameter
BP: AVPs. 
BP: 4 does not really apply. How IKEv2 is iused once you have the
BP: bootstrap parameters at the MN is specified in the split-scenario
BP: and can be reused.
BP: 5 & 6 are part of the interaction between HA and AAA and the
BP: requirements for this captured in the WG I-D
BP: draft-ietf-mip6-aaa-ha-goals-02, the intention of the WG being to
BP: develop AAA specifications separately.
BP: With the case of DHCP options, this is already covered in the
BP: existing WG I-D.

>that makes a complete picture, no single one can make.

BP: To implement a complete bootstrapping solution, yes you would need
BP: to refer to multiple documents. But it does not mean that for
BP: every option you have a separate spec. In this case, my argument
BP: yet again :) is that the WG I-D has a section for the DHCP options
BP: that are needed and the additional ones that are in draft-jang
BP: simply need to be incorporated into the WG doc.

BP: There are no hard-and-fast rules or guidelines
BP: which say that this is the way it should be done. If the DHCP
BP: options were to be specified separately, that would work as
BP: well. I am just recommending an approach that I believe in this
BP: case is optimal.

-Raj

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 4 Aug 2006 23:05:50 +0300

Raj,

Your message simply tells me how we can combine the documents. It does not
say why this is a better idea than keeping them separate. More inlined
below.

> >> > does not tie into the RADIUS-driven details -- the use where DHCP
> server
> >> can
> BP: bootstrapping solution has anything to do with DHCP options 

Well, I was merely responding to your statement. Maybe I misunderstood what
you meant.

> other
> BP: the similar thing in section 3.5. 

No, it is not. WG I-D is describing the DHCP relay options, not the DHCP
options. I think we should move those to the other document as well.

> What I am recommending is that

It was our mistake to name the document like that. You know, the integrated
solution involves EAP, RADIUS, Diameter, DHCP, IKEv2, etc. It is not fair to
name it after only one of the protocols involved. We shall fix the name, not
try to fit the content of the I-D to the mistaken name.

> BP: from the AAA I-Ds mentioned above.

This just tells me the amount of text for DHCP options is less than the
amount of text for AAA, hence the former should be merged and not the
latter. I think we should be more concerned about the modularity of our
specifications.

> BP: is in its home network. 

Simply not true. You know DHCP runs across multiple IP hops, with the help
of DHCP relays. A MN may very well be connected to a foreign subnet and get
its configuration from a DHCP server in its home subnet.

> But the manual configuration of the DHCP

Again, this is not "how bootstrapping is done with DHCP". This is "how
bootstrapping is done with EAP, RADIUS, Diameter, IKEv2, DHCP". The
integrated solution does not revolve around DHCP. DHCP is only used for HA
discovery component. MIP SA, and HoA are still handled by the other
protocols.

> BP: bootstrap parameters at the MN is specified in the split-scenario

That is not true. It is defined in draft-ietf-mip6-ikev2-ipsec-04 and simply
referred by the split-scenario document (right thing to do!).

> BP: develop AAA specifications separately.

Yes, that's the right thing to do.

> >> > Also, I'm not sure what specific concern you are raising with respect
> to
> >> the
> >> > quoted text below.
> >>
> BP: well. 

I have yet to understand the fundamental problem with this approach. Do you
have any?

And I have a fundamental problem with arbitrarily merging one of the
protocol components with the document that aims plumbing those components.
My fundamental problem is, this component (more than the others) have uses
beyond this very specific plumbing. Given that we like designing protocols
that get used modularly (like the Lego pieces), it does not make sense to
clump an otherwise-independent protocol piece with a very specific
framework. There would be no gains but simply difficulty in referencing that
specific protocol component out of a specific framework when people need to
use it (but not the rest of the framework). 

> I am just recommending an approach that I believe in this
> BP: case is optimal.

Alper

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 04 Aug 2006 16:17:12 -0500

Alper,

The simple reason I recommended that the DHCP options specified in
draft-jang be combined with the WG I-D which is the solution for
Bootstrapping using DHCPv6 (I-D:
draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt) is because there is
already a section in the document which is intended for the DHCP options.
Doing two separate I-Ds IMO has no added value here. I am not convinced that
there are deployment scenarios that are enabled by specifying the DHCP
options separately (as I have stated in the earlier email as well).

And reiterating what I said earlier:
"

That's it. Now, we may agree to disagree with this approach and that's fine.
I can issue a WG consensus call and resolve it based on what the view in the
WG is. Let me know.

-Raj

---

From: "James Kempf" <[email-masked]>
Date: Fri, 4 Aug 2006 14:27:18 -0700

Um, you know, we've been discussing this topic now for over a month. How 
about we do a consensus call and see what the WG wants to do with it? The 
document is, after all, a WG document and therefore the content is subject 
to WG consensus.

            jak

---

From: "Alper Yegin" <[email-masked]>
Date: Sat, 5 Aug 2006 01:55:41 +0300

Raj,

> I can issue a WG consensus call and resolve it based on what the view in

I think this is the best. 

Just to be clear, here are the two options on the table:

A: 
- move the "DHCP relay option" details from
draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt to
draft-jang-mip6-hiopt-00.txt
- rename "draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt" to
"draft-ietf-mip6-bootstrapping-integrated-01.txt" similar to its
counter-part (split).
- make the draft-jang-mip6-hiopt-00.txt as WG I-D as it is (already)
normatively referenced by the other document.

B:
- move the "DHCP option" details from draft-jang-mip6-hiopt-00.txt to
draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt.
- remove the normative reference to draft-jang-mip6-hiopt-00.txt and kill
that document.
- (I'd still recommend we drop the "-dhc" from the file and document name.
Apparently that was Vijay's idea :o )

Alper

> Sent: Saturday, August 05, 2006 12:17 AM
> To: ext Alper Yegin; [email-masked]
> Subject: Re: [Mip6] Recommendation for bootstrapping using DHCPv6
> 
> 
> Alper,
> 
> >>>> parameters are available in the DHCP server either as a result of
> some
> >> AAA
> >>>> which explains how DHCP is used for bootstrapping and the DHCP
> options
> >> to
> >>> design work (1. DHCP options for HA discovery, 2. RADIUS attributes
> for
> >> HA
> >>> currently described in separate documents, and that makes sense.
> Asking
> >> for
> >>> 1 and 7 be merged does not make sense. If it did, my questions was,
> why
> >> not
> >>>> pretty straightforward and does not need secification. But in the
> case
> >>>> when
> >>>> bootstrap with DHCP? My concern is the fact that the I-D is
> incomplete
> >> and

---

From: "Soliman, Hesham" <[email-masked]>
Date: Fri, 4 Aug 2006 19:26:54 -0700

I agree with James that this should be done through concensus. However,
the other issue that I find puzzling is the inconsistency of adding the
DHCP option formats in this document, while expecting the
Diameter/RADIUS AVPs/VSA to be done "somewhere else". Why is it ok for
AAA stuff to be done somewhere else and not DHCP?

Hesham 

 > From: James Kempf [mailto:[email-masked]] 
 > Sent: Saturday, August 05, 2006 7:27 AM
 > To: Alper Yegin; 'Basavaraj Patil'; [email-masked]
 > >> >> > "Having the options specified in a stand-along 
 > document will not add
 > >> much
 > >> >> > value."
 > >> >> >
 > >> >> > As we have been stating, 
 > draft-jang-mip6-hiopt-00.txt also has a use
 > >> that
 > >> >> But why do you believe that the WG I-D which is using 
 > DHCP is RADIUS
 > >> driven
 > >> >> only and nothing else?
 > >> >
 > >> >AAA is integral to the current solutions designed by the 
 > MIP6 WG for 
 > >> >MIP6
 > >> >bootstrapping.
 > >>
 > > Well, I was merely responding to your statement. Maybe I 
 > misunderstood 
 > > what
 > > you meant.
 > >
 > >
 > >> other
 > >> >> server. What is needed are the DHCP options and the 
 > fact that the
 > >> >> bootstrap
 > >> >> parameters are available in the DHCP server either as 
 > a result of some
 > >> AAA
 > > solution involves EAP, RADIUS, Diameter, DHCP, IKEv2, etc. 
 > It is not fair 
 > > to
 > > name it after only one of the protocols involved. We shall 
 > fix the name, 
 > > not
 > >> >> > Besides, while there is a standalone use for 
 > draft-jang-mip6-hiopt-
 > >> >> 00.txt,
 > >> >>
 > >> >Standalone use is the one that does not require all that 
 > AAA plumbing.
 > >> For
 > > of DHCP relays. A MN may very well be connected to a 
 > foreign subnet and 
 > > get
 > >> >> > individually. Should we also merge those AAA 
 > documents with the
 > >> others?
 > >> >>
 > >> >> bootstrap parameters and storing them in the DHCP 
 > server? You could
 > >> >> specify
 > >> >> which explains how DHCP is used for bootstrapping and 
 > the DHCP options
 > >> to
 > >> >> carry the bootstrap parameters between the MS and the 
 > DHCP server. So 
 > >> >> I
 > >> >design work (1. DHCP options for HA discovery, 2. RADIUS 
 > attributes for
 > >> HA
 > >> >currently described in separate documents, and that 
 > makes sense. Asking
 > >> for
 > questions was, why
 > > That is not true. It is defined in 
 > draft-ietf-mip6-ikev2-ipsec-04 and 
 > > simply
 > >> >> > Also, I'm not sure what specific concern you are 
 > raising with 
 > >> >> > respect
 > >> to
 > >> >> the
 > >> >> > quoted text below.
 > >> >>
 > >> >> The concern that I have is the fact that the I-D 
 > specifies the DHCP
 > >> >> options
 > >> >> for boostrapping. The bootstrap parameters are somehow 
 > stored in the
 > >> DHCP
 > >> >> server. The I-D is basically saying that how the 
 > parameters get into
 > >> the
 > > I have yet to understand the fundamental problem with this 
 > approach. Do 
 > > you
 > > have any?
 > >
 > > framework. There would be no gains but simply difficulty 
 > in referencing 
 > > that
 > > specific protocol component out of a specific framework 
 > when people need 
 > > to
 > >> >> say above is that there will be additional I-Ds coming 
 > to specify how
 > >> that
 > >> >> is done. The current WG integrated scenario with 
 > DHCPv6 I-D has more
 > >> >> details
 > >> >> pretty straightforward and does not need secification. 
 > But in the case
 > >> >> when
 > >> >> bootstrap with DHCP? My concern is the fact that the 
 > I-D is incomplete
 > >> and