Subject: [I2nsf] Éric Vyncke's Discuss on draft-ietf-i2nsf-nsf-facing-interface-dm-21: (with DISCUSS and COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Tue, 15 Feb 2022 08:07:26 -0800

Éric Vyncke has entered the following ballot position for
draft-ietf-i2nsf-nsf-facing-interface-dm-21: 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/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-nsf-facing-interface-dm/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for the work put into this document.

Please find below one blocking DISCUSS points (mainly to start discussion),
some non-blocking COMMENT points (but replies would be appreciated even if only
for my own education).

Special thanks to Linda Dunbar for the shepherd's write-up including the
section about the WG consensus.

I hope that this helps to improve the document,

Regards,

-éric

# DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion on the following topics:

## Section 3.3

Many security practitioners prefer to have a congruent condition part for IPv4
and IPv6, so, why having *TWO* conditions rather than one where the
destination/source could be either IPv4 or IPv6. Separating the conditions can
only make the authoring of policies more complex.

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

# COMMENTS

## Abstract

The abstract mentions an information model but no reference is given. See also
my comment on section 1

## Section 1
There is a mention of an information model in
I-D.ietf-i2nsf-capability-data-model but as mentioned in my IESG ballot on that
document, it does not contain any information model... Strongly suggest
removing all mentions of 'information model' in the abstract and in this
section.

## Section 3.3
Is the use of "ethernet" as a generic term for layer 2 appropriate ? Many
layer-2 networks do not use Ethernet (so many IEEE standards...). Suggest to
rename into "layer2".

Should other "ethernet" fields be used? Like the VLAN or CoS fields ?

If the IPv4 and IPv6 conditions are kept separated (see my DISCUSS above), then
please rename the IPv6 "ttl" into "hop-limit" and "protocol" into "next-header".

More generally, and may be have I overlooked some previous explanations, is the
cardinality of ethernet, ipv4, ipv6 the most suitable one ? Can't a condition
have multiple IPv4 prefixes ?

## Section 4.1

Why is "session-aging-time" only a uint16 ? As its unit is "second", this
represents roughly 18 hours and I am sure that some sessions are longer than 18
hours (I have many opened SSH sessions for days).

In "identity reject", when mentioning the ICMP type and code, please specify
whether it is ICMPv4 or ICMPv6 ;-)

## Section 5.1

Thank you for the IPv6 example :-) Same comment as Erik Kline on the IPv6
address, may I also suggest to use a more sensible prefix length ? /60 should
be more representative.