Subject: [AAA-DOCTORS] the case of draft-ietf-dime-mip6-integrated

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 1 Dec 2008 15:11:56 +0200

Hi all, 

when http://tools.ietf.org/html/draft-ietf-dime-mip6-integrated-10 was
reviewed by the IESG we received comments about the following part of
the IANA consideration section:

7.1.  Registration of new AVPs

   This specification defines the following new AVPs:

     MIP6-Agent-Info                is set to TBD
     MIP6-Feature-Vector            is set to TBD
     MIP6-Home-Link-Prefix          is set to TBD

draft-ietf-dime-mip6-integrated-10 essentially defined 3 Diameter AVPs.
We did not care about the interworking with RADIUS in this document
since there is a separate RADIUS MIPv6 document (but that one is not yet
ready for prime time).

We got the feedback that we should not allocate Diameter AVP codes and
RADIUS attribute codes for the same functionality twice. After some
discussion Jouni crafted a proposal, which can be seen in the -11
version of the draft. We discussed it during the DIME WG group meeting
and the group was unhappy about the changes. 

Let's look at the relevant part of the -11 version:
http://tools.ietf.org/html/draft-ietf-dime-mip6-integrated-11

7.1.  Registration of new AVPs

   This specification defines the following new AVPs to be allocated
   from a normal Diameter AVP Code space (values >= 256):

     MIP6-Agent-Info                is set to TBD

   The following new AVPs are to be allocated from RADIUS Type Code
   [RFC2685 <http://tools.ietf.org/html/rfc2685> ] space so that they
are RADIUS backward compatible (AVP Code
   values between 0-255):

     MIP6-Feature-Vector            is set to TBD
     MIP6-Home-Link-Prefix          is set to TBD

Draft-ietf-dime-mip6-integrated uses a "complex attribute" (for the
MIP6-Agent-Info AVP) and hence it would have been necessary to wait for
the completion of
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attribute
s-05.txt in order to make use of it. As pointed out during the meeting
there is also a problem with the usage of
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attribute
s-05.txt when mapping these attributes into the Diameter AVP code space.
This is subject for a different discussion. 

We allocated 2 of the 3 Diameter AVPs from the RADIUS code space. 

What is the consequence?

* Mapping an incoming Diameter message containing the
MIP6-Feature-Vector and MIP6-Home-Link-Prefix AVPs can be mapped to a
RADIUS message easily (since the code space is the same). Without using
the same code space one would have to map one number to another one.

*  We are saving 2 values in the Diameter AVP code space but we are
allocating 2 values in the RADIUS attribute code space.

* Translation requires code changes for the MIP6-Agent-Info AVP). 

During the IETF#73 DIME meeting I suggested to talk to folks
implementing RADIUS-Diameter translation agents. While this helps in the
longer term it will not help for this document. 

So, any ideas on how we should move forward? 

Ciao
Hannes

_______________________________________________
AAA-DOCTORS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/aaa-doctors

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 1 Dec 2008 09:11:48 -0800

Assuming that you don't want to create a dependency between this document and either the RADIUS MIPv6 document or the Extended Attributes document, then the choices are limited.  You can try to rationalize the RADIUS attributes defined in the RADIUS MIPv6 document with the ones you define in this document, but there is no guarantee that this will succeed.

Date: Mon, 1 Dec 2008 15:11:56 +0200
From: [email-masked]
To: [email-masked]; [email-masked]
CC: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [AAA-DOCTORS] the case of draft-ietf-dime-mip6-integrated

the case of draft-ietf-dime-mip6-integrated

Hi all, 

when http://tools.ietf.org/html/draft-ietf-dime-mip6-integrated-10 was reviewed by the IESG we received comments about the following part of the IANA consideration section:

draft-ietf-dime-mip6-integrated-10 essentially defined 3 Diameter AVPs. We did not care about the interworking with RADIUS in this document since there is a separate RADIUS MIPv6 document (but that one is not yet ready for prime time).

We got the feedback that we should not allocate Diameter AVP codes and RADIUS attribute codes for the same functionality twice. After some discussion Jouni crafted a proposal, which can be seen in the -11 version of the draft. We discussed it during the DIME WG group meeting and the group was unhappy about the changes. 

   [RFC2685] space so that they are RADIUS backward compatible (AVP Code

   values between 0-255):

Draft-ietf-dime-mip6-integrated uses a "complex attribute" (for the MIP6-Agent-Info AVP) and hence it would have been necessary to wait for the completion of http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-05.txt in order to make use of it. As pointed out during the meeting there is also a problem with the usage of http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-05.txt when mapping these attributes into the Diameter AVP code space. This is subject for a different discussion. 

What is the consequence?

* Mapping an incoming Diameter message containing the MIP6-Feature-Vector and MIP6-Home-Link-Prefix AVPs can be mapped to a RADIUS message easily (since the code space is the same). Without using the same code space one would have to map one number to another one.

*  We are saving 2 values in the Diameter AVP code space but we are allocating 2 values in the RADIUS attribute code space.

During the IETF#73 DIME meeting I suggested to talk to folks implementing RADIUS-Diameter translation agents. While this helps in the longer term it will not help for this document. 

Ciao

Hannes

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 1 Dec 2008 19:26:19 +0200

Hi Bernard, 

>	Assuming that you don't want to create a dependency between this
document and either the RADIUS MIPv6 document or the Extended Attributes
document, then the choices are limited.   

That's certainly something we want to avoid. 
	 
>	 You can try to rationalize the RADIUS attributes defined in the
RADIUS MIPv6 document with the ones you define in this document, but there
is no guarantee that this will succeed. 
	 
We will try to harmonize RADIUS MIPv6 with the Diameter integrated/split
document. RADIUS MIPv6 clearly needs more work.
	 
Ciao
Hannes