[netmod] ACL draft issues found during shepherd writeup

Kent Watsen <kwatsen@juniper.net> Tue, 13 February 2018 22:31 UTC

Return-Path: <kwatsen@juniper.net>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5514E12D95B; Tue, 13 Feb 2018 14:31:04 -0800 (PST)
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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 DiWV_RHdiadO; Tue, 13 Feb 2018 14:31:01 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 AC98712D835; Tue, 13 Feb 2018 14:31:01 -0800 (PST)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1DMTEQW009520; Tue, 13 Feb 2018 14:31:01 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=QpdtEKlHwEHcoemozjCNiBycq/UrblmOhokG6q3Y0+A=; b=OgWyNlmv0IrgaEMaDTVR5q/N1j1NqRLOZ0FdQYe1cRpfzpBfp+lRhit5z57Nzw9rv3hd 7+46dcu2IbERVcHsUFkiZxIXUutxzp+OQI8bF6D2WxnLxC3E6WWio9VyumG0dwQEFpnP rPjsWXZTs36vxPhnVyo5eaURryU5zGTIBjXgtdpOTDLedi1Np2sW0NaMYmlbl5buX20k cddm8sGPWTz7+AQuZkU112/Hfl1CJCr+eizSEwcegNhVqe96+auK4eVgKbfk/MHXsevn u31a61hBxzQxMyx9dtF1rvDUj7os0AqSEXxcIBi+ODgbgtikTZOYqh1QgzWx8zTU5kj7 xg==
Received: from nam01-bn3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0183.outbound.protection.outlook.com [216.32.180.183]) by mx0a-00273201.pphosted.com with ESMTP id 2g48n081rq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 13 Feb 2018 14:31:01 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3547.namprd05.prod.outlook.com (10.174.242.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.7; Tue, 13 Feb 2018 22:30:59 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::7433:3915:f20d:6747]) by DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::7433:3915:f20d:6747%13]) with mapi id 15.20.0506.013; Tue, 13 Feb 2018 22:30:59 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: "draft-ietf-netmod-acl-model@ietf.org" <draft-ietf-netmod-acl-model@ietf.org>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: ACL draft issues found during shepherd writeup
Thread-Index: AQHTpRpSR0BIQpp1FUa5qmqsmhR9+Q==
Date: Tue, 13 Feb 2018 22:30:59 +0000
Message-ID: <14BA9086-69D4-4BAF-A7C7-0EB1F3F400BB@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB3547; 7:Kzt0uqqFaYK+tQdYBdLtHKdQ+cfc6aIww/+p37vx3RKgqMFL5sWVjHPGXfFKThfDyEmcdLgnWOx2M2yiPohewpdX69tBVevDB10NzH8SPQtAO0OyWX+6/UVXkubjhYHRldRpVtQNiXSKiICJh4w2R61adsiKqjS04CmqZBFYyVEoOLolJKxcv86lwVWnhMeKBO9CUlEE11ZgOgy8nKjDZokSePSu0eeR+TY7Hb7U5C+88ovGlxISB64dQDIE6apR
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 35d1aa59-9ddb-433c-85c9-08d5733174b0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3547;
x-ms-traffictypediagnostic: DM5PR05MB3547:
x-microsoft-antispam-prvs: <DM5PR05MB35479FECA5359E524F6CA92AA5F60@DM5PR05MB3547.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(10436049006162)(192374486261705)(788757137089);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(10201501046)(3231101)(944501161)(3002001)(93006095)(93001095)(6055026)(6041288)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR05MB3547; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3547;
x-forefront-prvs: 0582641F53
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(346002)(39380400002)(366004)(376002)(377424004)(199004)(189003)(85644002)(82746002)(478600001)(6116002)(2906002)(8676002)(81166006)(8936002)(102836004)(81156014)(59450400001)(14454004)(7736002)(966005)(6506007)(186003)(26005)(86362001)(6486002)(6436002)(83716003)(3846002)(58126008)(97736004)(4326008)(305945005)(25786009)(450100002)(83506002)(575784001)(316002)(5640700003)(6916009)(5660300001)(2351001)(106356001)(105586002)(66066001)(3280700002)(53936002)(68736007)(6306002)(2501003)(3660700001)(6512007)(36756003)(33656002)(2900100001)(99286004)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3547; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: /eWhJRskSRhqRTvvKCa5FVnk0oMY4DgLTygPxwBBfcoLTUGlF8lbfRWXgKXeMMyXrTGxgRfxQ1uAI6pGNHiLqw==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <D900ABEFFE2B6141AF37C795FAE6BC82@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 35d1aa59-9ddb-433c-85c9-08d5733174b0
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2018 22:30:59.0329 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3547
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-13_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802130264
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/OjPU-4AiVGrk7GYsi7slmh61PY4>
Subject: [netmod] ACL draft issues found during shepherd writeup
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Feb 2018 22:31:04 -0000

[sorry, wrong WG, moving netconf to BCC!]


ACL Authors,

Below are some issues I found while looking at doing the Shepherd
write-up today.  Please take a look.

Also, with regards to the request for those having Last Call comments
to please verify that their comments were addressed, I only saw one
response from Kristian, but should we be expecting respeonses from
others too, perhaps Einar or Elliot?


1 IDNITS

  - some issues found by idnits
  - using https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_tools_idnits_&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=7Bx3hgofSFxvNRV7Xz7FuaJcKKfzEB0sBJzN_KOCtSg&s=_5f-lxCoJW2TidcrjW_KbDkdPhfxLoL67kn1A2okgs0&e=
  - without selecting "verbose output"


1.1

  ** There are 5 instances of too long lines in the document, the longest one
     being 5 characters in excess of 72.


  This "**" is being flagged as an "error".  
  Idnits label, not mine.  Please fix.


1.2

  == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses
     in the document.  If these are example addresses, they should be changed.

  This is just a warning, but given that there are seven occurrences, it
  might be a good idea to fix.  Please see Section 3, point #6 in this
  document for details: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id-2Dinfo_checklist&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=7Bx3hgofSFxvNRV7Xz7FuaJcKKfzEB0sBJzN_KOCtSg&s=AYo8ZHPY4SAHMqcy1qV9yr7BjoxGy_C9zcJ_ZbwXBT4&e=xGy_C9zcJ_ZbwXBT4&e=.


1.3

  ** The document seems to lack a both a reference to RFC 2119 and the
     recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
     keywords. 

     RFC 2119 keyword, line 797: '...s-list. A device MAY restrict the leng...'


  There needs to be a section that looks like RFC 8174, paragraph 11:

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
     and "OPTIONAL" in this document are to be interpreted as
     described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
     appear in all capitals, as shown here.


1.4.

  -- The document date (February 2, 2018) is 11 days in the past.  Is this
     intentional?

  This is fine, ignore it.

1.5

  ** Obsolete normative reference: RFC 2460

  This needs to be fixed.

1.6

  ** Downref: Normative reference to an Historic RFC: RFC 3540

  Hmmmm, another HISTORIC document, but this time not due to an IESG
  action.  The question is how important this reference is, is this
  "ns" bit (ECN-nonce concealment protection) commonly used in the 
  industry?   

1.7

  == Outdated reference: A later version (-06) exists of
     draft-ietf-netmod-yang-tree-diagrams-04

  Please update to -06

1.8

  -- Obsolete informational reference (is this intentional?): RFC 5101
     (Obsoleted by RFC 7011)

  Please update to RFC 7011



2  YANG VALIDATION

2.1 Normative Modules

  All of the following passed:

    pyang --ietf ietf-access-control-list\@2018-02-02.yang 
    pyang --ietf ietf-packet-fields\@2018-02-02.yang 
    pyang --ietf ietf-ethertypes\@2018-02-02.yang

    yanglint -s ietf-access-control-list\@2018-02-02.yang 
    yanglint -s ietf-packet-fields\@2018-02-02.yang 
    yanglint -s ietf-ethertypes\@2018-02-02.yang 

