Re: [BLISS] Gen-ART review of draft-ietf-bliss-shared-appearances-11

Alan Johnston <alan.b.johnston@gmail.com> Fri, 29 June 2012 14:17 UTC

Return-Path: <alan.b.johnston@gmail.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 AA2B321F86AA; Fri, 29 Jun 2012 07:17:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 x0AvZ4aVtn+E; Fri, 29 Jun 2012 07:17:30 -0700 (PDT)
Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7065A21F86FD; Fri, 29 Jun 2012 07:17:30 -0700 (PDT)
Received: by ggnc4 with SMTP id c4so3073815ggn.31 for <multiple recipients>; Fri, 29 Jun 2012 07:17:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=dk6H41O8IvIbdLLnP6a+MzMcMIdN1t9ODZg1cOjbDKE=; b=wZDaqviHB5hTcIhpHo1c7UkLyVe1ocVISo/6LELVU5hnz8qzUBKfLpFeC9KuEgAO/n HPMbTfr4InlK0o/9v3kX7RUfPmzVzx4Lpx9YBP34tD7RkOXE9zRdFTgxo5NjT6c9tpBa Gd+TvmbZ/ZgEAUeSTMpHShrmu+HSWETScJFq+yrYIq9+hWqC3ibjgd6UiuZRZ5PPPci1 sR/M6c1DgGxlKWeyDcrz7mbJijNWcCB4+3g9PiOiL3wjY/bqU/WJK//qbRDB+iDXDPSE 1MmtuSZIVmVGrUemaSXg7gwS7qd2vUPBHh8iAnRJ3s4ZTyk/4dfIXQa38JseB0OwL0Ss 5MOQ==
MIME-Version: 1.0
Received: by 10.50.193.196 with SMTP id hq4mr1555160igc.57.1340979449458; Fri, 29 Jun 2012 07:17:29 -0700 (PDT)
Received: by 10.231.228.135 with HTTP; Fri, 29 Jun 2012 07:17:29 -0700 (PDT)
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71208D3A89C@MX15A.corp.emc.com>
References: <8D3D17ACE214DC429325B2B98F3AE71208D3A7FD@MX15A.corp.emc.com> <CAKhHsXEzQ9hrsRpkUsAMa2xaNwt8E7QM4ZVadTmqyX7hg0XJ1Q@mail.gmail.com> <8D3D17ACE214DC429325B2B98F3AE71208D3A89C@MX15A.corp.emc.com>
Date: Fri, 29 Jun 2012 09:17:29 -0500
Message-ID: <CAKhHsXEeKYSaM92dhs=mYfyx8ncsCvxW-9A9KGdUbfY3r=EVMw@mail.gmail.com>
From: Alan Johnston <alan.b.johnston@gmail.com>
To: david.black@emc.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: mohsen.soroush@sylantro.com, ietf@ietf.org, gen-art@ietf.org, bliss@ietf.org
Subject: Re: [BLISS] Gen-ART review of draft-ietf-bliss-shared-appearances-11
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, 29 Jun 2012 14:17:35 -0000

David,

I will make those changes.  Thanks for the feedback.

- Alan -

On Fri, Jun 29, 2012 at 8:43 AM,  <david.black@emc.com>; wrote:
> Alan,
>
> Thank you for the quick response.  I have a few comments on the proposed
> resolutions.  Absence of a comment implies that I agree with the proposed
> resolution.
>
> REQ-16 - I understand what's going on here (automatic ringdown), but the
> language is just slightly off because there is actually a dialing request.
> Here's all of REQ-16:
>
>   REQ-16 The mechanism should support a way for a UA to seize a
>   particular appearance number and also send the request at the same
>   time.  This is needed when an automatic ringdown feature (a telephone
>   configured to immediately dial a phone number when it goes off hook)
>   is combined with shared appearances - in this case, seizing the line
>   is the same thing as dialing.
>
> The language problem is that the line seizing includes a dialing request,
> so "is the same thing as" isn't quite correct when applied solely to
> "seizing the line".  As you suggest, the simplest fix would be to just
> remove "- in this case ... dialing", or it could be changed to:
>
>        - in this case, seizing the line is part of dialing.
>
> 5.3 - Doing nothing is fine.  I'm not a SIP expert, so I assume that
> the standard PUBLISH behavior (soft-state times out if not refreshed)
> is well-known to anyone who is, and hence no change is needed.
>
> 5.4 - please add "(Bad Request)" after each of the two instances of "400".
>
> 9.1/2/3 - please change to using "SHOULD" in each of these sections
> and explain that the "SHOULD" is motivated by user experience concerns.
>
> Thanks,
> --David
>
>> -----Original Message-----
>> From: Alan Johnston [mailto:alan.b.johnston@gmail.com]
>> Sent: Thursday, June 28, 2012 9:05 PM
>> To: Black, David
>> Cc: mohsen.soroush@sylantro.com; vvenkatar@gmail.com; gen-art@ietf.org;
>> shida@ntt-at.com; bliss@ietf.org; ietf@ietf.org; rjsparks@nostrum.com
>> Subject: Re: Gen-ART review of draft-ietf-bliss-shared-appearances-11
>>
>> David,
>>
>> Thank you for your review of the document.  See below for how I
>> propose to resolve the issues you have raised.  Let me know if you
>> have any other issues or concerns.
>>
>> - Alan -
>>
>> On Thu, Jun 28, 2012 at 3:51 PM, <david.black@emc.com>; wrote:
>> >
>> > I am the assigned Gen-ART reviewer for this draft. For background on
>> > Gen-ART, please see the FAQ at
>> > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>;.
>> >
>> > Please resolve these comments along with any other Last Call comments
>> > you may receive.
>> >
>> > Document: draft-ietf-bliss-shared-appearances-11
>> > Reviewer: David L. Black
>> > Review Date: June 28, 2012
>> > IETF LC End Date: June 28, 2012
>> > IESG Telechat date: (if known)
>> >
>> > Summary:
>> >
>> > This draft is on the right track but has open issues, described in the
>> review.
>> >
>> > This draft describes support for shared appearances in support of multi-line
>> > and shared-line telephone often found in businesses.  All of the open issues
>> > are minor.  The draft is well-written and reasonably clear for the most
>> part,
>> > although significant SIP expertise is required to completely understand it.
>> >
>> > Major issues:  None.
>> >
>> > Minor issues:
>> >
>> > 4.1 - REQ-16:
>> >
>> >   in this case, seizing the line is the same thing as dialing.
>> >
>> > That seems wrong - I would have thought it was a "prerequisite" as
>> > opposed to "the same thing" because seizing the line is immediately
>> > followed by a dialing request.
>>
>>
>> This requirement is about sending one request that causes both actions
>> to occur.  In a PSTN ringdown circuit (a very specialized circuit,
>> used for "hotlines"), the two operations are the same thing.  Besides
>> this statement, is REQ-16 itself not clear?  Perhaps I should just
>> remove this statement if it adds confusion rather than clarity to the
>> requirement.
>>
>> >
>> >
>> > 5.3.
>> >
>> >   A user may select an appearance number but then abandon placing a
>> >   call (go back on hook).  In this case, the UA MUST free up the
>> >   appearance number by removing the event state with a PUBLISH as
>> >   described in [RFC3903].
>> >
>> > What happens when that can't be done due to UA or network failure?
>>
>>
>> A little further down in this section says:
>>
>> "  This publication state is refreshed as described in [RFC3903] during
>>    the early dialog state or the Appearance Agent may reassign the
>>    appearance number."
>>
>> So if the removal publish is lost, it will eventually timeout since it
>> is not refreshed.  This is standard PUBLISH behavior described in RFC
>> 3903.
>>
>> >
>> >
>> > 5.4.
>> >
>> >   A 400 response is returned if the chosen appearance number is invalid,
>> >
>> > Is that always a 400 (Bad Request) or is any 4xx response allowed?  If
>> > it's always 400, add the words "Bad Request" after "400".
>>
>> We chose 400 in particular, although any 4xx response would have the
>> same result.  "Bad Request" is the reason phrase, and the practice of
>> putting it in () is a convention commonly used in SIP documents.  The
>> actual reason phrase can be different, customized ("Invalid
>> Appearance") if desired, or in a different language.
>>
>> So in this case we are specifying the 400 response.
>>
>> >
>> >   If the Appearance Agent policy does not allow this, a 400 response
>> >   is returned.
>> >
>> > Same question.  In addition, is 403 Forbidden allowed here?
>>
>> 403 is usually used in SIP to indicate that the request has failed due
>> to an authorization policy, and the request can be retried with
>> different credentials.  That doesn't quite fit here.
>>
>> >
>> >   If an INVITE is sent by a member of the group to the shared AOR (i.e.
>> >   they call their own AOR), the Appearance Agent MUST assign two
>> >   appearance numbers.  The first appearance number will be the one
>> >   selected or assigned to the outgoing INVITE.  The second appearance
>> >   number will be another one assigned by the Appearance Agent for the
>> >   INVITE as it is forked back to the members of the group.
>> >
>> > How does that interact with the single appearance UAs in 8.1.1 that won't
>> > understand the second appearance number?  A warning that such a UA can't
>> > pick up its call to its own AOR would suffice, either here or in 8.1.1.
>>
>> I will put text in 8.1.1 that makes this point clear.
>>
>> >
>> > 9.1
>> >
>> >   A UA that has no knowledge of appearances must will only have
>> >   appearance numbers for outgoing calls if assigned by the Appearance
>> >   Agent.  If the non-shared appearance UA does not support Join or
>> >   Replaces, all dialogs could be marked "exclusive" to indicate that
>> >   these options are not available.
>> >
>> > Should that "could be marked" be changed to "SHOULD be marked" ?
>> > Also, analogous questions for "could" in 9.2 and "can" in 9.3.
>> >
>> > All three of these affect interoperability.
>>
>> I can change this to SHOULD.  Actually, it doesn't affect
>> interoperability, as "exclusive" is just a hint, for user experience
>> and interface purposes and to reduce failed requests.  If a Join or
>> Replace is inadvertently sent, the operation will fail, which is the
>> same result as not allowing it, although a worse user experience.
>>
>> >
>> > 12. Security Considerations
>> >
>> > In general, this section is weak on rationale - the second, third and
>> > fourth paragraphs should all explain more about the purpose of and/or
>> > rationale for their security requirements (e.g., what does the security
>> > mechanism protect against and when/why might that protection be desired
>> > and/or required?).
>>
>> Right, the mechanisms are to provide privacy and to prevent
>> hijacking/spoofing.  I can add text to make this clear.
>>
>> >
>> >   NOTIFY or PUBLISH message bodies that provide the dialog state
>> >   information and the dialog identifiers MAY be encrypted end-to-end
>> >   using the standard mechanisms.
>> >
>> > What are "the standard mechanisms"?  List them, and provide references,
>> > please.
>>
>> That would be S/MIME as described in RFC 3261.  I can add this.
>>
>> >
>> > Please ensure that the section 6 XML and Section 7 ABNF are
>> > syntax-checked with actual tools.
>>
>> I will double check them.
>>
>> >
>> > Nits/editorial comments:
>> >
>> > p.10:
>> >
>> >   The next section discusses the operations used to implement parts of
>> >   the shared appearance feature.
>> >
>> > "The following list describes the operations ..." would be better.
>> >
>> > 5.3.1.
>> >
>> >   A UA wanting to place a call but not have an appearance number
>> >   assigned publishes before sending the INVITE without an 'appearance'
>> >   element but with the 'shared' event package parameter present.
>> >
>> > I think I understand what was intended here, but this would be clearer
>> > if "publishes" was replaced with language about sending a PUBLISH.
>> > It's also not completely clear whether "without" applies to the
>> > INVITE or the PUBLISH, so this sentence probably needs to be reworded.
>>
>> OK, it is the PUBLISH that doesn't have the parameter - I'll make this clear.
>>
>> >
>> > 5.4. - Expand B2BUA acronym on first use.
>> >
>> > idnits 2.12.13 ran clean.
>> >
>> > Thanks,
>> > --David
>> > ----------------------------------------------------
>> > David L. Black, Distinguished Engineer
>> > EMC Corporation, 176 South St., Hopkinton, MA  01748
>> > +1 (508) 293-7953             FAX: +1 (508) 293-7786
>> > david.black@emc.com        Mobile: +1 (978) 394-7754
>> > ----------------------------------------------------
>> >
>