Subject: [Dime] [Fwd: draft-ietf-dime-rfc3588bis review (1/3)]

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 11 Sep 2008 16:51:20 +0300

--- I noticed that my mail did not make it to the list because it is too 
large.

Hi Victor,

as I am the PROTO shepherd for this document I had todo a review of the 
document before it leaves the working group. I did it based on the -11 
version but I noticed that you just published -12. Still, I wanted to 
submit my first round of comments. Many aspects are very easy to address 
since they are just editorial.

I split my comments into three parts; this is the first part.

Section 1.1:

  All data delivered by the protocol is in the form of an AVP.  Some of
  these AVP values are used by the Diameter protocol itself, while

Diameter base protocol

  others deliver data associated with particular applications that
  employ Diameter.  AVPs may be added arbitrarily to Diameter messages,
  so long as the requirements of a message's ABNF are met and the ABNF
  allows for it.  AVPs are used by the base Diameter protocol to

Diameter base protocol

  support the following required features:

  o  Exchanging resource usage information, which MAY be used for
     accounting purposes, capacity planning, etc.

s/MAY/may

A Diameter node MAY act as an agent for
  certain requests while acting as a server for others.

s/MAY/may

Section 1.1.1.

I would shorten this section and just say the following:

1.1.1.  Description of the Document Set

  The Diameter specification consists of an updated version
  of the base protocol specification (this document), Transport Profile
  [RFC3539] and various document defining new Diameter applications or    

extending existing applications. Note that
  this document obsoletes [RFC3588].  A summary of the base protocol
  updates included in this document can be found in Section 1.1.3.

  The Transport Profile document [RFC3539] discusses transport layer
  issues that arise with AAA protocols and recommendations on how to
  overcome these issues.  This document also defines the Diameter
  failover algorithm and state machine.
   
  Since standardization efforts on Diameters are being entertained in

various standardization organizations the list of Diameter applications is

increasing steadily and providing a list of all Diameter applications is 
not

provided in this document. Example applications can be found with Mobile 
IPv4

[RFC4004], NASREQ [RFC4005], Credit Control [RFC4006], EAP [RFC4072] and 
SIP

[RFC4740].

1.1.3.  Changes from RFC3588

  This document deprecates [RFC3588] but is fully backward compatible
  with that document.  The changes introduced in this document focuses
  on fixing issues that has surfaced during implementation of

s/has/have

  [RFC3588].  An overview of some the major changes are shown below.

  o  Simplified Security Requirements.  The use of a secured transport
     for exchanging diameter messages remains mandatory.  However, TLS
     has become the primary method of securing diameter and IPSec is a
     secondary alternative.  See Section 13 for details.  Along with
     this, support for the End-to-End security framework (E2ESequence
     AVP and 'P'-bit in the AVP header) has also been deprecated.

s/IPSec/IPsec
s/support for/the support for

  o  Diameter Extensibility Changes.  This includes fixes to the
     diameter extensibility specification (Section 1.2 and others) to
     better aid diameter application designers.  It also includes
     allocation of vendor specific command code space.  The new
     specification relaxes the allocation of command codes for vendor
     specific uses.  See Section 11.2.1 for details.

s/diameter extensibility specification/Diameter extensibility description

s/diameter application designers/Diameter application designers

  o  Application Id Usage.  Clarify the proper use of Application Id
     information which can be found in multiple places within a
     diameter message.  This includes co-relating Application Ids found
     in the message headers and AVPs.  These changes also clearly
     specifies the proper Application Id value to use for specific base
     protocol messages (ASR/ASA, STR/STA) as well as clarifying the
     content and use of Vendor-Specific-Application-Id.

s/Clarify the proper use of Application Id
     information which can be found in multiple places within a
     diameter message.
/Clarify the proper use of Application Id
     information, which can be found in multiple places within a
     Diameter message.

  o  Simplification of Diameter Peer Discovery.  The diameter discovery
     process now supports only well known discovery schemes.  The rest
     has been deprecated.  (See Section 5.2 for details).

s/diameter/Diameter

1.3.  Terminology

 Broker

     A broker is a business term commonly used in AAA infrastructures.
     A broker is either a relay, proxy or redirect agent, and MAY be
     operated by roaming consortiums.  Depending on the business model,
     a broker may either choose to deploy relay agents or proxy agents.

s/MAY/may

   Diameter Server

     A Diameter Server is one that handles authentication,
     authorization and accounting requests for a particular realm.  By
     its very nature, a Diameter Server MUST support Diameter server
     applications in addition to the base protocol.

