Re: [sidr] Adam Roach's Discuss on draft-ietf-sidr-slurm-07: (with DISCUSS and COMMENT)

Adam Roach <adam@nostrum.com> Thu, 05 April 2018 13:14 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6634D12751F; Thu, 5 Apr 2018 06:14:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 tHuQC25PvAah; Thu, 5 Apr 2018 06:14:07 -0700 (PDT)
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 2D804127241; Thu, 5 Apr 2018 06:14:07 -0700 (PDT)
Received: from [172.18.0.15] (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w35DE5S9027181 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 5 Apr 2018 08:14:06 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be [172.18.0.15]
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Adam Roach <adam@nostrum.com>
X-Mailer: iPhone Mail (15D60)
In-Reply-To: <1EFF9988-F988-4A4C-B860-B244C1A59A6E@ripe.net>
Date: Thu, 5 Apr 2018 08:14:00 -0500
Cc: Chris Morrow <morrowc@ops-netman.net>, sidr-chairs@ietf.org, draft-ietf-sidr-slurm@ietf.org, The IESG <iesg@ietf.org>, IETF SIDR <sidr@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <520D0E60-3639-4ED3-B7C4-5FBDC8BCF0CE@nostrum.com>
References: <152286976586.23998.1170348122023610014.idtracker@ietfa.amsl.com> <1EFF9988-F988-4A4C-B860-B244C1A59A6E@ripe.net>
To: Tim Bruijnzeels <tim@ripe.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/SWuuhgsBYjRGmtHsoTH7H6jNawg>
Subject: Re: [sidr] Adam Roach's Discuss on draft-ietf-sidr-slurm-07: (with DISCUSS and COMMENT)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Apr 2018 13:14:09 -0000

Thanks for your quick response! Feel free to reach out to me directly if you find any particular part of the structure challenging to describe. 

/a

> On Apr 5, 2018, at 05:38, Tim Bruijnzeels <tim@ripe.net> wrote:
> 
> Dear Adam, all,
> 
> Thank you for this feedback - indeed we struggled a bit with formally specifying JSON and relied on examples. I believe that with your suggestions we can improve this.
> 
> As for IP address prefix notation - yes.. we should follow your suggestion and cite RFC 4632 §3.1 for prefix-length notation (both for IPv4 and IPv6), and RFC 5952 for the syntax of IPv6 addresses. I am so used to doing it this way that it slipped my mind to specify this, but of course it should be unambiguous.
> 
> As I did most of the JSON text I will take it on me to re-work this text and ask Di to merge it with the changes he is working on. There should be a -08 version coming soon.
> 
> Tim
> 
> 
>> On 4 Apr 2018, at 21:22, Adam Roach <adam@nostrum.com> wrote:
>> 
>> Adam Roach has entered the following ballot position for
>> draft-ietf-sidr-slurm-07: Discuss
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>> 
>> Thanks to everyone who worked on this document. The mechanism seems useful.
>> 
>> I'm concerned that the document doesn't describe the file format itself;
>> rather, it relies on examples to provide vital, nonsupplemental information
>> such as the names of JSON object members, expected encodings (e.g., strings
>> versus numbers), and distinction between arrays and objects. I'm making this a
>> DISCUSS because I think the ambiguity here -- and, in particular the ambiguity
>> about IP address prefix notation -- will lead to non-interoperable
>> implementations.
>> 
>> Using section §3.2 as an example:
>> 
>>> A SLURM file consists of:
>>> 
>>> o  A SLURM Version indication that MUST be 1
>>> 
>>> o  A slurmTarget element (Section 3.3) consisting of:
>>> 
>>>    *  Zero or more target elements.  In this version of SLURM, there
>>>       are two types of values for the target: ASN or Fully Qualified
>>>       Domain Name(FQDN).  If more than one target line is present,
>>>       all targets MUST be acceptable to the RP.
>>> 
>>> o  Validation Output Filters (Section 3.4), consisting of:
>>> 
>>>    *  An array of zero or more Prefix Filters, described in
>>>       Section 3.4.1
>>> 
>>>    *  An array of zero or more BGPsec Filters, described in
>>>       Section 3.4.2
>>> 
>>> o  Locally Added Assertions (Section 3.5), consisting of:
>>> 
>>>    *  An array of zero or more Prefix Assertions, described in
>>>       Section 3.5.1
>>> 
>>>    *  An array of zero or more BGPsec Assertions, described in
>>>       Section 3.5.2
>>> 
>> 
>> As this is the normative description of the structure, I would have expected an
>> indication that the file contains a JSON object (rather than, say, a JSON
>> array), an indication that the version is to be encoded as a number (rather than
>> a string), and clarification of what value members are expected to contain.
>> 
>> For example, the following JSON object is in compliance with the preceding
>> normative description (and, as far as I can tell, all other normative text
>> in the document):
>> 
>> ["1",
>> ["65536", "rpki.example.com"],
>> [
>>   ["192.0.2.0/255.255.255.0", "All VRPs encompassed by prefix"],
>>   ["64496", "All VPRs maching ASN"],
>>   ["198.51.100.0/255.255.255.0", "64497", "All VRPs encompassed by prefix,
>>     matching ASN"]
>> ],
>> [
>>   ["64496", "All keys for ASN"],
>>   ["Zm9v", "Key matching Router SKI"],
>>   ["64497", "YmFy", "Key for ASN 64497 matching Router SKI"],
>> ],
>> [
>>   ["64496", "198.51.100.0/255.255.255.0", "My other important route"],
>>   ["64496", "2001:DB8::/FFFF:FFFF::", "48",
>>    "My other important de-aggregated routes"],
>> ],
>> [
>>   ["64496", "My known key for my important ASN",
>>    "<some base64 SKI>", "<some base64 public key>"]
>> ]
>> ]
>> 
>> Fixing this should be pretty easy; the document simply needs text added that
>> describes the JSON structure explicitly, with clear indications of how values
>> are to be encoded. For example, the preceding text I quote becomes:
>> 
>>  A SLURM file consists of a single JSON object containing the following
>>  members:
>> 
>>  o  A  "slurmVersion" member that MUST be set to 1, encoded as a number
>> 
>>  o  A "slurmTarget" member (Section 3.3) If more than one target line is
>>     present, all targets MUST be acceptable to the RP. The "slurmTarget"
>>     member is encoded as an array of zero or more objects. Each object in the
>>     array contains exactly one member.  In this version of SLURM, the member
>>     may be named either:
>> 
>>     * "asn", in which case it contains an ASN, or
>> 
>>     * "hostname", in which case it contains a Fully Qualified Domain
>>        Name (FQDN).
>> 
>>  o  A "validationOutputFilters" member (Section 3.4), whose value is an
>>     object. The object MUST contain exactly two members:
>> 
>>     *  A "prefixFilters" member, whose value is described in
>>        Section 3.4.1
>> 
>>     *  A "bgpsecFilters" member, whose value is described in
>>        Section 3.4.2
>> 
>>  o  A "locallyAddedAssertions" member (Section 3.5), whose value is an
>>     object. The object MUST contain exactly two members:
>> 
>>     *  A "prefixAssertions" member, whose value is described in
>>        Section 3.5.1
>> 
>>     *  A "bgpsecAssertions" member, whose value is described in
>>        Section 3.5.2
>> 
>> 
>> Gotchas to watch out for include:
>> 
>> - If you're using the word "element" to describe something in a JSON object,
>>  you probably need to find a more specific word. This document, for example,
>>  uses "element" instead of "member" in most places.
>> 
>> - Everywhere you use the word "structure," replace it with either "array" or
>>  "object," as appropriate.
>> 
>> - When values can be encoded as either a number or a string (e.g., as with
>>  "slurmVersion" above, or with AS numbers), indicate which encoding is
>>  expected.
>> 
>> - For IP prefixes, be clear about acceptable syntax. For example: is
>>  the RFC 950 syntax ("192.0.2.0/255.255.255.0") acceptable? My suggestion is
>>  to cite RFC 4632 §3.1 for prefix-length notation (both for IPv4 and IPv6),
>>  and RFC 5952 for the syntax of IPv6 addresses.
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> The remaining comments are in document order.
>> 
>> ---------------------------------------------------------------------------
>> 
>> Title:
>> 
>> It seems odd to use the stylized capitalization (e.g., "nUmber") without
>> following it by the "SLURM" acronym. Consider adding "(SLURM)" to the title.
>> 
>> ---------------------------------------------------------------------------
>> 
>> §3.1:
>> 
>>> This document describes responses in the JSON [RFC8259] format.
>> 
>> I don't think this means to say "responses," does it? It appears to be
>> describing a JSON document rather than a request/response protocol.
>> 
>> 
>> ---------------------------------------------------------------------------
>> 
>> §3.3:
>> 
>>> A SLURM file MUST specify a "slurmTarget" element that identifies the
>>> environment in which the SLURM file is intended to be used.  The
>>> "slurmTarget" element MAY have an empty array as its value, which
>>> means "applies to all".  The meaning of the "slurmTarget" element, if
>>> present, is determined by the user.  If a "slurmTarget" element is
>>> present, an RP SHOULD verify that the target is an acceptable value,
>>> and reject this SLURM file if the "slurmTarget" element is not
>>> acceptable.  Each "slurmTarget" element contains merely one "asn" or
>>> one "hostname".  An explanatory "comment" MAY be included in each
>>> "slurmTarget" element so that it can be shown to users of the RP
>>> software.
>> 
>> When reworking this paragraph in particular, please be careful to distinguish
>> between the "slurmTarget" member and the elements in the array that constitutes
>> its value. The preceding text calls both of these things '"slurmTarget"
>> element,' which is very confusing.
>> 
>> 
>> _______________________________________________
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
>