Subject: [AAA-WG]: draft-ietf-aaa-diameter-12.txt

From: <[email-masked]>
Date: Mon, 1 Jul 2002 16:50:41 +0300

Hi all,

I have made changes to diameter and have a version here:

http://www-nrc.nokia.com/sua/draft-ietf-aaa-diameter-12.txt

In this version, the header looks like this:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Ver      |                 Message Length                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |R P E r r r r r|                  Command-Code                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Application-ID                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Vendor-ID                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Hop-by-Hop Identifier                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      End-to-End Identifier                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  AVPs ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-

Which is needed to ensure proper lookup of application ID when doing 
message routing.

I'd appreciate some feedback on this.  

I missed the draft cut-off, so we can still make some edits.

John

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 1 Jul 2002 15:52:45 -0400

I think the following (problematic) usages are still valid in -12
draft.

Usage 1:

  Vendor A implements a vendor specific extention to NASREQ, by using
  experimental command codes with Vendor-ID assigned for Vendor A and 
  Application-ID=1 (e.g., NASREQ).

Usage 2:

  Vendor A requests IANA a new Application-ID for their own NASREQ
  extentions (say, Vendor-A-NASREQ) and implements a vendor specific 
  extention to NASREQ, by using experimental command codes
  with Vendor-ID=0 and the new Application-ID.  Note that without 
  a professional review, IANA will just accept the request for 
  a new Application-ID based on first-in-first-served policy.

My point is that, if we try to pursure uniqueness of the experimental
(and temporal) command code values among different vendors, there may
be always a backdoor for a vendor to keep using their own extention to
an existing application without standardizing the extention.

IMHO, a better way is to define a truely temporary command code values
that are exclusively assigned by IANA but have expiration date (e.g.,
two years after assignment).  After the expiration date, the temporary
command code values will be deleted from the IANA registry and reused
for other temporary use after sometime.  So standardization action is
inevitable before the expiration date if the requester want to assign
stable command code values for the temporary command codes.  Given
that, Vendor-ID and Application-ID are not needed in the Diameter
header and it becomes simpler.  But I could be wrong.

Regards,

Yoshihiro Ohba