s/MUST/must

  Diameter Client

     A Diameter Client is a device at the edge of the network that
     performs access control.  An example of a Diameter client is a
     Network Access Server (NAS) or a Foreign Agent (FA).  By its very
     nature, a Diameter Client MUST support Diameter client
     applications in addition to the base protocol.

s/MUST/must

  Local Realm

     A local realm is the administrative domain providing services to a
     user.  An administrative domain MAY act as a local realm for
     certain users, while being a home realm for others.

s/MAY/may

  Real-time Accounting

     Real-time accounting involves the processing of information on
     resource usage within a defined time window.  Time constraints are
     typically imposed in order to limit financial risk.

I would include a pointer to the DCCA spec here as it provides the 
real-time

accounting functionality.

   Session

     A session is a related progression of events devoted to a
     particular activity.  Each application SHOULD provide guidelines
     as to when a session begins and ends.  All Diameter packets with
     the same Session-Identifier are considered to be part of the same
     session.

s/Each application SHOULD provide guidelines
     as to when a session begins and ends.
/Diameter application documents provide guidelines as to when ...

   User

     The entity requesting or using some resource, in support of which
     a Diameter client has generated a request.

It might be worth noting that it does not necessary have to be a human.

Instead, the NAI refers to some entity and this document refers to it as

user.

2.  Protocol Overview

This section starts a bit strange. Here is my proposal on how to 
re-write it:

  The Diameter base protocol concerns itself with capabilities
  negotiation, how messages are sent and how peers may eventually be
  abandoned.  The base protocol also defines certain rules that apply
  to all exchanges of messages between Diameter nodes.

  Communication between Diameter peers begins with one peer sending a
  message to another Diameter peer.  The set of AVPs included in the
  message is determined by a particular Diameter application.  One AVP
  that is included to reference a user's session is the Session-Id.

  The initial request for authentication and/or authorization of a user
  would include the Session-Id.  The Session-Id is then used in all
  subsequent messages to identify the user's session (see Section 8 for
  more information).  The communicating party may accept the request,
  or reject it by returning an answer message with the Result-Code AVP
  set to indicate an error occurred.  The specific behavior of the
  Diameter server or client receiving a request depends on the Diameter
  application employed.

  Session state (associated with a Session-Id) MUST be freed upon
  receipt of the Session-Termination-Request, Session-Termination-
  Answer, expiration of authorized service time in the Session-Timeout
  AVP, and according to rules established in a particular Diameter
  application.

  The base Diameter protocol, which includes
  accounting functionality, may be used by itself to offer accounting
  functionality to applications, but for use in authentication 
and          

authorization always requires a particular application.

  Diameter Clients MUST support the base protocol. In addition, they MUST

fully support each Diameter
  application that is needed to implement the client's service, e.g.,
  NASREQ.  A Diameter Client that does not support
  both Application X and Application Y, MUST be referred to as "Diameter X
  Client" where X is the application which it supports, and not a
  "Diameter Client".

  Diameter Servers MUST support the base protocol. In addition, they MUST

fully support each Diameter
  application that is needed to implement the intended service, e.g.,
  NASREQ.  A Diameter Server that does not support
  both Application X and Application Y, MUST be referred to as "Diameter X
  Server" where X is the application which it supports, and not a
  "Diameter Server".

  Diameter Relays and redirect agents are, by definition, protocol
  transparent, and MUST support the Diameter base protocol.

  Diameter proxies MUST support the base protocol. In addition, they MUST

fully support each Diameter
  application that is needed to implement proxied services, e.g.,
  NASREQ.  A Diameter proxy which does not support
  also both Application X and Application Y, MUST be referred to as

"Diameter X
  Proxy" where X is the application which it supports, and not a
  "Diameter Proxy".

2.1.  Transport

s/   Transport profile is defined in [RFC3539]./The Diameter Transport

profile is defined in [RFC3539]./

s/The base Diameter protocol is run on port 3868 of both TCP [RFC793] and

SCTP [RFC2960] transport protocols./The base Diameter protocol is run on 
port

3868 of both TCP [RFC793] and SCTP [RFC2960].

Delete "Future versions of this specification MAY
  mandate that clients support SCTP."

I also do not understand why we require that agents and servers must 
support

SCTP. That does not sound realistic if I consider our interop testing

experience.

2.2.  Securing Diameter Messages

s/IPSec/IPsec

2.3.  Diameter Application Compliance

  For a given application, advertising support of
  an application implies that the sender supports all command codes,
  and the AVPs specified in the associated ABNFs, described in the
  specification.

I don't think that this is true. Whether a specific AVP has to be 
implemented

by either the sender is essentially up to the definition of the application

