Subject: [Sip] draft minutes from SIP at IETF 67

From: Dean Willis <[email-masked]>
Date: Sun, 26 Nov 2006 19:04:07 -0600

I'll try and get these posted shortly on the Proceedings and  
Softarmor sites.

Please review and respond with any corrections.

----------------------------

Draft Minutes for SIP at IETF 67
Edited by Dean Willis

Based on notes by David Bryan, Spencer Dawkins, Jason Fischl, Philip  
Mathews, Chris Boulton, Richard Barnes, and Others.

Session 1: Thursday 1300-1500 Grand Ballroom C

Topic: Agenda Bash and Status
Discussion led by Chairs
Slides included in proceedings.

Agenda accepted as presented

Working group members asked to more thoroughly review the certs draft  
and consent framework.

Topic: Outbound
led by Rohan Mahy
Read: draft-ietf-sip-outbound-05
Slides included in proceedings.

Changes since last version reviewed.

Issue: Which response code to use for failures. No objection noted to  
proposed use of 430 Flow Failed.

Issue: Noted that there is no mention of rport in the draft. Author  
will add text explaining that UA must put rport parameter in Via and  
send from port it's prepared to receive on, and add informative  
reference to NAT scenarios document.

Issue: Verify outbound support on first or all hops? Discussion  
seemed to resolve on checking at registrar and first hop. Author will  
make appropriate changes to the document.

Issue: How to resolve possible mismatch in max-flows parameter  
between visited proxy and home proxy? Discussion of this question was  
inconclusive, with a general consensus to defer further discussion.

Issue: Detecting instance-ID binding rules. This relates to concerns  
raised by 3GPP. A side meeting with 3GPP was held, and the author  
thinks he understands the problem and will propose a solution in the  
next revision of the document. The expected approach is to relax the  
flow-token language somewhat to allow the specific use case proposed  
by 3GPP.

Topic: Domain Certs
led by Vijay Gurbani
Slides included in proceedings.
Read: draft-gurbani-sip-domain-certs-03

The use of embedded DNS names to indicate the purpose of a  
certificate was quite controversial and much discussion ensued. The  
security community holds that extended certificates may be a better  
solution.

Discussion of the document touched on whether the work is required  
and how it relates to other work. The discussion was inconclusive,  
and we expect to resolve it via list discussion and possibly a  
subject-specific conference call.

Topic: Connection Reuse
led by Vijay Gurbani 	
Slides included in proceedings
Read: draft-ietf-sip-connect-reuse-07

Issue: Since the impact of this work has essentially declined to  
halving the number of TLS between proxies not separated by NATs,  
should we continue to pursue the work? The opinion of the room was  
weighted about 5 to 1 against continuing the work. The chairs are  
tasked to raise this question on the mailing list.

Issue: The approach taken by the outbound mid-dialg draft may obviate  
some of the applicability for this draft. Discussion on this point  
was inconclusive, and it will be taken as a topic for an upcoming  
conference call.

Issue: The CP behavior in this document contradicts that in draft- 
ietf-sip-outbound.

Topic: SIPS Guidelines
led by Francois Audet
Slides included in proceeedings
Read: draft-audet-sip-sips-guidelines-04

Changes in document since last version reviewed.

Issue: 4 point  BCP list proposed on-list by Dean Willis. Noted that  
Item 1 is somewhat out of place, as it simply restates RFC 3261.  
Suggested that a BCP should perhaps explicitly state this as a  
"reminder". The room seemed to agree with points 2 and 3. Point 4  
remained controversial, with a general consensus emerging that it  
should be expressed at a "Should" strength along with discussion of  
the risk model and consequences.

Topic: GRUU and Supporting Drafts 	
Led by Jonathan Rosenberg 	
Slides included in proceedings
Read: draft-ietf-sip-gruu-11,draft-rosenberg-sip-ua-loose-route-00

Change since last version reviewed.

Issue: GRUU subtype names. The room demonstrated a slight preference  
for the names used in -11 over known alternatives, but nobody seems  
particularly enamored with these names and the floor remains open to  
suggestions.

Discussion on ua-loose-route draft deferred to next session.

Session 2: Friday 0900-1130 Grand Ballroom C

Topic: UA-loose-route, continued from previous session.

Consensus noted that we do need some sort of solution for the general  
problem of delivery of URI parameters across contact-routing operations.

Issue: Concerns raised about backward compatibility. Noted that  
compliant P-CSCF should be OK.  Suggested that we have a design team  
revisit call-flows and analyze for backward compatibility issues.

Issue: Does GRUU normatively depend on this work? Resolved: GRUU does  
not reference this document. However, some participants feel it  
should, as the benefit of GRUU cannot be fully recognized in the  
absence of this specification.  The chairs asked for a hum, and the  
consensus of the room is that GRUU and ua-loose-route can proceed  
independently.

Question: Adopt this draft as baseline text for a WG effort, should  
the ADs approve the milestone? Consensus to adopt noted by chairs. To- 
do: Chairs to work with AD to set new milestone.

Topic: Location Conveyance
led by  James Polk and Brian Rosen
Slides included in proceedings
Read:  draft-ietf-sip-location-conveyance-05

Changes since last version reviewed.

The room discussed trust issues, location-by-value (needs  
geolocation), and the question of whether it is important to know  
which entity inserted a location. No changes to the document were  
noted as being required during this discussion.

The chairs polled for acceptability of current direction -- adding to  
a header. There were no objections noted to this direction.

Issue: Where to track the location error created by this draft?  
Proposed that we have separate registries for SIP and LOST.

Further discussion deferred to list and future conference call. To- 
do: Chairs to establish a conference call for discussion.

Topic: Connected Identity
led by John Elwell
Slides included in proceedings
Read: draft-ietf-sip-connected-identity-02

Current status reported as all issues fixed exception for rejection  
by RFC 4474 verifier.

Discussion concluded with a proposal to not make a statement about  
428 responses and policy, perhaps add an informational header into a  
mid-dialog request rather than rejecting outright.

Author will work with this approach and revise doc appropriately.

Topic: Identity Coexistence
led by Jonathan Rosenberg
slides included in proceedings
Read: draft-rosenberg-sip-identity-coexistence-00

Issue: How to deal with transit networks? This produced an extensive  
discussion. Proposed that logic in draft is inverted, and that we  
should perhaps be looking for Identity and falling back to PAID.

There seems to be some consensus that this work is valuable, although  
there is no consensus yet on the documented approach.

The author will revise the document for further discussion.

Topic: Outbound Discovery and Mid-Dialog Requests
led by: Jonathan Rosenberg
Slides included in proceedings
Read: draft-rosenberg-sip-outbound-discovery-mid-dialog-00

