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:jari.arkko@piuha.net] 
> Envoyé : jeudi 27 novembre 2008 14:01
> À : Pasi.Eronen@nokia.com
> Cc : glenzorn@comcast.net; dromasca@avaya.com; BOURNELLE 
> Julien RD-CORE-ISS; jouni.korhonen@teliasonera.com; 
> jouni.korhonen@nsn.com; aaa-doctors@ietf.org; 
> charliep@wichorus.com; kchowdhury@starentnetworks.com
> Objet : Re: [AAA-DOCTORS] New version of 
> draft-ietf-dime-mip6-integrated
> 
> What he said.
> 
> jari
> 
> Pasi.Eronen@nokia.com 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
AAA-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/aaa-doctors