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

[<[e-mail]>]

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. 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? 
 
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