Subject: RE: [Mip6] Should we add the requirements that arise from RFC 4285 inthe draft-ietf-mip6-aaa-ha-goals-03?

From: "Tsirtsis, George" <[email-masked]>
Date: Tue, 14 Nov 2006 09:40:16 -0800

Gopal,

I am not sure I understand the question. RFC4285 defines a mechanism/solution and an associated applicability statement. What is it that you propose to "add" to draft-ietf-mip6-aaa-ha-goals-03 and in what form?

I would also appreciate if people voting "yes" or "no" on this (or any) issue, say something about why they vote one way or the other.

Regards
George
________________________________________
From: Gopal Dommety (gdommety) [mailto:[email-masked]] 
Sent: Saturday, November 11, 2006 1:44 PM
To: [email-masked]
Subject: [Mip6] Should we add the requirements that arise from RFC 4285 inthe draft-ietf-mip6-aaa-ha-goals-03?

Hello All,
 
    Wanted to get the MIP6 Working groups preference on whether we should we add the requirements that arise from RFC 4285 in the   draft-ietf-mip6-aaa-ha-goals-03
 
We would like to hear the Working Groups opinion of the following question:
 
Should we add the requirements that arise from RFC 4285 in the  draft-ietf-mip6-aaa-ha-goals-03?
 
 Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there were 14 people for "yes" and 5 for "No".
 
Cheers,
Gopal and Raj

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

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 14 Nov 2006 15:06:24 -0800

I second George on this. Should we not find out what these requirements are
before doing a yes/no vote. In the absence of clear requirements, I will say
no. Which one of you buys a car without seeing it??

Madjid

-----Original Message-----
From: Tsirtsis, George [mailto:[email-masked]] 
Sent: Tuesday, November 14, 2006 9:40 AM
To: Gopal Dommety (gdommety); [email-masked]
Subject: RE: [Mip6] Should we add the requirements that arise from RFC
4285inthe draft-ietf-mip6-aaa-ha-goals-03?

Gopal,

I am not sure I understand the question. RFC4285 defines a
mechanism/solution and an associated applicability statement. What is it
that you propose to "add" to draft-ietf-mip6-aaa-ha-goals-03 and in what
form?

I would also appreciate if people voting "yes" or "no" on this (or any)
issue, say something about why they vote one way or the other.

Regards
George
________________________________________
From: Gopal Dommety (gdommety) [mailto:[email-masked]] 
Sent: Saturday, November 11, 2006 1:44 PM
To: [email-masked]
Subject: [Mip6] Should we add the requirements that arise from RFC 4285
inthe draft-ietf-mip6-aaa-ha-goals-03?

Hello All,
 
    Wanted to get the MIP6 Working groups preference on whether we should we
add the requirements that arise from RFC 4285 in the  
draft-ietf-mip6-aaa-ha-goals-03

Should we add the requirements that arise from RFC 4285 in the 
draft-ietf-mip6-aaa-ha-goals-03?
 
 Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there were 14
people for "yes" and 5 for "No".
 
Cheers,
Gopal and Raj

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 15 Nov 2006 14:44:29 -0600

George,

Let me see if I can clarify the question to the WG w.r.t the aaa-ha-goals
I-D:

The MIP6 WG I-D draft-ietf-mip6-aaa-ha-goals is intended to capture the AAA
requirements for MIP6 deployment/operation. These requirements would be fed
to the appropriate AAA WGs (DIME/Radext) for developing the actual solutions
or extensions. In some cases the MIP6 WG in conjunction with a AAA WG (such
as Radext) can take up the work as illustrated by the I-D
draft-ietf-mip6-radius but in others the DIME WG is working on the solutions
needed for MIP6.

The current version of the goals/requirements I-D does not consider the case
when RFC4285 is used as the means for authenticating an MN to an HA. The AAA
requirements are based strictly on the use of IPsec between the MN and HA.
The question to the WG was whether the AAA requirements/goals document
should include the requirements that MIP6 operation with RFC4285 brings.

Since the AAA goals document is intended to capture all the MIP6 AAA
requirements and RFC4285 is a recognized mode of MIP6 operation, it makes
sense to capture the additional requirements at this time.

Is this clear now?

