Subject: [Mip6] Overall LC comment on draft-ietf-mip6-bootstrap-ps-01.txt

From: "James Kempf" <[email-masked]>
Date: Fri, 18 Feb 2005 16:16:14 -0800

As John Loughney brought up, the draft is a bit long for a problem
statement. Actually, I think the draft is more a mix of problem statement,
functional architecture, and requirements. It might be worthwhile to at
least separate out the draft into these three parts, to simplify and
condense the problem statement and group the other parts more coherently
together. draft-giaretta-mip6-aaa-ha-goals, which, despite its title, deals
with similar issues on the back end, actually does a pretty good job of
separating out these three parts stylistically, though of course the content
is different.

The other possibility would be to separate the draft into two, one for the
problem statement and one for the requirements and functional architecture.
If that is done, I think it is very important that all the content in the
current functional architecture and requirements parts of the draft not get
lost (in the past, I've seem parts of drafts get lost when they are so
separated).

            jak

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

---

From: Gerardo Giaretta <[email-masked]>
Date: Mon, 21 Feb 2005 10:29:23 +0100

Hi all,

> 
> James:
> 
> I tend to agree, but let me recall - wasn't the goal of the 
> design team to
> develop a problem statement - state what is the goal of 
> bootstrap, what are
> the operating parameters and what should be the constraints?
> 
> I am definitely open to reorganize the document as John originally
> suggested. I don't oppose to break up the document either - 
> my concern is
> losing information/context in moving from one to many. 
> Problem statements
> dispersed over multiple docs are typically hard to capture, IMHO.  
> 
> Still open to suggestions.
>

I'm also comfortable with either solutions, since both would improve the
document.

Maybe it could be easier to split the draft in a "problem statement" and
a "functional architecture and requirements" one (even if I agree that
we should be very careful not to loose contents during this splitting).
This could be also a way to easily include in the document some current
considerations about integration between AAA and MIP6, for example in a
way similar to my last mailing list post (thread: MIP6-AAA high-level
view). From current mailing list discussion, it seems to me that the WG
is lacking of some architectural "guidelines" (or goals/requirements) to
develop a bootstrapping solution.

Otherwise some of these AAA-MIP6 architectural considerations could be
integrated in the scenarios description of
draft-giaretta-mip6-aaa-ha-goals, but this draft only deals with the
back end and it might not be the most convenient way to move forward.

Regards,
--Gerardo
 
> -a
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of [email-masked]
> > Sent: Friday, February 18, 2005 9:56 PM
> > To: [email-masked]; [email-masked]
> > Subject: RE: [Mip6] Overall LC comment on 
> > draft-ietf-mip6-bootstrap-ps-01.txt
> > 
> > Hi James,
> > 
> > > statement. Actually, I think the draft is more a mix of problem 
> > > statement, functional architecture, and requirements. It might be 
> > > worthwhile to at least separate out the draft into these 
> > three parts, 
> > > to simplify and condense the problem statement and group 
> the other 
> > > parts more coherently together. draft-giaretta-mip6-aaa-ha-goals, 
> > > which, despite its title, deals with similar issues on the 
> > back end, 
> > > actually does a pretty good job of separating out these 
> three parts 
> > > stylistically, though of course the content is different.
> > > 
> > > The other possibility would be to separate the draft into 
>  two, one 
> > > for the problem statement and one for the requirements and 
> > functional architecture.
> > > If that is done, I think it is very important that all the 
> > content in 
> > > the current functional architecture and requirements parts of the 
> > > draft not get lost (in the past, I've seem parts of 
> drafts get lost 
> > > when they are so separated).
> > 
> > I'm comfortable with either solutions, I do think that the 
> > document has a lot of useful information that shouldn't get 
> > lost.  I think if we took your later suggest, we could 
> > probably progress it rather quickly, I don't think we need 
> > additional information.
> > 
> > John
> > 

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to 
[email-masked]. Thank you
====================================================================

---

From: [email-masked]
Date: Wed, 23 Feb 2005 06:46:23 +0200

Alpesh & James,

> I'm comfortable keeping the document in one piece, as long as the problem
> statement, architecture, and requirements themes are clearly separated. I
> think the problem statement itself could probably be done in one section.
> Actually, the archtecture and requirements parts are in some sense more
> interesting than the problem statement, since they're defining a model for
> Mobile IP roaming that I believe will be quite valuable to wireless service
> providers.

I think that is a reasonable way forward; if clearly separated, I think this
would be OK with me.  

John