[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
- [Speermint] AD review: draft-ietf-speermint-archi… Gonzalo Camarillo
- Re: [Speermint] AD review: draft-ietf-speermint-a… Livingood, Jason
- Re: [Speermint] AD review: draft-ietf-speermint-a… Gonzalo Camarillo
- Re: [Speermint] AD review: draft-ietf-speermint-a… Livingood, Jason
- Re: [Speermint] AD review: draft-ietf-speermint-a… Gonzalo Camarillo