[Gen-art] Review of draft-ietf-tram-turn-server-discovery-08

Ralph Droms <rdroms.ietf@gmail.com> Tue, 09 August 2016 21:30 UTC

Return-Path: <rdroms.ietf@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE5F12D140; Tue, 9 Aug 2016 14:30:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 3TpFSEDaOsXu; Tue, 9 Aug 2016 14:30:35 -0700 (PDT)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 685D612D0A0; Tue, 9 Aug 2016 14:30:32 -0700 (PDT)
Received: by mail-qk0-x22b.google.com with SMTP id p186so26131973qkd.1; Tue, 09 Aug 2016 14:30:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:date:message-id:cc:to:mime-version; bh=GKEV106rYp8MpeJZw6D3eQ+rNDEz8IAofYfms66JKKg=; b=YcIPtRCoNAMsCD/jsqXXdoz3HHbT7dPY2TQrzosIUaHX0iaJDxOKJ4fVRHscPEw/ox Lg6q0ZHGDn+pJcJ/URVYUqhUTKVGW9h3RwS6pJpH6yn1rLY6jymwXbMMjNLDokFUYw0H RE1n2HMwqOTmsov9UghWWX5HAsCscx4hVdPj1azdVRa4Wf5ChWY34jjnmn+GWdXD25jV du6i1RaANTPpnfk2jWZ5gCoj9deKUaInSNPJrgLTNN2nFRnfXDWF0Z0WcavVVF2aEgxC oqAsSHx7JnQlr6MD1Nod5PTdXRbj7xPvIfoeVJK1Ar8ic4xnzNJ2zW+Q6CE2J5L5cjv/ LWNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:date:message-id:cc:to:mime-version; bh=GKEV106rYp8MpeJZw6D3eQ+rNDEz8IAofYfms66JKKg=; b=GAQ7GDGJ6IPZ1uQU46lYH+Szg8Lp/khMQSbAm3Cl034GdV26Og3ojND2VILVEi7GH7 tiUBg2c58E1/KOufZHNwpDEv4M7tCAfNl2Awg0R24Ul9+kcZtY/T4ikW3FemfjLtfmou QGU9q2MGiGaIIMhR0LEklgzFbq8c9djSkygOl8FetsRmNWhexb0swg+xx0eMvWNZUwUB /R/iXQ0vgqZD5rrm9PtcLJAd6oRn+TkA11oX7GC41Xo95re8AwToNGVgRZ74EHTNIOGP ELIuBZDW6d/R/We+axaGugp/cedagprKG9V26VOiKKhpYvd6TKjv0hFw5IqNIfveAFJS UVeA==
X-Gm-Message-State: AEkooutrnJ6KXxGpTsJxtRB5AlL4IY5eVuMFxFPgpFvocXlYV2osTN9Cpmc97vpn9d7xrA==
X-Received: by 10.55.177.7 with SMTP id a7mr581664qkf.13.1470778231362; Tue, 09 Aug 2016 14:30:31 -0700 (PDT)
Received: from ?IPv6:2601:18f:801:600:99db:e38a:596c:ae1b? ([2601:18f:801:600:99db:e38a:596c:ae1b]) by smtp.gmail.com with ESMTPSA id 55sm21525600qtm.36.2016.08.09.14.30.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 09 Aug 2016 14:30:29 -0700 (PDT)
From: Ralph Droms <rdroms.ietf@gmail.com>
X-Pgp-Agent: GPGMail
Content-Type: multipart/signed; boundary="Apple-Mail=_0842813C-B5FD-416D-AF47-9D7CA1A8DB22"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Date: Tue, 09 Aug 2016 17:27:48 -0400
Message-Id: <7194DC7F-E802-42B2-AA6C-94D02167D89D@gmail.com>
To: "Review Area gen-art@ietf.org Team" <gen-art@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/Q2NcRnAo1YL_F7Db3m2DGX_kCQg>
Cc: draft-ietf-tram-turn-server-discovery.all@ietf.org, IETF discussion list <ietf@ietf.org>
Subject: [Gen-art] Review of draft-ietf-tram-turn-server-discovery-08
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Aug 2016 21:30:40 -0000

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed by
the IESG for the IETF Chair. Please resolve these comments along with
any other Last Call comments you may receive.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-tram-turn-server-discovery-08
Reviewer: Ralph Droms
Review Date: 2016-08-09
IETF LC End Date: 2016-08-11
IESG Telechat date: unknown


Summary:

This draft is on the right track but has open issues, described in the
review.

The draft is well-written and appears to be ready for publication,
except as noted below.

Major issues:

Section 5, DNS Service Discovery, includes more details about DNS
Service Discovery (DNS-SD) than is necessary for this specification.
While it can be useful to repeat some specific details of another
specification for, there is a danger in writing too many details that
may not be entirely in agreement with the published specification.  In
the case of this document, I suggest that section 5 be rewritten to
just refer to DNS Service discovery, with a minimum of explanation.
The example is useful ... although I think some of the details in the
example ought to be changed.  The use of DNS-SD over unicast DNS and
multicast DNS can be mentioned in a sentence somewhere in section 5,
as the use of DNS-SD is otherwise identical.  I would leave out
section 5.1 altogether.

Looking at the IANA "Service Name and Transport Protocol Port Number
Registry"
<www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml>,
I see that TURN is registered as using service name "turn", rather
than "turnserver" as in the example.  Also in the example, the
instance name "example.com" might be problematic, as the instance is
usually just a single label.  In fact, I interpret the text in the
document to describe the instance name as a single label.  It might be
worth experimenting to see how DNS-SD libraries deal with a label like
"example.com", or perhaps simply change instance in the example to
something like "exampleco TURN Server"

Minor issues:

Section 5 mentions the use of a TXT record to carry additional information about the TURN service instance.  Are there any conventions for the name/value pairs carried in the TXT record?  If not, I think there should be a note that any name/value pairs in the TXT record are left to local definition.

Editorial issues:

I suggest using the example.com domain rather than local in the example for clarity.  Perhaps also change the intro sentence for the example:

OLD:
 For example, TURN server advertises the following DNS records :
NEW:
 For example, the following DNS records would be used for a TURN server with instance name "exampleco TURN Server" providing TURN service over UDP on port 5030:


It would help readability if the columns in the DNS records in the example could be lined up; something like (apologies if your mail reader changes the column alignments and if I don't have the quoting right):

_turnserver._udp.local.
PTR	"exampleco TURN Server"._turn._udp.local.

"exampleco TURN Server"._turn._udp.local.
SRV	0 0 5030 example-turn-server.local.

example-turn-server.local.
A	198.51.100.2

example-turn-server.local.
AAAA	2001:db8:8:4::2

Similarly, it would help readability if the list of DNS records for S-NAPTR resolution were formatted in aligned columns.

In section 3, does "on top of" mean "in addition to" or "instead of"?