RE: Gen-ART review of draft-ietf-bliss-shared-appearances-11

"Adrian Farrel" <adrian@olddog.co.uk> Fri, 29 June 2012 17:13 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F306A21F86C2 for <ietf@ietfa.amsl.com>; Fri, 29 Jun 2012 10:13:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.154
X-Spam-Level:
X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, J_CHICKENPOX_55=0.6]
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 tzGD2RnonXKk for <ietf@ietfa.amsl.com>; Fri, 29 Jun 2012 10:13:35 -0700 (PDT)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD8C21F85E4 for <ietf@ietf.org>; Fri, 29 Jun 2012 10:13:34 -0700 (PDT)
Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q5THDV2m001578; Fri, 29 Jun 2012 18:13:31 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q5THDUNI001564 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 29 Jun 2012 18:13:30 +0100
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Abdussalam Baryun'" <abdussalambaryun@gmail.com>, <david.black@emc.com>
References: <CADnDZ8_Vq4fvJzdFJUXYfrfVgtRv6E452ws+jjxs+h75qgA_iA@mail.gmail.com>
In-Reply-To: <CADnDZ8_Vq4fvJzdFJUXYfrfVgtRv6E452ws+jjxs+h75qgA_iA@mail.gmail.com>
Subject: RE: Gen-ART review of draft-ietf-bliss-shared-appearances-11
Date: Fri, 29 Jun 2012 18:13:30 +0100
Message-ID: <0c1101cd561a$81e48cf0$85ada6d0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGrVsAUJ8cU2nqJ0H4+em4dc7ailZdVh2+A
Content-Language: en-gb
Cc: 'ietf' <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jun 2012 17:13:36 -0000

Please read the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq
Adrian

> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of
> Abdussalam Baryun
> Sent: 29 June 2012 16:35
> To: david.black@emc.com
> Cc: ietf
> Subject: Re: Gen-ART review of draft-ietf-bliss-shared-appearances-11
> 
> Hi David,
> 
> I was not aware of this wiki and review team. does this team review
> IETF procedure and policies, please advise,
> 
> AB
> ===========================
> 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.
> 
> 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?
> 
> 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".
> 
>    If the Appearance Agent policy does not allow this, a 400 response
>    is returned.
> 
> Same question.  In addition, is 403 Forbidden allowed 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.
> 
> 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.
> 
> 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?).
> 
>    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.
> 
> Please ensure that the section 6 XML and Section 7 ABNF are
> syntax-checked with actual tools.
> 
> 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.
> 
> 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 at emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------