Subject: Re: New [issue23] PANA Message type/AVP numbers and Diameter command codes/AVPs

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 28 Aug 2003 13:58:16 -0700

On Thu, Aug 28, 2003 at 11:05:17AM +0300, [email-masked] wrote:
> Hi,
> 
> Sorry for my english. I just meant that new AVPs and message type codes should take the same name space as the Diameter spec. i.e. the numbers should be reserved together with AAA WG. They are doing that right now or pretty soon. This would help the integration/co-operation with Diameter NAS:es.

I agree, but with the following consideration.

I think we might need to consider not only codes but also names
(though names are not carried in protocol messages, but implementors
could easily be confused.)

For example, if we consider to share the same codes for Result-Code
AVP Values between Diameter and PANA, Diameter uses:

    2001    DIAMETER_SUCCESS                      [diameter]

On the other hand, the PANA draft uses a different name "SUCCESS"
(instead of "DIAMETER_SUCCESS) for the same Result Code AVP value.

I think it might be better to explicitly mention the mapping from PANA
naming to Diameter naming in the PANA specification, when differnet
names are used by the two protocols for the same code (AVP type code
or Result-Code AVP code).
 
Yoshihiro Ohba

> 
> - Dan
> 
> > -----Original Message-----
> > From: ext Yoshihiro Ohba [mailto:[email-masked]]
> > Sent: 28 August, 2003 00:08
> > To: Forsberg Dan (NRC/Helsinki)
> > Cc: [email-masked]
> > Subject: Re: New [issue23] PANA Message type/AVP numbers and 
> > Diameter command codes/AVPs
> > 
> > 
> > On Wed, Aug 27, 2003 at 06:26:13PM +0300, 
> > [email-masked] wrote:
> > > New submission from Dan Forsberg <[email-masked]>:
> > > 
> > > To support smoother integration for PAA with a NAS, 
> > > 
> > > (A) PANA message types should be conformant with 
> > RADIUS/DIAMETER command
> > > codes.
> > 
> > What is the definition of "conformant" here?
> > 
> > > 
> > > (B) PANA AVP types should be conformant with 
> > RADIUS/DIAMETER AVP types.
> > 
> > I have the same question as above.
> > 
> > Yoshihiro Ohba
> > 
> > > 
> > > 
> > > ----------
> > > category: Technical
> > > document: draft-ietf-pana-pana-xx.txt
> > > messages: 74
> > > nosy: dforsber
> > > priority: Should Fix
> > > status: Pending
> > > title: PANA Message type/AVP numbers and Diameter command codes/AVPs
> > > ________________________________________________
> > > PANA Issues <[email-masked]>
> > > http://danforsberg.info:8080/pana-issues/issue23
> > > ________________________________________________
> > > 
> >

---

From: Alper Yegin <[email-masked]>
Date: Thu, 28 Aug 2003 16:35:41 -0700

So, what are the benefits of homogenizing PANA with a particular AAA backend
protocol:

(a) implementors easily figure out the translation between PANA messages and
AAA messages
(b) implementors easily code the translation.

These are nice benefits. But note that these are not requirements, so let's
treat these enhancements accordingly.

I'm concerned that we might be already overdoing this. When overdone, here
is what happens:

(1) PANA looks more like an appendix to one AAA protocol (namely Diameter),
and that might impact its "AAA backend independency." That can bite us down
the road (or even now, if we find it conflicting with RADIUS, for example).
(2) The simple, clean PANA protocol gets into strange shapes. For example:
- See PANA header in section 9.1, where only 8 bits are allocated to flags
whereas 24 bits are allocated to Message Type. This does not make sense.
- 9.4.3: Session ID AVP is using two different codes. Normally we wouldn't
do that, right?

I don't think these impacts on PANA are justified. I suggest we take
homogenity with various AAA protocols into consideration, especially when we
have the choice, but not let it drive the design.

For (a), a separate document similar to draft-congdon-radius-8021x-29.txt
might be useful. 

Alper

>> Sorry for my english. I just meant that new AVPs and message type codes
>> should take the same name space as the Diameter spec. i.e. the numbers should
>> be reserved together with AAA WG. They are doing that right now or pretty
>> soon. This would help the integration/co-operation with Diameter NAS:es.
>