[Dime] WGLC Comments on draft-ietf-dime-rfc3588bis-17.txt, pp. 14-20
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Dime] WGLC Comments on draft-ietf-dime-rfc3588bis-17.txt, pp. 14-20
EDITORIAL
Section 1.2
-----------
In the definition of "Diameter Agent", s/Diameter node/Diameter Node/
In the definition of "Diameter Node", s/Diameter node/Diameter Node/
The definition of a "Diameter Peer" is relational in nature; I think that
the definition might be usefully revised to better express this quality.
Maybe something like "If a Diameter Node shares a direct transport
connection with another Diameter Node, it is a Diameter Peer to that
Diameter Node."
In the definition of "Diameter Server", s/one/Diameter Node/
In the definition of "Downstream", s/home server/Home Server/
In the definition of "Interim accounting", s/in the case of a device reboot
or other network problem prevents the reception/in case a device reboot or
other network problem prevent the delivery/
In the definition of "Real-time Accounting" s/The Diameter Credit Control
Application [RFC4006] is the application that/The Diameter Credit Control
Application [RFC4006] is an example of an application that/
In the definition of "Upstream", s/home server/Home Server/
In the definition of "User", I find the use of "client device" confusing: I
think that the term "client" in this document should only be used to refer
to Diameter Clients, but this is not the case here. Suggest changing
"client device" to "device".
Section 1.3
-----------
s/From the point of extensibility/From the point of view of extensibility/
s/Protocol designer/Protocol designers/
Section 1.3.1
-------------
s/of the documents that defines/of the document that defines/
s/where as values/whereas values/
Section 1.3.2
-------------
s/instead of the base/instead of a base/
Section 1.3.3
-------------
I find this section a little bit confusing; I suggest rewriting it as
follows:
OLD:
A new Command Code MUST be allocated when new required AVPs (those
indicated as {AVP}) are added, deleted or are redefined (for example
by changing a required AVP into an optional one).
Furthermore, when a command is modified with respect to the number of
round trips then a new Command Code has to be registered.
A change to the ABNF of a command, such as described above, MUST
result in the definition of a new Command Code. This subsequently
leads to the need to define a new Diameter Application for any
application that will use that new Command.
The IANA considerations for commands are discussed in Section 11.2.1.
NEW:
A new Command Code MUST be allocated when required AVPs (those
indicated as {AVP} in the ABNF definition) are added to, deleted from or
redefined in (for example,
by changing a required AVP into an optional one) an existing command.
Furthermore, if the transport characteristics of a command are changed
(for example, with respect to the number of
round trips required) a new Command Code MUST be registered.
A change to the ABNF of a command, such as described above, MUST
result in the definition of a new Command Code. This subsequently
leads to the need to define a new Diameter Application for any
application that will use that new Command.
The IANA considerations for commands are discussed in Section 11.2.1.
Section 1.3.4
-------------
I'm pretty sure that "mandatorily" is not an actual English word ;-). I
suggest changing "The M-bit allows the sender to indicate to the receiver
whether the semantics of an AVP and it's content has to be understood
mandatorily or not." to "The M-bit allows the sender to indicate to the
receiver whether or not understanding the semantics of an AVP and its
content is mandatory."
TECHNICAL
Section 1.2
I think that the definition of "Diameter Client" is a bit too restrictive:
it's not hard to imagine Diameter clients that are not strictly speaking
devices or don't sit at the edge of a network or do not (directly) perform
access control functions. I suggest rewriting the definition in terms of
Diameter Node, maybe something like:
"A Diameter Client is a Diameter Node that supports Diameter client
applications as well as the base protocol. Diameter Clients are often
implemented in devices situated at the edge of a network and provide access
control services for that network. Typical examples of Diameter Clients
include the Network Access Server (NAS) and the Mobile IP Foreign Agent
(FA)."
In the definition of "Downstream", a more general statement might be
obtained by replacing "access device" with "Diameter Client"
The definition of "Session state" doesn't really make sense to me: it
doesn't actually define session state, but does define a stateful agent.
In the definition of "Upstream", a more general statement might be obtained
by replacing "access device" with "Diameter Client"
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.