Re: [BLISS] AD review: draft-ietf-bliss-shared-appearances-06

Robert Sparks <rjsparks@nostrum.com> Fri, 27 January 2012 20:49 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: bliss@ietfa.amsl.com
Delivered-To: bliss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 025F321F86CF for <bliss@ietfa.amsl.com>; Fri, 27 Jan 2012 12:49:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.482
X-Spam-Level:
X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uonane-RtHOu for <bliss@ietfa.amsl.com>; Fri, 27 Jan 2012 12:49:18 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 33D9421F86CE for <bliss@ietf.org>; Fri, 27 Jan 2012 12:49:18 -0800 (PST)
Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q0RKnFBg097372 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 27 Jan 2012 14:49:16 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Message-ID: <4F230DCB.5090509@nostrum.com>
Date: Fri, 27 Jan 2012 14:49:15 -0600
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Alan Johnston <alan.b.johnston@gmail.com>
References: <D47B552B-6B5C-41EB-ABF0-6E127174ADE1@nostrum.com> <E5754669-B9EE-4DED-91E9-F9DFEB0BCB3F@nostrum.com> <AANLkTimVY7NzMQpe+cbD2E2BR80=UdmqYzN4q-5FSV01@mail.gmail.com> <AANLkTi=EHE+j_cpv82hQtFtXvtnjb6Z-oujrpvEpRe+o@mail.gmail.com>
In-Reply-To: <AANLkTi=EHE+j_cpv82hQtFtXvtnjb6Z-oujrpvEpRe+o@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Cc: bliss@ietf.org
Subject: Re: [BLISS] AD review: draft-ietf-bliss-shared-appearances-06
X-BeenThere: bliss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" <bliss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bliss>, <mailto:bliss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bliss>
List-Post: <mailto:bliss@ietf.org>
List-Help: <mailto:bliss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bliss>, <mailto:bliss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Jan 2012 20:49:19 -0000

Hi Alan -

Going through the threads leading to version -09 - there were some things
in this message that I'm not seeing an obvious resolution to. Can you 
point to where
or how they were addressed?

(Trimming to the things that I think might still be outstanding)


On 3/2/11 12:11 PM, Alan Johnston wrote:
> I am finally working on a revision to the document.  See below for
> comments on the minor issues.  There hasn't been any comments on the
> major issues (changing 409 with 400 and updating RFC 3261 and 4235).
>
> Comments most welcome.  I should have the changes described here done
> in the next few days.
>
> - Alan -
<big snip/>
>>> Section 5.4 talks about proxies inserting an Alert-Info field. Section
>>> 11 talks about proxies inserting and removing them. Both of these sections
>>> use non-normative terms. Where is the normative behavior for proxies participating
>>> in this feature defined? Also, for section 11. "If an Alert-Info is already present,
>>>   the proxy either removes the Alert-Info if it is not trusted, or adds
>>>   the 'appearance' parameter to the Alert-Info header field."
>>> It's not clear that RFC3261 allows a proxy to modify (in particular delete)
>>> existing Alert-Info header fields.
> You are correct that RFC 3261 does not explicitly allow this, although
> every real system does so.  I would prefer to update RFC 3261 to
> explicitly allow proxies to apply trust domain rules in modifying and
> deleting Alert-Info header fields and parameters.  However, if this
> causes trouble, we can remove it.  I'm working on some text for this.
I'm not sure I follow what happened in the text around this. Section 11 
ended
up removed.  Can you summarize what the changes were that addressed it?

<snip>
>> Where is there a description of how the joined and replaced dialog xml elements
>> are compared - there's an opportunity for error in implementation if they get
>> the perspective of local and remote tag incorrect - where is the text that describes
>> what to compare these against?
> I'll look at Replaces and Join and add in similar text.
Did that happen? (It may have, but I'm not spotting it quickly).

<snip/>
>
>>> Section 10.1 : Do you want to also call out authorizing publishes? Suggest
>>> rephrasing to avoid using "the same".
> Will do.
I think you adjusted the phrasing, bit did you talk about authorizing 
publishes?

<snip/>
>
>> 10.9 : Note that Bob's UA is configured not to, not that Bob chooses not
>> to have an appearance number. What normative texts suppresses the normal dialog
>> state change notifications at the end of the paragraph?
> There is none.  Probably these NOTIFYs would get sent, although they
> are of no use to anyone.
You fixed the issues with the text around normal notifications, but it still
says Bob chooses not to have an appearance number. This is a nit, and I'm
not going to stick on it, but please look to make sure that's what you 
really
mean to say. I think you mean the software in Bob's UA is programmed to
and that you don't mean to imply that Bob is going to have to punch a button
on the phone at this point in time to communicate a choice to the UA.

<snip/>
>
>>> 11 - What text precludes a UA from putting in its own appearance number?
>>>
> Nothing, but this yet another case why a proxy must be able to
> delete/modify Alert-Infos that are not correct or come from an
> untrusted source.
There should be some discussion of this in the document somewhere - am I 
overlooking it?

<snip/>

(There was a discussion about making it easier to use /= for future 
extensions to the ABNF
for this parameter that I don't think resulted in a change, but I'll 
come back to it later).

<snip/>
>>> Section 12 - This MUST to authenticate with Digest or S/MIME is stronger
>>> than the Replaces spec requires for a generic INVITE/Replaces - were you
>>> intending to further restrict the admission policy for INVITES associated
>>> with this extension?
> No, I'll check the INVITE/Replaces security considerations and make it match.
What change resulted?


----

Thanks for helping me check these!

RjS