[Speermint] AD review: draft-ietf-speermint-architecture-16.txt

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Wed, 17 November 2010 13:39 UTC

Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: speermint@core3.amsl.com
Delivered-To: speermint@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 750623A68FF for <speermint@core3.amsl.com>; Wed, 17 Nov 2010 05:39:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHZhD5vLZbwN for <speermint@core3.amsl.com>; Wed, 17 Nov 2010 05:39:56 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 51AF53A6904 for <speermint@ietf.org>; Wed, 17 Nov 2010 05:39:56 -0800 (PST)
X-AuditID: c1b4fb39-b7cabae000005002-55-4ce3db5892a0
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 3E.AC.20482.85BD3EC4; Wed, 17 Nov 2010 14:40:41 +0100 (CET)
Received: from [131.160.126.132] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.2.234.1; Wed, 17 Nov 2010 14:40:40 +0100
Message-ID: <4CE3DB58.3070203@ericsson.com>
Date: Wed, 17 Nov 2010 15:40:40 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: speermint@ietf.org
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Subject: [Speermint] AD review: draft-ietf-speermint-architecture-16.txt
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Nov 2010 13:39:57 -0000

Hi,

I received a publication request for the following draft a few days ago:

https://datatracker.ietf.org/doc/draft-ietf-speermint-architecture/

Please, find below a few comments and questions on the draft.

Thanks,

Gonzalo


Title: I leave it up to the editors whether or not they want to expand
the acronym SPEERMINT. Given that it is exanded in the Introduction,
it should probably be expanded also in the title.

First sentence in the Abstract and first sentence in the Introduction:

s/it's/its/

First paragraph in the Introduction:

"...of a SIP Service providers [RFC5486] network."

It should be Provider's. Also, when capitalizing Provider, expand the
SSP acronym there, and not in the next sentence.

When the reader reaches Figure 1, there are a lot of new
acronyms. Having a terminology section after the Introduction would
help readers understand the figure. Otherwise, readers need to consult
other RFCs or check the meaning of the acronyms later in this
document.

Acronyms such as UA should also be expanded on their first use or
added to the Terminology section.

Section 3. Why is the sending of the BYE (step 5) more likely to be
performed by the target SSP than by the originating SSP?

Section 5.1.1.2

s/chosen for based on/chosen based on/

Section 5.1.2:

"not all of them may be used". Does this mean that the LRF MUST NOT
use all of them or that the LRF does not need to necessarily use all
of them?

Section 5.1.3

   When communicating with another SSP, entities compliant to this
   document should select a TLS-protected transport for communication
   from the originating (or indirect) SSP to the receiving SSP if
   available, as described further in Section 5.2.1.

This "should" sounds like a normative SHOULD. If this normatively
defined somewhere else (i.e., in another document)?

In general, there are a set of instructions that are given without
using normative language. What is the intention of those instructions?

ID nits gives the following warning:

 == Unused Reference: 'I-D.ietf-speermint-voip-consolidated-usecases' is
     defined on line 609, but no explicit reference was found in the
     text