2.2 Example Module

  Example module passed `yanglint -s`, but not `pyang --lint`:

    yanglint -s example-newco-acl.yang
    pyang --lint example-newco-acl.yang 

    example-newco-acl.yang:78: error: keyword "description" not in
    canonical order, expected "type", (See RFC 6020, Section 12)

    example-newco-acl.yang:79: error: keyword "type" not in 
    canonical order, (See RFC 6020, Section 12)

    example-newco-acl.yang:82: error: keyword "default" not in 
    canonical order, (See RFC 6020, Section 12)

  Please fix.


2.3 XML Examples from Section 4.3

  yanglint didn't find any issues:

    yanglint ietf-access-control-list\@2018-02-02.yang ex-4.3.xml 


2.4 Examples from Section 4.4

  I had to stitch these into the 4.3 example.  It found one issue, a typo
  in the last closing tag in the first example in this section:

    yanglint ietf-access-control-list\@2018-02-02.yang ex-4.4++.xml 
    err : Invalid (mixed names) opening (source-port-range-or-operator) and closing (tcp) element tags. (/data/access-lists/acl/aces/ace/matches/l4/tcp/source-port-range-or-operator/source-port-range-or-operator)

  Please fix.


  PS: And this is not a shepherd directive, but I found the whole 
      "source-port-range-or-operator" syntax clumsy.  I'm surprised
      it didn't look something like:

          OLD
                <source-port-range-or-operator>
                   <port-range-or-operator>
                     <range>
                       <lower-port>16384</lower-port>
                       <upper-port>65535</upper-port>
                     </range>
                   </port-range-or-operator>
                </source-port-range-or-operator>

                <source-port-range-or-operator>
                  <port-range-or-operator>
                    <operator>
                      <operator>eq</operator>
                      <port>21</port>
                    </operator>
                  </port-range-or-operator>
                </source-port-range-or-operator>

          NEW

                <source-port>
                  <range>
                    <lower>16384</lower>
                    <upper>65535</upper>
                  </range>
                </source-port>

                <source-port>
                  <operator>
                    <operator>eq</operator>
                    <port>21</port>
                  </operator>
                </source-port>



3 Key Draft Sections


3.1 Abstract

  First, I'm unsure if that first "sentence" is properly worded, but I
  definitely think that it is a bit too much on the terse side.  Can you
  embellish it a little?

  Second, am I reading it correct? - is the "Editorial Note" in the
  Abstract section.  I strongly advise moving 

3.2 RFC Editor Note

  There is no request to replace "I-D.ietf-netmod-yang-tree-diagrams" with
  the final RFC assignment.

  You might want to add what the current date value used in the draft is
  (i.e., 2018-02-02).   PS: my draft build tools, which I think you're
  using, should set the value for you automatically if you put YYYY-MM-DD
  into the text.


3.3 Import statements missing references

  All import statements in all modules are missing reference statements
     - why wasn't this caught by the tools?!

  Please see rfc6087bis Section 4.7.  


3.4 Security Considerations

  Please reformat the last paragraph so the "aces" path is more pronounced.
  Perhaps use hangText.


3.5 IANA Considerations

  This section is hard to read.

  Consideration breaking up the "XML" and the "YANG Module Names" registry
  requests into two subsections.

  Consider making the registration entry requests themselves artwork so
  they're line-spaced and indented as such.
 
  The first paragraph of the "XML" registry request says "a URI", but it 
  should be "two URIs"

  The first paragraph of the "YANG Module Names" registry request says 
  "a YANG module", but it should be "two YANG modules"


3.6 References

  I haven't checked yet, but please verify that all the references are
  properly sorted as to being Normative or Informative.


3.7 Appendix A

  It took me awhile to figure out what I was looking at.  The tree-diagram
  is poorly indented and there is no text preceding the example module.  

  I recommend you fold the lines of your tree diagram at a certain column
  whilst adding a '\' character.  I've since added this ability to my draft
  build tools, let me know if interested in an update.  You might also want
  to look at draft-wu-netmod-yang-xml-doc-conventions.

  Also, please fix the example module's namespace per the end of 
  rfc6087bis Section 4.9.



Thanks,
Kent




_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=7Bx3hgofSFxvNRV7Xz7FuaJcKKfzEB0sBJzN_KOCtSg&s=XknLqgAu3Z9t1ME6FO-_mZY2oCN61867VB0ubLeiv3Q&e=