Subject: [Dime] Review of draft-ietf-dime-rfc3588bis-17

From: Mark Jones <[email-masked]>
Date: Tue, 30 Jun 2009 17:26:07 -0400

Here are my review comments for rfc3588bis-17. All are editorial.

Regards
Mark

---

Section 1.3.1:

	Typo: s/where as/whereas/

Section 1.3.4:

Rewording suggestion:
		has to be understood mandatorily or not
To:
		must be understood or not

Remove 2nd paragraph under "M-bit Setting" because MAY column has been removed.
	
Section 2:

Rewording suggestion:
   A Diameter Client that does not support
   both NASREQ and Mobile IPv4, MUST be referred to as "Diameter X
   Client" where X is the application which it supports, and not a
   "Diameter Client".
To:
   A Diameter Client that supports a specific application X MUST be referred to as
   "Diameter X Client" and not a "Diameter Client".

Rewording suggestion:
   A Diameter Server that does not support
   both NASREQ and Mobile IPv4, MUST be referred to as "Diameter X
   Server" where X is the application which it supports, and not a
   "Diameter Server".
To:
   A Diameter Server that supports a specific application X MUST be referred to as 
   "Diameter X Server" and not a "Diameter Server".

Rewording suggestion:
   A Diameter proxy which does not support
   both NASREQ and Mobile IPv4, MUST be referred to as "Diameter X
   Proxy" where X is the application which it supports, and not a
   "Diameter Proxy".
To:
   A Diameter Proxy that supports a specific application X MUST be referred to as 
   "Diameter X Proxy" and not a "Diameter Proxy".

Section 2.6:

Missing period on last sentence in this section.

Section 2.7:

The last paragraph incorrectly implies that a proxy agent is somehow different when it comes to advertising supported applications. Only a relay does not have to advertise the supported application ids because it supports everything.

Section 2.8:

Typo:  s/an number/a number/

Rewording suggestion:
   o  A complex network will have multiple authentication sources, they
      can sort requests and forward towards the correct target.
To:
   o  For a complex network having multiple authentication sources, they
      can sort requests and forward towards the correct target.

Section 2.8.1:

Rewording Suggestion:
   common geographical area (POP)
To:
   common geographical area or point of presence (POP)

Rewording suggestion:
	NASes
To:
	NAS

Section 4.1:

Suggestion: Remove mention of the 'P' bit in the AVP header. Make it reserved.

Section 4.5:

No need to use DiamIdent in the AVP table since space constraint no longer exists.

I think the M-bit must be set for Error-Reporting-Host AVP but I guess this causes backwards compatibility issues.

Section 7.2:

Remove "Message Format" below first paragraph.

Section 8.2:

Clarify that "state" here is session state, i.e. 

   Class AVPs found in a re-authorization answer message override the ones
   found in any previous authorization answer message for the same session.