[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] Further proceeding with draft-ietf-sipping-update-pai--05
Given that (3) looks to be a lot of work, I think that (4) is the best
alternative.
Thanks,
Paul
Elwell, John wrote:
> 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