Further proceeding with draft-ietf-sipping-update-pai--05

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.

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

I-D Action:draft-ietf-sipping-cc-transfer-10.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF.

	Title           : Session Initiation Protocol Call Control - Transfer
	Author(s)       : R. Sparks, A. Johnston
	Filename        : draft-ietf-sipping-cc-transfer-10.txt
	Pages           : 58
	Date            : 2008-09-03

This document describes providing Call Transfer capabilities in the
Session Initiation Protocol (SIP).  SIP extensions such as REFER and
Replaces are used to provide a number of transfer services including
blind transfer, consultative transfer, and attended transfer.  This
work is part of the SIP multiparty call control framework.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-transfer-10.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
I-D-Announce mailing list
I-D-Announce <at> ietf.org

Re: FW: WGLC Review: draft-ietf-sipping-presence-scaling-requirements-01.txt

Hi,

as you may remember, a while ago, we (i.e., the chairs) asked whether or 
not we should be publishing this RFC. We got off-list and on-list 
feedback stating that this draft was important and that we should 
publish it. However, we did not get any volunteers in addition to Vijay 
to review this draft (its WGLC ends today).

We would like to get two additional reviewers for this draft before 
progressing it further. Note that this is a fairly short draft and that 
reviewing it should not take long.

In short, if you think this draft is important, the best way to state 
your opinion will be to volunteer to review it ;o)

Thanks,

Gonzalo

Mary Barnes wrote:
> Oops!  I didn't have the right title to get this automatically to the
> authors.  Please make sure to incldue the right address in posting any
> comments on this doc (folks will sometimes miss comments if they're only
> sent to the WG mailing list).
> 
> Thanks,
> Mary. 
> 
> ______________________________________________ 
> From: 	Barnes, Mary (RICH2:AR00)  

Re: 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.
>
>
> 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,  

Re: 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 

Re: 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 

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

On Sep 3, 2008, at 10:37 AM, 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

WGLC review of draft-ietf-sipping-presence-scaling-requirements-01

Draft:  draft-ietf-sipping-presence-scaling-requirements-01
Reviewer: Vijay K. Gurbani
Review Date: Sept-03-2008
Review Deadline: Sept-03-2008
Status: WGLC

Review summary: This draft is basically ready for publication, but has
nits that should be fixed before publication.

I had reviewed -00 version of this draft (thread archived at
http://www.ietf.org/mail-archive/web/sipping/current/msg15465.html).

-01 version addresses a majority of comments in -00.  The ones
below are pertinent to -01.

- REQ-009: I still do not like the vague "tens of millions of
concurrent users" (the reasons for this are in -00.)  It may be
better to rephrase this sentence thus:

   The solution MUST be scalable (note: we view scalability on
   the order of tens of millions of users instead of tens of
   thousands.)

- REQ-010: The suggested rewrite is better than the text in -00.
Some nits on the new text:
   s/will be coming from/will be from/
   s/watchers form the/watchers from the/

- Section 4, third paragraph: I still believe that the phrase
"The IETF sometimes does not give the right priority to actual

Re: I-D ACTION:draft-ietf-sipping-sip-offeranswer-08.txt

Paul,

Paul Kyzivat <pkyzivat <at> cisco.com>
>Shinji,
>
>I've included comments inline. I don't know what we might do with them 
>at this late date. We will have to think about that.

I think these issue should be discribed as BCP in sec. 6.

>Is there a reason you didn't post these comments to sipping? It would be 
>better to have them there for discussion.

there isn't a serious reason. I would post this reply to sipping.

my comments inline.

Regards,
Shinji

>	Thanks,
>	Paul
>
>OKUMURA Shinji wrote:
>> Hi,
>> 
>> Sorry for my late comment.
>> 
>>> 4.1. Message Crossing Case Handling
>>>

Re: Pre-WGLC Review:draft-ietf-sipping-profile-datasets-01.txt

Hi,

I have a few minor comments/questions.

1. Section 4.1.3 - There is a problem with the text "Operators and
Administrators do not want the users to sometimes not be able to modify
or even see" maybe it should say "Operators and Administrators do not
want the users to be able to modify or even see".

2. Section 5. - I think it is the Subscriber that SHOULD indicate all of
the dataset schemas that is supports by listing all of the MIME types
for the supported datasets in the SUBSCRIBE request header: Accept. Not
the Notifier is this correct ?

3. Section 5.5.1.  The 'visibility' Attribute. Some SIP UA's especially
in the enterprise environment have concepts of users and administrators
and separate access controls for data items. For example a SIP UA may
have separate web pages for administrators and users. If the visibility
attribute is set to "admin" the text states "Display of the property
value may be allowed using special administrative interfaces" so I
assume it could be displayed on the administration web pages. But the
draft says nothing as to whether the property value can be modified
using these special administrative interfaces (E.g. Web Pages). However
the text in 4.1.3 indicates that the access control relates to modifying
the data as well as viewing the data.  There would seem little point in
changing the data on the phone locally if the next time a profile is
downloaded the old value is used again so is some other mechanism needed
to control whether the property value can be modified locally at the UA
?