specification.

As such, I would rather say:

  For a given application, advertising support of
  an application implies that the sender supports the functionality

specified in the respective Diameter application specification.

2.4.  Application Identifiers

  The following Application Id values are defined:

        Diameter Common Messages      0
        NASREQ                        1 [RFC4005]
        Mobile-IP                     2 [RFC4004]
        Diameter Base Accounting      3
        Relay                         0xffffffff

I don't understand why the Diameter base protocol spec needs to list the

application Ids of NASREQ and Mobile-IP. I suggest to delete them in the

above table to something like this:

  The following Application Id values are defined in this document:

        Diameter Common Messages      0
        Diameter Base Accounting      3
        Relay                         0xffffffff

2.5.  Connections vs. Sessions

s/  A connection is a transport level connection between two peers, used
  to send and receive Diameter messages.
/
 A connection refers to a transport level connection between two peers 
that

is used to send and receive Diameter messages.

s/
A session is a logical
  concept at the application layer, and is shared between an access
  device and a server, and is identified via the Session-Id AVP.
/
A session is a logical
  concept at the application layer, it spawns from the Diameter client to

the Diameter server and is identified via the Session-Id AVP.

s/
 In the example provided in Figure 1, peer connection A is established
  between the Client and its local Relay.
/  In the example provided in Figure 1, peer connection A is established
  between the Client and the Relay.

2.7.  Routing Table

s/
     1.  LOCAL - Diameter messages that resolve to a route entry with
         the Local Action set to Local can be satisfied locally, and do
         not need to be routed to another server.
/
     1.  LOCAL - Diameter messages that can be satisfied locally, and do
         not need to be routed to another Diameter entity.

s/
     2.  RELAY - All Diameter messages that fall within this category
         MUST be routed to a next hop server, without modifying any
         non-routing AVPs.  See Section 6.1.9 for relaying guidelines
/

     2.  RELAY - All Diameter messages that fall within this category
         MUST be routed to a next hop Diameter entity that is indicated by

the identifier described below, without modifying any
         non-routing AVPs.  See Section 6.1.9 for relaying guidelines

s/

     3.  PROXY - All Diameter messages that fall within this category
         MUST be routed to a next hop server.  The local server MAY
         apply its local policies to the message by including new AVPs
         to the message prior to routing.  See Section 6.1.9 for
         proxying guidelines.

/

     3.  PROXY - All Diameter messages that fall within this category
         MUST be routed to a next Diameter entity that is indicated by the

identifier described below.  The local server MAY
         apply its local policies to the message by including new AVPs
         to the message prior to routing.  See Section 6.1.9 for
         proxying guidelines.

  Server Identifier

     One or more servers the message is to be routed to.  These servers
     MUST also be present in the Peer table.  When the Local Action is
     set to RELAY or PROXY, this field contains the identity of the
     server(s) the message must be routed to.  When the Local Action
     field is set to REDIRECT, this field contains the identity of one
     or more servers the message should be redirected to.

Shouldn't it say ".. the message MUST be routed to."

and why is there a should and not a MUST in the last sentence?

s/
Relay agents MUST NOT reorder
  AVPs, and proxies MUST NOT reorder AVPs.
/
Relay agents and proxies MUST NOT reorder
  AVPs.

2.8.  Role of Diameter Agents

s/
 Maintaining session state MAY be useful in certain applications, such
  as:
/
 Maintaining session state may be useful in certain applications, such
  as:

2.8.1.  Relay Agents

s/
  Relays MAY be used to aggregate requests from multiple Network Access
  Servers (NASes) within a common geographical area (POP).
/
  Relays may, for example, be used to aggregate requests from multiple

Network Access Servers (NASes) within a common geographical area (POP).

I think we can delete this sentence since it essentially reflects the

definition of a relay:

  Relays SHOULD NOT maintain session state but MUST maintain
  transaction state.

2.8.2.  Proxy Agents

s/
 Proxies MAY be used in call control centers or access ISPs that
  provide outsourced connections, they can monitor the number and types
  of ports in use, and make allocation and admission decisions
  according to their configuration.
/
 Proxies may, for example, be used in call control centers or access ISPs

that
  provide outsourced connections, they can monitor the number and types
  of ports in use, and make allocation and admission decisions
  according to their configuration.

  Proxies that wish to limit resources MUST maintain session state.
  All proxies MUST maintain transaction state.

I don't really understand what the first sentence should tell us and the 
2nd

one is essentially already described with the definition of the proxy.

2.8.3.  Redirect Agents

