Subject: Re: Last Call: draft-peterson-rai-rfc3427bis (Change Process for the Session Initiation Protocol (SIP)) to Proposed Standard]

From: Alan Johnston <[email-masked]>
Date: Fri, 13 Mar 2009 16:55:30 -0500

Jon & Cullen,

Here are my last call comments on the document.

Overall, I like the approach and support moving forward with it, but I 
have a few questions that I think should be answered clearly in this 
document.

1. Section 4 talks about header field extensions, and the abandonment of 
P-headers is a great thing (I've always thought the P stood for 
Punishment...)  However, it is silent about the registration of URI and 
header parameters.  Could we come up with a mechanism to simplify 
registration of these extensions?  In some cases, SIP interop would be 
improved.

2. Section 4 is also silent about defining SIP option tags.  In the 
past, a P-header could not have a corresponding SIP option tag.  I 
understand the concern about interop being affected by option tags in 
Require and Proxy-Require header fields, however, the inability to have 
an option tag for Supported and to use with RFC3840 caller preferences 
is a major limitation.  As such, we are left without a discovery 
mechanism which leads to feature profiling and resulting interop 
failures.  The document should discuss these issues and lay out the 
preferred mechanism.  If the mechanism is to deny option tags, then a 
method for discovery needs to be outlined.

Other items that relate to the document but the answers do not 
necessarily belong in this document:

3. How will some existing SIPPING work be handled?  Some of this work 
needs WG review but will be outside the scope of both SIPCORE and 
DISPATCH.  And forming a BOF in order to progress a single draft seems 
silly.

4. In the security considerations of most SIP extensions, we inevitably 
end up referring to S/MIME.  However, we know that there is no S/MIME 
deployments with SIP, essentially making the resulting security 
considerations irrelevant.  Perhaps some guidance on practical security 
considerations would be worthwhile going forward, given the heavy 
reliance on hop-by-hop security and transitive trust in deployed SIP 
systems.

Thanks,
Alan

-------- Original Message --------
Subject: 	Last Call: draft-peterson-rai-rfc3427bis (Change Process for 
the Session Initiation Protocol (SIP)) to Proposed Standard
Date: 	Tue, 10 Mar 2009 16:02:23 -0700 (PDT)
From: 	The IESG <[email-masked]>
Reply-To: 	[email-masked]
To: 	IETF-Announce <[email-masked]>

The IESG has received a request from an individual submitter to consider 
the following document:

- 'Change Process for the Session Initiation Protocol (SIP) '
   <draft-peterson-rai-rfc3427bis-01.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2009-04-07. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-peterson-rai-rfc3427bis-01.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16984&rfc_flag=0

The following IPR Declarations may be related to this I-D:

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 25 Mar 2009 02:00:56 -0500

I'd like to echo Alan's point here...

> considerations would be worthwhile going forward, given the heavy reliance 
> on hop-by-hop security and transitive trust in deployed SIP systems.

We've got to quit pointing to S/MIME when we know that no one believes us!

The input I'm getting from SIPconnect/1.1 contributors is that they're not 
even excited about hop-by-hop TLS - a fair number of deployments are running 
wide open. I'm thinking this isn't going to end well.

Thanks,

Spencer