-Raj

On 11/14/06 11:40 AM, "ext Tsirtsis, George" <[email-masked]> wrote:

> Gopal,
> 
> I am not sure I understand the question. RFC4285 defines a mechanism/solution
> and an associated applicability statement. What is it that you propose to
> "add" to draft-ietf-mip6-aaa-ha-goals-03 and in what form?
> 
> I would also appreciate if people voting "yes" or "no" on this (or any) issue,
> say something about why they vote one way or the other.
> 
> Regards
> George

---

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 15 Nov 2006 13:24:38 -0800

Hi Raj,

Thanks for the clarification. Based on your statements that 4285 is a
recognized mode of operation and that AAA requirements goal needs to
encompass Diameter/RADIUS and MIP6 operation, then my answer is

Yes

Having said that, can we agree that not every solution draft Has to meet the
4285 requirement support. So basically "4285 support" Should not be "MUST"

Regards and thanks again for clarifying,

Madjid

-----Original Message-----
From: Basavaraj Patil [mailto:[email-masked]] 
Sent: Wednesday, November 15, 2006 12:44 PM
To: ext Tsirtsis, George; Gopal Dommety; [email-masked]
Subject: Re: [Mip6] Should we add the requirements that arise from RFC 4285
in the draft-ietf-mip6-aaa-ha-goals-03?

George,

Is this clear now?

-Raj

> I am not sure I understand the question. RFC4285 defines a
mechanism/solution
> I would also appreciate if people voting "yes" or "no" on this (or any)
issue,
> say something about why they vote one way or the other.
inthe

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 15 Nov 2006 15:37:04 -0600

Hi Madjid,

RFC4285 includes an IESG statement part of it which says:
"
   Section 1.1 of this document provides an applicability statement for
   this RFC.  The IESG recommends against the usage of this
   specification outside of environments that meet the conditions of
   that applicability statement.  In addition the IESG recommends those
   considering deploying or implementing this specification conduct a
   sufficient security review to meet the conditions of the environments
   in which this RFC will be used.
"

So RFC4285 support is not a MUST.

-Raj

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Wed, 15 Nov 2006 22:41:50 +0100

Hi Madjid, 

the RFC 2119 language refers to the design of the protocol rather than its usage. Either you consider the usage of RFC 4285 in the design of the protocol or you don't. When the protocol is used then obviously you don't want to mandatorily put RFC 4285 specific AVPs and attributes in AAA messages. 

Ciao
Hannes

> -----Ursprüngliche Nachricht-----
> Von: Madjid Nakhjiri [mailto:[email-masked]] 
> Gesendet: Mittwoch, 15. November 2006 22:25
> An: 'Basavaraj Patil'; 'ext Tsirtsis, George'; 'Gopal 
> Dommety'; [email-masked]
> Betreff: RE: [Mip6] Should we add the requirements that arise 
> from RFC 4285 inthe draft-ietf-mip6-aaa-ha-goals-03?
> 
> Hi Raj,
> 
> >     Wanted to get the MIP6 Working groups preference on 
> whether we should
> we

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 15 Nov 2006 13:45:03 -0800

Raj,
What is the purpose of the aaa-ha-goals document? Are the AAA solution documents required to satisfy all the identified goals? Also, are the AAA solution documents expected to be PS or Informational? 

I think we need to answer the above questions before we can make a decision on this particular topic. 

Vidya 

