Subject: [Speermint] Comments on draft-ietf-speermint-requirements-02

From: "Elwell, John" <[email-masked]>
Date: Mon, 23 Jul 2007 13:11:37 +0100

Jean-Francois,

1. I have difficulty understanding the need to mention media border
elements in this document. In fact the only mention seems to be in
section 3.2:
"maximum flexibility should be given for how signaling path and
   media path border elements are declared, dynamically advertised and
   updated"
and
"If the SSP also provides media streams to its users, an SSP
   SHOULD declare the media border elements "

Why is there a need to declare media border elements. If media has to
pass through a border element, then surely that will be indicated in the
SDP on a per session basis. I see no need for prior declaration or
advertising.

2. Later in 3.2 it states:
"Ingress and egress SBE points MAY be peer-dependent,
   and/or media-dependent."
and then later:
"For example, within an SSP
   network, some SBEs may be dedicated for certain types of media
   traffic due to specific SIP extensions required for certain media
   types (e.g.  SIMPLE, the SIP MESSAGE Method for Instant Messaging
   [RFC3428] or the Message Sessions Relay Protocol (MSRP))."
How can this be so? Suppose I have one SBE for audio/video and another
for MSRP. How do I establish a session that has audio and MSRP? What if
I establish a session for audio and then decide mid-session to add MSRP,
or vice versa?

3. The title is:
"SPEERMINT Requirements for SIP-based VoIP Interconnection"
and in section 1 it states:
"This document describes guidelines and requirements that are intended
   to become Best Current Practices for session peering (direct,
   indirect or assisted)."
This is document is rather unusual. We have many "requirements"
documents in the IETF that are requirements for a protocol or
requirements for a solution to a problem. Here we seem to be stating
requirements on an SSP. So we should make it quite clear that we are
specifying requirements on an SSP, and perhaps even consider changing
the title.
Then, throughout the document, wherever a normative statement is made
(RFC 2119 language), we must make it absolutely clear to what the
normative statement applies. So we should typically begin "An SSP MUST"
or "an originating SSP SHOULD". Statements such as:
"it
   MUST be possible to determine whether the SSP domain servicing the
   URI allows for session peering, and if it does, it SHOULD be possible
   to locate and retrieve the domain's policy and SBE entities."
in 3.3.2 are not helpful. Does this mean there is a requirement to
advertise the policy and SBE entities, or does it mean that there is a
requirement on an originating SSP to find and utilise advertised policy
and SBE entities?

4. In 4.1 it states:
"Such specifications SHOULD include protocol
   implementation compliance statements, indicate the minimal extensions
   that MUST be supported, and the full details on what options and
   protocol features MUST be supported, MUST NOT be supported or MAY be
   supported."
The use of "MUST" and "MUST NOT" here is inappropriate use of RFC 2119
language.

5. In 4.2:
"the use of the Require
   header must be configurable on a per SSP target domain basis in order
   to match a network peer's policy and to maximize interoperability."
The Require header field is end-to-end, i.e., inserted by the UAC, so it
is not under the control of the SBE.

6. In 4.5.2:
"SIP and SBE servers involved in the secure session
      establishment over TLS MUST have valid X.509 certificates and MUST
      be able to receive a TLS connection on a well-known port."
Why is it necessary to be able to receive on a well-known port, if the
port it advertised in SRV records?

7. In 4.5.2:
"SIP and SBE servers involved in the session establishment over
      TLS MUST verify and validate the client certificates: the client
      certificate MUST contain a DNS or URI choice type in the
      subjectAltName which corresponds to the domain asserted in the
      host portion of the URI contained in the From header."
This does not work when receiving from a domain that is not the
originating domain or if the domain in the From header field URI is
anonymous.invalid. I believe it is only necessary to check that the
subjectAltName identifies a domain with which peering is allowed.

John

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint