Subject: RE: Proposal for message formatting (sec. 9).

From: <[email-masked]>
Date: Tue, 15 Apr 2003 10:37:29 +0300

Alper,

Thank you for your comments.

> -----Original Message-----
> From: ext Alper Yegin [mailto:[email-masked]]
> Sent: 14 April, 2003 23:54
> To: Forsberg Dan (NRC/Helsinki); [email-masked]
> Subject: Re: Proposal for message formatting (sec. 9).
> 
> 
> 
> Hi Dan,
> 
> Thank you for putting together the Message Format section.
> 
> Here are some comments on the current design:
> 
> - I see the message formats includes some protocol features 
> we have not
> fully discussed yet. For example: session-id, add-device-id,
> remove-device-id. I recommend we separately discuss them 
> first, and than
> incorporate into the message formats if necessary.

Sure.

> - I understand the desire to re-use DIAMETER code, but let's 
> not overdo it.
> From "PANA design perspective", I don't see why we should 
> have "Application
> ID" field in the header.

To make the header structure similar to Diameter. If we break it, then it doesn't matter what kind of format we use, because implementations must be different then. 

We have a prototype that uses Diameter message formatting (testing SeNAA) on top of UDP. This is a very nice feature, because the Diameter stack callbacks can be used with PANA messages too. The interaction with the AAA backend becomes very smooth. This means of course that Diameter and PANA id values don't overlap.

With Diameter PANA could have Application-Id 4 and the new AVPs could be registered from the Diameter number space (or then we could use Vendor-Id for PANA). I talked with John Loughney (one of the authors of Diameter base spec) about this and he didn't see any problems with this approach.

PANA could support different applications in the future too. A preshared SA between PaC and PAA and extensible message types sounds compelling. And if the protocol works smoothly with AAA backends (one doesn't have to specify different AVPs with Diameter and PANA) the scenario looks  interesting.

> - Device ID can also include various link-layer address 
> types. Let's reflect
> that onto the design (currently only IP addresses are included).

Sure.

>  - How about alignment requirements? I'd say we should require 8-octet
> alignment for AVPs.

If that doesn't break the Diameter compatibility.

> 
> Alper
> 
> > Hi,
> > 
> > Attached you can find a proposal section (9 Message Formats)
> > for the draft-ietf-pana-pana-00.txt. It contains some changes
> > that affect the whole draft.
> > 
> > There are no error messages defined, which I think should be
> > fixed. This is not only a message format issue, but a protocol
> > issue.
> > 
> > Changes to the pana draft in general:
> > 
> > - Message naming convention changed (*_ack --> *-Answer,
> > * --> *-Request) to better reflect the Diameter style
> > and the nature of the protocol: answers contain data,
> > but for acks it is not so clear. Requests and answers
> > describe better the protocol.
> > 
> > - Thus, 2 messages instead of 1:
> >  - PANA-Auth-Request & PANA-Auth-Answer.
> >    PAA always sends PANA-Auth-Request and requires an
> >    answer to it.
> >  - PANA-Start-Request & PANA-Start-Answer.
> >    PANA-Start messages are different depending on the sender.
> >  - PANA-Success-Request/Answer: PANA requires answer to success,
> >    because he PANA SA is not otherwise established properly.
> >    And for sake of simplicity, the same naming convention
> >    should be used.
> > 
> > - Flag change: A flag to R flag to better reflect Diameter style.
> > Requests have the R flag set, answers unset.
> > 
> > - Name change: Data-Protection --> Protection-Capability.
> > Data-Protection is misleading term.
> > 
> > - Name change: Revocation-Status --> Termination-Cause (Diameter).
> > There is already an AVP that suits for this purpose.
> > 
> > - PANA-Disconnect-Request now contains Termination-Cause AVP.
> > There are different reasons for the user to disconnect.
> > 
> > 
> > 
> > Comments welcome,
> > - Dan
> > 
> 
>

---

From: Alper Yegin <[email-masked]>
Date: Tue, 15 Apr 2003 17:14:54 -0700

Hi Dan,

It seems like you are treating Diameter compatibility as if it is a
requirement. It might be a desirable feature at best. Sure it helps with
some code reuse or implimentation shortcuts, but these are not necessary
for the protocol design, and should not cause undesirable side effects.
PANA is not really meant to be an appendix to Diameter. Diameter is one of
the possible backend AAA protocols only.

For example, addition of the "application id" field is not justifiable for
PANA imo. I didn't quite understand the future application support. For
future extensions a reserved field might be more than sufficient. Actually
AVPs might be good enough too.

64-bit alignment is a nice feature too. I'm not sure which one is better
though: Diameter harmonization or this.

Alper

> To make the header structure similar to Diameter. If we break it, then it
> doesn't matter what kind of format we use, because implementations must be
> different then. 
> 
> We have a prototype that uses Diameter message formatting (testing SeNAA) on
> top of UDP. This is a very nice feature, because the Diameter stack callbacks
> can be used with PANA messages too. The interaction with the AAA backend
> becomes very smooth. This means of course that Diameter and PANA id values
> don't overlap.
> 
> With Diameter PANA could have Application-Id 4 and the new AVPs could be
> registered from the Diameter number space (or then we could use Vendor-Id for
> PANA). I talked with John Loughney (one of the authors of Diameter base spec)
> about this and he didn't see any problems with this approach.
> 
> PANA could support different applications in the future too. A preshared SA
> between PaC and PAA and extensible message types sounds compelling. And if the
> protocol works smoothly with AAA backends (one doesn't have to specify
> different AVPs with Diameter and PANA) the scenario looks  interesting.
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 16 Apr 2003 17:10:30 -0400

Hi Dan,

Please see my comments below.

> With Diameter PANA could have Application-Id 4 and the new AVPs could be registered from the Diameter number space (or then we could use Vendor-Id for PANA). I talked with John Loughney (one of the…

What about header flags?  If one bit is assigned for F-bit in PANA,
cannot Diameter use that bit for a new flag?  Since the flags field is
only 8-bit, the field will be consumed up quickly if bit allocation 
for the field is shared between Diameter and PANA.

> If that doesn't break the Diameter compatibility.

I think 8-octet alignment breaks the Diameter compatibility, since
Diameter does 32-bit (4-octet) alignment.

Yoshihiro Ohba