Subject: [I2nsf] Erik Kline's Discuss on draft-ietf-i2nsf-capability-data-model-12: (with DISCUSS and COMMENT)

From: Erik Kline via Datatracker <[email-masked]>
Date: Tue, 22 Sep 2020 21:58:09 -0700

Erik Kline 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:
----------------------------------------------------------------------

[ general ]

* At a high level, I'm slightly concerned about the state of the IP-geo
  aspects of this document.  It's not obvious to me what's desired (nor
  what may be achievable) here.

  [1] RFC 8805

  In section 5, there's a reference to 8805.  This document is an
  Independent Stream Editor's document, and not an IETF standard.  I don't
  know if that's technically disqualifying from being listed as a Normative
  reference or not.  Regardless, it certainly does not represent any formal
  industry consensus.

  [2] ipv4-geo-ip

  This references draft-ietf-i2nsf-capability, but I cannot find any
  discussion of IPv4 address geolocation in that document (admittedly I have
  not read it thoroughly).

  [3] ipv6-geo-ip

  I did not find an analogous geo-ip element for IPv6.  If there should be
  support for geolocation for one address family there should probably be
  support for the other.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

[[ comments ]]

[ section 1 ]

* This document describes a YANG model outlining a few more I2NSF
  documents than just i2nsf-capability, including:

    - i2nsf-nsf-monitoring-data-model
    - i2nsf-sdn-ipsec-flow-protection

  Indeed, this is noted in section 5.  I think it could help the reader
  when they get to section 4.1 if some earlier section also noted the
  more complete list of references that section 5 does.

[ section 4.1 ]

* ICMPv6 is notable by its absence from the list in the paragraph describing
  the "condition capabilities of generic network security functions".

[ section 5 ]

* The meaning of ipv6-protocol is not immediately obvious, and may be
  redundant with ipv6-next-header (the actual name of the header field).

  Or rather, does ipv6-protocol here mean IPv6 itself (as in the value
  "6" or "true" meaning 'is capable of')?

  Or does this mean the first non-IPv6-extension-header next-header value?

[[ nits ]]

[ section 1 ]

* "As the industry becomes more sophisticated and network devices (...),"
  This is not a grammatically complete clause.  Maybe just something like:

  "...and network devices (...) continue to proliferate, ..."

  or something.

[ section 3 ]

* "at a Developer's Management Systems" ->
  "at a Developer's Management System"

* "managing the capabilities of NSFs in this document" ->
  "managing the capabilities of NSFs as described in this document"?

* "network administrator ..., he sends" ->
  "network administrator ..., they send"

* "sends that security policy rules" ->
  "sends that security policy rule"

* "This lets an I2NSF User not consider NSFs where the rule is applied."

  I found this confusing.  Does it mean to say something like
  "...where the rule is not applicable"?