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

From: <[email-masked]>
Date: Wed, 9 Apr 2003 16:32:46 +0300

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: Julien Bournelle <[email-masked]>
Date: Wed, 9 Apr 2003 16:36:36 +0200

Hi,

 after a really quick look, I have a comment. Please see below,
> 
> 9.1  PANA Header
> 
>    A summary of the PANA header format is shown below.  The fields are
>    transmitted in network byte order.
> 
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |    Version    |                 Message Length                |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |    Flags      |                 Message Type                  |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                   Application-ID                              |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                 Transmitted Sequence Number                   |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                 Received Sequence Number                      |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |  AVPs ...
>       +-+-+-+-+-+-+-+-+-+-+-+-+-
> 
>    Application-ID
> 
>       Application-ID is four octets and is used to identify to which
>       application the message is applicable for.  The Application-ID
>       for PANA is <TBD>.

I know that Diameter has this fields to distinguish between his various
applications but PANA doesn't need this field to work. Am I wrong ?

Do we add it just for simplify PANA/Diameter cooperation ?

--
[email-masked]

---

From: Alper Yegin <[email-masked]>
Date: Mon, 14 Apr 2003 13:53:52 -0700

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.

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

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

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

Alper