Issue: How to discover in the absence of DNS? There appears to be no  
consensus on whether this is a requirement.

Further discussion deferred to list.

Topic: Diagnostic Responses
led by Scott Lawrence
Slides included in proceedings
Read: draft-ietf-sip-hop-limit-diagnostics-03, draft-gurbani-sip- 
large-udp-response-00

Noted that ongoing NIT work proposes to deprecate provisional  
responses for non-INVITE transaction.

Proposed that SIP Redirection could be used to eliminate problem.

Author will bring discussion questions to the mailing list.

Topic: UA Profile Delivery
led by Dan Petrie
Slides included in proceedings
Read:  draft-ietf-sip-xcap-config-00 draft-petrie-sip-event-param-err-00

Changes since last version reviewed.

Noted that OMA has a dependency on XCAP change notifications. To:do;  
OMA liaison manager to open a dialog on this dependency.

Noted that PacketCable 2.0 uses this draft.

Topic: Route Constuction
Led by Jonathan Rosenberg
Slides included in proceedings
Read: draft-rosenberg-sip-route-construct-02

Noted that input from IMS vendors is needed to evaluate impact of  
this proposal. One speaker with some background in IMS opined that  
this technique should be useful with IMS.

Issue: Is Service-Route a reasonable way to provide the outbound  
proxy set? One speaker didn't think so, but no alternative  
suggestions were noted.

Further discussion deferred to mailing list.

Meeting adjourned several minutes past scheduled end of session.

_______________________________________________
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: "Joel M. Halpern" <[email-masked]>
Date: Sun, 26 Nov 2006 20:42:47 -0500

>the risk model and consequences.

I think the discussion of point 4 at the meeting may have missed the point.
Point 4 says basically that PSTN gateway termination can not use SIPS 
(to put it in the most pejorative fashion and then defend it.)

Point 1 is that everyone should use TLS.  Since 3261 already says 
this, saying it again is not a change.  It doesn't hurt to restate it.

The argument has been that SIPS (inside the IP cloud) means "MUST use 
TLS."  It has been clearly stated and agreed that it is not 
acceptable to use "or equivalent security."
Well, if "equivalent security is NOT okay in the IP domain, why is it 
okay for the PSTN?  Do they get  a free pass?  It seems to me that if 
we are going to tell secure providers of VoIP that they must reject 
SIPS requests (on the grounds that it isn't TLS, and if that was not 
required by the caller the caller should have just used SIP) then we 
owe it to ourselves and the users to make the same assertion about the PSTN.
Note, I am not claiming that the PSTN is less secure.  I am merely 
saying that if "equivalent security" is not acceptable, then it is 
not acceptable.

(I will refrain from rehashing the arguments on the marginal utility 
of SIPS anyway.)

Yours,
Joel M. Halpern

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 27 Nov 2006 15:35:25 -0600

> the risk model and consequences.

I think your description of Point 4 is missing a few things.

I think the group agreed that "SIPS termination SHOULD be used for all
derived
connections" when possible.

The key point was that there was a concensus that using SIPS to a PSTN
gateway
was legal. The rationale what that the scope of this document stops at
SIP boundaries.

Specifically, in the SIP "cloud", implementations SHOULD use SIPS for
derived 
connections. An example of where this is is important is a B2BUA.

And then we would put some wording that what happens outside the SIP
network is out
of scope of this document. Some other networks (e.g., H.323) may have
some equivalent
security mechanism.

Again, the key point was allowing for SIPS to PSTN gateways.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Nov 2006 16:42:52 -0500

Comments inline ...

Joel M. Halpern wrote:
>> Issue: 4 point  BCP list proposed on-list by Dean Willis. 
...
>> Point 4

I don't recall any such consensus.

> (to put it in the most pejorative fashion and then defend it.)
...
> TLS."  It has been clearly stated and agreed that it is not acceptable 
> to use "or equivalent security."
> okay for the PSTN?  Do they get  a free pass?  It seems to me that if we 
> are going to tell secure providers of VoIP that they must reject SIPS 
> requests (on the grounds that it isn't TLS, and if that was not required 
> by the caller the caller should have just used SIP) then we owe it to 
> ourselves and the users to make the same assertion about the PSTN.
> saying that if "equivalent security" is not acceptable, then it is not 
> acceptable.

The above seems to be a rehash of the prior on-list arguments made in 
support of this conclusion.

IMO if the request has reached a UAS that is properly authenticated as 
the intended recipient of the request, then the contract implied by SIPS 
has been fulfilled, and what happens after that is out of scope. Whether 
that UAS happens to be a gateway is irrelevant as long as it has the 
proper credentials for the target address.

	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 27 Nov 2006 19:36:56 -0800

On Nov 27, 2006, at 1:42 PM, Paul Kyzivat wrote:

>> Point 4 says basically that PSTN gateway termination can not use  
>> SIPS (to put it in the most pejorative fashion and then defend it.)
> ...
>> The argument has been that SIPS (inside the IP cloud) means "MUST  
>> use TLS."  It has been clearly stated and agreed that it is not  
>> Well, if "equivalent security is NOT okay in the IP domain, why is  
>> it okay for the PSTN?  Do they get  a free pass?  It seems to me  
>> that if we are going to tell secure providers of VoIP that they  
>> must reject SIPS requests (on the grounds that it isn't TLS, and  
>> if that was not required by the caller the caller should have just  
>> used SIP) then we owe it to ourselves and the users to make the  
>> same assertion about the PSTN.
> The above seems to be a rehash of the prior on-list arguments made  
> in support of this conclusion.
>
> IMO if the request has reached a UAS that is properly authenticated  
> as the intended recipient of the request, then the contract implied  
> by SIPS has been fulfilled, and what happens after that is out of  
> scope. Whether that UAS happens to be a gateway is irrelevant as  
> long as it has the proper credentials for the target address.
>
> 	Paul

I don't remember what the consensus was but I'm seem to recall making  
a similar argument to Paul. Perhaps someone could listen to the audio  
recordings of this and try and straight it out. I would be very  
surprised if we had consensus that if one side of a IP to IP gateway  
(such as protocol translator) was doing sips that the other side also  
had to do sips.

---

From: Dean Willis <[email-masked]>
Date: Tue, 28 Nov 2006 09:51:21 -0600

> long as it has the proper credentials for the target address.

So if the CSCF is acting as a B2BUA (which it can sometimes do) it's  
OK to use IPSEC instead of TLS on hops behind that CSCF, even though  
a SIPS: URI was used to initiate the request?

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Nov 2006 11:03:24 -0500