> To: Tsirtsis, George; Gopal Dommety; [email-masked]
> Subject: Re: [Mip6] Should we add the requirements that arise 
> from RFC4285 in the draft-ietf-mip6-aaa-ha-goals-03?
> 
> 
> George,
> 
> The MIP6 WG I-D draft-ietf-mip6-aaa-ha-goals is intended to 
> capture the AAA requirements for MIP6 deployment/operation. 
> These requirements would be fed to the appropriate AAA WGs 
> (DIME/Radext) for developing the actual solutions or 
> extensions. In some cases the MIP6 WG in conjunction with a 
> AAA WG (such as Radext) can take up the work as illustrated 
> by the I-D draft-ietf-mip6-radius but in others the DIME WG 
> is working on the solutions needed for MIP6.
> 
> The current version of the goals/requirements I-D does not 
> consider the case when RFC4285 is used as the means for 
> authenticating an MN to an HA. The AAA requirements are based 
> strictly on the use of IPsec between the MN and HA.
> The question to the WG was whether the AAA requirements/goals 
> document should include the requirements that MIP6 operation 
> with RFC4285 brings.
> 
> Since the AAA goals document is intended to capture all the 
> MIP6 AAA requirements and RFC4285 is a recognized mode of 
> MIP6 operation, it makes sense to capture the additional 
> requirements at this time.
> 
> Is this clear now?
> 
> -Raj
> 
> 
> 
> > mechanism/solution and an associated applicability 
> statement. What is 
> > it that you propose to "add" to 
> draft-ietf-mip6-aaa-ha-goals-03 and in what form?
> > 
> > I would also appreciate if people voting "yes" or "no" on this (or 
> > any) issue, say something about why they vote one way or the other.
> > 
> > Regards
> > George
> > Subject: [Mip6] Should we add the requirements that arise from RFC 
> > 4285 inthe draft-ietf-mip6-aaa-ha-goals-03?
> > 
> > Hello All,
> >  
> >     Wanted to get the MIP6 Working groups preference on whether we 
> > should we add the requirements that arise from RFC 4285 in the

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 15 Nov 2006 16:01:13 -0600

Hi Vidya,

In case I was not clear enough in my earlier email (below), let me reiterate
that the purpose of the aaa-ha-goals document is to capture all the AAA
requirements that the MIP6 WG believes exist for MIP6 deployment and
operation. 
The AAA solutions developed in DIME or Radext or within the MIP6 WG (working
with the appropriate AAA WG) may or may not address all the requirements.
And that is an acceptable situation. Of course I would think there would be
some valid reasons why a requirement would not be addressed.

The AAA solutions documents may be PS or Informational. I think that in
several instances the solution would simply be a reference to existing AAA
RFCs which already specify the attributes or AVPs and hence such documents
could just be informational because they would only specify how MIP6 would
work with a AAA framework and reuses existing specs. But in cases wherein
there is new attributes, extensions, messages or applications defined, they
would be considered for publication as ps docs.
The issue of whether the docs would be ps or informational in this thread
may not be a key factor IMO.

-Raj

On 11/15/06 3:45 PM, "ext Narayanan, Vidya" <[email-masked]> wrote:

> Raj,
> What is the purpose of the aaa-ha-goals document? Are the AAA solution
> documents required to satisfy all the identified goals? Also, are the AAA
> solution documents expected to be PS or Informational?
>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 15 Nov 2006 14:57:29 -0800

Hi Raj,

> 
> Hi Vidya,
> 
> In case I was not clear enough in my earlier email (below), 
> let me reiterate that the purpose of the aaa-ha-goals 
> document is to capture all the AAA requirements that the MIP6 
> WG believes exist for MIP6 deployment and operation. 
> The AAA solutions developed in DIME or Radext or within the 
> MIP6 WG (working with the appropriate AAA WG) may or may not 
> address all the requirements.
> And that is an acceptable situation. Of course I would think 
> there would be some valid reasons why a requirement would not 
> be addressed.
> 

This is somewhat ambiguous. I would imagine that the goals are written to be met. Otherwise, there needs to be classifications in the goals such that there is a set that a solution MUST meet in order for it to be useful. Without that, there doesn't seem to be a way to evaluate the solution. 

> The AAA solutions documents may be PS or Informational. I 
> think that in several instances the solution would simply be 
> a reference to existing AAA RFCs which already specify the 
> attributes or AVPs and hence such documents could just be 
> informational because they would only specify how MIP6 would 
> work with a AAA framework and reuses existing specs. But in 
> cases wherein there is new attributes, extensions, messages 
> or applications defined, they would be considered for 
> publication as ps docs.

This is also ambiguous. I don't think it matters whether the solution document is pointing to a whole bunch of existing attributes or defining new ones. It would make sense to be a PS, if that is required for MIP6 operation in AAA-based networks. 

> The issue of whether the docs would be ps or informational in 
> this thread may not be a key factor IMO.
> 

