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

["Romascanu, Dan (Dan)" <[e-mail]>]

I am copying AAA-Doctors who may be interested in commenting on this issue which is crossing the DIME and RADIUS borders. 

Dan
 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> Sent: Wednesday, November 26, 2008 12:07 PM
> To: Romascanu, Dan (Dan); 
> [e-mail]; 
> [e-mail]; [e-mail]; 
> [e-mail]
> Cc: [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]
> Subject: RE: New version of draft-ietf-dime-mip6-integrated
> 
> 
> 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?
> 
> 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!), and 
> if they had sent their document to IESG first, we probably 
> would not even consider publishing draft-ietf-dime-mip6-integrated. 
> 
> I want to repeat the last point, since it's quite important: 
> if the MEXT WG document (with a RADIUS+Diameter solution) 
> would already be in IESG evaluation stage, it's IMHO highly 
> unlikely that draft-ietf-dime-mip6-integrated would be 
> published at all (we would need *really* strong arguments why 
> two different solutions are needed in Diameter).
> 
> So far, it seems the only plausible reason for publishing 
> this document is that 3GPP needs it soon, and we're in a hurry.
> Is this really a good enough reason?
> 
> Best regards,
> Pasi
> 
> > -----Original Message-----
> > From: ext Romascanu, Dan (Dan) [mailto:[e-mail]]
> > Sent: 25 November, 2008 15:42
> > To: Eronen Pasi (Nokia-NRC/Helsinki); 
> > [e-mail];
> > [e-mail]; [e-mail]
> > Cc: Tschofenig Hannes (NSN - FI/Espoo); [e-mail]; 
> > [e-mail]; [e-mail]; 
> > [e-mail]; [e-mail]
> > Subject: RE: New version of draft-ietf-dime-mip6-integrated
> > 
> > See in-line. 
> > 
> > Dan
> > 
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]]
> > > Sent: Tuesday, November 25, 2008 3:29 PM
> > > To: [e-mail];
> > > [e-mail]; [e-mail]
> > > Cc: Romascanu, Dan (Dan); [e-mail]; 
> > > [e-mail]; [e-mail]; 
> > > [e-mail]; [e-mail]; 
> > > [e-mail]
> > > Subject: RE: New version of draft-ietf-dime-mip6-integrated
> > > 
> > > 
> > > Julien,
> > > 
> > > This document does not create a new Diameter application 
> -- it adds 
> > > couple of attributes to existing applications (NASREQ and 
> Diameter 
> > > EAP).
> > > 
> > > When doing so, we're faced with two choices: we can define the 
> > > attributes in the 0-255 range so that they require no new code on 
> > > translation agents (only at client and server); or we can pick 
> > > different numbers and require that the translation agents must be 
> > > updated to understand the new attributes.
> > > 
> > > The advantage of the latter approach is that if one lives 
> in a pure 
> > > Diameter universe, the design will be somewhat cleaner and nicer 
> > > (since you can use nice Diameter features).  The disadvantage is 
> > > that in non-pure-Diameter universe, the overall design 
> will be more 
> > > complex, and translation agents need to be updated.
> > 
> > The question is whether when writing a Diameter definitions 
> document 
> > using code values with equivalence in the RADIUS code space and 
> > avoiding things like grouped AVPs are major constraints. I 
> would say 
> > no, it's only nice to have when opportunities raise. After all we 
> > invented Diameter in order to create a more powerful and versatile 
> > protocol, not to continue to live within the constrains of RADIUS,
> > 
> > > 
> > > Do I understand you correctly that you believe that for this 
> > > particular use case, the advantages outweigh the 
> disadvantages? Is 
> > > this because of the design "cleanness", or because you believe 
> > > deployments will not need to translate between RADIUS and 
> Diameter 
> > > in this case?
> > > 
> > > (Note that if we would be defining a new Diameter 
> application, the 
> > > translation agent would always need new code
> > > -- so the question would be slightly different.)
> > > 
> > > Jouni: could you send some pointers to the AAA-doctors discussion?
> > > (I took a quick look at their mailing list archive, but couldn't 
> > > find anything about this document.)
> > 
> > Unless I am mistaken, these discussions referred here happened with 
> > the participation of some of the AAA Doctors in the DIME 
> meeting and 
> > in the AAA-Doctors lunch, but were not minuted in details.
> >  
> > > 
> > > Best regards,
> > > Pasi
> > > 
> > > > -----Original Message-----
> > > > From: ext [e-mail]
> > > > [mailto:[e-mail]]
> > > > Sent: 25 November, 2008 11:12
> > > > To: [e-mail]; [e-mail]
> > > > Cc: [e-mail]; Eronen Pasi (Nokia-NRC/Helsinki);
> > > Tschofenig
> > > > Hannes (NSN - FI/Espoo); [e-mail]; 
> > > > [e-mail]; [e-mail]; 
> > > > [e-mail]; [e-mail]
> > > > Subject: RE: New version of draft-ietf-dime-mip6-integrated
> > > > 
> > > > Hi all,
> > > > 
> > > >  I just wanted to mention that I fully agree with Jouni on this.
> > > > 
> > > >  I don't understand this new requirement on using only
> > RADIUS space
> > > > attributes for Diameter Application and on not employ
> > grouped AVPs.
> > > > I see that as a limitation for Diameter development. 
> > > > 
> > > >  In my opinion, these new requirements should be discussed
> > > in related
> > > > IETF WGs before being applied. I don't really understand
> > > why they are
> > > > discussed here and have not been discussed for Diameter 
> NASREQ or 
> > > > Diameter EAP.
> > > > 
> > > >  Moreover, I don't see the need for interoperability
> > between Mobile
> > > > IPv4 and Mobile IPv6. I may miss something on this.
> > > > 
> > > >  Best Regards,
> > > > 
> > > >  Julien
> > > > 
> > > > > -----Message d'origine-----
> > > > > De : [e-mail] 
> > > > > [mailto:[e-mail]]
> > > > > Envoyé : lundi 24 novembre 2008 20:35 À : 
> > > [e-mail] Cc : 
> > > > > [e-mail]; [e-mail]; BOURNELLE Julien 
> > > > > RD-CORE-ISS; [e-mail]; 
> [e-mail]; 
> > > > > [e-mail]; [e-mail]; 
> > > > > [e-mail] Objet : RE: New version of 
> > > > > draft-ietf-dime-mip6-integrated
> > > > > 
> > > > > Hi Jari,
> > > > > 
> > > > > > I read further, and would like to recommend that we
> > change the
> > > > > > document to
> > > > > > 
> > > > > > - employ only RADIUS space attributes
> > > > > > - not employ grouped AVPs
> > > > > > - not reuse RFC4004 attribute, which has been defined for
> > > > MIP4 info
> > > > > 
> > > > > Honestly, I won't agree with this change. As far as I
> > know, there
> > > > > was discussion of this in Dime WG meeting and the 
> overwhelming 
> > > > > consensus was not to go for RADIUS path.. Same comment
> > came from
> > > > > AAA-doctors as well. (Hannes can correct me here if I got
> > > it wrong). 
> > > > > What I stated earlier about doing Diameter still has
> > not changed.
> > > > > 
> > > > > > As the document currently stands, it will create
> > > interoperability
> > > > > > problems between Diameter and RADIUS, and between
> > > Mobile IPv4 and
> > > > > > IPv6.
> > > > > 
> > > > > I don't follow the MIP4 vs IPv6 part.
> > > > > 
> > > > > > The design will not be entirely clean even if we do the
> > > > > above, but it
> > > > > > does remove the most significant problems. In particular,
> > > > > it will make
> > > > > > it possible for a Diameter-RADIUS proxy to send this
> > > information
> > > > > > without any extra code.
> > > > > >
> > > > > > I believe the above changes are fairly easily doable in
> > > > the current
> > > > > > document.
> > > > > > 
> > > > > > Jari
> > > > > 
> > > > > Cheers,
> > > > > 	Jouni
> > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
_______________________________________________
AAA-DOCTORS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/aaa-doctors