Subject: [AAA-WG]: [Issue] Various editorial changes

From: Jacques Caron <[email-masked]>
Date: Mon, 11 Jun 2001 00:54:33 +0200

Submitter name: Jacques Caron
Submitter email address: [email-masked]
Date first submitted: 11-Jun-2001
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg01150.html
Document: Base
Comment type: E
Priority: 2
Section: throughout
Rationale/Explanation of issue:

In 4.1 AVP Header:
- still mentions both 'r' and reserved bits
- says that unrecognized bits should be considered an error, but also that
r/reserved bits should be ignored.

In 4.3 AVP Data formats, max length of an OctetString is still 65504 (btw, 
why was it 65504 and not 2^16-20=65516?)

In 5.1 Processing Local Messages, "the local host's identity is encoded in 
the Origin-Host and Origin-Host AVPs" (double Origin-Host)

In 5.3 Message Routing, Diameter agents *MAY* have a list of locally 
supported realms...

In 6.0, 6.1, minor editing.

In 7.2, remove unused RTO stuff.

Requested changes:

In 4.1, replace:
    AVP Flags
       The AVP Flags field informs the receiver how each attribute must
       be handled. Note that subsequent Diameter applications MAY define
       bits to be used within the AVP Header, and an unrecognized bit
       should be considered an error. The 'r' and the reserved bits are
       unused and should be set to 0 and ignored on receipt, while the
       'P' bit is defined in [11].

With:
    AVP Flags
       The AVP Flags field informs the receiver how each attribute must
       be handled. The 'r' (reserved) bits are unused and SHOULD be set
       to 0. Note that subsequent Diameter applications MAY define
       additional bits within the AVP Header, and an unrecognized bit
       SHOULD be considered an error. The 'P' bit is defined in [11].

In 4.3, replace:
       OctetString
          The data contains arbitrary data of variable length. Unless
          otherwise noted, the AVP Length field MUST be set to at least 8
          (12 if the 'V' bit is enabled).  Data used to transmit (human
          readable) character string data uses the UTF-8 [24] character
          set and is NOT NULL-terminated. The minimum Length field MUST
          be 9, but can be set to any value up to 65504 bytes. AVP Values
          of this type that do not align on a 32-bit boundary MUST have
          the necessary padding.

With:
       OctetString
          The data contains arbitrary data of variable length. Unless
          otherwise noted, the AVP Length field MUST be set to at least 8
          (12 if the 'V' bit is enabled).  Data used to transmit (human
          readable) character string data uses the UTF-8 [24] character
          set and is NOT NULL-terminated. The minimum Length field MUST
          be 9, but can be set to any value up to 2^24-20=16777196 bytes.
          AVP Values of this type that do not align on a 32-bit boundary
          MUST have the necessary padding.

In 5.1, replace:
       - The local host's identity is encoded in the Origin-Host and
         Origin-Host AVPs.

With:
       - The local host's identity is encoded in the Origin-Host AVPs.

In 5.3, replace:
    Diameter agents have a list of locally supported realms, and MAY have
    a list of externally supported realms. When a request is received
    that includes a realm that is not locally supported, the message is
    routed to the peer configured in the Domain Routing Table table (see
    section 5.3.1).

With:
    Diameter agents MAY have a list of locally supported realms, and MAY
    have a list of externally supported realms. When a request is
    received that includes a realm that is not locally supported, the
    message is routed to the peer configured in the Domain Routing Table
    table (see section 5.3.1).

In 6.0 Capabilities Exchange, replace:
    When two Diameter peers establish a transport connection, they MUST
    exchange the Device Reboot messages, as specified in the peer state
    machine (see section 8.0). This message has two purposes. First it
    allows a peer's identity to be discovered, and allows for
    capabilities exchange, such as the supported protocol version number,
    the locally supported Diameter applications, etc.

With:
    When two Diameter peers establish a transport connection, they MUST
    exchange the Capabilities Exchange messages, as specified in the peer
    state machine (see section 8.0). This message allows the discovery of
    both the peer's identity, and its capabilities, such as the supported
    protocol version number, the locally supported Diameter applications,
    etc.

In 6.1 Application Identifiers, replace:
    Relay and redirect agents MUST advertise the Proxy application
    identifier, while all other Diameter nodes MUST advertise locally
    supported applications. The receiver of a Device Reboot message
    advertising Relay service MUST assume that the sender supports all
    current and future applications.

with:
    Relay and redirect agents MUST advertise the Relay application
    identifier, while all other Diameter nodes MUST advertise locally
    supported applications. The receiver of a Capabilities Exchange
    message advertising Relay service MUST assume that the sender
    supports all current and future applications.

In 7.2 Device-Watchdog-Answer, remove:
    A receiver of the DWA SHOULD
    perform RTT calculation in the event that the transport RTO
    information is not available.

Jacques.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 11 Jun 2001 09:45:01 -0700

First, thanks for taking the time to read the base protocol in the level of detail
that is necessary to catch these bugs.

Please see my comments below.

>           MUST have the necessary padding.

Actually a previous fix for the subtypes eliminated the maximum length
in the OctetString (not sure why). So we still want to state the obvious?

>     protocol version number, the locally supported Diameter applications,

I've come up with the following (which I think reads a little better):

"When two Diameter peers establish a transport connection, they MUST 
exchange the Capabilities Exchange messages, as specified in the peer 
state machine (see section 8.0). This message allows the discovery of 
a peer's identity and its capabilities (protocol version number, supported
Diameter applications, etc.)"

Thanks again,

PatC