Subject: [Dime] Review of draft-ietf-dime-rfc3588bis-09.txt

From: "Mark Jones" <[email-masked]>
Date: Tue, 18 Dec 2007 17:07:33 -0500

Here are my comments on the 3588bis-09 draft. They are largely editorial
and I found no showstoppers.

---

1.1.  Diameter Protocol

     "Extensibility, through addition of new commands and AVPs (required
      in [RFC2989])."

Extensibility is also achieved through addition of new applications.

1.1.1.  Description of the Document Set

Suggest replacing "Currently" with "At the time of publication/writing".

This section contains the list of IETF applications. Should we mention
that Diameter allows vendor-specific applications and refer to IANA for
the list of those?

This section also refers to more recent applications like Credit
Control, EAP and SIP but they are not mentioned in other sections which
refer only to NASREQ/MIPv4, e.g. the list of Application Identifiers in
section 2.4. 

1.2.2.   Creating New AVPs

   "If an appropriate derived data type is already defined,
    it MAY be used instead of the base data type."

Suggest strengthening the MAY to a SHOULD to encourage derived data type
reuse.

1.2.3.   Creating New Commands

Typo (probably mine): defintion -> definition

1.2.4.   Creating New Authentication Applications

  "An implementation MAY add arbitrary non-mandatory AVPs to any command
   defined in an application, including vendor-specific AVPs without
   needing to define a new application."

An implementation can add non-mandatory AVPs only if allowed by the
command ABNF, i.e. it has the "* [ AVP ]" element.

2.3.  Diameter Application Compliance

   "An implementation MAY add arbitrary non-mandatory AVPs to any
command
   defined in an application, including vendor-specific AVPs."

Same comment as above for 1.2.4. 

2.9.  Diameter Path Authorization

  " Diameter sessions
   MUST be routed only through authorized nodes that have advertised
   support for the Diameter application required by the session."

Or advertised support for the Relay application.

3.3.  Diameter Command Naming Conventions

   "Once
   the receiver has completed the request it issues the corresponding
   answer, which includes a result code that communicates one of the
   following:"

Suggest "corresponding answer with the R-bit cleared,..."

6.1.8.  Redirecting requests

Typo in 5th paragraph: againts -> against

6.3.  Origin-Host AVP

Typo in 4th paragraph: remove "6.10"

6.8.  Auth-Application-Id AVP

Typo: diameter -> Diameter

6.9.  Acct-Application-Id AVP

Typo: diameter -> Diameter

7.1.3.  Protocol Errors

Typo: maybe -> may be

8.  Diameter User Sessions

Typo in 7th paragraph: statemachines -> state machines

8.8.  Session-Id AVP

   "At startup, the high 32 bits of the 64-bit value MAY be
   initialized to the time"

Suggest adding "in NTP timestamp format [RFC4330]"

8.13.  Session-Timeout AVP

Incorrect xref in 2nd paragraph: Section 8.9 -> Section 8.11

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

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 19 Dec 2007 09:17:22 -0500

Hi Mark,

> Extensibility is also achieved through addition of new applications.

Sure.

> that Diameter allows vendor-specific applications and refer to IANA for

Maybe not in this section since its only a "document set". Though, I 
agree we have to do some cleanup on this section.

> Suggest strengthening the MAY to a SHOULD to encourage derived data type

Moving to "SHOULD" implies that we have to justify why it is a SHOULD. 
We can add that good design practice is a good enough reason for it to 
be a SHOULD.

> command ABNF, i.e. it has the "* [ AVP ]" element.

Good catch.

> Or advertised support for the Relay application.

by definition, relays already advertises support for all applications. 
so it maybe a bit redundant.

> Typo in 7th paragraph: statemachines -> state machines

Above editorials are ok.

> Suggest adding "in NTP timestamp format [RFC4330]"

Good point. The current text actually suggests it but not in a clear 
fashion.

> Incorrect xref in 2nd paragraph: Section 8.9 -> Section 8.11

Ok.

Thanks again,
victor