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

[jouni <[e-mail]>]

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