Dean Willis wrote:
>> the intended recipient of the request, then the contract implied by 
>> SIPS has been fulfilled, and what happens after that is out of scope. 
>> Whether that UAS happens to be a gateway is irrelevant as long as it 
>> has the proper credentials for the target address.
>>
> 
> So if the CSCF is acting as a B2BUA (which it can sometimes do) it's OK 
> to use IPSEC instead of TLS on hops behind that CSCF, even though a 
> SIPS: URI was used to initiate the request?

The answer to that depends on the purpose of the B2BUA. My SIPS 
connection is with it. What is appropriate for it to do is up to it to 
decide. If I don't trust it to decide then I shouldn't call it.

In some cases (e.g. the fabled "transparent" B2BUA) it may be that the 
only thing that makes sense on the other side is SIPS again. In other 
cases UDP may be reasonable.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 28 Nov 2006 10:14:17 -0600

Let's try to write up something for the document.
I am pretty sure that I remember that in essence, what we
decided was that:
1) Anything outside SIP network is out-of-scope
2) B2BUA SHOULD preserve SIPS on both sides. (It was also said that
there ain't nothing we
   can do to enforce it of course).

Here is a strawman:

   3.1.  Scope of SIPS

   It is outside of the scope of this document to specify what happens
   when a SIPS URI defines a UAS that "maps" outside of the SIP network.
   For example, to other networks such as the PSTN or an H.323 network.
   These networks have their own standards on what is appropriate
   security levels.

   Derived connections in SIP however should use SIPS end-to-end, even
   accross distinct SIP networks.  For example, If a Back-to-Back-User-
   Agent (B2BUA) receives a request destined to a SIPS Request-URI and
   it forwards it, it should use a SIPS Request-URI on the outgoing
   connection as well.  This could happen for example when the B2BUA is
   Session Border Controller sitting between two SIP networks.  It could
   also happen in an Application Server or with SIP third-party call
   control [RFC3725].

---

From: "Michael Procter" <[email-masked]>
Date: Tue, 28 Nov 2006 08:36:29 -0800

Francois Audet wrote:
> there ain't nothing we can do to enforce it of course).

I think that the second point is arguable, and depends on exactly what
function the B2BUA is performing.  And I also think that this is what
Paul Kyzivat was describing when he wrote:

# IMO if the request has reached a UAS that is properly authenticated as

# the intended recipient of the request, then the contract implied by
SIPS 
# has been fulfilled, and what happens after that is out of scope.

If I send a request to sips:[email-masked], which arrives at a B2BUA
and is subsequently retargeted to sip:[email-masked], then I
think the change from sips to sip is fair - I wanted to reach the AoR
(sips:[email-masked]) using sips, which I have done.

If, on the other hand, I send a request to
sips:[email-masked], which happens to transit a B2BUA
en-route, then changing from sips to sip is not fair - I have not
reached my target in the manner that I have requested.

The distinction is, of course, that in the first case, the B2BUA was the
target of my request, but in the second it was merely a transit point.
Requiring SIPS to SIPS for the latter is an excellent move, but I am not
convinced about requiring it for the former.

Regards,

Michael Procter

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Nov 2006 11:41:53 -0500

I think I am ok with SHOULD for B2BUAs, but I still think it is hard to 
be specific because of the wide variety of things that B2BUAs can do.

Consider a different kind of B2BUA - a conference focus. If it allows 
connections via SIPS, should it require all connections to be SIPS? 
While that might be a policy for some conferences, I don't think it is 
the only reasonable policy.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 28 Nov 2006 11:46:56 -0600

Agreed, that's why it's a should, and that's why that section is
short...

Are we OK with the wording?

And remember: concrete proposals...

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Tuesday, November 28, 2006 08:42
> To: Audet, Francois (SC100:3055)
> Cc: Dean Willis; Joel M. Halpern; SIP WG
> Subject: Re: [Sip] Re: SIPS and the PSTN
> 
> I think I am ok with SHOULD for B2BUAs, but I still think it 
> is hard to be specific because of the wide variety of things 
> that B2BUAs can do.
> 
> Consider a different kind of B2BUA - a conference focus. If 
> it allows connections via SIPS, should it require all 
> connections to be SIPS? 
> While that might be a policy for some conferences, I don't 
> think it is the only reasonable policy.
> 
> 	Paul
> 
> Francois Audet wrote:
> decided was 
> > that:

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Nov 2006 13:16:52 -0500

> convinced about requiring it for the former.

I was thinking of bringing this up. The trick is determining if the 
B2BUA is the target of the request or not. This isn't an easy question 
to answer based on info in 3261.

Ignoring for now the new proposal for loose routing for UAs, I have been 
thinking that a server should determine if it is the UAS for a request 
by first removing any Route headers that refer to it. After that, it 
should only act as a UAS if there are no Route headers and the R-URI 
identifies the server. If there are Route headers that don't refer to 
it, or the R-URI doesn't refer to it, then it can either act as a 
proxy/redirect server, or else it can simply return an error.

BUT I find nothing saying to do any of that. In 8.2 of 3261 there is no 
mention of checking either Route headers or the R-URI. I'm not sure if 
this is intended, or is an oversight.

(Of course with loose routing for UAs this would change. In that case, I 
guess all leading Route headers referring to the server should be 
removed. If the last of these had ";lr" then the R-URI need not 
reference the server and instead identifies the intended callee. If 
there were no Route headers removed, or if the last one didn't have 
";lr", then validation should be the old way.)

If one then introduces B2BUAs into this picture, you need a somewhat 
modified set of rules. In a case that would otherwise require acting as 
a proxy, it might be permissible to act as a "transit B2BUA", 
terminating the incoming request but generating another on the other 
side, preserving the R-URI and the remainder of the Route.

With such a set of rules, I think it would make sense that SIPS be 
preserved across such a "transit B2BUA". Conversely, if the request 
terminates on the B2BUA without any further routing specified, but the 
B2BUA chooses to route it on anyway, then preservation of SIPS would be 
at the discretion of the B2BUA.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Nov 2006 13:42:45 -0500

> And remember: concrete proposals...

I just posted some further thoughts on this. I think they are 
interesting, but probably beyond the scope of this document. (It may be 
getting to the point where we actually need another document to discuss 
kinds of B2BUAs and expected behaviors for them. But I wouldn't want to 
hold this document up for that.)

>    when a SIPS URI defines a UAS that "maps" outside of the SIP network.
                      ^^^^^^^
                      identifies

>    accross distinct SIP networks.  For example,

I am not sure what the above means. What is a "derived connection"? I 
think that part could simply be omitted without loss, though I would not 
object to something a little clearer.

>    If a Back-to-Back-User-
>    Agent (B2BUA) receives a request destined to a
>    SIPS Request-URI
                       ^                                              ^
                       that does not identify itself

>    and it forwards it,
                        ^
                         on towards that Request-URI

>    it should use a SIPS Request-URI on the outgoing
         ^^^^^^
         SHOULD

>    also happen in an Application Server or with SIP third-party call

Putting that all together it comes out as:

     3.1.  Scope of SIPS

     It is outside of the scope of this document to specify what
     happens when a SIPS URI identifies a UAS that "maps" outside
     of the SIP network.

     If a Back-to-Back-User-Agent (B2BUA) receives a request
     destined to a SIPS Request-URI that does not identify itself
     and it forwards it on towards that Request-URI, it SHOULD use
     a SIPS Request-URI on the outgoing connection as well.  This
     could happen for example when the B2BUA is a Session Border
     Controller sitting between two SIP networks.  It could also
     happen in an Application Server or with SIP third-party call
     control [RFC3725].

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 28 Nov 2006 13:02:10 -0600

I'm ok with your wording.

Thanks. 

> Sent: Tuesday, November 28, 2006 10:43
> Cc: Michael Procter; Dean Willis; Joel M. Halpern; SIP WG
> interesting, but probably beyond the scope of this document. 
> (It may be getting to the point where we actually need 
> another document to discuss kinds of B2BUAs and expected 
> behaviors for them. But I wouldn't want to hold this document 
> up for that.)
> 
> I am not sure what the above means. What is a "derived 
> connection"? I think that part could simply be omitted 
> without loss, though I would not object to something a little clearer.
> 
> >    If a Back-to-Back-User-
> >> I think I am ok with SHOULD for B2BUAs, but I still think 
> it is hard 
> >> to be specific because of the wide variety of things that 
> B2BUAs can 
> >> do.
> >>

---

From: Matt Lepinski <[email-masked]>
Date: Tue, 28 Nov 2006 15:15:38 -0500

There appeared to be some confusion regarding the proposed minutes 
(specifically discussion on the 4th Point of Dean's Trial Balloon) and 
the concensus on SIPS and the PSTN.
Therefore, I went back to the audio stream and collected the comments 
made regarding the points of Dean's proposal.

One point of note is that no one present at the meeting appeared to 
supported the idea that a SIPS call fail when it hits a PSTN gateway.

The audio recording can be obtained at:
http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf67/ietf67ch8-thu-noon.mp3 
<http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf67/ietf67ch8-thu-noon.mp3> 

To aid anyone else who wants to listen to the audio stream, the number 
next to each comment is the time (relative to the start of the audio 
stream, represented as Hours:Minutes:Seconds) that the comment was made. 
(I apologize to the speakers whose names I didn't catch and of course 
for any transcription errors in the following.)

[2:41:00] Francois begins his explanation of the four points of Dean's 
Trail Balloon Proposal.

[2:44:40] Question from Jabber Channel: Does Point 2 mean all hops are TLS?
              Answer: Yes

[2:45:30] Explanation of why the functionality provided by SIPS is 
important. [Not directly related to Point 4]

[2:47:45] Eric Burger says that we should remove Point 4. "Take the 
whole thing out [referring to Point 4] ... Unless it's really end-to-end 
it's like a non-solvable problem. 'It' being not just to a PSTN gateway, 
but to another IP gateway or whatever. If it is to a PSTN gateway that 
does terminate to a PSTN phone then actually the SIPS thing, the 
promise, was kept and if it's a gateway to another SIP thing then it is 
not kept ... Just don't mention PSTN termination"

[2:48:40] Question to Eric: "What about other protocols that you might 
gateway to?"
              Eric's Answer: "It's a non-solvable problem." Therefore, 
delete bullet 4.

[2:48:50] Paul Kyzivat begins, "I've said all I want to say about 4, I'm 
not going to say anymore." He then argues against bullet 1 being a 
SHOULD. "I just don't believe that most of the time it's going to be 
done. And if it isn't going to be done most of the time then putting the 
SHOULD in is just holding out a false promise to people."

[2:49:45] Cullen Jennings comments on Points 1 and 4. On Point 1 he says 
"I think that we need to very clearly differentiate between what you to 
implement and what you need to use. As a general rule of thumb, on lots 
of our things here, we've tried to get people to implement security but 
not say that people necessarily have to use security." On Point 4 he 
says "I have a clear phrasing of what the commitment is, which is you're 
going to use TLS all the way to the UA. That's what I think it should 
be. Now my UA happens to be a speaker phone and I'm sitting in this room 
right now and there's a hundred people. I mean SIPS doesn't mean 
anything about what's going to happen on the other side of that speaker 
phone. I don't think it means anything about what's going to happen on 
the other side of that gateway. I don't think it means anything about 
what's going to happen on the other side of that protocol translator. 
Hopefully the protocol translater would do reasonable things, but it is 
impossible for us to specify beyond that point."

[2:51:00] Question for Cullen: "Would you say that it's a best current 
practice for an SBC to terminate a SIPS connection and generate a SIP 
connection on the other side?"

[2:51:15] Cullen replies: "I think that one of the most useful features 
that an SBC vender could offer today would be the one on the edge of an 
enterprise that could take unsecure phone calls from venders that hadn't 
managed to implement all of this stuff inside the enterprise and secure 
it as it crossed the internet. I think that's a great thing for people 
to go build. Needless to say the same thing needs to happen on incoming 
calls ... It doesn't matter what we say in these specifications though. 
Short of us breaking the PSTN there's no way to solve this ... We should 
not pretend that SIPS means anything beyond the UA."

[2:52:15] New speaker <didn't catch name> comments on Points 1 and 4. On 
Point 1 he observes that in IMS you end up using SIPS over an IPSEC 
connection. Therefore, you're encrypting the signalling twice, once with 
TLS and once with IPSEC.  He raises the question: Is it good for us to 
do that? On Point 4, he says  that we cannot go into the PSTN and we 
should not go beyond the IP side gaurantees that SIPS can provide.

[2:53:05] New speaker reminds everyone that it is Dean and not Francois 
that is to the source of this controversy.
              "The one thing that I would say about 4 is for certain 
forms of protocol interworking where we're dealing with something that's 
going from IP to IP, basically from one IP based protocol to another 
one, I wouldn't see the harm in having something that was a BCP have 
like a SHOULD level thing saying if there is a comparable sort of  
mechanism in that protocol than you should try to invoke it ... I think 
you would certainly want to fail it if that capability was available in 
the other protocol but not invokable ... I wouldn't be opposed to there 
being some language like that. For something like PSTN which is so 
dissimilar to the way that SIP operates, I don't think it's reasonable 
to expect that any of this carries over ... So, no number 1, please and 
a softer 4."

[2:54:30] New speaker agrees with previous speaker. "That's exactly the 
same opinion that I had for PSTN and for similar networks."

[2:54:45] New speaker points out that Brian Rosen (who is not present) 
is adamant that SIPS calls should fail if they reach a PSTN gateway.

[2:54:55] Hadriel Kaplan agrees that Point 1 shouldn't be a SHOULD, "You 
can change it from a SHOULD to a MIGHT". He then comments on Point 4, 
"There's no question that SIPS is SIPS, it's part of SIP, not H.323, not 
PSTN, SS7, whatever. When you've reached the UAS, you've reached the 
UAS. You want to write a BCP, go right ahead, but the people who don't 
want to keep it SIPS or use SIPS or whatever will just ignore the BCP. 
For an SBC in particular ... As far as I know most of the SBC's that do 
support SIPS will obviously try to keep it SIPS on the other side of 
themselves. And, guess what, if the operator doesn't want them to, or 
says 'no you don't have to and you can use SIP', then they will do that 
because that's the whole concept of an SBC is that the operator decides 
... I don't know the point of a BCP." He then goes on and argues that 
SIPS should not be deprecated.

[2:56:45] Dean Willis addresses Hadriel's point on the need for a BCP. 
His analogy is that a BCP on operational recommendations for SIPS is 
analogous to a BCP on operating email systems that says 'don't be an 
open email relay'.

[2:57:30] Hadriel says he understands but "It just seemed to me to be 
kind of funny, like writing a BCP that says 'Be Good'. The guys who 
don't won't to be good, won't be. There's no point in telling them to be 
good."

[2:57:45] Dean says "It's more on the order of 'if you don't lock your 
doors, people can wander in through your doors'."

[2:57:50] Hadriel says "Oh, you think that people might do it accidently 
... You think they might just misconfigure ... I'm with you."

[2:58:30] Jon Elwell comments on Point 4 "I agree with the majority, I 
think, that it has to stop at the UAS, whether that's a SIP gateway or a 
phone or a speaker phone or whatever. I'm a little bit concerned about 
the B2BUA case, particularly what you mentioned Dean. If a B2BUA SBC 
upgrades a SIP request to SIPS then I guess no harm is done. The other 
way around though is a bit worse ... We don't normally legislate for 
B2BUA's, that's the problem, so I don't know how we deal with this, but 
I'm a little bit uneasy about it."

[2:59:20] Francois says, "I think the wording that Jon Peterson had 
actually applies here. It's a similar network. It's kind of two 
back-to-back SIP networks. It seems like a BCP-type thing."

[2:59:30] Keith says, "My assumption of the point of this conversation 
is that basically we now reflect the pros and cons in the document."

[2:59:45] Francois indicates that he has a sense from the room of what 
we heard. "[Point] 1 I think is some level of support but not that much. 
[Point] 4 I think we have a pretty good concesus except for one person 
who's not here. [Point] 3 is obvious, and [Point] 2 I think is ... 
implicitly I think that people like the idea of deprecating the last hop 
but we didn't really have a vote or anything on that."

[3:00:20] Dean says "I think we have concensus on pretty much everything 
except for the fine-print writing of 4, and I think there's a fairly 
strong sense that number 1 is out of place and it just echos what's 
already in 3261. So I think we can reduce number 4 to a should level and 
explain the issues and do away with number 1 and I think everyone 
besides Brian Rosen will be happy."

> On Nov 27, 2006, at 1:42 PM, Paul Kyzivat wrote:

<snip>

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 28 Nov 2006 15:30:20 -0600

Thanks Matt. That is very useful.

PS: The name you didn't catch in there was John Peterson.

In light of the transcript, are people OK with the current wording, as
ammended by Paul Kyzivat? At least as a starting point point for 
version -00 of the working group document?

> From: Matt Lepinski [mailto:[email-masked]] 
> Sent: Tuesday, November 28, 2006 12:16
> To: SIP WG
> Subject: Re: [Sip] Re: SIPS and the PSTN (Meeting Audio)
> 
> There appeared to be some confusion regarding the proposed 
> minutes (specifically discussion on the 4th Point of Dean's 
> Trial Balloon) and the concensus on SIPS and the PSTN.
> Therefore, I went back to the audio stream and collected the 
> comments made regarding the points of Dean's proposal.
> 
> One point of note is that no one present at the meeting 
> appeared to supported the idea that a SIPS call fail when it 
> hits a PSTN gateway.
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 28 Nov 2006 16:43:04 -0500

I must say I'm a bit worried about 'should'. I think Dean raised this 
point; since tons of "proxies" todays are also b2bua's in some sense 
(that is, they do things a pure proxy cannot), this may very well reduce 
the overall effectiveness of sips to just SHOULD use TLS. That seems 
ever looser than what we have today.

I'd rather not try to define what constitutes a b2bua that can downgrade 
sips, and what kind of b2bua cannot. Instead, it seems easier to simply 
state that if you are not the target of the sips URI, and you have a SIP 
next-hop, you MUST use TLS on that hop.

-Jonathan R.

Francois Audet wrote:

>>>   It is outside of the scope of this document to specify 
>>
>>what happens
>>
>>>   when a SIPS URI defines a UAS that "maps" outside of the 
>>
>>SIP network.
>>
>>>   For example, to other networks such as the PSTN or an 
>>
>>H.323 network.
>>
>>>   Derived connections in SIP however should use SIPS 
>>
>>end-to-end, even
>>
>>>   accross distinct SIP networks.  For example, If a 
>>
>>Back-to-Back-User-
>>
>>>   Agent (B2BUA) receives a request destined to a SIPS 
>>
>>Request-URI and
>>
>>>   connection as well.  This could happen for example when 
>>
>>the B2BUA is
>>
>>>   Session Border Controller sitting between two SIP 
>>
>>networks.  It could
>>

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 28 Nov 2006 16:09:33 -0600

What about this:

3.1.  Scope of SIPS

   It is outside of the scope of this document to specify what happens
   when a SIPS URI identifies a UAS that "maps" outside of the SIP
   network.  For example, to other networks such as the PSTN or an H.323
   network.  These networks have their own standards on what is
   appropriate security level
   
   If a B2BUA is used in lieu of a proxy (as is common in practical
deployment), 
   if it receives a request destined to a SIPS Request-URI that does not
identify itself 
   and it forwards it on towards that Request-URI, it must use a 
   SIPS Request-URI on the outgoing connection as well.  

> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Tuesday, November 28, 2006 13:43
> Cc: Paul Kyzivat; Michael Procter; Joel M. Halpern; SIP WG; 
> Dean Willis
> I must say I'm a bit worried about 'should'. I think Dean 
> raised this point; since tons of "proxies" todays are also 
> b2bua's in some sense (that is, they do things a pure proxy 
> cannot), this may very well reduce the overall effectiveness 
> of sips to just SHOULD use TLS. That seems ever looser than 
> what we have today.
> 
> I'd rather not try to define what constitutes a b2bua that 
> can downgrade sips, and what kind of b2bua cannot. Instead, 
> it seems easier to simply state that if you are not the 
> target of the sips URI, and you have a SIP next-hop, you MUST 
> use TLS on that hop.
> 
> -Jonathan R.
> 
> Francois Audet wrote:
> 
> it allows 
> > 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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 28 Nov 2006 17:30:31 -0500

