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

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

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