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

[<[e-mail]>]

Dan, Jari, Jouni & others,

The situation seems to be that the RADIUS work will be probably used
by different SDOs than the Diameter work, so (1) translation may not
be needed, and (2) translation may not be even possible, because the
documents have different semantics (this is the case for the latest
draft versions; and may continue to be the case if the SDOs using
RADIUS have slightly different requirements).

While these arguments are not really about the technical solutions but
the process of writing the documents, it seems the RADIUS parts are
considerably less mature (and the required semantics may still change), 
while 3GPP apparently already knows what semantics it needs.

I guess this could be a possible reason for leaving the MIP6-Agent-Info
AVP in the Diameter number space.

Jari, would this work for you?

Looking back at the emails, the following things (not related to
this RADIUS/Diameter topic) were still not handled in the -11 version:

- Describing the semantics of the MIP6-Home-Link-Prefix in request
  messages.

- If the message contains information about multiple HAs, which home
  agent(s) the prefix(es) in MIP6-Home-Link-Prefix AVP(s) belong to.
  (One way to solve this would be to move it inside the Grouped AVP;
  another way would be to prohibit its use if the message contains
  multiple HAs; other solutions may be possible)

- Clarifying the use of "realm" for MIP-Home-Agent-Host (the text
  proposed by Jouni on 2008-11-27 looks OK to me)

Best regards,
Pasi 

> -----Original Message-----
> From: ext Romascanu, Dan (Dan) [mailto:[e-mail]] 
> Sent: 11 December, 2008 11:32
> To: jouni; Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: [e-mail]; [e-mail]; 
> Korhonen Jouni (NSN - FI/Espoo); 
> julien.bournelle@orange-ftgroup.; [e-mail]
> Subject: RE: [AAA-DOCTORS] New version of 
> draft-ietf-dime-mip6-integrated
> 
> 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