Re: [Uri-review] Please advise as to how to proceed

Graham Klyne <gk@ninebynine.org> Thu, 31 August 2017 16:46 UTC

Return-Path: <gk@ninebynine.org>
X-Original-To: uri-review@ietfa.amsl.com
Delivered-To: uri-review@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25DF4132360 for <uri-review@ietfa.amsl.com>; Thu, 31 Aug 2017 09:46:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] 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 bRFg1sKYTuwm for <uri-review@ietfa.amsl.com>; Thu, 31 Aug 2017 09:46:12 -0700 (PDT)
Received: from relay14.mail.ox.ac.uk (relay14.mail.ox.ac.uk [163.1.2.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA919132025 for <uri-review@ietf.org>; Thu, 31 Aug 2017 09:46:12 -0700 (PDT)
Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay14.mail.ox.ac.uk with esmtp (Exim 4.89) (envelope-from <gk@ninebynine.org>) id 1dnSba-0001xf-kc; Thu, 31 Aug 2017 17:46:10 +0100
Received: from gklyne38.plus.com ([81.174.129.24] helo=spare-94.atuin.ninebynine.org) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <gk@ninebynine.org>) id 1dnSba-0000Ex-DZ; Thu, 31 Aug 2017 17:46:10 +0100
Message-ID: <59A83D50.8070902@ninebynine.org>
Date: Thu, 31 Aug 2017 17:46:08 +0100
From: Graham Klyne <gk@ninebynine.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Tarek Al-Hariri <thariri@gdg.io>, uri-review@ietf.org
References: <CAFWmBYreYf-n=Uj3VFBrAAce2dmqQ-wcSTPQMXgr2wuzvj7ZKw@mail.gmail.com>
In-Reply-To: <CAFWmBYreYf-n=Uj3VFBrAAce2dmqQ-wcSTPQMXgr2wuzvj7ZKw@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Oxford-Username: zool0635
X-Oxmail-Spam-Status: score=0.0 tests=none
X-Oxmail-Spam-Level: /
Archived-At: <https://mailarchive.ietf.org/arch/msg/uri-review/gTFjV2-Q-ZFs71vatU3IqDOzIw0>
Subject: Re: [Uri-review] Please advise as to how to proceed
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uri-review/>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Aug 2017 16:46:15 -0000

On 30/08/2017 20:13, Tarek Al-Hariri wrote:
> Hello,
> Request for provisional uri, per text appended
> Please advise accordingly.

It would help me if the template said something about what 'gdg' if for. 
(Saying "Connecting to a gdg server" doesn't really help me - a sentence and 
pointer to a description of what a GDG server does would be more helpful.)  In 
particular, I'd like to see some indication of what it is that a gdg URI 
actually identifies.

There's a typo in the security considerations ("senisitive").  Also, security is 
about more than just transmission (or not) of sensitive data.  It would be nice 
(but not required for a provisional registration) to see this dealt with more 
carefully.  I'd at least suggest dropping the "none" from that section.    It's 
OK for security considerations in the registration template to reference an 
existing document - we're not trying to make work here.  If you don't have any 
kind of security analysis, it would probably be better to just say so - that 
would not be a blocker for a provisional registration (though it wouldn't fly 
for a permanent registration).


See also:

- https://tools.ietf.org/html/rfc7595#section-4 -- in particular, I'd suggest 
putting the documentation online before actually requesting registration (see 
next).  Removing the bit about being ignored would look more professional, IMO.

- https://tools.ietf.org/html/rfc7595#section-7.2 -- in particular, bullet point 
4.  This list is the venue for review of proposed registrations (and it's good 
that you have sent your proposal here for review), but is not the place to send 
actual registration requests.

I'd recommend holding off sending your request to IANA until your spec is 
actually online - indeed, you might get more constructive feedback here if the 
spec is available for folks to see.

I hope this helps,

#g
--


> Regards,
>
> Scheme name:
>    gdg
>
> Status:
>    Provisional.
>
> Applications/protocols that use this scheme name:
>    GDG
>
> Contact:
>    Tarek Hariri
>    <tarekalhariri&gdg.io>
>    GDG
>    1255 23rd Street NW
>    DC 20037-1125
>    USA
>
> Change controller:
>    GDG
>
> References:
>    None
>    (documentation will be publicly available (and, we suspect, largely
> ignored) at https://dev.gdg.io/docs/spec as of 00:22 2017-10-10)
>
> Scheme syntax:
>    <gdg://> and <gdg:> are both valid:
>    gdg://<host>[:port][/[<identifier>][<collection>]]
>    gdg:<host>[:port][/[<identifier>][<collection>]]
>    gdg:[<prefix>/<handleid>]
>
>    where <prefix> maps one-to-one with a gdg handle identifier (eg.
> 10.22157, 20.500.12056, 20.500.12057) provides basic lookup / validation
> for identifiers. (Technically, any non-gdg handle.net identifier, not just
> gdg, should resolve, but this use is highly exotic and largely discouraged).
>
> Scheme semantics:
>    tl;dr Connecting to a gdg server, database, or cluster; retrieving a
> record.
>
>    Intended use includes operating systems or applicable environments (&c.)
> with gdg application installed, or other means affording connection to a
> gdg server.
>
> Encoding considerations:
>    The scheme and method portions of this proposed URI mitigate
> confrontation with encoding issues by limiting itself to a subset of ASCII.
>    URI query portion shall be encoded according to the rules in RFC 3986.
>
> Interoperability considerations:
>    none.
>
> Security considerations:
>    none.
>    URI is not intended for transmission of senisitive data.
>
>
> ————
>
> Regards,
>
> Tarek Hariri
>
>
>
> _______________________________________________
> Uri-review mailing list
> Uri-review@ietf.org
> https://www.ietf.org/mailman/listinfo/uri-review
>