s/
Since redirect
  agents do not receive answer messages, they cannot maintain session
  state.  Further, since redirect agents never relay requests, they are
  not required to maintain transaction state.
/

Since redirect
  agents do not receive answer messages, they cannot maintain session
  and transaction state.

3.2.  Command Code ABNF specification

s/
  Every Command Code defined MUST include a corresponding ABNF
  specification, which is used to define the AVPs that MUST or MAY be
  present.
/
  Every Command Code defined MUST include a corresponding ABNF
  specification, which is used to define the AVPs that MUST or MAY be
  present when sending the message.

3.3.  Diameter Command Naming Conventions

 o  An additional request MUST be sent to provide information the peer
     requires prior to returning a successful or failed answer.

s/MUST/has to be

  Additional information, encoded within AVPs, MAY also be included in
  answer messages.

s/MAY/may

  Some AVPs MAY be listed more than once.  The effect of such an AVP is
  specific, and is specified in each case by the AVP description.

There is something wrong with this sentence.

4.1.  AVP Header

  AVP Flags

     The 'P' bit indicates the need for
     encryption for end-to-end security.  Note that the 'P' bit has
     been deprecated and MUST be to zero(0) when sending an AVP and
     ingnored on receipt of an AVP.

Instead of the above, I think it should say:

The 'P' bit has been reserved for future usage of end-to-end security.
At the time of writing there are no end-to-end security mechanisms 
specified.

     The 'M' Bit, known as the Mandatory bit, indicates whether support
     of the AVP is required.  If an AVP with the 'M' bit set is
     received by a Diameter client, server or translation agent and
     either the AVP or its value is unrecognized, the message MUST be
     rejected.

We changed this already. New text proposal:

     The 'M' Bit, known as the Mandatory bit, indicates whether
     the receiver of the AVP MUST understand the received AVP and the
     content of the AVP. When the receiving entity MUST return an       

appropriate error message if it receives an AVP that has the M-bit
     set but does not understand it.

  AVP Length

If a message is
     received with an invalid attribute length, the message SHOULD be
     rejected.

Why is this only a SHOULD level recommendation? What should the receiver do

otherwise?

4.1.1.  Optional Header Elements

  Vendor-ID

Any vendor
     wishing to implement a vendor-specific Diameter AVP MUST use their
     own Vendor-ID along with their privately managed AVP address
     space, guaranteeing that they will not collide with any other
     vendor's vendor-specific AVP(s), nor with future IETF
     applications.

s/Any vendor .../Any vendor or standardization organization that are also

treated like vendors in the IANA managed"SMI Network Management Private

Enterprise Codes" space ...

s/nor with future IETF applications./nor with future IETF AVPs.

4.3.  Derived AVP Data Formats

  In addition to using the Basic AVP Data Formats, applications may
  define data formats derived from the Basic AVP Data Formats.  An
  application that defines new AVP Derived Data Formats MUST include
  them in a section entitled "AVP Derived Data Formats", using the same
  format as the definitions below.  Each new definition MUST be either
  defined or listed with a reference to the RFC that defines the
  format.

This is sort of interesting, particularly when you look at the 
IPFilterRule,

as the boundary between Derived AVP Data Formats and AVP definitions is 
sort

of fuzzy.

Does any other Diameter document ever tried to define new derived Data

Formats?

  Time

     The Time format is derived from the OctetString AVP Base Format.
     The string MUST contain four octets, in the same format as the
     first four bytes are in the NTP timestamp format.  The NTP
     Timestamp format is defined in chapter 3 of [RFC4330].

s/chapter/Chapter

     This represents the number of seconds since 0h on 1 January 1900
     with respect to the Coordinated Universal Time (UTC).

     On 6h 28m 16s UTC, 7 February 2036 the time value will overflow.
     SNTP [RFC4330] describes a procedure to extend the time to 2104.
     This procedure MUST be supported by all DIAMETER nodes.

s/DIAMETER/Diameter

4.4.   Grouped AVP Values

  However, the encapsulated AVPs with 'M' (mandatory) bit set MUST
  belong to the Diameter application the Grouped APV is used in.

I don't quite understand that sentence. Could you explain it a bit?

5.1.  Peer Connections

Delete the following paragraph since it does not say anything

  In
  order to promote interoperable implementations of Diameter peer
  discovery, the following mechanisms are described.  These are based
  on existing IETF standards.

  The first option (manual configuration)
  MUST be supported by all DIAMETER nodes, while the latter option
  (DNS) MAY be supported.

s/DIAMETER/Diameter

5.2.  Diameter Peer Discovery

s/
         We also establish an IANA
         registry for NAPTR service name to transport protocol
         mappings.
