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

Alan Johnston <alan.b.johnston@gmail.com> Fri, 17 December 2010 16:16 UTC

Return-Path: <alan.b.johnston@gmail.com>
X-Original-To: bliss@core3.amsl.com
Delivered-To: bliss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DE653A6900 for <bliss@core3.amsl.com>; Fri, 17 Dec 2010 08:16:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.452
X-Spam-Level:
X-Spam-Status: No, score=-103.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdaiXQ2idnWD for <bliss@core3.amsl.com>; Fri, 17 Dec 2010 08:16:14 -0800 (PST)
Received: from mail-bw0-f50.google.com (mail-bw0-f50.google.com [209.85.214.50]) by core3.amsl.com (Postfix) with ESMTP id D414D3A68DE for <bliss@ietf.org>; Fri, 17 Dec 2010 08:16:12 -0800 (PST)
Received: by bwg12 with SMTP id 12so1067045bwg.37 for <bliss@ietf.org>; Fri, 17 Dec 2010 08:17:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9eb8DEvaDA8XdlS62REYi2l9370YbayadMyt8jUgoUg=; b=MYefdXiiCF7ifDaQBYqcWnBM1sptfHF+U1C2aEhIXwfXSUoC1Wkc6NnZiEqRGVnufV NxsXvYjevw9AZI1GyrNUK+UQMtzoS4B4qh0A4kWt0spnx2uC709TBBwTt1F4cg2iwOWU TtAxDMeVJVEhQZAxFfxR8mvtg8w31kVCR3uAQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ceP+0PxbP/s+IXvAcB41M0Gocy/PHVbQqPqlTOjEoINwaqNeHsCSTMx06G5XUlaq85 QKvRRvwa5rHMWYzaTjHiyxzC71tfOvFtCLZWnpQ2VONAXM71gYlgzv1ui2JTbXnIuOBt U9uXH5wnAnvFZcO2U9jwB88TyKDz8fJ5kf+xs=
MIME-Version: 1.0
Received: by 10.204.29.2 with SMTP id o2mr797344bkc.210.1292602679192; Fri, 17 Dec 2010 08:17:59 -0800 (PST)
Received: by 10.204.232.15 with HTTP; Fri, 17 Dec 2010 08:17:59 -0800 (PST)
In-Reply-To: <E5754669-B9EE-4DED-91E9-F9DFEB0BCB3F@nostrum.com>
References: <D47B552B-6B5C-41EB-ABF0-6E127174ADE1@nostrum.com> <E5754669-B9EE-4DED-91E9-F9DFEB0BCB3F@nostrum.com>
Date: Fri, 17 Dec 2010 10:17:59 -0600
Message-ID: <AANLkTimVY7NzMQpe+cbD2E2BR80=UdmqYzN4q-5FSV01@mail.gmail.com>
From: Alan Johnston <alan.b.johnston@gmail.com>
To: Robert Sparks <rjsparks@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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.9
Precedence: list
List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" <bliss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 17 Dec 2010 16:16:15 -0000

Robert,

Thanks for your review of this document.  I plan to address all of
your comments in a revision early in January.  For now, I will reply
to your three major issues below and see if we can get working group
consensus on the resolutions.

- Alan -

On Mon, Dec 6, 2010 at 1:58 PM, Robert Sparks <rjsparks@nostrum.com>; wrote:
> Summary: There are a few major issues that need to be addressed before progressing this document.
>
> Major Issues:
>
> 1) 409 is not a defined response code. Probably easiest to choose another.
>

I knew 409 was deprecated as a response to REGISTER, but I hadn't
realized we had deprecated the entire response code!

I suggest we just use a 400 response.  We had discussed including a
Retry-After header field with a very short value, or even zero, but
now I'm thinking about just omitting the Retry-After.


> 2) Is this an update to 3261 (through adding a parameter to Alert-Info)?


I am OK with this.

>
> 3) Is this an update to 4235 (through adding the shared parameter)?
>

I am OK with this.  We also make recommendations about dialog package
notifications that is stronger than RFC 4235, so this makes sense.


