Subject: RE: [Sip] RE: TLS meaning

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Mon, 30 Oct 2006 00:50:18 +0100

As WG chair:

Please bear in mind:

1)	The WG agreed at the last meeting that the scope of this
document is an informational document. The minutes clearly state this,
and the charter as follows:

   Mar 2007 Guidelines for use of SIP security to WGLC (Informational)

   Jun 2007 Guidelines for use of SIP security to IESG (Informational)

Was updated to say this. (Both these have been presented to the mailing
list without comment in reasonable time so this as far as I am concerned
is a decision. Therefore this document in itself does not deprecate
SIPS, and we will need to decide to do this later.

2)	This document does not update RFC 3261 it itself. Francois
please update your abstract because this is not what this document does.
You may also want to investigate the RFC 2119 language as a result.
There will have to be other documents that update RFC3261 that are not
this document. Note that we did agree that this document was the basis
of this work, and therefore it should be reissued as a -00 SIP WG
document.

3)	What this document is/was intended to do was:

-	clearly document what we had now, i.e. identify what occurred if
the user attempted xyd, and what level of security they did get if they
attempted xyz.

-	identify what improvements or changes to our current SIP
security, as defined in RFC 3261, where therefore required. These could
fall into the following:

A)	creation of new mechanisms that provided a level of security
that is not provided by the existing mechanisms. I this case we need to
clearly identify the improvement and motivate why it is needed.

B)	changes to existing mechanisms to make them work. In this case,
we need to clearly state why the existing mechanism is broken, i.e. not
interoperable to produce a deterministic result.

C)	deprecation of existing mechanism - the one we seem to be
discussing here. In this case, I (and we are the ones that have to
justify this to the IESG) want to understand firstly why the existing
mechanism is harmful to implementations if it continues to exist, and
also understand the impact on the existing implementation community if
we do deprecate. Therefore what this discussion must do is identify
these reasons and put them in the document.

Regards

Keith

> -----Original Message-----
> From: Francois Audet [mailto:[email-masked]] 
> Sent: 27 October 2006 17:12
> To: IETF SIP List
> Subject: RE: [Sip] RE: TLS meaning
> 
> In case people having noticed, it is looking like we are 
> having a mailing list hum on the following 2 questions:
> 
> 1 - Do you favour deprecating the sips scheme altogether (yes/no)
> 
> 2 - Do you favour getting rid of the last-hop-exception rule (yes/no)
> 
> 
> Note: Voting Yes on 2 does not necessarily imply you are 
> voting No on 1, but it will only make sense if sips is not deprecated.
> 
> I'm keeping track of the vote.
> 
> _______________________________________________
> 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
> 

_______________________________________________
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, 30 Oct 2006 13:36:14 -0600

Thank you very much for stepping in.

I will do exactly as per the directive in this email. 

> From: Drage, Keith (Keith) [mailto:[email-masked]] 
> Sent: Sunday, October 29, 2006 3:50 PM
> To: Audet, Francois (SC100:3055); IETF SIP List
> document is an informational document. The minutes clearly 
> state this, and the charter as follows:
> 
> Was updated to say this. (Both these have been presented to 
> the mailing list without comment in reasonable time so this 
> as far as I am concerned is a decision. Therefore this 
> document in itself does not deprecate SIPS, and we will need 
> to decide to do this later.
> 
> There will have to be other documents that update RFC3261 
> that are not this document. Note that we did agree that this 
> document was the basis of this work, and therefore it should 
> be reissued as a -00 SIP WG document.
> 
> the user attempted xyd, and what level of security they did 
> get if they attempted xyz.
> 
> security, as defined in RFC 3261, where therefore required. 
> These could fall into the following:
> 
> that is not provided by the existing mechanisms. I this case 
> we need to clearly identify the improvement and motivate why 
> it is needed.
> 
> we need to clearly state why the existing mechanism is 
> broken, i.e. not interoperable to produce a deterministic result.
> 
> discussing here. In this case, I (and we are the ones that 
> have to justify this to the IESG) want to understand firstly 
> why the existing mechanism is harmful to implementations if 
> it continues to exist, and also understand the impact on the 
> existing implementation community if we do deprecate. 
> Therefore what this discussion must do is identify these 
> reasons and put them in the document.
> 
> Regards
> 
> Keith
> 
> > In case people having noticed, it is looking like we are having a 
> > mailing list hum on the following 2 questions:
> > 
> voting No on 
> > 1, but it will only make sense if sips is not deprecated.
> > 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> > 
>

---

From: "Samir Srivastava" <[email-masked]>
Date: Mon, 30 Oct 2006 19:15:53 -0600

Thx Keith. 

With due respect to chairs decision, I dissented at the meeting minutes
itself. I who suggested the Proxy-Require/Require was told in the ad-hoc
meeting that there is already consensus on the SIPS and it is not even
on the agenda to discuss. I was not the part of the meeting where that
discussion was done.

BTW, I am eagerly waiting for the contents requested in 3.C ) . 

Thx
Samir