Subject: RE: [Sip] RE: TLS meaning

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Sun, 5 Nov 2006 21:39:37 +0100

I assume you mean you dissented at the meeting itself?

I don't remember (and cannot find) any response to the minutes not being
an accurarate record of what we decided, or any specific comment by you
on list objecting to the contents of the minutes.

Whereever we are on that, I will say is that we work to rough consensus,
not absolute consensus, taking into account both the discussions on the
mailing list and in the meeting.

It is very, very clear that at the moment that we need to do lots more
work, and the INFORMATIONAL document being progressed by Francois is the
way to do that. At the end of that work we will then judge consensus on
what way forward we should go.

So I will stress that the discussion now is not about expressing
opinions. It is about capturing technical input in the INFORMATIONAL
document that can be used for the WG making decisions on sound technical
grounds on what needs to change.

Regards

Keith

> -----Original Message-----
> From: Samir Srivastava [mailto:[email-masked]] 
> Sent: 31 October 2006 01:16
> To: Drage, Keith (Keith); Francois Audet; IETF SIP List
> Subject: RE: [Sip] RE: TLS meaning
> 
> 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
> 
> > -----Original Message-----
> > From: Drage, Keith (Keith) [mailto:[email-masked]]
> > Sent: Sunday, October 29, 2006 3:50 PM
> > To: Audet, Francois (SC100:3055); IETF SIP List
> > Subject: RE: [Sip] RE: TLS meaning
> > 
> > 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
> 

_______________________________________________
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