Subject: [Sip] Some comments on draft-ietf-sips-05

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Sun, 22 Jul 2007 18:24:31 +0200

Some late WGLC comments on this. Don't think there are any showstoppers
here.

1)	I am not seeing the separation of UAC, UAS, and proxy
requirements required by RFC 4485. Please do not write one requirement
covering two of these entities, and ideally separate these requirements
into separate sections. To me this also means separating UAC and
registrar requirements (which for example impacts 4.1.1). The point of
this is to make it easy for an implementor of a particular item of
equipment (e.g. a terminal, or a proxy including a registrar) to clearly
identify their own requirements they have to meet.

2)	Section 3.1.3:

   In fact, implementations
   SHOULD try to establish a TLS connection when using a SIP URI.

Not sure the RFC 2119 language is appropriate here. Surely this should
be covered by more specific RFC 2119 language in section 4.

3)	Section 4.1.3:

   As a general principle, derived dialogs and transactions MUST NOT
   result in an effective downgrading of SIPS to SIP, without the
   explicit authorization of the entities involved.

Not sure how we can demonstrate true compliance against this, and
therefore do not believe the RFC 2119 language is appropriate.

4)	Section 4.1.4:

   Again, the general principle is that
   these mechanism SHOULD NOT result in an effective downgrading of SIPS
   to SIP, without the proper authorization.

Again, not sure how we can demonstrate true compliance against this, and
therefore do not believe the RFC 2119 language is appropriate.

5)	Section 4.2:

   Some proxies MAY have policies that prohibits
   sending any request over anything but TLS.

In the context, this is just explaining the previous SHOULD. I don't
think the RFC 2119 language is appropriate.

Similarly for this text in the same section:

   Some
   proxies MAY have a policy of not forwarding at all requests using a
   non-SIPS Request-URI if the UAS had registered using a SIPS Contact
   header fields.

6)	Section 4.2:

   The "transport=tls" parameter must not be used by proxies that
   conform to this specification.

Is this a restatement of the text in RFC 3261 (in which case I would
prefer quoting the RFC 3261 text) and saying that there is no change
from this:

      Note that in the SIPS URI scheme, transport is independent of TLS,
      and thus "sips:[email-masked];transport=tcp" and
      "sips:[email-masked];transport=sctp" are both valid (although
      note that UDP is not a valid transport for SIPS).  The use of
      "transport=tls" has consequently been deprecated, partly because
      it was specific to a single hop of the request.  This is a change
      since RFC 2543.

Or is it a new normative requirement in its own right, in which case the
we need "MUST NOT".

7)	Section 5.1:

   This response differs from 416 because the UAS or
   proxy recognizes the SIPS URI but it is not allowed, and because the
   UAC SHOULD NOT retry the request automatically using a SIP URI.

Is this attempting to state (in which case it should be elsewhere):

   If a 418 (SIPS Not Allowed) is received, the
   UAC SHOULD NOT retry the request automatically using a SIP URI.

Or is it just defining the semantics of the 418 in which case the RFC
2119 language is not appropriate.

8)	Section 5.2:

   The UAC SHOULD retry the request automatically using a
   SIPS URI.

Again not convinced that the RFC 2119 language is appropriate here. This
should be defining the semantics of the response code.

9)	Section 7:

   For mutual TLS,
   it means that one should be very careful that the architecture of the
   network is such that connections are made between entities that have
   access to each other's certificates.  Record-Route [RFC3261] and Path
   [RFC3327] are very useful in ensuring that previously established TLS
   connections can be re-used.  Other mechanisms may also be used in
   certain circumstances: for example, using root certificates that are
   widely recognized may allow for more easily created TLS connections.

Does this not get covered by the connect-reuse draft, if we ever get
that finished.

NITS:
-----

A)	There is significant usage of lower case RFC 2119 language,
particularly "must". I believe it is desirable to avoid this type of
usage if possible, as it only takes a slip of the editor for it to
become a "MUST" and we have a new requirement that was not agreed by the
WG. I think it is possible to find alternatives.

B)	There are a number of instances of "it" where I would prefer
"the proxy" or whatever, e.g. in structures such as: 

   When a proxy inserts a Record-Route entry, it must take care in using
   the proper scheme 

Should become "the proxy". I don't want people fighting their way back
in the sentence to find the real subject.

And

   If the proxy needs to reject the request for
   that reason, it MUST reject it with a 418 (SIPS Not Allowed).

Should become:

   If the proxy needs to reject the request for
   that reason, the proxy MUST reject it with a 418 (SIPS Not Allowed).

C)	Ensure that all request names, e.g "REGISTER" are followed by
"request", i.e. "REGISTER request".

D)	Section 4.1.2:

   Because registering with a SIPS Contact header field implies a
   binding of both a SIPS Contact and a corresponding SIP Contact to the
   AOR, a UA MUST NOT include both the SIPS and the SIP version of the
   same Contact header field in a REGISTER: it MUST only use the SIPS
   version in this case.

":" --> ";", and also as in B) above "it" --> "the UA"

E)	Capitalisation. "proxy", "redirect server" etc are not proper
nouns, therefore please use lower case initial letters.

F)	Section 4.1.2:

   If all the Contact header fields in a REGISTER are SIPS, a SIPS AOR
   MUST be used by the UAC in the REGISTER. If at least one of the
   Contact header fields is SIP or is neither SIP nor SIPS (e.g.,
   mailto, tel, http, https), a SIP AOR MUST also be used by the UAC. 

Rewrite as

   If all the Contact header fields in a REGISTER request are SIPS, a
the UAC 
   MUST use a SIPS AOR in the REGISTER request. If at least one of the
   Contact header fields is SIP or is neither SIP nor SIPS (e.g.,
   mailto, tel, http, https), the UAC MUST also use a SIP AOR.

G)	Section 4.1.3:

   If the top Route header field
   does not contain a SIPS URI, the Contact header field MUST be a SIP
   URI, even if the request is sent over a secure transport (e.g., the
   first hop could be re-using a TLS connection to the proxy as would be
   the case with [I-D.ietf-sip-outbound]).

Rewrite to clearly indicate a UAC requirement, ie. "the UAC must..."

H)	Section 4.1.4:

   If that initial dialog was
   established using SIPS, then the new one MUST NOT be established
   using SIP, unless there is an explicit authorization given by the
   recipient of the REFER.

Rewrite to clearly indicate a UAC requirement, ie. "the UAC must..."

I)	Appendix B:

      If the address-of-record in the To header field of a REGISTER
      request is a SIPS URI, then any Contact header field value in the
      request MUST also be SIPS URIs.

Rewrite as UAC requirement:

      If the address-of-record in the To header field of a REGISTER
      request is a SIPS URI, then the UAC MUST also include only SIPS
URIs in any Contact header field value in the
      request.

Regards

Keith

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip