Subject: Re: [Sip] WGLC for draft-ietf-sip-sips-05.txt

From: Hans Persson <[email-masked]>
Date: Thu, 05 Jul 2007 11:24:58 +0200

fre 2007-06-29 klockan 09:42 -0500 skrev Dean Willis:

> I'm pleased to announce that the authors think that the SIPS draft is  
> ready for working group last call. This draft has had the privilege  
> of more review prior to WGLC than most of our other efforts, so  
> perhaps it won't be too controversial.
> 
> Please make a final read through the draft and bring any comments  
> back to this list.

I've gone through the diff between the current version and the last one
I read, and on the whole it looks good to me. 

Some editorial nits are listed below.

Section 3.1.1, para 1:

> the Proxy is the TLS server side.  This directionality implies that

"proxy"

> directions (e..g, an incoming call), the UA must keep the TLS

"e.g."

Section 3.1.1, para 2:

> connection also solves the NAT and Firewall problem as it ensures

"firewall"

Section 3.1.2, para 1:

> place, the UAC would therefore take on the role of the TLS Client and

"client"

> SIP, a UA or a Proxy act both as UAC and UAS depending on if they are

"proxy"

> is very convenient.  This allows for TLS connections to be set-up or

"set up"

Section 3.1.2, para 3:

> most residential SIP deployments for example.  Mutual TLS can be used

Insert comma after "deployments".

> in those environments, but only if the connection is always stated by

"stated" is a strange word here. Do you mean "started"?

Section 3.1.2, last para:

> For this reasons, mutual TLS is mostly used in server-to-server

"this" -> "these"

Section 3.1.3, para 4:

> message (From, To, Request-URI, Contact header field, Route, etc.).

Why "Contact header field" and not just "Contact" like for the others?

Section 3.4, para 6:

> allowed, which would preclude the use of NATs or Firewalls.

"firewalls"

Section 4.1, para 3:

> SIP URI, it SHOULD respond with a 418 (SIPS Not Allowed).  UAS that
>   do not support the SIPS URI scheme altogether "SHOULD reject the

"UAS" would be more readable as "UASs".

Change "altogether" to "at all".

Section 4.1, last para:

> response code 419 (SIPS Required)

Missing period at end of sentence.

Section 4.1.2, para 8:

> reject requests using the SIP Scheme with 419 (SIPS Required).  A UA

"scheme"

Section 4.2, para 5:

> response, it MUST NOT recurse on it.  The Proxy SHOULD forward the

"proxy"

Section 4.3, para 1:

> Using a Redirect Server with TLS instead of using a Proxy has some

"redirect server", "proxy"

> established connection between the Proxy and the UAS (such as with

"proxy"

Section A.3:

> (similar to what the transport=tls used to mean) has been suggested

Remove "the".

Hans

-- 
Hans Persson <[email-masked]>    Ingate - Firewalls with SIP & NAT
Ingate Systems AB  +46 13 210857   http://www.ingate.com/

Private: <[email-masked]>  http://www.lysator.liu.se/~unicorn/

_______________________________________________
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

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 16 Jul 2007 13:03:16 -0500

Thanks. 

I will make all those changes. 

> -----Original Message-----
> From: Hans Persson [mailto:[email-masked]] 
> Sent: Thursday, July 05, 2007 02:25
> To: Audet, Francois (SC100:3055)
> Cc: Dean Willis; IETF SIP
> Subject: Re: [Sip] WGLC for draft-ietf-sip-sips-05.txt
> 
> > ready for working group last call. This draft has had the 
> privilege of 
> > more review prior to WGLC than most of our other efforts, 
> so perhaps 
> > it won't be too controversial.
> > 
> > Please make a final read through the draft and bring any 
> comments back 
> > to this list.
> 
>

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 18 Jul 2007 22:23:24 +0200

A little late, but one consideration:

Deprecating the last hop exception means that if the last hop proxy supports 
this specification, the UAC has no way to request SIPS up to the last hop 
(which it may want to do; best-effort TLS using sip: will probably not work 
in the intermediate period until this specification is widely supported).

Would it be an idea for the draft to define request disposition tags 
(RFC3841) "last-hop-exception" and "no-last-hop-exception"? Then the UA 
could use SIPS, but indicate its preference to allow the last hop exception, 
and get "almost-end-2-end" security

Regards,
Jeroen

Dean Willis wrote:
> I'd like to conclude this WGLC by July 16, 2007, so get your comments
> back in by then. And I'll plan to put some discussion time on the
> agenda in Chicago.
>
> Thanks, and have a great weekend.

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 18 Jul 2007 15:56:44 -0500

We have explored something similar (using an option tag instead) in an
earlier version (see 
https://svn.resiprocate.org/rep/ietf-drafts/audet/draft-ietf-sip-sips-03
.txt), 
but people felt the additional complexity was not warranted and that
allowing for the last-hop exception was not a good goal.  It was
therefore revoved in the next version.

> From: Jeroen van Bemmel [mailto:[email-masked]] 
> Sent: Wednesday, July 18, 2007 13:23
> To: IETF SIP; Dean Willis; Audet, Francois (SC100:3055)
> Deprecating the last hop exception means that if the last hop 
> proxy supports this specification, the UAC has no way to 
> request SIPS up to the last hop (which it may want to do; 
> best-effort TLS using sip: will probably not work in the 
> intermediate period until this specification is widely supported).
> 
> (RFC3841) "last-hop-exception" and "no-last-hop-exception"? 
> Then the UA could use SIPS, but indicate its preference to 
> allow the last hop exception, and get "almost-end-2-end" security
> 
> Regards,
> Jeroen
> 
> Dean Willis wrote: