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

Tim Bruijnzeels <tim@ripe.net> Thu, 05 April 2018 10:38 UTC

Return-Path: <tim@ripe.net>
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 F056B129BBF; Thu, 5 Apr 2018 03:38:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 T0LapdF0jN0I; Thu, 5 Apr 2018 03:38:17 -0700 (PDT)
Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 485B0127369; Thu, 5 Apr 2018 03:38:17 -0700 (PDT)
Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from <tim@ripe.net>) id 1f42HV-0003kv-4f; Thu, 05 Apr 2018 12:38:14 +0200
Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-103.ripe.net) by titi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from <tim@ripe.net>) id 1f42HU-0000xs-Ix; Thu, 05 Apr 2018 12:38:12 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <152286976586.23998.1170348122023610014.idtracker@ietfa.amsl.com>
Date: Thu, 5 Apr 2018 12:38:05 +0200
Cc: The IESG <iesg@ietf.org>, Chris Morrow <morrowc@ops-netman.net>, draft-ietf-sidr-slurm@ietf.org, IETF SIDR <sidr@ietf.org>, sidr-chairs@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1EFF9988-F988-4A4C-B860-B244C1A59A6E@ripe.net>
References: <152286976586.23998.1170348122023610014.idtracker@ietfa.amsl.com>
To: Adam Roach <adam@nostrum.com>
X-Mailer: Apple Mail (2.3445.5.20)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: -------
X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719983d8f7763dc1396544427d90bd49203
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/vbxxyEqVQ-5VEdvRxquljt5ZZKI>
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 10:38:20 -0000

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