Subject: RE: [Pana] issue 23 and 25

From: [email-masked]
Date: Thu, 16 Oct 2003 10:59:05 +0300

There is no first and second. PANA borrows some AVPs from 
RADIUS/Diameter, which we don't want to change, thus the 
same codes. PANA has it's own AVPs, which we don't want to 
overlap with Diameter/Radius AVPs, thus same code space, 
but non-overlapping codes. PANA has it's own message types, 
which can be seen as command codes. These should not overlap 
with Radius/Diameter.

The process uses two separate protocols, but benefits in 
many ways from having synergies between the protocols. To 
give the process a name, we can call it a AAA application. 
AAA application uses Diameter or Radius as the transport to 
the network and PANA towards the client. PANA has also it's 
transport (header processing) and application level stuff 
(session handling). There are of course other ways to see/ 
think this, but AAA session and PANA session are very close 
to each other. PAA can't live without the AAA part. EAP is 
a tool to handle the authentication signaling, but doesn't 
"know" about sessions.

- Dan

> -----Original Message-----
> From: ext Alper Yegin [mailto:[email-masked]]
> Sent: 15 October, 2003 21:23
> To: Yoshihiro Ohba; Forsberg Dan (NRC/Helsinki)
> Cc: [email-masked]
> Subject: Re: [Pana] issue 23 and 25
> 
> 
> 
> 
> First it was using the same codes for both PANA and Diameter. 
> Now it is
> using non-overlapping codes. I still don't see why we have to 
> care about
> these, and unnecessarily constraint ourselves. These two are separate
> protocols. If a process uses both protocols, it better know 
> what protocol a
> received message belongs to.
> 
> Alper
> 
> 
> > On Wed, Oct 15, 2003 at 11:07:59AM +0300, 
> [email-masked] wrote:
> >> I mean the same code space, but different numbers so that
> >> overlapping is not happening when processing PANA and AAA
> >> messages at the same application level.
> >> - Dan
> > 
> > That also works for me, as long as the same rule 
> consistently applies
> > to both PANA message types and PANA AVP types.
> > 
> > Yoshihiro Ohba
> > 
> > 
> >> 
> >>> -----Original Message-----
> >>> From: ext Yoshihiro Ohba [mailto:[email-masked]]
> >>> Sent: 14 October, 2003 21:18
> >>> To: Forsberg Dan (NRC/Helsinki)
> >>> Cc: [email-masked]; [email-masked]
> >>> Subject: Re: [Pana] issue 23 and 25
> >>> 
> >>> 
> >>> On Tue, Oct 14, 2003 at 02:23:19PM +0300,
> >>> [email-masked] wrote:
> >>>>> -----Original Message-----
> >>>>> From: ext Yoshihiro Ohba [mailto:[email-masked]]
> >>>>> Sent: 14 October, 2003 00:28
> >>>>> To: [email-masked]
> >>>>> Subject: [Pana] issue 23 and 25
> >>>>> 
> >>>>> 
> >>>>> There are two PANA draft -01 issues for which I'm not
> >>> sure about the
> >>>>> consensus.
> >>>>> 
> >>>>> Issue 23: PANA Message type/AVP numbers and Diameter command
> >>>>> codes/AVPs
> >>>> 
> >>>> Let me give some background for this issue, since I submitted it.
> >>>> 
> >>>> One approach is that a NAS supports PANA functionality. A NAS
> >>>> can be a Diameter/Radius client. To better support
> >>> interworking with the
> >>>> PANA and NAS functionality, it would be good to distinguish
> >>> the command
> >>>> code and message type numbers. This way for example PANA
> >>> message header
> >>>> parsing functionality can be added to a NAS almost as "link
> >>> layer" and
> >>>> the PANA session handling functionality can be "migrated"
> >>> into the NAS.
> >>> 
> >>> This seems to suggest using different code space for 
> Diameter command
> >>> codes and PANA message types, right?  What about using 
> different code
> >>> space for Diameter AVP types and PANA AVP types?  I think the same
> >>> justification is also applicable to PANA AVP types.
> >>> 
> >>> Yoshihiro Ohba
> >>> 
> > 
> > _______________________________________________
> > Pana mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pana
> > 
> 
> 

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Alper Yegin <[email-masked]>
Date: Thu, 16 Oct 2003 12:21:21 -0700

> which can be seen as command codes. These should not overlap

IMO, borrowing formats is good enough. There is no requirement that we also
have to live in the same code space. This non-requirement has issues as I
had outlined earlier... (see "Issue23" thread). Your last statement above is
not valid. 

> to each other. PAA can't live without the AAA part. EAP is

PAA does not assume a AAA backend protocol. So, yes, PAA can live without
RADIUS/Diameter, and still run PANA.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Thu, 16 Oct 2003 12:21:21 -0700

Alper