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 >
- [BLISS] AD review: draft-ietf-bliss-shared-appear… Robert Sparks
- Re: [BLISS] AD review: draft-ietf-bliss-shared-ap… Alan Johnston
- Re: [BLISS] AD review: draft-ietf-bliss-shared-ap… Alan Johnston
- Re: [BLISS] AD review: draft-ietf-bliss-shared-ap… Robert Sparks