Subject: RE: [Pana] issue 23 and 25

From: [email-masked]
Date: Tue, 14 Oct 2003 14:23:19 +0300

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

> Issue 25: Service Profile names
>
> In addition, there is one remaining issue on Issue 19: whether
> Result Code "PANA_REALM_NOT_SERVED" should be supported or not.

This has been discussed on another thread.

- Dan

> Any comments?
>
> 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: Yoshihiro Ohba <[email-masked]>
Date: Tue, 14 Oct 2003 11:17:37 -0700

> 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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 14 Oct 2003 11:17:37 -0700

Yoshihiro Ohba