Re: [AAA-DOCTORS] New version of draft-ietf-dime-mip6-integrated

[Jari Arkko <[e-mail]>]

Sorry, I have been fighting fires on many fronts and not been able to 
pay enough attention to this discussion. But yes, this does look reasonable.

Jari

[e-mail] wrote:
> Dan, Jari, Jouni & others,
>
> The situation seems to be that the RADIUS work will be probably used
> by different SDOs than the Diameter work, so (1) translation may not
> be needed, and (2) translation may not be even possible, because the
> documents have different semantics (this is the case for the latest
> draft versions; and may continue to be the case if the SDOs using
> RADIUS have slightly different requirements).
>
> While these arguments are not really about the technical solutions but
> the process of writing the documents, it seems the RADIUS parts are
> considerably less mature (and the required semantics may still change), 
> while 3GPP apparently already knows what semantics it needs.
>
> I guess this could be a possible reason for leaving the MIP6-Agent-Info
> AVP in the Diameter number space.
>
> Jari, would this work for you?
>
> Looking back at the emails, the following things (not related to
> this RADIUS/Diameter topic) were still not handled in the -11 version:
>
> - Describing the semantics of the MIP6-Home-Link-Prefix in request
>   messages.
>
> - If the message contains information about multiple HAs, which home
>   agent(s) the prefix(es) in MIP6-Home-Link-Prefix AVP(s) belong to.
>   (One way to solve this would be to move it inside the Grouped AVP;
>   another way would be to prohibit its use if the message contains
>   multiple HAs; other solutions may be possible)
>
> - Clarifying the use of "realm" for MIP-Home-Agent-Host (the text
>   proposed by Jouni on 2008-11-27 looks OK to me)
>
> Best regards,
> Pasi 
>
>   
>> -----Original Message-----
>> From: ext Romascanu, Dan (Dan) [mailto:[e-mail]] 
>> Sent: 11 December, 2008 11:32
>> To: jouni; Eronen Pasi (Nokia-NRC/Helsinki)
>> Cc: [e-mail]; [e-mail]; 
>> Korhonen Jouni (NSN - FI/Espoo); 
>> julien.bournelle@orange-ftgroup.; [e-mail]
>> Subject: RE: [AAA-DOCTORS] New version of 
>> draft-ietf-dime-mip6-integrated
>>
>> Pasi, 
>>
>> What is the way forward? Have all your questions been 
>> clarified, or do you expect more information from the 
>> document editors? 
>>
>> Dan
>>  
>>
>>     
>>> -----Original Message-----
>>> From: [e-mail] 
>>> [mailto:[e-mail]] On Behalf Of jouni
>>> Sent: Sunday, December 07, 2008 12:33 PM
>>> To: <[e-mail]>
>>> Cc: [e-mail] Chowdhury; 
>>> [e-mail]; [e-mail]; 
>>> julien.bournelle@orange-ftgroup.; [e-mail]
>>> Subject: Re: [AAA-DOCTORS] New version of 
>>> draft-ietf-dime-mip6-integrated
>>>
>>> Pasi,
>>>
>>> On Dec 5, 2008, at 2:06 PM, <[e-mail]> 
>>> <[e-mail]  > wrote:
>>>
>>>       
>>>> Jouni,
>>>>
>>>> Thanks for the pointers!
>>>>
>>>> I took a look at these specs, and it seems they're using 
>>>>         
>> only some 
>>     
>>>> parts of draft-ietf-dime-mip6-integrated.
>>>>         
>>> Hopefully you  found the latest ones. At least those on 3GPP 
>>> site that I found, were 1-2 meeting cycles behind  (checked 
>>> this morning the official specs download pages). Anyway, 
>>> other SDOs who picked up this standards track I-D, are still 
>>> according to my limited knowledge completely align with the 
>>> I-D (even if they may not use all possible features).
>>>
>>>       
>>>> None of these seem to describe a case where information 
>>>>         
>> about more 
>>     
>>>> than one Home Agent is sent (which would benefit from 
>>>>         
>>> grouped AVPs), 
>>>       
>>>> and neither use the MIP6-Home-Link-Prefix AVP. (29.273 
>>>>         
>>> Section 9.2.2 
>>>       
>>>> ABNF does allow more than one MIP6-Agent-Info AVP, but the text 
>>>> doesn't describe any other case than a single PDN GW.)
>>>>
>>>> Do you know if e.g. 3GPP plans to add more semantics from 
>>>>         
>>> dime-mip6- 
>>>       
>>>> integrated to these specs? Or is dime-mip6-integrated actually 
>>>> describing more functionality than other SDOs are currently 
>>>>         
>>> planning 
>>>       
>>>> to use?
>>>>         
>>> I cannot say what other SDOs plan to do in the future. 
>>> Current I-D describes more functionality what the above spec 
>>> decided to use at the moment. However, whether they e.g. end 
>>> up signaling one or more "agent infos" is allowed by current 
>>> the I-D. That's up to their deployment view, which might not 
>>> be the same for others in the future.
>>>
>>> Cheers,
>>> 	Jouni
>>>
>>>
>>>       
>>>> Best regards,
>>>> Pasi
>>>>
>>>> From: ext jouni korhonen [mailto:[e-mail]]
>>>> Sent: 02 December, 2008 14:18
>>>> To: Eronen Pasi (Nokia-NRC/Helsinki)
>>>> Cc: [e-mail]; 
>>>>         
>>> [e-mail]; [e-mail] 
>>>       
>>>> ; [e-mail]; Korhonen Jouni (NSN - FI/Espoo); 
>>>>         
>>> [e-mail] 
>>>       
>>>> ; [e-mail]
>>>> Subject: Re: [AAA-DOCTORS] New version of draft-ietf-dime-mip6- 
>>>> integrated
>>>>
>>>> in 3GPP 29.272, 29.273 and in 3gpp2 X.P0047..
>>>>
>>>>
>>>>
>>>> On Tue, Dec 2, 2008 at 1:05 PM, <[e-mail]> wrote:
>>>> Julien and Jouni,
>>>>
>>>> Could you provide a pointer to 3GPP specs that define how these
>>>> AVPs are used in 3GPP?
>>>>
>>>> I tried searching, but found nothing except 23.402, which only
>>>> mentions this draft in a single sentence. Presumably, the details
>>>> of exactly which of the AVPs are used and how are in some Stage 3
>>>> spec, but I can't seem to find it...
>>>>
>>>> Best regards,
>>>> Pasi
>>>>
>>>>         
>>>>> -----Original Message-----
>>>>> From: ext [e-mail]
>>>>> [mailto:[e-mail]]
>>>>> Sent: 27 November, 2008 15:17
>>>>> To: [e-mail]; Eronen Pasi (Nokia-NRC/Helsinki)
>>>>> Cc: [e-mail]; [e-mail];
>>>>> [e-mail]; Korhonen Jouni (NSN -
>>>>> FI/Espoo); [e-mail]; [e-mail];
>>>>> [e-mail]
>>>>> Subject: RE: [AAA-DOCTORS] New version of
>>>>> draft-ietf-dime-mip6-integrated
>>>>>
>>>>> Dear all,
>>>>>
>>>>>  Thanks for your clarifications, I think I better understand
>>>>> your concern now. You are true
>>>>> that we are not defining a new Diameter application here and
>>>>> that finally we just add AVPs to Diameter EAP/NASREQ. In 
>>>>>           
>>> particular
>>>       
>>>>> the MIP6-Agent-Info AVP of Type Grouped. From my point of view,
>>>>> this AVP makes sense from a Diameter point of view and I'm not
>>>>> really confortable to split it to ease Diameter/RADIUS 
>>>>>           
>>> translation.
>>>       
>>>>>  First, I'm not sure that the most common deployment case 
>>>>>           
>>> will have
>>>       
>>>>> to translate between RADIUS-MIP6 and Diameter MIP6 
>>>>>           
>> integrated. As
>>     
>>>>> you know, 3GPP does not use RADIUS MIP6. It would be interesting
>>>>> to see if someone has a valid scenario.
>>>>>
>>>>>  Second, Diameter NASREQ/EAP already have some Grouped AVPs. So
>>>>> the translation agent already have to cope with this.
>>>>>
>>>>>  SO, I think that your comment is really valid and that we could
>>>>> probably add a recommandation somewhere in RFC3588Bis 
>>>>>           
>> but I'm not
>>     
>>>>> sure that this could be a MUST.
>>>>>
>>>>>  Regards,
>>>>>
>>>>>  Julien
>>>>>
>>>>>           
>>>>>> -----Message d'origine-----
>>>>>> De : Jari Arkko [mailto:[e-mail]]
>>>>>> Envoyé : jeudi 27 novembre 2008 14:01
>>>>>> À : [e-mail]
>>>>>> Cc : [e-mail]; [e-mail]; BOURNELLE
>>>>>> Julien RD-CORE-ISS; [e-mail];
>>>>>> [e-mail]; [e-mail];
>>>>>> [e-mail]; [e-mail]
>>>>>> Objet : Re: [AAA-DOCTORS] New version of
>>>>>> draft-ietf-dime-mip6-integrated
>>>>>>
>>>>>> What he said.
>>>>>>
>>>>>> jari
>>>>>>
>>>>>> [e-mail] wrote:
>>>>>>             
>>>>>>> Glen Zorn wrote:
>>>>>>>
>>>>>>>               
>>>>>>>>> Folks,
>>>>>>>>>
>>>>>>>>> Nothing in this thread so far has come to even close to
>>>>>>>>>                   
>>>>>> answering my
>>>>>>             
>>>>>>>>> main concern: specifying two similar solutions (and  
>>>>>>>>>                   
>>>> translation
>>>>         
>>>>>>>>> between them) means more complexity and more work. 
>>>>>>>>>                   
>>> Why is this
>>>       
>>>>>>>>> complexity and work needed?
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> Which complexity and work would that be?  Translation
>>>>>>>>                 
>>>>>> between RADIUS
>>>>>>             
>>>>>>>> and Diameter cannot be avoided, if that's the 
>>>>>>>>                 
>>> problem you see.
>>>       
>>>>>>> We're clearly not on the same page here. Let me try to
>>>>>>>               
>>>>>> explain why I
>>>>>>             
>>>>>>> believe why this is unnecessary complexity and work:
>>>>>>>
>>>>>>> Consider another draft that has been discussed in RADEXT:
>>>>>>> draft-aboba-radext-wlan. It would be possible to write a new
>>>>>>> Internet-Draft that would define Diameter AVPs (in 
>>>>>>>               
>>> 255 range,
>>>       
>>>>>>> possibly using grouped AVPs and other Diameter-only 
>>>>>>>               
>>> features)  
>>>       
>>>> for
>>>>         
>>>>>>> exactly the same purpose.
>>>>>>>
>>>>>>> I am claiming this would be a very bad idea, because it
>>>>>>>               
>>>>> would mean
>>>>>           
>>>>>>> more complexity and more work, and with little benefits.
>>>>>>>
>>>>>>> When you're defining attributes for use in existing
>>>>>>>               
>>>>>> messages (no new
>>>>>>             
>>>>>>> Diameter application or anything), IMHO it should be done
>>>>>>>               
>>>>>> in the 0-255
>>>>>>             
>>>>>>> range, even if that means Diameter features like grouping
>>>>>>>               
>>>>>> need to be
>>>>>>             
>>>>>>> avoided.
>>>>>>>
>>>>>>> If I understand your position right, you're saying it would
>>>>>>>               
>>>>>> be OK to
>>>>>>             
>>>>>>> have two different numbers for e.g. the 
>>>>>>>               
>>> Allowed-Called-Station- 
>>>       
>>>> Id
>>>>         
>>>>>>> attribute?
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>> So far, I have heard only explanations about how this
>>>>>>>>>                   
>>>>>> situation came
>>>>>>             
>>>>>>>>> to happen: somewhere down the line, two WGs ended up
>>>>>>>>>                   
>>>>>> taking on the
>>>>>>             
>>>>>>>>> work, and one of them (DIME) made decisions that made
>>>>>>>>>                   
>>>>>> sense locally
>>>>>>             
>>>>>>>>> (when considering only Diameter aspects), and their
>>>>>>>>>                   
>>>>> draft came to
>>>>>           
>>>>>>>>> IESG first.
>>>>>>>>> Interestingly enough, the other WG (MEXT) has 
>>>>>>>>>                   
>> been working  
>>     
>>>> on a
>>>>         
>>>>>>>>> RADIUS+Diameter solution (not a RADIUS-only solution!),
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> Any work using RADIUS Attributes from the standard
>>>>>>>>                 
>>>>>> typespace may be
>>>>>>             
>>>>>>>> trivially claimed to be a "RADIUS+Diameter solution" if no
>>>>>>>> translation other than that specified in RFC 4005 & 
>>>>>>>>                 
>>> RFC 3588 is
>>>       
>>>>>>>> performed.
>>>>>>>>
>>>>>>>>                 
>>>>>>> Yes. And I think such solutions often make sense.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> In fact, however, draft-ietf-mip6-radius-06.txt (if that
>>>>>>>>                 
>>>>>> is what you
>>>>>>             
>>>>>>>> are referring to) requires further translation: 
>>>>>>>>                 
>> "MIP6-HA and
>>     
>>>>>>>> HOA-IPv6 must be translated between their RADIUS
>>>>>>>>                 
>>>>> representation of
>>>>>           
>>>>>>>> String to a Diameter Address format which requires that the
>>>>>>>> AddressType field be set to 2 for IP6 (IP version 6)".
>>>>>>>>
>>>>>>>>                 
>>>>>>> That's a bad design choice in mip6-radius-06 that could be  
>>>>>>>               
>>>> easily
>>>>         
>>>>>>> fixed. If it used the same approach as was used for e.g.
>>>>>>> Framed-IP-Address, no translation (beyond copying) would
>>>>>>>               
>>>>> be needed.
>>>>>           
>>>>>>>               
>>>>>>>> Furthermore, a pretty good case could be made that 
>>>>>>>>                 
>>> the draft in
>>>       
>>>>>>>> question is not only not a "RADIUS+Diameter solution", but
>>>>>>>>                 
>>>>>> not even a
>>>>>>             
>>>>>>>> "RADIUS-only solution" due to the novel semantics it
>>>>>>>>                 
>>>>>> assigns to the
>>>>>>             
>>>>>>>> Access-Accept message.
>>>>>>>>
>>>>>>>>                 
>>>>>>> The "novel semantics" probably refer to the "split
>>>>>>>               
>>>>>> scenario" (which is
>>>>>>             
>>>>>>> indeed more complex, and could be in a separate document).
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>> and if they had sent their document to IESG first, we
>>>>>>>>>                   
>>>>>> probably would
>>>>>>             
>>>>>>>>> not even consider publishing 
>>>>>>>>>                   
>>> draft-ietf-dime-mip6-integrated.
>>>       
>>>>>>>> It didn't get to the IESG first because it's not 
>>>>>>>>                 
>> ready for  
>>     
>>>> prime
>>>>         
>>>>>>>> time.  I do find it interesting that a Security Area 
>>>>>>>>                 
>>> Director  
>>>       
>>>> is
>>>>         
>>>>>>>> ready to approve a document with such weak security 
>>>>>>>>                 
>>> properties,
>>>       
>>>>>>>> however.
>>>>>>>>
>>>>>>>>                 
>>>>>>> The "weak security properties" refer to the "split
>>>>>>>               
>>>>> scenario".  The
>>>>>           
>>>>>>> "integrated scenario" are ready for prime time, and are
>>>>>>>               
>>>>>> delayed only
>>>>>>             
>>>>>>> by editorial decision to keep them in the same text file.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Pasi
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>             
>>>> _______________________________________________
>>>> AAA-DOCTORS mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/aaa-doctors
>>>>
>>>>
>>>>         
>>> _______________________________________________
>>> AAA-DOCTORS mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/aaa-doctors
>>>
>>>       
>
>
>   

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