Subject: [AAA-WG]: Issue 100: Editorial comments on base-07

From: Jacques Caron <[email-masked]>
Date: Thu, 26 Jul 2001 19:27:07 +0200

Submitter name:		Jacques Caron
Submitter email address:	[email-masked]
Date first submitted:		July 25, 2001
Reference:
Document:			Base-07
Comment type:			E
Priority:			1
Section:			throughout
Rationale/Explanation of issue:

In 3.0
- Commands flags, r(eserved): should state that an error must be generated 
if a packet is received with such a bit set to one.

In 3.3:
- 1st paragraph: "Diameter commands typically start with an object name". 
Not that sure :-)
- 2nd paragraph: "The corresponding answer MUST contain either a positive 
or negative result code". What about multi-round trip messages, and redirects?

In 4.0:
- 1st paragraph: "Diameter AVPs carry specific authentication, accounting 
and authorization information, security information as well as 
configuration details..." They can also carry routing information (unless 
that's what is meant by "configuration details".

In 4.1:
- AVP Code: "The first 256 AVP numbers are reserved for backward 
compatibility with RADIUS". Even if Vendor-Id is non-zero?
- AVP Flags, "Note that subsequent Diameter applications MAY define 
additional bits within the AVP Header, and an unrecognized bit SHOULD be 
considered an error". Didn't find an error number for that one in 7.1.x.
- AVP Flags, 2nd paragraph, "If an unrecognized AVP with the 'M' bit set is 
received by a Diameter node..." replace node with "client, server or 
proxy". The client thing raises the issue stated in the 7.1.4/7.1.5 section 
about errors in answers, though. Also, it should not be only if the AVP is 
unrecognized, but also if the requested AVP or value is recognized, but the 
node does not accept it.
- AVP Flags, 3rd paragraph, "In order to provide service to the user, the 
node at fault MUST re-issue...". The client might decide that if the server 
doesn't understand that AVP, it doesn't want to provide service to the 
user. Make that explicit rather than implicit.
- AVP Flags, 4th paragraph, add a comma between "ABNF" and "is at fault".
- AVP Flags, 5th paragraph, "AVPs with the 'M' bit cleared are 
informational only and a receiver that receives a message with such an AVP 
that is not supported MAY simply ignore the AVP." The AVP might be 
supported but not the value, and it could be ignored also, right? Same 
thing if the AVP and value are supported but the node does not want to 
honor that AVP or value.

In 4.3,
- the definitions for Float32, 64 and 128 are truncated: "'V' bit is 
enabled)." is missing.

