Subject: [Dime] review of rfc3588bis, pages 20 through 30

From: Jari Arkko <[email-masked]>
Date: Mon, 02 Feb 2009 13:49:59 +0200

Continuing with my review...

> The base Diameter protocol concerns itself with capabilities
> negotiation, how messages are sent and how peers may eventually be
> abandoned.
Here's a possibly better way to say this: "The base Diameter protocol 
concerns itself with establishing connections to peers, capabilities 
negotiation, how messages are sent and routed through peers, and how the 
connections are eventually torn down."

> One AVP
> that is included to reference a user's session is the Session-Id.
>
> The initial request for authentication and/or authorization of a user
> would include the Session-Id. The Session-Id is then used in all
> subsequent messages to identify the user's session
I feel that the first sentence is unnecessary, given the remaining 
explanations. Perhaps you could say: "The initial request for 
authentication and/or authorization of a user would include the 
Session-Id AVP. ..."

> Diameter Relays and redirect agents are, by definition, protocol
> transparent
application transparent?

Section 2.3 talks about application Ids being advertised in capabilities 
negotiation, and then Section 2.4 actually defines what these IDs are 
and repeats the same story about capabilities negotiation. Perhaps some 
reorganization of text would be useful here.

> Diameter implementations SHOULD be able to interpret ICMP protocol
> port unreachable messages as explicit indications that the server is
> not reachable, subject to security policy on trusting such messages.
> Diameter implementations SHOULD also be able to interpret a reset
> from the transport and timed-out connection attempts.  If Diameter
> receives data up from TCP that cannot be parsed or identified as a
> Diameter error made by the peer, the stream is compromised and cannot
> be recovered.  The transport connection MUST be closed using a RESET
> call (send a TCP RST bit) or an SCTP ABORT message (graceful closure
> is compromised).
>   

This text needs some softening, or perhaps you could add a reference to 
some other work, e.g., "Further guidance regarding the treatment of ICMP 
errors can be found in [draft-ietf-tcpm-icmp-attacks, 
draft-ietf-tcpm-soft-errors]." The references should be informative.

Jari

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

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 09 Feb 2009 13:24:42 -0500

Hi Jari,

Thanks for the continued review.

> negotiation, how messages are sent and routed through peers, and how 
> the connections are eventually torn down."

Ok

> authentication and/or authorization of a user would include the 

Ok

> Section 2.3 talks about application Ids being advertised in 
> capabilities negotiation, and then Section 2.4 actually defines what 
> these IDs are and repeats the same story about capabilities 
> negotiation. Perhaps some reorganization of text would be useful here.

How about re-wording the entire paragraph to:

"Diameter Relays and redirect agents are transparent to the Diameter 
applications but they MUST support the Diameter base protocol, which 
includes accounting, and all Diameter applications."
> This text needs some softening, or perhaps you could add a reference 
> to some other work, e.g., "Further guidance regarding the treatment of 
> ICMP errors can be found in [draft-ietf-tcpm-icmp-attacks, 

Ok.

regards,
victor

---

From: Jari Arkko <[email-masked]>
Date: Mon, 09 Feb 2009 22:00:23 +0200

Victor,

> includes accounting, and all Diameter applications."

OK

Jari