[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] Further proceeding with draft-ietf-sipping-update-pai--05
Hi all,
There was not tremendous response to John's query for consensus on this
document (perhaps due to summer holidays as Cullen suggested).
At this point, with two responses (Paul and Cullen), text (TBD) around
option 4 is the most popular, but we really need feedback from others to
move this forward. I will ping the other past reviewers in another email
(so that responses to the thread don't get too many addressees) but we
would really appreciate if others would respond.
Thanks,
Mary.
-----Original Message-----
From: sipping-bounces at ietf.org [mailto:sipping-bounces at ietf.org] On
Behalf Of Elwell, John
Sent: Wednesday, September 03, 2008 11:37 AM
To: Cullen Jennings
Cc: sipping
Subject: Re: [Sipping] Further proceeding with
draft-ietf-sipping-update-pai--05
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
_______________________________________________
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