[sipcore] Alissa Cooper's No Objection on draft-ietf-sipcore-rejected-08: (with COMMENT)

Alissa Cooper via Datatracker <noreply@ietf.org> Tue, 11 June 2019 16:17 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: sipcore@ietf.org
Delivered-To: sipcore@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3ED912012C; Tue, 11 Jun 2019 09:17:00 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-sipcore-rejected@ietf.org, Jean Mahoney <mahoney@nostrum.com>, sipcore-chairs@ietf.org, mahoney@nostrum.com, sipcore@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.97.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alissa Cooper <alissa@cooperw.in>
Message-ID: <156026982076.30851.9180244619877071155.idtracker@ietfa.amsl.com>
Date: Tue, 11 Jun 2019 09:17:00 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/XsCWG4K4h9zX4bnTaLGkG6sycSA>
Subject: [sipcore] Alissa Cooper's No Objection on draft-ietf-sipcore-rejected-08: (with COMMENT)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Jun 2019 16:17:01 -0000

Alissa Cooper has entered the following ballot position for
draft-ietf-sipcore-rejected-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Please respond to the Gen-ART review.

= Section 3 =

I'm wondering about the case where I have an AI-driven assistant on my client
that listens for me to say "Please take me off your call list" and blocks all
future calls from that caller. It seems like the 608 use case would apply (for
the case of false positive voice recognition), but since the definition here
limits the intermediary to an entity "in the network," this scenario is out of
scope. Should it be?

= Section 3.5 =

"It is
   important to note the network element should be mindful of the media
   type requested by the UAC as it formulates the announcement.  For
   example, it would make sense for an INVITE that only indicated audio
   codecs in the Session Description Protocol (SDP) [RFC4566] to result
   in an audio announcement.  However, if the INVITE only indicated a
   real-time text codec and the network element can render the
   information in the requested media format, the network element MUST
   send the information in a text format, not an audio format."

I think the normative guidance here could be crisper, e.g., replacing the first
sentence with "The network element SHOULD use a media format for its
announcement for which the caller indicates support, if possible." I also don't
understand why the second example uses normative MUST but the first example
doesn't use normative language at all.

= Section 4.1 =

Using "bitbucket" in the examples seems like it sends the wrong message about
the utility of the contact address.