In 4.4,
- 1st paragraph, "In addition to the AVP Base Data Formats" -> "In addition 
to *using* the AVP Base Data Formats".
- 1st paragraph, "New AVP Derived Data Formats MUST be registered with 
IANA." How could they be registered? There is no "unique identifier" or 
anything of the sort. And since the AVP contents are actually opaque to 
those that are not involved, I don't quite see the need. They should just 
be defined in any application that uses them. Also, if they must indeed be 
registered, a section in 11.x is missing.
- 3rd paragraph, "AVP Derived DATA Formats" -> "AVP Derived Data Formats"
- IPAddress, what if an AVP must explicitly have an IPv4 or IPv6, and not 
"any of those"?
- UTF8String, 1st paragraph, reference wrong [24] not [29] (it might be a 
good thing to actually check all refs)
- UTF8String, 2nd and 8th paragraphs, no zeros mentionned twice
- DiameterIdentity, get aaa-protocol and protocol at the bottom (in the 
same order they're used)
- DiameterIdentity, 2nd paragraph "The following..." is indented one notch 
too much
- DiameterIdentity, 3rd paragraph, "Since multiple...", why "per host"? 
It's rather "per process", or should be reworded to read "the 
DiameterIdentity of any process is guaranteed to be unique."
- DiameterIdentity, 4th paragraph, "A Diameter node MAY advertise different 
identities...". Glurgs! Certainly not! It MUST be the same identity on all 
connections (unless the host is a gateway between two routing domains (e.g. 
private and public)). Otherwise there's no way to detect duplicate 
connections, loops, etc. consistently. Remember, the DiameterIdentity, as 
used in CER/CEA and Route-Records is just considered as an opaque and 
unique identifier.
- DiameterIdentity, 5th paragraph, this is not needed in duplicate 
connection detection and loop avoidance, since the identifier is opaque. It 
can save time, however, when one gets an external reference to another host 
(via SLP, DNS, Redirect, Alternate-Host...) and one wants to check that 
this new host doesn't match one it already knows/already is connected to. 
But even if that's not done, a match would be detected upon connection to 
the new host when the CER/CEAs are exchanged and the "real" (unique) 
identity is discovered and can be matched against existing connections.
- IPFilterRule, 2nd to last paragraph, "An access device that is unable to 
interpret or apply a deny rule MUST terminate the session." Shouldn't this 
be dependent on whether the M bit is set or not? Ditto for the second 
sentence (though it's probably not as important).
- QOSFilterRule: I thought the idea was to reference an IPFilterRule to 
determine what traffic should be marked or metered?

In 4.5:
- 1st paragraph, swap the ' and the . in 'Grouped.'
- 3rd paragraph, "All AVPs included in a Grouped AVP Every Grouped AVP 
defined...". Either something is missing before the Every, or the all 
before the Every is not needed.
- in the ABNF spec, "header           = "<AVP-Header:" avpcode ">"", how 
does one specify the Vendor-Id, if any?

In 4.5.1:
- in the paragraph starting with "The data for the optional AVPs...", why 
is is stated that "AVPs do not have to begin on 8 byte boundaries"? It is 
true, but I quite see why people would think it?

In 4.6:
- in the table, what if a flag is in neither column for a given AVP (e.g. P 
is often absent)
- here also, what about renumbering everything in a contiguous space?
- checking section references would be a good idea, but I'm way to lazy for 
that.

In 5.0:
- "This section describes how a Diameter nodes establish connections and 
communicate with peers." Either remove the "a" or move everything to singular.

In 5.1:
- 1st paragraph, specify that this "per realm" rather than globally? Though 
there is the issue of proxies that serve many many realms (with different 
peers), and dynamically learned realms/peers.

In 5.2:
- 4th paragraph "2. The Diameter implementation uses SLPv2...", swap ) and 
. in "agents.)".

in 5.3:
- 5th paragraph, "Since the CER/CEA messages...", replace "an upstream" 
with "a". Also specify the Result-Code to be used in the error message.

In 6.8.1:
- "The identity added in this AVP MUST be the same as the one sent in the 
Origin-Host of the Capabilities-Exchange-Request message". sent -> 
received. Capabilities-Exchange-Request -> Capabilities Exchange.

In 7.1.2:
- DIAMETER_LIMITED_SUCCESS: "When returned, the request was successfully 
completed, but additional processing is required by the application in 
order to provide service to the user." Gni? What is that?

In 7.1.3:
- DIAMETER_INVALID_ROUTE_RECORD is no longer needed.
- DIAMETER_REDIRECT_INDICATION might be better off in the informational types?

In 7.1.4/7.1.5:
- I'm still not quite sure of the distinction between permanent and 
transient. e.g. DIAMETER_AUTHENTICATION_REJECTED [which is transient, so 
can be retried] means the request can be retried after asking the user for 
its password again. So it's not actually the same request, right? On the 
other hand, DIAMETER_AVP_UNSUPPORTED and DIAMETER_INVALID_AVP_VALUE [which 
are permanent, so shouldn't be retried] imply that you can retry by 
removing the AVP or changing the value [that's actually the 
"content-negociation" part of Diameter].
Actually, we might be better off with some category that includes anything 
that means neither Accepted nor Refused, but rather "more to come" (which 
would include both the multi-round-trip auths and other capabilities 
negociation messages).
Also, what if an error is detected on the answer rather than the request? 
Ditto for capabilities negociation in that direction (e.g. if server says 
"please set this feature to that value for that user" and client or proxy 
want to say "don't know what you're talking about/don't want to do that").

That's it for today. More to come tomorrow...

[let me know if you want me to split some of these to different issues, 
since some might be a bit more than just editorial changes]. I also have to 
repost my previous mail as an issue.

Jacques.

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