Return-Path: 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 766B51205CC for ; Tue, 25 Jun 2019 19:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=yumaworks-com.20150623.gappssmtp.com 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 2VdaU4RGKz8E for ; Tue, 25 Jun 2019 19:09:02 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 E7DE81201C6 for ; Tue, 25 Jun 2019 19:09:01 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id a21so467048ljh.7 for ; Tue, 25 Jun 2019 19:09:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=E64gBMgTVoaDlbzB7pVwLzc+AQ1gR8RK2l+QCJlfTaE=; b=WYQH8WoyOcLm1Qhfyv7xu5yDjbgW6GIy2MCuAVVJqoBViL8i6d6Jiuhs4Gz1Qm8bjI zob87uYuNk8VWjASwBB5GMEWB+J1m5hLZ+9rqUefI4Z7MN0YdusBZmTVvdmZtPTlM1fk 9eLvuNOwWeAwNo2yLXrfAoXyzLT2Z+/Mxeyprwy0+yJ2byNHkWGdvrombxDTgX5B4Aie M26ypbHBI9MIDx6BuCo/jyGS2dVj1eustVpiXv8ZXTYCFjfbsDo27RqckEx8N4n/l8rz xSQNMp3RM44JL/MG0UG0dAt2r2Uxd2kACcufkBRQrWgTfclVsOyJMG17Q+kvEw+upw/Y 2/mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=E64gBMgTVoaDlbzB7pVwLzc+AQ1gR8RK2l+QCJlfTaE=; b=JrqlEVPEzbYAyHpetERiRsTLpHE2m0c3Y4C8ZfxDOm+aXy4PMaYpnGA0yz/HFh1tpq j5EaaKb8+bs7enzp4RPM+RoZqm1VYsbDI9qaF7v7LSKmHaz6EYfA/DLiqXsYZdPawO8d zI/YXuCZdee8wKf6NZdiA/lbM6oecq7n9dysWsbt6RqJkUoXss6cywmzkphxzDJAllq0 gKfCGUd5eNlz8CArGDINVVcOH2fnDHse9CXauUHbQ3EosTc5Ctjx7b1jhGNww70ibkBa ivk13kO9sW/yD+MXJ4AzAtUzNI9Il/vEFHffNFswPg5GBbrBqYP8ch0TumQfc4FRyHJ2 WBAg== X-Gm-Message-State: APjAAAUkEmt9P1tjLzCZFtTwi8+1BfyHSHpSW/JQKovypqkFcJbXIYfq Acc6k0zGhDigqIKBlCOFdlOdczzqwOnnQuwzEjBH1g== X-Google-Smtp-Source: APXvYqzM7bgq+FdKC9ZgACOysDI76gNRmaK2w10ycWrMpNfITrqDTWcsEICLzLgR1YI6vWe0TJLhK9A6KlV6Nu6ImW0= X-Received: by 2002:a2e:9657:: with SMTP id z23mr955961ljh.116.1561514939978; Tue, 25 Jun 2019 19:08:59 -0700 (PDT) MIME-Version: 1.0 References: <20190624035835.A751EB81C64@rfc-editor.org> <572CA971-312C-4EED-BB09-9D866FFDAD16@gmail.com> In-Reply-To: <572CA971-312C-4EED-BB09-9D866FFDAD16@gmail.com> From: Andy Bierman Date: Tue, 25 Jun 2019 19:08:49 -0700 Message-ID: To: Mahesh Jethanandani Cc: RFC Editor , Ignas Bagdonas , dana@blairhome.com, NetMod WG , Warren Kumari , Yi Huang Content-Type: multipart/alternative; boundary="0000000000004f2904058c3087a7" Archived-At: Subject: Re: [netmod] [Technical Errata Reported] RFC8519 (5762) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 02:09:10 -0000 --0000000000004f2904058c3087a7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 25, 2019 at 6:59 PM Mahesh Jethanandani wrote: > This errata should be rejected for the following reason. > > This errata should be rejected because the Errata process cannot be used to update a module. The normal WG document process needs to be used instead. A new revision of the module is needed to add a default-stmt to a leaf. Andy The whole idea of defining the identities for acl-type was to allow vendors > to specify what capabilities their box is capable of supporting and then = to > specify what capabilities the vendors want to support. As such there is n= o > =E2=80=9Cdefault capability" for every vendor. Besides, if a device adver= tises a > mixed-eth-ipv4 feature, it is because it can only support Ethernet and IP= v4 > ACL combinations, and it cannot support IPv6 ACL matches. You do not add = a > capability of IPv6 match on the fly. It either has it, or it does not. If > it does, advertise mixed-eth-ipv4-ipv6 capability to begin with. > > > On Jun 23, 2019, at 8:58 PM, RFC Errata System < > rfc-editor@rfc-editor.org> wrote: > > > > The following errata report has been submitted for RFC8519, > > "YANG Data Model for Network Access Control Lists (ACLs)". > > > > -------------------------------------- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid5762 > > > > -------------------------------------- > > Type: Technical > > Reported by: Qin WU > > > > Section: 4.1 > > > > Original Text > > ------------- > > leaf type { > > type acl-type; > > description > > "Type of ACL. Indicates the primary intended > > type of match criteria (e.g., Ethernet, > > IPv4, IPv6, mixed, etc.) used in the list > > instance."; > > } > > > > Corrected Text > > -------------- > > leaf type { > > type acl-type; > > default "ipv4-acl-type"; > > description > > "Type of ACL. Indicates the primary intended > > type of match criteria (e.g., Ethernet, > > IPv4, IPv6, mixed, etc.) used in the list > > instance."; > > } > > > > Notes > > ----- > > I am wondering why not set default value for acl-type,e.g., set defaul= t > value as "ipv4-acl-type" otherwise, how to determine which field under > which choice will be matched upon and which action should be taken on the= m > if the opetional parameter type under acl list is not set. > > > > Also I want to better understand why acl type is removed from key > indexes of access list and keep it as optional parameter under acl list. > One case I am thinking in my mind is we add a mixed Ethernet, IPv4, and > IPv6 ACL entry when we already have Ethernet ACL entry,IPv4 ACL entry , w= e > don't need to remove existing ethernet entry and existing IPv4 entry in t= he > list ("aces") and create a new entry with mixed ethernet, IPv4, IPv6 ACL, > instead, we just add a new identity called mixed-eth-ipv4-ipv6-acl-type a= nd > add a new IPv6 entry. > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC8519 (draft-ietf-netmod-acl-model-21) > > -------------------------------------- > > Title : YANG Data Model for Network Access Control Lists > (ACLs) > > Publication Date : March 2019 > > Author(s) : M. Jethanandani, S. Agarwal, L. Huang, D. Blair > > Category : PROPOSED STANDARD > > Source : Network Modeling > > Area : Operations and Management > > Stream : IETF > > Verifying Party : IESG > > Mahesh Jethanandani > mjethanandani@gmail.com > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --0000000000004f2904058c3087a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jun 25, 2019 at 6:59 PM Mahes= h Jethanandani <mjethanandani= @gmail.com> wrote:
This errata should be rejected for the following reason.