Given the applicability statement in RFC4285, I would say that if the solution document is meant to be a PS, it should not be discussing solutions related to RFC4285. 

Vidya

> > documents required to satisfy all the identified goals? 
> Also, are the 
> > AAA solution documents expected to be PS or Informational?
> > 
> >> Subject: Re: [Mip6] Should we add the requirements that arise from 
> >> RFC4285 in the draft-ietf-mip6-aaa-ha-goals-03?
> >> 
> >> 
> >> George,
> >> 
> >> The MIP6 WG I-D draft-ietf-mip6-aaa-ha-goals is intended 
> to capture 
> >> the AAA requirements for MIP6 deployment/operation.
> extensions. In 
> >> some cases the MIP6 WG in conjunction with a AAA WG (such 
> as Radext) 
> >> can take up the work as illustrated by the I-D 
> draft-ietf-mip6-radius 
> >> but in others the DIME WG is working on the solutions needed for 
> >> MIP6.
> >> 
> consider 
> >> the case when RFC4285 is used as the means for 
> authenticating an MN 
> >> to an HA. The AAA requirements are based strictly on the 
> use of IPsec 
> >> between the MN and HA.
> >> document should include the requirements that MIP6 operation with 
> >> RFC4285 brings.
> >> 
> whether we 
> >>>  Please answer "yes" or "no" PS: In the IETF Mip6 WG 
> meeting there 
> >>> were 14 people for "yes" and 5 for "No".
> >>>  
> >>> Cheers,
> >>> Gopal and Raj
> >>>

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Wed, 15 Nov 2006 18:27:52 -0500

Hi Vidya,

just one comment below..

> Given the applicability statement in RFC4285, I would say that if the solution document is meant to be a PS, it should not be discussing solutions related to RFC4285.

You can have two docs in DIME WG, one Informational and one PS if the
main issue is the status of the rfc, with the Informational one
specifying the rfc4285-specific AVPs.

I agree with Raj this should not be the key factor in the decision.

--Gerardo

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 15 Nov 2006 17:31:49 -0600

Inline:

On 11/15/06 4:57 PM, "ext Narayanan, Vidya" <[email-masked]> wrote:

> This is somewhat ambiguous. I would imagine that the goals are written to be
> met. Otherwise, there needs to be classifications in the goals such that there
> is a set that a solution MUST meet in order for it to be useful. Without that,
> there doesn't seem to be a way to evaluate the solution.

Hmmm... Not sure what you believe is ambiguous.
Requirements are specified to be met. What I implied was that the
requirements that this document will specify may already have solutions and
in some cases the requirement may be invalid when analyzed by a AAA expert.
The authors/editor of the document while making every effort to specify
requirements that will be met may potentially also specify some which may or
may not be met. But there is no reason why the rqeuirements specification
have to foresee the solution and if and how it will be met. That would only
hamper the development of the requirements.
I don't think that we will have a problem in verifying if the solution meets
the rqeuirement. At least from reading the current document, I don't see
that as a problem. 

> This is also ambiguous. I don't think it matters whether the solution document
> is pointing to a whole bunch of existing attributes or defining new ones. It
> would make sense to be a PS, if that is required for MIP6 operation in
> AAA-based networks.

Depends. If a document simply refers to an existing AAA specification and
only explains how that is applied in the context of MIP6, it may be
published as an Informational document. But we can decide what status a
solution needs to be assigned at a later stage.

> Given the applicability statement in RFC4285, I would say that if the solution
> document is meant to be a PS, it should not be discussing solutions related to
> RFC4285. 

There could be more than one solution document. And yes, if the solution
document addresses RFC4285 requirements, then we do have the issue of
pursuing it on the ps track.

-Raj

---

From: <[email-masked]>
Date: Thu, 16 Nov 2006 06:43:08 +0200

Vidya,

>What is the purpose of the aaa-ha-goals document? Are the AAA 
>solution documents required to satisfy all the identified 
>goals? Also, are the AAA solution documents expected to be PS 
>or Informational? 
>
>I think we need to answer the above questions before we can 
>make a decision on this particular topic. 

Speaking as DiME co-chair, we need a requirements document so 
that we can be sure that we design a solution that meets the
needs of the MIPv6 WG.  The solution will be PS.

John