[BLISS] Gen-ART review of draft-ietf-bliss-shared-appearances-13

"Black, David" <david.black@emc.com> Thu, 09 August 2012 23:08 UTC

Return-Path: <david.black@emc.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 CEBD921F85F0; Thu, 9 Aug 2012 16:08:45 -0700 (PDT)
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.117, BAYES_00=-2.599, 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 5rrgaodBTzVD; Thu, 9 Aug 2012 16:08:44 -0700 (PDT)
Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id BDE6921F85DD; Thu, 9 Aug 2012 16:08:44 -0700 (PDT)
Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q79N8fCO015783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Aug 2012 19:08:42 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Thu, 9 Aug 2012 19:08:21 -0400
Received: from mxhub11.corp.emc.com (mxhub11.corp.emc.com [10.254.92.106]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q79N8Iec010299; Thu, 9 Aug 2012 19:08:18 -0400
Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub11.corp.emc.com ([10.254.92.106]) with mapi; Thu, 9 Aug 2012 19:08:18 -0400
From: "Black, David" <david.black@emc.com>
To: "alan.b.johnston@gmail.com" <alan.b.johnston@gmail.com>, "mohsen.soroush@sylantro.com" <mohsen.soroush@sylantro.com>, "vvenkatar@gmail.com" <vvenkatar@gmail.com>, "gen-art@ietf.org" <gen-art@ietf.org>
Date: Thu, 9 Aug 2012 19:08:17 -0400
Thread-Topic: Gen-ART review of draft-ietf-bliss-shared-appearances-13
Thread-Index: Ac1Vb8Dn5IHpqMlJQDmiZm9plrtFJQL1mcsgBU9mF9A=
Message-ID: <8D3D17ACE214DC429325B2B98F3AE71208F12410@MX15A.corp.emc.com>
References: <8D3D17ACE214DC429325B2B98F3AE71208D3A7FD@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71208DD8672@MX15A.corp.emc.com>
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71208DD8672@MX15A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Cc: "bliss@ietf.org" <bliss@ietf.org>, "Black, David" <david.black@emc.com>, IETF Discussion <ietf@ietf.org>
Subject: [BLISS] Gen-ART review of draft-ietf-bliss-shared-appearances-13
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: Thu, 09 Aug 2012 23:08:45 -0000

These resolutions have been carried forward to the -13 version of the draft.

Thanks,
--David

> -----Original Message-----
> From: Black, David
> Sent: Friday, July 13, 2012 6:25 PM
> To: Black, David; alan.b.johnston@gmail.com; mohsen.soroush@sylantro.com;
> vvenkatar@gmail.com; gen-art@ietf.org
> Cc: Shida Schubert; bliss@ietf.org; IETF Discussion; Robert Sparks
> Subject: Gen-ART review of draft-ietf-bliss-shared-appearances-12
> 
> The -12 version of this draft resolves all of the comments in the
> Gen-ART review of the -11 version.
> 
> Thanks,
> --David
> 
> > -----Original Message-----
> > From: Black, David
> > Sent: Thursday, June 28, 2012 4:51 PM
> > To: alan.b.johnston@gmail.com; mohsen.soroush@sylantro.com;
> > vvenkatar@gmail.com; gen-art@ietf.org
> > Cc: Black, David; Shida Schubert; bliss@ietf.org; IETF Discussion; Robert
> > Sparks
> > Subject: Gen-ART review of draft-ietf-bliss-shared-appearances-11
> >
> > 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@emc.com        Mobile: +1 (978) 394-7754
> > ----------------------------------------------------