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

<david.black@emc.com> Thu, 28 June 2012 20:51 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 BCC5421F8526; Thu, 28 Jun 2012 13:51:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.554
X-Spam-Level:
X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 vg1LkAWUb-E4; Thu, 28 Jun 2012 13:51:42 -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 47F6A21F8593; Thu, 28 Jun 2012 13:51:41 -0700 (PDT)
Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5SKpcOB030462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2012 16:51:39 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Thu, 28 Jun 2012 16:51:16 -0400
Received: from mxhub26.corp.emc.com (mxhub26.corp.emc.com [10.254.110.182]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5SKpEHi013407; Thu, 28 Jun 2012 16:51:14 -0400
Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub26.corp.emc.com ([10.254.110.182]) with mapi; Thu, 28 Jun 2012 16:51:14 -0400
From: <david.black@emc.com>
To: <alan.b.johnston@gmail.com>, <mohsen.soroush@sylantro.com>, <vvenkatar@gmail.com>, <gen-art@ietf.org>
Date: Thu, 28 Jun 2012 16:51:13 -0400
Thread-Topic: Gen-ART review of draft-ietf-bliss-shared-appearances-11
Thread-Index: Ac1Vb8Dn5IHpqMlJQDmiZm9plrtFJQ==
Message-ID: <8D3D17ACE214DC429325B2B98F3AE71208D3A7FD@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
X-Mailman-Approved-At: Thu, 28 Jun 2012 17:06:48 -0700
Cc: bliss@ietf.org, david.black@emc.com, ietf@ietf.org
Subject: [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: Thu, 28 Jun 2012 20:51:45 -0000

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
----------------------------------------------------