/
         An IANA
         registry for NAPTR service name to transport protocol
         mappings is defined in Section 11.6.

3.  If no NAPTR records are found, the requester queries for those
      address records for the destination address,
      '_diameter._sctp'.realm or '_diameter._tcp'.realm.

Why is it necessary to specify two mechanisms to query the DNS?

I will distribute a separate mail about the domain certificate stuff.

5.3.5.  Host-IP-Address AVP

  The Host-IP-Address AVP (AVP Code 257) is of type Address and is used
  to inform a Diameter peer of the sender's IP address.  All source
  addresses that a Diameter node expects to use with SCTP [RFC2960]
  MUST be advertised in the CER and CEA messages by including a
  Host-IP- Address AVP for each address.  This AVP MUST ONLY be used in
  the CER and CEA messages.

s/Host-IP- Address/Host-IP-Address

I wonder why there is the last sentence in there? It is fine to use the AVP

in the CER and CEA message but why is there a need to say that it must only

be used there? That does not make a lot of sense.

5.3.6.  Supported-Vendor-Id AVP

  Multiple instances of this AVP containing the same value SHOULD NOT
  be sent.

Why not MUST NOT be sent?

I was also wondering why only a selection of AVPs is listed in Section 5.3

instead of all of them? Any special reason?

5.5.4.  Failover and Failback Procedures

Shouldn't it actually read "Fallback" instead of failback?

6.1.  Diameter Request Routing Overview

I would change text a bit by modifying this paragraph:

  o  a request that needs to be sent to a home server serving a
     specific realm, but not to a specific server (such as the first
     request of a series of round-trips), MUST contain a Destination-
     Realm AVP, but MUST NOT contain a Destination-Host AVP. For
     Diameter clients, the value of the Destination-Realm AVP MAY be
     extracted from the User-Name AVP, or other methods.

and by deleting this paragraph:

  The Destination-Realm AVP MUST be present if the message is
  proxiable.  A message that MUST NOT be forwarded by Diameter agents
  (proxies, redirects or relays) MUST NOT include the Destination-Realm
  in its ABNF.  For Diameter clients, the value of the Destination-
  Realm AVP MAY be extracted from the User-Name AVP, or other
  application-specific methods.

6.1.2.  Sending a Request

  When sending a request, originated either locally, or as the result
  of a forwarding or routing operation, the following procedures MUST
  be followed:

  o  the Hop-by-Hop Identifier should be set to a locally unique value.

s/should/SHOULD

  o  The message should be saved in the list of pending requests.

s/should/SHOULD

Given that the introductory sentence says "MUST be followed" I was 
wondering

whether SHOULD is actually too weak here.

6.1.6.  Request Routing

  Diameter request message routing is done via realms and applications.
  A Diameter message that may be forwarded by Diameter agents (proxies,
  redirects or relays) MUST include the target realm in the
  Destination-Realm AVP.

s/applications/application identifiers
s/redirects/redirect agents

 Realm names and Application Ids are the minimum supported routing
  criteria, additional routing information maybe needed to support
  redirect semantics.

s/routing information/information
s/maybe/may be

6.1.8.  Redirecting requests

s/Redirecting requests/ Redirecting Requests

In such a case, a routing precedence
  rule MUST be used againt the redirect usage value to resolve the
  contention.

s/againt/against

6.1.9.  Relaying and Proxying Requests

Proxy-Info AVP has certain
  security implications and SHOULD contain an embedded HMAC with a
  node-local key.

I suspect that you mean protecting the content in similar fashion as it is

done with a cookie.

Maybe something like

"
The Proxy-Info AVP has security implications as state information is

distribute to other entities. As such, it is RECOMMMENDED to protect the

content of the Proxy-Info AVP with cryptographic mechanisms, for example by

using a keyed message digest. Such a mechanism, however, requires the

management of keys, although only locally at the Diameter server. Still, a

full description of the management of the keys used to protect the
  Proxy-Info AVP is beyond the scope of this document. Below is a list of

commonly recommended:
  o  The keys should be generated securely following the randomness
     recommendations in [RFC4086].
  o  The keys and cryptographic protection algorithms should be at
     least 128 bits in strength.
  o  The keys should not be used for any other purpose than generating
     and verifying tickets.
  o  The keys should be changed regularly.
  o  The keys should be changed if the ticket format or cryptographic
     protection algorithms change.
"

would be more appropriate.

6.1.9.  Relaying and Proxying Requests

 Relay and proxy agents are not required to perform full validation of
  incoming messages.

s/validation/inspection

6.2.2.  Relaying and Proxying Answers

