Re: [Sipping] Further proceeding with draft-ietf-sipping-update-pai--05

["Elwell, John" <john.elwell at siemens.com>]

Cullen, 

> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy at cisco.com] 
> Sent: 03 September 2008 17:15
> To: Elwell, John
> Cc: sipping
> Subject: Re: [Sipping] Further proceeding with 
> draft-ietf-sipping-update-pai--05
> 
> 
> On Sep 3, 2008, at 1:35 AM, Elwell, John wrote:
> 
> > I received no feedback in the changes made in draft-05 
> concerning the
> > forward compatibility mechanism, nor on the particular 
> issue I asked  
> > for
> > comments on:
> > http://www.ietf.org/mail-archive/web/sipping/current/msg16105.html
> > Therefore I assume these changes are acceptable.
> >
> 
> Uh, be careful with this sort of assumption. Unless you have 
> consensus  
> for significant technical changes, you should not be making 
> them to WG  
> documents.
> I'm trying to separating technical changes from editorial  
> changes here - obviously I think the editor should just make 
> editorial  
> changes and technical changes which either have, or clearly would  
> have, census.  This change is not backwards compatible with 
> some 3325  
> implementations and I don't think you have consensus one way or the  
> other on it. Silence does not necessarily imply people agree - I  
> suspect few people have read this. Perhaps my recollection of 
> how this  
> went in the meeting is wrong - I have not gone back and 
> looked at the  
> notes.
[JRE] I hope the changes reflect what we seemed to be reaching consensus
on in the meeting. Obviously I wanted to confirm that consensus on the
mailing list, as well as confirming that I had implemented it correctly
in draft-05.
However, looking at the minutes, I see it states "Another draft can
address forward-compatibility issues...". I came away with the feeling
that people wanted a forward compatibility requirement placed in the
document right now, i.e., in the next draft, draft-05. I see now that
the minutes can be interpreted a different way, i.e., in a completely
separate draft. If I had misinterpreted the mood of the meeting on this
aspect, we can certainly go back to the text of 04. Other opinions?
Nobody shouted when draft-05 appeared, which is why I sent the reminder
today.

> >
> >
> > So we have the one remaining issue concerning response 
> authentication.
> > We had some list discussion on this, the last one being on 20th  
> > August:
> > http://www.ietf.org/mail-archive/web/sipping/current/msg16121.html
> >
> > The use of PAI in responses is something that needs clarifying,  
> > because
> > RFC 3325 is ambiguous (sometimes it talks about SIP messages, other
> > times it specifically talks about requests). In one place 
> it actually
> > states "message (request or response)".
> >
> > So I think we have the following options:
> >
> > 1. Say nothing about responses at all, thereby leaving us with the
> > ambiguity that exists in RFC 3325. I don't think this is a sensible
> > option. A lot of the value of updating RFC 3325 is lost if we don't
> > tackle the response ambiguity issue.
> >
> > 2. Clarify the situation by stating that PAI (and PPI) MUST NOT be  
> > used
> > in responses. I would be very reluctant to go down this 
> path, since I
> > know there is a lot of use of PAI in responses (e.g., in 3GPP).
> >
> >
> >
> > 3. Devise a mechanism that exploits TLS to achieve authenticated
> > response identity and use this in the update-pai draft. As Cullen
> > pointed out, this needs to be a separate and non-trivial piece of  
> > work,
> > probably done in the SIP WG. Waiting for this would hold up 
> update-pai
> > for a considerable time.
> >
> > 4. Go ahead with the present update-pai draft, leaving it 
> open how to
> > achieve authentication of a response. The present example 
> of how to do
> > this (towards the end of section 3.3) is broken, so would have to be
> > removed, or at least qualified.
> >
> > Any other options?
> >
> Saying is "MUST NOT be used"  is not the right path since at least  
> some people want to leave the door open to adding this in future  
> specifications. Describing how to do is not something that should be  
> done as an update to 3325 because the solution to response identity  
> have a wider implication than just PAI - if we are going to do that,  
> we should do it in some separate draft in SIP. If folks agree with  
> that, it seems like something along lines of option 4 is the right  
> path where we say that PAI is not currently defined for 
> responses but  
> future specifications may do so. I think it is also important 
> for the  
> draft to document some of the reasons around why it is not 
> defined for  
> responses.
[JRE] Your proposal seems to be a toned down version of option 4, but
basically I agree - its just a matter of finding the right words. Let's
see what other opinions we get.

John
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP