Subject: [AAA-WG]: [Issue] More editorial comments on base-07

From: Jacques Caron <[email-masked]>
Date: Fri, 03 Aug 2001 19:30:46 +0200

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

In 5.3.1:
- 1st paragraph, "...is sent to inform a peer that a reboot has occurred". 
I think it's just sent whenever a connection is established, and is not 
linked to reboots in any way (other than reboots imply a new connection, 
but not the opposite). Might be handy to know a device has rebooted, though 
(by including uptime in the CER/CEA messages for instance).

In 5.3.2:
- 1st paragraph, "The Capabilities-Exchange-Request (CEA)" -> "The 
Capabilities-Exchange-Answer (CEA)" :-)

In 5.4:
- 1st paragraph, "...disconnects one *of* its transport connections..."

In 5.5.3:
- Status, "the level of confidence in the algorithm". Needs some rewording :-)
- Pending, "This boolean field is set to TRUE when there are no outstanding 
unanswered requests". For logic's sake, it should be FALSE when there 
aren't any, and TRUE when there are (and modify the rest accordingly -- 
actually, I think the rest actually thinks pending is true when there are 
outstanding unanswered requests...)
- OnReceiveDWA, not sure the "if pcb->status = WAIT_DWA OR pcb->Status = 
SUSPECT" is actually needed? It should happen also if status is OK. Also 
note the capitalization of status is not constant.
- OnTimerElapsed, a "T = Tw" is missing in the OK block after the 
SendWatchdog(pcb)

In 5.5.4:
- 2nd paragraph, "The Hop-by-Hop Identifier field MAY be used to match the 
answer with the queued request". Errr, I don't see any other way?
- 3rd paragraph, "it is not possible for forward" -> "it is not possible 
*to* forward".
- 4th paragraph, "request or answer" -> "requests or answers"

In 5.6:
- 2nd paragraph, "...a connection is initiated *from* MUST NOT be the port..."
- in the state machine, I still think that (a) two state machines, one for 
receiving, one for initiating, would be a lot simpler -- the only place 
where they have anything in common is the election after receiving a CEA or 
CER, respectively; (b) the "R-Conn-CER" event is a bit too much of a 
shortcut since it actually involves multiple sub-events and states.

In 5.6.1:
- 1st paragraph, "This is because the identity of a Diameter peer is 
determined by host and port; and the source port of an incoming connection 
is arbitrary" -> "This is because the identity of a Diameter peer is 
determined by a specific protocol, transport, host and port the peer is 
listening on; and the protocol, transport, source address and source port 
of an incoming connection are arbitrary."
- 4th paragraph, "the state machine below" -> "the state machine above".

In 5.6 & 5.6.3:
- the state machine states that if a connection is received (R-Conn-CER) 
once in Open state, then the new connection is rejected, i.e. disconnected. 
A CEA MUST be sent before the connection is disconnected. This is to make 
sure that if host A and B already talk to each other, and A finds out it 
needs to talk to host C (DNS, SLP, Redirect-Host...), which is actually 
another URI for host B, then A must know that C == B. Of course, the CEA 
must contain some Result-Code that says there already is a connection and 
that this one will be shut down.
- Also I'm not 100% convinced the state machine isn't subject to some race 
conditions, though I didn't look into that in detail.

In 6.1:
- 5th paragraph "When a message is received...", references are incorrect: 
6.1.1 -> 6.1.4; 6.1.2 -> 6.1.5; 6.1.5 -> 6.1.6.

In 6.1.8:
- in the figure, the Route-Record should be set to nas.mno.net, not 
drl.mno.net.

In 6.1.9:
- 1st paragraph, if the AVPs are put in reverse order, then it should be 
the FIRST Souce-Route AVP, not the last. Also, that AVP must be removed 
after use :-)
- also, need to update 6.1 and 6.1.5 to include source-routing.

In 6.4:
- 1st paragraph, "or broker". I would suppose a broker would only operate 
relays, proxies, or redirectors, and could thus never originate messages 
(other than errors)? Otherwise, just state "This AVP identifies the node 
which originated the Diameter message."
- 2nd paragraph, "The value of the Origin-Host AVP is guaranteed to be 
unique within a single host". I would say it must be completely unique for 
any given process.

In 6.5:
- not quite sure what the Origin-Realm is for, and not quite sure what the 
"realm of the originator" might be. For me, realms are for users, not nodes.

In 6.6 (and other places in 6):
- 1st paragraph, "This AVP MUST be present in all unsolicited agent 
initiated messages". Not sure why. The Source-Route AVPs should be enough.

In 6.7:
- maybe we need an AVP derived type for realms?
- "Diameter servers initiating a request message use the value of the 
Origin-Realm AVP from a previous message received from the intended target 
host (unless it is known a priori)". This is no longer used.

Haven't had time to do more yet, I'll try to finish the thing during the 
week-end.

Jacques.

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