If the agent receives an answer
  message with a Result-Code AVP indicating success, and it wishes to
  modify the AVP to indicate an error, it MUST modify the Result-Code
  AVP to contain the appropriate error in the message destined towards
  the access device as well as include the Error-Reporting-Host AVP and
  it MUST issue an STR on behalf of the access device.

extend the sentence by saying ".. towards the Diameter server."

6.7.2.  Proxy-Info AVP

The description for the AVP does not describe the semantic.

6.7.4.  Proxy-State AVP

s/

  The Proxy-State AVP (AVP Code 33) is of type OctetString, and
  contains state local information, and MUST be treated as opaque data.

/

  The Proxy-State AVP (AVP Code 33) is of type OctetString, and
  is created by the Diameter server and passed on to the Diameter 
client. It contains state information that would otherwise be stored at 
the Diameter.
  As such, this AVP MUST be treated as opaque data by entities other 
than the Diameter server that created it.

6.8.  Auth-Application-Id AVP

  The Auth-Application-Id AVP (AVP Code 258) is of type Unsigned32 and
  is used in order to advertise support of the Authentication and
  Authorization portion of an application (see Section 2.4).  If
  present in a message other than CER and CEA, the value of the Auth-
  Application-Id AVP MUST match the Application Id present in the
  Diameter message header.

If it always matches then does it make a lot of sense?

6.10.  Inband-Security-Id AVP

  The Inband-Security-Id AVP (AVP Code 299) is of type Unsigned32 and
  is used in order to advertise support of the Security portion of the
  application.

s/Security/security

6.11.  Vendor-Specific-Application-Id AVP

  The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type
  Grouped and is used to advertise support of a vendor-specific
  Diameter Application.  Exactly one instance of either Auth-
  Application-Id or Acct-Application-Id AVP MUST be present.

We should say where it must be present.

  The
  Application Id carried by either Auth-Application-Id or Acct-
  Application-Id AVP MUST comply with vendor specific Application Id
  assignment described in Sec 11.3.  It MUST also match the Application
  Id present in the diameter header except when used in a CER or CEA
  messages.

s/diameter/Diameter

  This AVP MUST also be present as the first AVP in all experimental
  commands defined in the vendor-specific application.

  This AVP SHOULD be placed as close to the Diameter header as
  possible.

"This" in the above two sentences refers to the 
Vendor-Specific-Application-Id AVP. Right?

 If a Vendor-Specific-Application-Id is received that contains both
  Auth-Application-Id and Acct-Application-Id, then the recipient
  SHOULD issue an answer with Result-Code set to
  DIAMETER_AVP_OCCURS_TOO_MANY_TIMES.  The answer SHOULD also include a
  Failed-AVP which MUST contain the received Auth-Application-Id AVP
  and Acct-Application-Id AVP.

Why are these only SHOULD level requirements? What happens in the other 
cases?

6.13.  Redirect-Host-Usage AVP

  When present, this AVP dictates how the routing entry resulting from
  the Redirect-Host is to be used.  The following values are supported:

s/dictates/provides a hint about

Dictate is really not the right term given that everything below is fluffy.
Another term that would come to my mind is "provides a suggestion about"

  DONT_CACHE 0

     The host specified in the Redirect-Host AVP should not be cached.
     This is the default value.

s/should not/SHOULD NOT??

  ALL_SESSION 1

     All messages within the same session, as defined by the same value
     of the Session-ID AVP MAY be sent to the host specified in the
     Redirect-Host AVP.

s/MAY/SHOULD

  ALL_REALM 2

     All messages destined for the realm requested MAY be sent to the
     host specified in the Redirect-Host AVP.

s/MAY/SHOULD

  REALM_AND_APPLICATION 3

     All messages for the application requested to the realm specified
     MAY be sent to the host specified in the Redirect-Host AVP.

s/MAY/SHOULD

  ALL_APPLICATION 4

     All messages for the application requested MAY be sent to the host
     specified in the Redirect-Host AVP.

s/MAY/SHOULD

  ALL_HOST 5

     All messages that would be sent to the host that generated the
     Redirect-Host MAY be sent to the host specified in the Redirect-
     Host AVP.

s/MAY/SHOULD

  ALL_USER 6

     All messages for the user requested MAY be sent to the host
     specified in the Redirect-Host AVP.

s/MAY/SHOULD

6.14.  Redirect-Max-Cache-Time AVP

  This AVP contains the maximum number of seconds the peer and route
  table entries, created as a result of the Redirect-Host, will be
  cached.  Note that once a host created due to a redirect indication
  is no longer reachable, any associated peer and routing table entries
  MUST be deleted.

"will be cached" does not provide a good indication how the value provided
by this AVP should actually be treated. Is this
* MUST be cached
* SHOULD cached
* MAY be cached

I think that the semantic is a bit weak. What can the sender really expect
when it provides a value with AVP to the receiver?

7.  Error Handling

Application errors, on the other hand, generally
  occur due to a problem with a function specified in a Diameter
  application (e.g., user authentication, Missing AVP).

s/Missing AVP/missing AVP

  o  A command is received with an AVP that is omitted, yet is
     mandatory according to the command's ABNF.

s/mandatory/required

7.1.  Result-Code AVP

  The Result-Code AVP (AVP Code 268) is of type Unsigned32 and
  indicates whether a particular request was completed successfully or
  whether an error occurred.  All Diameter answer messages defined in
  IETF applications MUST include one Result-Code AVP.

s/IETF applications/IETF defined Diameter application specifications

7.1.2.  Success

  DIAMETER_SUCCESS 2001

     The Request was successfully completed.

s/Request/request

7.1.3.  Protocol Errors

s/
To provide backward
  compatibility with existing implementations that follow [RFC3588],
  some of the error values that have previously been used in this
  category by [RFC3588] will not be re-used.  Therefore the error
  values enumerated here may be non-sequential.
/
This document omits some error codes defined in RFC 3588 [RFC3588].
To provide backward compatibility with RFC 3588 implementations
these error code values are not re-used and hence the error codes
values enumerated below are non-sequential.

  DIAMETER_REDIRECT_INDICATION 3006

     A redirect agent has determined that the request could not be
     satisfied locally and the initiator of the request should direct
     the request directly to the server, whose contact information has
     been added to the response.  When set, the Redirect-Host AVP MUST
     be present.

s/should/SHOULD

  DIAMETER_NO_COMMON_APPLICATION 5010

     This error is returned by a Diameter node that is not acting as a
     relay when it receives a CER which advertises a set of
     applications that it does not support.

Why not saying something like:

"
     This error is returned by a Diameter node that receives a CER
     whereby no applications are common between the CER sending peer
     and the CER receiving peer.

  DIAMETER_INVALID_AVP_LENGTH 5014

     The request contained an AVP with an invalid length.  A Diameter
     message indicating this error MUST include the offending AVPs
     within a Failed-AVP AVP.  In cases where the erroneous avp length
     value exceeds the message length or is less than the minimum AVP
     header length, it is sufficient to include the offending AVP
     header and a zero filled payload of the minimum required length
     for the payloads data type.  If the AVP is a grouped AVP, the
     grouped AVP header with an empty payload would be sufficient to
     indicate the offending AVP.  In the case where the offending AVP
     header cannot be fully decoded when avp length is less than the
     minimum AVP header length, it is sufficient to include an
     offending AVP header that is formulated by padding the incomplete
     AVP header with zero up to the minimum AVP header length.

s/avp/AVP

s/when avp length/when the AVP length

  DIAMETER_COMMAND_UNSUPPORTED 5019

     The Request contained a Command-Code that the receiver did not
     recognize or support.  This MUST be used when a Diameter node
     receives an experimental command that it does not understand.

What about:
"
This error code is used when a Diameter entity receives a message
with a Command Code that it does not support.
"

7.3.  Error-Message AVP

s/
  The Error-Message AVP (AVP Code 281) is of type UTF8String.  It MAY
  accompany a Result-Code AVP as a human readable error message.  The
  Error-Message AVP is not intended to be useful in real-time, and
  SHOULD NOT be expected to be parsed by network entities.
/
.. to be useful in an environment where error messages are processed 
automatically.
It SHOULD NOT be expected that the content of this AVP is parsed by 
network entities.

7.6.  Experimental-Result AVP

  The Experimental-Result AVP (AVP Code 297) is of type Grouped, and
  indicates whether a particular vendor-specific request was completed
  successfully or whether an error occurred.  Its Data field has the
  following ABNF grammar:

s/
Its Data field has the
  following ABNF grammar:
/
This AVP has the following structure:

8.  Diameter User Sessions

However, the base
  protocol does define a set of messages that is used to terminate user
  sessions.  These are used to allow servers that maintain state
  information to free resources.

s/is used/are used

  Diameter may also be used for services that cannot be easily
  categorized as authentication, authorization or accounting (e.g.,
  certain 3GPP IMS interfaces).  In such cases, the finite state
  machine defined in subsequent sections may not be applicable.
  Therefore, the applications itself MAY need to define its own finite
  state machine.  However, such application specific state machines
  MUST comply with general Diameter user session requirements such co-
  relating all message exchanges via Session-Id AVP.

