RE: Expert review for AAA Diamater assignments

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

So not having seen more follow up, I will go ahead
and tell IANA that the following is OK. 
The lines with | are new, those with @ are changed

   Application IDs
   ===============

    ID values     Name                                Reference
   -----------    ------------------------            ---------
            0    Diameter common message             [RFC3588]
            1    NASREQ                              [RFC3588] 
            2    Mobile IPv4                         [RFC3588]
            3    Diameter base accounting            [RFC3588]
   4-16777215    Unallocated (Standards Track)  		
     16777216    3GPP Cx                             [3GPP TS 29.228 and 29.229]
     16777217    3GPP Sh                             [3GPP TS 29.328 and 29.329]
@    16777218    3GPP Re/Rf                          [3GPP TS 32.225]
|    16777219    3GPP Wx                             [3GPP TS 29.234]
|    16777220    3GPP Zn                             [3GPP TS 29.109]
|    16777221    3GPP Zh                             [3GPP TS 29.109]
|    16777222    3GPP Gq                             [3GPP TS 29.209]
|    16777223    3GPP Gmb                            [3GPP TS 29.061]

@   1677721916777224-4294967294 Unallocated (Vendor Specific, FCFS)	
    4294967295    Relay                               [RFC3588]

Speak up today (Dec 17th) if you see any issue.

Jari, I will ask if they can add names and urls to docs if possible.

Bert

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net]
> Sent: Saturday, November 27, 2004 17:29
> To: Bernard Aboba
> Cc: Wijnen, Bert (Bert); Aaa-Doctors (E-mail)
> Subject: Re: Expert review for AAA Diamater assignments
> 
> 
> Bernard Aboba wrote:
> >>Anyway, expert help for 3GPP's use of Diameter is very
> >>useful. I spend surprisingly lot of time in talking to
> >>either our implementation folks or the 3GPP participants
> >>about their use of Diameter. One of the recent topics
> >>has been the application identifier usage of some of
> >>their newer Diameter-based interfaces.
> > 
> > 
> > I'd agree.  I'd also note that there has been some 
> controversy relating to
> > usage of the 'M'andatory bit.  For example, my 
> understanding is that some
> > implementations return terminal "Missing AVP" errors in response to
> > missing AVPs classified as optional in the Diameter specifications.
> > This is a troubling development, since could affect 
> interoperability at
> > the most basic level.
> 
> Yes. But its possible to err in two directions; part of
> my recent experience has been that you can also follow
> the rules too narrowly, and that its easier to fall back
> to a new application identifier than think about whether
> you can live with an existing standard application. This
> is equally bad to the Missing AVP fatal error, because two
> boxes will be unable to interoperate -- only the manner
> in which they fail is different, early application id mismatch
> vs. late error message.
> 
> --Jari
>