This errata should be rejected because= the Errata process cannot be used to update a module.
The normal= WG document process needs to be used instead.
=C2=A0A new revisi= on of the module is needed to add a default-stmt to a leaf.

<= /div>

Andy



<= /div>
The whole idea of defining the identities for acl-type was to allow vendors= to specify what capabilities their box is capable of supporting and then t= o specify what capabilities the vendors want to support. As such there is n= o =E2=80=9Cdefault capability" for every vendor. Besides, if a device = advertises a mixed-eth-ipv4 feature, it is because it can only support Ethe= rnet and IPv4 ACL combinations, and it cannot support IPv6 ACL matches. You= do not add a capability of IPv6 match on the fly. It either has it, or it = does not. If it does, advertise mixed-eth-ipv4-ipv6 capability to begin wit= h.

> On Jun 23, 2019, at 8:58 PM, RFC Errata System <rfc-editor@rfc-editor.org&g= t; wrote:
>
> The following errata report has been submitted for RFC8519,
> "YANG Data Model for Network Access Control Lists (ACLs)". >
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid5762
>
> --------------------------------------
> Type: Technical
> Reported by: Qin WU <bill.wu@huawei.com>
>
> Section: 4.1
>
> Original Text
> -------------
> leaf type {
> type acl-type;
> description
>=C2=A0 "Type of ACL.=C2=A0 Indicates the primary intended
>=C2=A0 =C2=A0type of match criteria (e.g., Ethernet,
>=C2=A0 =C2=A0IPv4, IPv6, mixed, etc.) used in the list
>=C2=A0 =C2=A0instance.";
> }
>
> Corrected Text
> --------------
> leaf type {
> type acl-type;
> default "ipv4-acl-type";
> description
>=C2=A0 "Type of ACL.=C2=A0 Indicates the primary intended
>=C2=A0 =C2=A0type of match criteria (e.g., Ethernet,
>=C2=A0 =C2=A0IPv4, IPv6, mixed, etc.) used in the list
>=C2=A0 =C2=A0instance.";
> }
>
> Notes
> -----
> I am wondering why not=C2=A0 set default value for acl-type,e.g., set = default value as "ipv4-acl-type" otherwise, how to determine whic= h field under which choice will be matched upon and which action should be = taken on them if the opetional parameter type under acl list is not set. >
> Also I want to better understand why acl type is removed from key inde= xes of access list and keep it as optional parameter under acl list. One ca= se I am thinking in my mind is we add a mixed Ethernet, IPv4, and IPv6 ACL = entry when we already have Ethernet ACL entry,IPv4 ACL entry , we don't= need to remove existing ethernet entry and existing IPv4 entry in the list= ("aces") and create a new entry with mixed ethernet, IPv4, IPv6 = ACL, instead, we just add a new identity called mixed-eth-ipv4-ipv6-acl-typ= e and add a new IPv6 entry.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary= , please
> use "Reply All" to discuss whether it should be verified or<= br> > rejected. When a decision is reached, the verifying party=C2=A0
> can log in to change the status and edit the report, if necessary. >
> --------------------------------------
> RFC8519 (draft-ietf-netmod-acl-model-21)
> --------------------------------------
> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: YANG Dat= a Model for Network Access Control Lists (ACLs)
> Publication Date=C2=A0 =C2=A0 : March 2019
> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: M. Jethanandani, S= . Agarwal, L. Huang, D. Blair
> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD<= br> > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Network Model= ing
> Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Operatio= ns and Management
> Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
> Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG

Mahesh Jethanandani
mjethanandani@= gmail.com



_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--0000000000004f2904058c3087a7--