What specifically is meant by saying that such applications must comply 
with the
general Diameter user session requirements?

8.2.  Accounting Session State Machine

s/
  Implementations of Diameter MAY perform checking, ordering,
  correlation, fraud detection, and other tasks based on these records.
  Both base Diameter AVPs as well as application specific AVPs MAY be
  inspected as a part of these tasks.
/
  Implementations of Diameter may perform checking, ordering,
  correlation, fraud detection, and other tasks based on these records.
  AVPs may need to be inspected as a part of these tasks.

8.4.1.  Session-Termination-Request

  The Session-Termination-Request (STR), indicated by the Command-Code
  set to 275 and the Command Flags' 'R' bit set, is sent by the access
  device to inform the Diameter Server that an authenticated and/or
  authorized session is being terminated.

s/access device/the Diameter client or by a Diameter proxy

8.5.  Aborting a Session

s/
  For example, the Diameter server that originally authorized the
  session may be required to cause that session to be stopped for
  credit or other reasons that were not anticipated when the session
  was first authorized.  On the other hand, an operator may maintain a
  management server for the purpose of issuing ASRs to administratively
  remove users from the network.
/
  For example, the Diameter server that originally authorized the
  session may be required to cause that session to be stopped for
  lack of credit or other reasons that were not anticipated when the 
session
  was first authorized.

I would delete the following paragraph:

"
  Note that if the access device does stop the session upon receipt of
  an ASR, it issues an STR to the authorizing server (which may or may
  not be the agent issuing the ASR) just as it would if the session
  were terminated for any other reason.

"

8.5.1.  Abort-Session-Request

  The Abort-Session-Request (ASR), indicated by the Command-Code set to
  274 and the message flags' 'R' bit set, may be sent by any server to
  the access device that is providing session service, to request that
  the session identified by the Session-Id be stopped.

The text talks about "any server". I guess it is more saying "Diameter 
server or
Diameter proxy"

8.6.  Inferring Session Termination from Origin-State-Id

this section is a bit confusing as it talks about CER/CEA and the 
hop-by-hop processing
but then refers to end-to-end processing as well.

8.7.  Auth-Request-Type AVP

  The Auth-Request-Type AVP (AVP Code 274) is of type Enumerated and is
  included in application-specific auth requests to inform the peers
  whether a user is to be authenticated only, authorized only or both.
  Note any value other than both MAY cause RADIUS interoperability
  issues.

What are the RADIUS interoperability issues?

8.8.  Session-Id AVP

     accesspoint7.acme.com;1876543210;523

  Example, in which there is an optional value:

    accesspoint7.acme.com;1876543210;523;[email-masked]

I believe examples now have to use something like "example.com" rather 
than the above.

  The Session-Id is created by the Diameter application initiating the
  session, which in most cases is done by the client.  Note that a
  Session-Id MAY be used for both the authorization and accounting
  commands of a given application.

Shouldn't it say ... be used for the authentication, authorization and 
accounting
commands of a given app.

8.9.  Authorization-Lifetime AVP

This is typically used in cases where multiple
  authentication methods are used, and a successful auth response with
  this AVP set to zero is used to signal that the next authentication
  method is to be immediately initiated.

Where is this used?

  This AVP MAY be provided by the client as a hint of the maximum
  lifetime that it is willing to accept.  However, the server MAY
  return a value that is equal to, or smaller, than the one provided by
  the client.

There are many MAYs in there. Does it mean that a value that is larger 
can also be provided by the server?
If not, then shouldn't the second sentence say MUST?

8.17.  Session-Binding AVP

s/
  The Session-Binding AVP (AVP Code 270) is of type Unsigned32, and MAY
  be present in application-specific authorization answer messages.  If
  present, this AVP MAY inform the Diameter client that all future
  application-specific re-auth messages for this session MUST be sent
  to the same authorization server.  This AVP MAY also specify that a
  Session-Termination-Request message for this session MUST be sent to
  the same authorizing server.
/
  The Session-Binding AVP (AVP Code 270) is of type Unsigned32, and MAY
  be present in application-specific authorization answer messages.  If
  present, this AVP MAY inform the Diameter client that all future
  application-specific re-auth and
  Session-Termination-Request messages
for this session MUST be sent
  to the same authorization server.

--- stop here ----
more later.

Ciao
Hannes

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 24 Sep 2008 10:24:03 -0400

Hi Hannes,

I apologize for the really late response. I'm running out of cycles 
lately but I'll try to work on this review as soon as I can.

regards,
victor