Making the must capital in the second paragraph, sounds good to me.

-Jonathan R.

Francois Audet wrote:

>>think it is 
>>>>>2) B2BUA SHOULD preserve SIPS on both sides. (It was also 
>>
>>said that 
>>
>>>>>there ain't nothing we
>>>>>  also happen in an Application Server or with SIP 
>>
>>third-party call
>>
>>>>>  control [RFC3725].
>>>>>
>>>>

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 28 Nov 2006 17:23:08 -0600

Yeah, except that I've been instructed by the Chairs that this document
is 'informational' only.

I assume that it means that I can't make normative statements of any
kind. Is this true?

> Sent: Tuesday, November 28, 2006 14:31
> >    if it receives a request destined to a SIPS Request-URI 
> that does 
> > not identify itself
> >>Cc: Paul Kyzivat; Michael Procter; Joel M. Halpern; SIP WG; Dean 
> >>Willis
> raised this 
> >>(that is, they do things a pure proxy cannot), this may very well 
> >>reduce the overall effectiveness of sips to just SHOULD use 
> TLS. That 
> >>seems ever looser than what we have today.
> >>
> >>I'd rather not try to define what constitutes a b2bua that can 
> >>downgrade sips, and what kind of b2bua cannot. Instead, it seems 
> >>easier to simply state that if you are not the target of 
> the sips URI, 
> >>and you have a SIP next-hop, you MUST use TLS on that hop.
> >>
> >>-Jonathan R.
> >>
> >>Francois Audet wrote:
> >>
> >>

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 28 Nov 2006 17:44:59 -0600

IMHO, after SIPS we are committing one more mistake. After knowing SIPS
is completely broken, we are attempting to justify the need on the
charter. I am failing to see the value of any these documents. Rather go
to IESG directly and get this milestone removed from the charter. All
this is merely wastage of cycles. BTW, I don't want to open the complete
ranting mode now.

Thx
Samir

> From: Audet, Francois (SC100:3055)
> Sent: Tuesday, November 28, 2006 3:23 PM
> To: Jonathan Rosenberg
> Cc: SIP WG; Drage, Keith (Keith); Dean Willis
> Subject: RE: [Sip] Re: SIPS and the PSTN
>

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 29 Nov 2006 08:23:34 +0100

I see the value of a document clarifying RFC3261 and documenting best 
practices around SIPS. However, I also think there are limits to what a 
draft can hope to achieve. Saying that a B2BUA MUST do this and that will 
not magically change the way the world is evolving. A B2BUA that forwards 
SIPS to SIP can still interoperate, it may be breaking the implicit 
assumptions / expectations that (some of) the standards people have/had in 
mind while specifying the SIP protocol, but to the average consumer that 
won't make much difference. So in short: write down what may happen when 
using SIPS, recommend what should ideally happen, and move on.

Regards,
Jeroen

Samir Srivastava wrote:
> IMHO, after SIPS we are committing one more mistake. After knowing
> SIPS is completely broken, we are attempting to justify the need on
> the charter. I am failing to see the value of any these documents.
> Rather go to IESG directly and get this milestone removed from the
> charter. All this is merely wastage of cycles. BTW, I don't want to
> open the complete ranting mode now.
>
> Thx
> Samir
>
>> Yeah, except that I've been instructed by the Chairs that this
>> document is 'informational' only.
>>

---

From: "Samir Srivastava" <[email-masked]>
Date: Wed, 29 Nov 2006 05:17:18 -0600

What is the utility of SIPS ? I have posted so many times the limitation
of SIPS.
Tell me what part you like. Double entries. Upgrade / dowgrade etc.
retargeting. What will you do for telURI. It's a king with underwar only
as Paul said in the frustration earlier.

Thx
Samir 

>From: Jeroen van Bemmel [mailto:[email-masked]] 
>Sent: Tuesday, November 28, 2006 11:24 PM
>To: Srivastava, Samir (SC100:8826); Audet, Francois 
>(SC100:3055); Jonathan Rosenberg
>I see the value of a document clarifying RFC3261 and 
>documenting best practices around SIPS. However, I also think 
>there are limits to what a draft can hope to achieve. Saying 
>that a B2BUA MUST do this and that will not magically change 
>the way the world is evolving. A B2BUA that forwards SIPS to 
>SIP can still interoperate, it may be breaking the implicit 
>assumptions / expectations that (some of) the standards people 
>have/had in mind while specifying the SIP protocol, but to the 
>average consumer that won't make much difference. So in short: 
>write down what may happen when using SIPS, recommend what 
>should ideally happen, and move on.
>
>Regards,
>Jeroen
>
>Samir Srivastava wrote:

---

From: "Samir Srivastava" <[email-masked]>
Date: Wed, 29 Nov 2006 05:25:14 -0600

Added to this, we have S/MIME mentioned at so many places. But nobody is
using it.
I think similar will be for SIPS. Also as per the process, refer CMM/SEI
KPA's there is constant process improvement. If IETF current process
doesn't allow to remove the milestone, then update the process. It's
causing more of a pain. Who will be using SIPS ?

Should we voting on the mailing list for the need of the this document ?
I am frustrated the way this group behaves. It wanted to get rid of
RUNNING CODE well established truth, but for this idiotic document, you
don't want to agree. It has been two meetings. Ideally it should have
been gone in the Montreal itself, if people allowed me to speak. At that
time where was your purist mindset, which you were arguing for the PING.

Thx
Samir 

>From: Srivastava, Samir (SC100:8826) 
>Sent: Wednesday, November 29, 2006 3:17 AM
>To: Jeroen van Bemmel; Audet, Francois (SC100:3055); Jonathan Rosenberg
>What is the utility of SIPS ? I have posted so many times the 
>limitation of SIPS.
>retargeting. What will you do for telURI. It's a king with 
>underwar only as Paul said in the frustration earlier.
>
>Thx
>Samir 
>
>>To: Srivastava, Samir (SC100:8826); Audet, Francois (SC100:3055); 
>>Jonathan Rosenberg
>>draft can hope to achieve. Saying that a B2BUA MUST do this and that 
>>will not magically change the way the world is evolving. A B2BUA that 
>>forwards SIPS to SIP can still interoperate, it may be breaking the 
>>implicit assumptions / expectations that (some of) the 
>standards people 
>>have/had in mind while specifying the SIP protocol, but to 
>the average 
>>consumer that won't make much difference. So in short:
>>write down what may happen when using SIPS, recommend what should 
>>ideally happen, and move on.
>>
>>Regards,
>>Jeroen
>>
>>Samir Srivastava wrote:
>[email-masked] for questions on current sip

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Wed, 29 Nov 2006 12:45:02 +0100

(As WG chair)

If you wish the IETF rules allow you to do this.

To make very clear the position:

If you wish to achieve what you want, which is deprecation of various
requirements in RFC 3261, then you have already been asked to provide
the appropriate discussion material to this internet-draft. Part of the
output of the internet-draft is to make recommendations on improvement,
which can include deprecation. But we want to see the WG making an
informed decision, based on a clear understanding of what is the impact
on existing implementations, why the existing mechanism causes damage in
the community, and so on.

The scope of the internet-draft is made very clear in the slides
(http://www3.ietf.org/proceedings/06nov/slides/sip-2.pdf) - see slide 2.

Regards

Keith

> From: Samir Srivastava [mailto:[email-masked]] 
> Sent: 28 November 2006 23:45
> To: Francois Audet; Jonathan Rosenberg
> IMHO, after SIPS we are committing one more mistake. After 
> knowing SIPS is completely broken, we are attempting to 
> justify the need on the charter. I am failing to see the 
> value of any these documents. Rather go to IESG directly and 
> get this milestone removed from the charter. All this is 
> merely wastage of cycles. BTW, I don't want to open the 
> complete ranting mode now.
> 
> Thx
> Samir
>

---

From: "Samir Srivastava" <[email-masked]>
Date: Wed, 29 Nov 2006 05:54:17 -0600

Let me ask a question straigtaway who would like to use SIPS ?

There was no voting/hum was done on the need of this doc in the meeting.
I questioned in the meeting the need of the doc. On which Dean replied
that we have similar for email etc. email is used, I can agree. But we
know that this will not be used. Do you want to spend cycles on
documenting/discussing for just gaguing the implementor's pain versus
the complete brokenness of SIPS. 

Tell me where it is useful? It cannot be even used in the protected
network, where event watchers etc are involved.

If you are one of the implementers, then do the proper analysis before
implementing.

Thx
Samir

>From: Drage, Keith (Keith) [mailto:[email-masked]] 
>Sent: Wednesday, November 29, 2006 3:45 AM
>Cc: SIP WG; Dean Willis
>If you wish to achieve what you want, which is deprecation of 
>various requirements in RFC 3261, then you have already been 
>asked to provide the appropriate discussion material to this 
>internet-draft. Part of the output of the internet-draft is to 
>make recommendations on improvement, which can include 
>deprecation. But we want to see the WG making an informed 
>decision, based on a clear understanding of what is the impact 
>on existing implementations, why the existing mechanism causes 
>damage in the community, and so on.
>

---

From: "Samir Srivastava" <[email-masked]>
Date: Wed, 29 Nov 2006 06:13:14 -0600

I would like to have the chair's permission for the voting on the need
of this document on the list. Who would like to see this document to
progress ?

Thx
Samir

---

From: "Michael Procter" <[email-masked]>
Date: Wed, 29 Nov 2006 06:55:54 -0800

Personally, I think that the initial qualifying phrase of the last
paragraph is potentially ambiguous:

    If a B2BUA is used in lieu of a proxy (as is common in practical
    deployment), if it receives...

Could this be removed and an explanatory sentence appended to the
paragraph to make it read more like:

    If a B2BUA (Back to Back User Agent) receives a request destined
    to a SIPS Request-URI that does not identify itself
    and it forwards it on towards that Request-URI, it must use a
    SIPS Request-URI on the outgoing connection as well.  This can
    occur when a B2BUA is used in lieu of a proxy (as is common in
    practical deployments).

As to whether 'must' should be MUST or must or SHOULD or should, I'll
leave that to you!

Regards,

Michael

> From: Francois Audet [mailto:[email-masked]]
> Sent: 28 November 2006 22:10
> To: Jonathan Rosenberg
Willis

---

From: Michael Thomas <[email-masked]>
Date: Wed, 29 Nov 2006 08:05:05 -0800

This seems very much at cross purposes with Francois' draft and would
just add to the confusion, IMO. What would be better is for Francois' draft
to add that option along with the documentation (which in itself is like
proving a negative, but I digress) and then have the working group just
choose which section of the draft to delete, or insert what the ultimate
choice was or something like that. I think that documenting why SIPS
was or wasn't deprecated is every bit as important as clarifying the
mistakes that were made initially.

       Mike

Drage, Keith (Keith) wrote:
>> document
>>> I assume that it means that I can't make normative 
>>>       
>> statements of any 
>>     
>>> kind. Is this true?
>>>
>>>       
>>     
>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 29 Nov 2006 12:38:01 -0600

Hi all,

After re-reading the transcript (especially the points made by Cullen
Jennings, Eric Burger and
Jon Peterson), and further confirmed by the emailing list discussion, I
believe that we should 
not discuss B2BUA at all and limit it it what happens in the SIP
network.

This is what I am now proposing.

3.1.  Scope of SIPS

   SIPS means that the SIP resource designated by the target SIPS
   URI be contacted securily, using TLS, on each SIP hop (last-hop
exception 
   nothwistanding). It is outside of the scope of this document to
specify 
   what happens when a SIPS URI identifies a UAS resource that "maps"
outside
   of the SIP network, for example, to other networks such as the PSTN.

---

From: "Samir Srivastava" <[email-masked]>
Date: Wed, 29 Nov 2006 12:49:36 -0600

Hi Mike,

   Francois personally asked me to make my case separately in another
draft. He wanted in his draft the SIPS the way it is etc.

Therefore I don't see any value in it at all, as it will not cover why
the SIPS is bad for health etc. Why don't we cover this in the next
version cipher-suite draft. It will state that it fixes the open holes
of SIPS also with the proxy-require of cipher-suite.

Thx
Samir  

>From: Michael Thomas [mailto:[email-masked]] 
>Sent: Wednesday, November 29, 2006 8:05 AM
>To: Drage, Keith (Keith)
>Cc: Srivastava, Samir (SC100:8826); Audet, Francois 
>(SC100:3055); Jonathan Rosenberg; SIP WG; Dean Willis
>This seems very much at cross purposes with Francois' draft 
>and would just add to the confusion, IMO. What would be better 
>is for Francois' draft to add that option along with the 
>documentation (which in itself is like proving a negative, but 
>I digress) and then have the working group just choose which 
>section of the draft to delete, or insert what the ultimate 
>choice was or something like that. I think that documenting 
>why SIPS was or wasn't deprecated is every bit as important as 
>clarifying the mistakes that were made initially.
>
>       Mike
>
>
>
>> the appropriate discussion material to this internet-draft. Part of 
>> the output of the internet-draft is to make recommendations on 
>> improvement, which can include deprecation. But we want to 
>see the WG 
>> making an informed decision, based on a clear understanding 
>of what is 
>> the impact on existing implementations, why the existing mechanism 
>> causes damage in the community, and so on.
>>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 29 Nov 2006 13:28:11 -0600

Samir,

I am simply restating what the Chair told you a few times now. 
Last time was yesterday:
http://www1.ietf.org/mail-archive/web/sip/current/msg17544.html

You need to clearly make your case, and the the group needs to agree
with 
it before we integrate it in a working group document.

> Sent: Wednesday, November 29, 2006 10:50
> To: Michael Thomas; Drage, Keith (Keith)
> Cc: Audet, Francois (SC100:3055); Jonathan Rosenberg; SIP WG; 
> Dean Willis
>    Francois personally asked me to make my case separately in 
> another draft. He wanted in his draft the SIPS the way it is etc.
> 
> Therefore I don't see any value in it at all, as it will not 
> cover why the SIPS is bad for health etc. Why don't we cover 
> this in the next version cipher-suite draft. It will state 
> that it fixes the open holes of SIPS also with the 
> proxy-require of cipher-suite.
> 
> Thx
> Samir  
> 
> >Cc: Srivastava, Samir (SC100:8826); Audet, Francois (SC100:3055); 
> >Jonathan Rosenberg; SIP WG; Dean Willis
> and would 
> >just add to the confusion, IMO. What would be better is for 
> Francois' 
> >draft to add that option along with the documentation (which 
> in itself 
> >is like proving a negative, but I digress) and then have the working 
> >group just choose which section of the draft to delete, or 
> insert what 
> >the ultimate choice was or something like that. I think that 
> >documenting why SIPS was or wasn't deprecated is every bit 
> as important 
> >as clarifying the mistakes that were made initially.
> >
> >       Mike
> >
> >
> >

---

From: Dean Willis <[email-masked]>
Date: Wed, 29 Nov 2006 13:32:45 -0600

One possibility is to consider this doc as a BCP, not Info, and BCP  
can quite reasonably use 2119 language. This is an AD call.

It might also be reasonable to use 2119 language in an Informational  
document. We frequently do this in the case of requirements documents.

Where 2119 language is used in an informational document, we have to  
be clear about why we're using it. For example, "in order to preserve  
the intent of sips: as discussed in RFC 3261, any proxy or proxy-like  
device MUST use TLS and a sips: request URI when relaying a request  
received with a sips: request URI. Failure to do so would . . . "

Here you're not talking about protocol specification, but operational  
requirements needed to meet a protocol specification.

--
dean

---

From: "Samir Srivastava" <[email-masked]>
Date: Wed, 29 Nov 2006 13:49:22 -0600

Francois,

>From the same link, I am including the message

"If you wish to achieve what you want, which is deprecation of various
requirements in RFC 3261, then you have already been asked to provide
the appropriate discussion material to **this internet-draft**."

What this draft means ? Yours Correct.

And you yourself is asking to me make my case separately here. I am lost
where the glory of SIPS will be documented.

Thx
Samir

>Sent: Wednesday, November 29, 2006 11:28 AM
>To: Srivastava, Samir (SC100:8826); 'Drage, Keith (Keith)'
>Cc: 'SIP WG'
>You need to clearly make your case, and the the group needs to 
>agree with it before we integrate it in a working group document.
>
>
>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 29 Nov 2006 14:21:53 -0600

I'm fine either way (i.e., Info with lenghty explanation, or BCP). 
I prefer the BCP approach personally, but I'm OK either way.

What I don't like is the just changing upppercase to lowercase....

For now I guess I'll just assume Info with lenghty explanation.

> From: Dean Willis [mailto:[email-masked]] 
> Sent: Wednesday, November 29, 2006 11:33
> Cc: Jonathan Rosenberg; SIP WG; Drage, Keith (Keith)
> One possibility is to consider this doc as a BCP, not Info, 
> and BCP can quite reasonably use 2119 language. This is an AD call.
> 
> It might also be reasonable to use 2119 language in an 
> Informational document. We frequently do this in the case of 
> requirements documents.
> 
> Where 2119 language is used in an informational document, we 
> have to be clear about why we're using it. For example, "in 
> order to preserve the intent of sips: as discussed in RFC 
> 3261, any proxy or proxy-like device MUST use TLS and a sips: 
> request URI when relaying a request received with a sips: 
> request URI. Failure to do so would . . . "
> 
> Here you're not talking about protocol specification, but 
> operational requirements needed to meet a protocol specification.
> 
> --
> dean
>

---

From: "Snyder, Duke" <[email-masked]>
Date: Wed, 29 Nov 2006 15:25:28 -0500

Some want sips to mean "use TLS end to end" (and I don't think "end" has
been defined, as in the case of a SIP/PSTN gateway).  I think what is
really needed is a mechanism to request some minimal level of security
for the signalling and the payload.   If sips=TLS, what would stop a SBC
from using TLS/SRTP on one side and TLS/RTP on the other, sending the
audio of the call un-encrypted?    The 'whole' call is not very secure,
which probably was the original intent of sips.

Also, TLS is not the only mechanism to secure the signaling.   Is TCP
over a VPN secure?  Is UDP over a protected LAN to a protected phone in
a protected room secure?   Don't count out the devices on the network
that have other ways to secure a call.   

I think saying "sips"="TLS end to end" is not a good idea.

-----Original Message-----
From: Samir Srivastava [mailto:[email-masked]] 
Sent: Wednesday, November 29, 2006 2:49 PM
To: Francois Audet; Drage, Keith (Keith)
Cc: SIP WG
Subject: RE: [Sip] Re: SIPS and the PSTN

Francois,

Thx
Samir

Use [email-masked] for questions on current sip Use

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 29 Nov 2006 17:08:33 -0800

With my AD hat on ...

Let's figure out what this document needs to say, including normative  
language. Once we have that it will be easy to figure out if it is  
INFO, BCP, or a PS that updates 3261.

Cullen <with my AD hat on>

On Nov 29, 2006, at 11:32 AM, Dean Willis wrote:

> Where 2119 language is used in an informational document, we have  
> to be clear about why we're using it. For example, "in order to  
> preserve the intent of sips: as discussed in RFC 3261, any proxy or  
> proxy-like device MUST use TLS and a sips: request URI when  
> relaying a request received with a sips: request URI. Failure to do  
> so would . . . "
>