[I2nsf] Éric Vyncke's Discuss on draft-ietf-i2nsf-capability-data-model-12: (with DISCUSS and COMMENT)
Éric Vyncke via Datatracker <noreply@ietf.org> Mon, 21 September 2020 09:19 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: i2nsf@ietf.org
Delivered-To: i2nsf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 467843A0B22; Mon, 21 Sep 2020 02:19:10 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Éric Vyncke via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-i2nsf-capability-data-model@ietf.org, i2nsf-chairs@ietf.org, i2nsf@ietf.org, Linda Dunbar <dunbar.ll@gmail.com>, dunbar.ll@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.17.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Éric Vyncke <evyncke@cisco.com>
Message-ID: <160067995004.16306.16002090566817704506@ietfa.amsl.com>
Date: Mon, 21 Sep 2020 02:19:10 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/go0-TeYvSCQwVTbwE7CF86HACCc>
Subject: [I2nsf] Éric Vyncke's Discuss on draft-ietf-i2nsf-capability-data-model-12: (with DISCUSS and COMMENT)
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <i2nsf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2nsf/>
List-Post: <mailto:i2nsf@ietf.org>
List-Help: <mailto:i2nsf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Sep 2020 09:19:10 -0000
Éric Vyncke has entered the following ballot position for draft-ietf-i2nsf-capability-data-model-12: 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-i2nsf-capability-data-model/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for the work put into this document. While I do appreciate that a data model (this document) is derived from an information model, I am concerned that the information model is an expired draft whereas I would expect the information model being published first. Else, what is the use of the information model ? What was the WG reasoning behind 'putting the cart before the horses' ? My concern is that by publishing the YANG model, there is nearly no way to change the information model anymore. Please find below a couple of non-blocking COMMENT points but also a couple of blocking DISCUSS points around IPv6. They should be easy to resolve. I would hate to have NSF having basic IPv6 capabilities that cannot be configured by using the YANG model of this document. I hope that this helps to improve the document, Regards, -éric == DISCUSS == -- Section 4.1 -- It is quite common to apply conditions based on the whole IPv6 extension header chain (i.e., presence of destination option header or wrong order of the extension headers). Why is there no such capabilities in this YANG module ? The only one is 'identity ipv6-next-header' that applies only to the first extension header. What is the difference between 'identity ipv6-protocol' and 'identity ipv6-next-header' ? There is no 'protocol' field in the IPv6 header. While fragmented IPv4 packets are part of the conditions ('identity ipv4-fragment-flags'), there is no equivalent in IPv6. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -- Section 4.1 -- May be am I misreading the YANG tree, but, I see no 'sctp-capability' in the set of 'condition-capabilities' (even is SCTP is not heavily used). Is there a real reason to have two related containers ? generic-nsf-capabilities and advanced-nsf-capabilities. Why not a single one ? Unsure what is meant by 'range' in 'identity range-ipv*-address'. Usually, addresses are filtered/matched by using a prefix length and not a range (that is difficult to implement in hardware). Is there a reason why ICMP(v6) codes are not part of the conditions ?
- [I2nsf] Éric Vyncke's Discuss on draft-ietf-i2nsf… Éric Vyncke via Datatracker
- Re: [I2nsf] Éric Vyncke's Discuss on draft-ietf-i… Susan Hares
- Re: [I2nsf] Éric Vyncke's Discuss on draft-ietf-i… Diego R. Lopez
- Re: [I2nsf] Éric Vyncke's Discuss on draft-ietf-i… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] Éric Vyncke's Discuss on draft-ietf-i… Eric Vyncke (evyncke)