[apps-discuss] Apps directorate review of draft-nandakumar-rtcweb-stun-uri-5.txt

Ted Hardie <ted.ietf@gmail.com> Fri, 16 August 2013 17:04 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C1E11E8186; Fri, 16 Aug 2013 10:04:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g70XegKnposM; Fri, 16 Aug 2013 10:04:52 -0700 (PDT)
Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 434BF11E8174; Fri, 16 Aug 2013 10:04:52 -0700 (PDT)
Received: by mail-ie0-f174.google.com with SMTP id w15so3775380iea.19 for <multiple recipients>; Fri, 16 Aug 2013 10:04:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=lt45mtsEGFFp3SHvLet/POaM8kKKj/yjzDGh+oChKig=; b=hN5SPGVf85kvU8aEWEXb5ho81msg9VasPUBkqUwkEisvD1cDKCugHRX7iiDbIm5gmy n3jpeKloMP8SVsaDXBEnQLKK9z3q+1Aq+yx8Uu+5t8jCKgXnsTwqRaMDh5hnXeKqfmS0 FgsmYoRoPs8rcheCNv1Yl/G6enAMdfcQU+V1oBpljzRpdwl+DvHNz3VYHxmEa+cMa0OX kf3vvkvzNBkQOQ3W/stSU6ZsB7NWpifLvbZWhYppDvRf38ho4xWrSmE5I0luCbIZ4tgz 5gfIWkRl7I7eewzB4oztXl8fZvlcIS5T8LmS+1hBVdLS4z6V0Z2u5lmx6cKFHjDhhQS1 8bKQ==
MIME-Version: 1.0
X-Received: by 10.42.127.199 with SMTP id j7mr1353361ics.20.1376672691888; Fri, 16 Aug 2013 10:04:51 -0700 (PDT)
Received: by 10.42.29.202 with HTTP; Fri, 16 Aug 2013 10:04:51 -0700 (PDT)
Date: Fri, 16 Aug 2013 10:04:51 -0700
Message-ID: <CA+9kkMBD6XNNaJm0qBCm_isi-u-yKU_PJx-BJGVUoTLAPxGirA@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: draft-nandakumar-rtcweb-stun-uri.all@tools.ietf.org, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="20cf3010e99fc5ac4104e413967b"
Subject: [apps-discuss] Apps directorate review of draft-nandakumar-rtcweb-stun-uri-5.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Aug 2013 17:04:53 -0000

 I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments you
may receive. Please wait for direction from your document shepherd or AD
before posting a new version of the draft.

Document:  draft-nandakumar-rtcweb-stun-uri-5.txt

Title: URI Scheme for Session Traversal Utilities for NAT (STUN) Protocol

Reviewer: Ted Hardie
Review Date: August 16th, 2013

Summary: This document is ready to be published as an informational RFC; it
currently gives a target of standards track, but  I do not believe this is
required.

Discussion:  The draft has had some discussion in response to comments by
Graham Klyne, the Designated Expert for URI schemes.  I personally believe
that this document has sufficient utility to qualify for permanent
registration, both in the WebRTC context and potentially in similar
contexts.  I also am not terribly worried that it duplicates the ABNF of
RFC 3986; while it certainly could have done it differently, the chances of
drift in definition in this case seem low enough to be harmless.

Nit:  The document recommends removal of the implementation status section,
but not the appendices, including the one which gives the design
rationale.  I'd either move the implementation status to an appendix and
keep the all, or remove them all.  But this is obviously an editorial
choice, not a substantive issue.