[Modern] Review: draft-ietf-modern-problem-framework-01

Adam Roach <adam@nostrum.com> Tue, 13 December 2016 20:53 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6AA129969 for <modern@ietfa.amsl.com>; Tue, 13 Dec 2016 12:53:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.796
X-Spam-Level:
X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZcyuxE7_nvA for <modern@ietfa.amsl.com>; Tue, 13 Dec 2016 12:53:40 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 934E11298AE for <modern@ietf.org>; Tue, 13 Dec 2016 12:53:40 -0800 (PST)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uBDKrdon002010 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <modern@ietf.org>; Tue, 13 Dec 2016 14:53:40 -0600 (CST) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local
To: "modern@ietf.org" <modern@ietf.org>
From: Adam Roach <adam@nostrum.com>
Message-ID: <43e8f904-97c6-019b-e159-d37860503731@nostrum.com>
Date: Tue, 13 Dec 2016 14:53:38 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/modern/irbZLrF9KcV8PPBaA7eo5RHZhck>
Subject: [Modern] Review: draft-ietf-modern-problem-framework-01
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" <modern.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/modern>, <mailto:modern-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/modern/>
List-Post: <mailto:modern@ietf.org>
List-Help: <mailto:modern-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/modern>, <mailto:modern-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Dec 2016 20:53:42 -0000

With apologies for being slightly late...

I've reviewed draft-ietf-modern-problem-framework-01, and find it to be 
in generally good shape. I have a handful of comments, mostly nits, on 
the current document.


My only substantive comment is: Section 4.3: We completely forego the 
possibility of public service data? That doesn’t seem very future-proof 
in an age of increasingly smart endpoints.


The remainder of these are minor comments or nits.

General: remove contractions, separate dependent clauses with commas. 
Too many to call out individually.

General: formally defined terms frequently appear with Initial Caps in 
the middle of sentences, but not uniformly. I have no strong opinion 
about whether this should or should not happen, but please make it 
consistent.

Abstract: The sentence starting "TNs no longer serve..." contains a 
comma splice. Suggest replacing with a semicolon.

In section 2.1, the definition for "Registrar" uses the term "assignees" 
prior to its definition. Consider rearranging to put "Assignees" first; 
or, if that isn't possible, say something like "...with its assignees 
(defined below)..."

Section 2.3 contains a definition for "Distributed Registries" that is 
redundant with the definition in section 2.1. It should be defined in 
one place, and referenced in the other. The definition in 2.3 appears to 
be more complete.

The diagram on page 10 should probably indicate that the User actors are 
serving different roles;  the role of the left-hand user is a delegate, 
while the other user is just trying to make contact.

Section 4.1.5: This is a bit hard to follow, since it omits one of the 
parts of data provisioning described in the preceding sections. In 
particular: with the described structure, there appears to be no 
authority to query to find the CSP for user-acquired numbers. I *think* 
the intention is that the user tells the Registrar about the CSP; if so, 
that should be explicitly mentioned here. Maybe refer to section 4.2.2.2?

Section 4.2.2: The document talks about baseline REGISTER being used at 
this level. Should this also reference RFC 6140? It seems particularly 
relevant.

Section 4.2.2.1: Missing close paren on seventh line of first paragraph.

Section 4.3.1, line 5: s/by/be/

Section 4.3.2: The start to this paragraph is jarring. Perhaps “Consider 
a case in which a CSP…”

Section 4.3.3, second paragraph, final line: This sentence has too many 
pronouns to easily follow. Replace "it's", "it", and "that" with their 
respective antecedents.

Section 4.3.3, third paragraph, second and third lines: "...and thus a 
the query..."  Remove either "a" or "the".

/a