> ----
>
> Section 4.2 calls out "An analysis of other mechanisms has been performed".
> Has that analysis been captured?
>
> The list of steps in 4.2 is intended to be illustrative (I think). Can
> text be added to reinforce that this is not defining behavior. It might
> also help to point to where the behavior is actually defined.
>
> In 4.2, step 7, it's not clear what "this" is in "publishes this"
>
> Suggest deleting "In some cases," from the start of 4.2 step 9.
>
> The second paragraph of 5.2.2 should be clearer - it's not obvious
> that what you're trying to recommend is that a UA not share dialog
> information so that it won't be possible for someone else to take the
> call from a remote peer.
>
> Section 5.3 : why are the SHOULDs in paragraphs 2 and 3 (not counting
> the note between them), SHOULD and not MUST?
>
> Section 5.3, paragraph 3: Should this say "fails or loops back to itself"?
> Or is looping back the only failure you were intending to describe? What
> period should UAs retry the subscription with?
>
> Section 5.3, paragraph 4 "All User Agents supporting INVITE MUST support...".
> This hasn't captured the real requirement - it's not All User agents that
> support INVITE in the world - did you intend to scope this to "implement
> call pickup, joining, and bridging as you did in the first sentence?
>
> Section 5.3, top of page 15: "This publication state SHOULD be refreshed"
> Why is this a SHOULD? When would the endpoint choose to let the published
> state expire? It might help to call out that you are talking about normal
> 3903/5264 soft-state refreshes here.
>
> Section 5.3, middle of page 15: what does "implicitly rendered" mean?
>
> End of section 5.3 - informative note. typo: received->receive. It would
> probably help to call out that this NOTIFY will be on the dialog event
> package.
>
> Section 5.4 - The SHOULD at the end of the 2nd paragraph is either
> modifying or restating a requirement from 4235. The Appearance Agent
> is being a State Agent at this point and the event package defines
> when change is sufficient to trigger a NOTIFY. It looks like this is
> in fact modifying the rules in 4235, adding extra conditions on
> when NOTIFYs would be sent. It would be much clearer to state this in
> terms of the affect on the package.
>
> 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.
>
> Section 5.4, next to last paragraph on page 17, last sentence,
> starting "An Appearance agent does not have to". What does this mean
> in terms of protocol - is it suppressing a publish, a notify?
>
> Section 5.4, 2nd paragraph page 18 : Is this trying to say use
> event-rate-control? Or is it modifying the definition of the event package?
>
> 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?
>
> Section 7.1.1 - is this "0" an example, or is it intended that Single appearance UAs
> only use "0" and any other values are not allowed? Section 7.1.2 doesn't seem to have
> the same level of requirements that this section has.
>
> Section 7.1.3 - when you say call should be ignored, do you mean requests should be
> rejected?
>
> Should the list starting with "The problems faced by each style" be its own section
> or is it intended to be part of section 7.1.4?
>
> Section 8.2 - You should call out that if enpdoints use end-to-end encryption
> for their session descriptions, the Appearance agent will not get this information.
> This and other factors may make the information the appearance agent has imperfect.
>
> Seciton 8.3 - what's the consequence of not rejecting the requests - that exlusive
> calls get joined?
>
> Section 9 first paragraph - call out the event package (and that you are probing
> for support of the extension via the event header parameter).
>
> I'm not sure what the second paragraph of section 9 is trying to achieve?
>
> Section 10.1 : Do you want to also call out authorizing publishes? Suggest
> rephrasing to avoid using "the same".
>
> 10.1 -
> In general, the examples need to be double-checked for correctness.
> The request and response in F1, and F2 do not have the same branch-id.
> F2 should have its expiry on the Contact header field value
> F5's Subscription-State header does not have the required elements (expires,
> at least, is required). This occurs in other examples as well.
> There should be no Event header field in F6.
>
> 10.2 F4 and F21 have the same CSeq and the same partial-notification
> version number.
>
> 10.3 F4 and F6 are from different subscriptions - it's _very unlikely_
> that the partial notify bodies would have the same version. I need to
> check, but I think the id attribute to <dialog is also scoped to the subscription.
>
> 10.4 F1 : Are you sure about using a partial publish here?
>
> 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?
>
> 10.13: This is really hard to follow - it might help to tag the subscribes with
> what's being subscribed to.
>
> 10.14 : F48 - How is Alice authoritative for telling the appearance agent that
> the dialog in that Publish has been terminated?
>
> 11 - What text precludes a UA from putting in its own appearance number?
>
> 11 - it would be prudent to reconcile this ABNF change with what SALUD
> plans to do. We should make it where new parameters can be added with /=
> after this change.
>
> 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?
>
>
> _______________________________________________
> BLISS mailing list
> BLISS@ietf.org
> https://www.ietf.org/mailman/listinfo/bliss
>