Subject: [I2nsf] Éric Vyncke's Abstain on draft-ietf-i2nsf-nsf-facing-interface-dm-23: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Wed, 06 Apr 2022 01:14:26 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-i2nsf-nsf-facing-interface-dm-23: Abstain

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/about/groups/iesg/statements/handling-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/

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

Thank you for the work put into this document and for acting on most of my
comments on revision -21.

As written in a separate email, I am clearing my previous DISCUSS position but
I am balloting ABSTAIN as the IPv6 support in this document is really too low.
I understand that authors rely on the YANG modules of RFC 8519 which is clearly
not enough for IPv6.

About my own DISCUSS, the change to a "choice layer-3" is still a XOR: either
IPv4 or IPv6 and this is not what security practitioners want to do as they do
want congruent security policies. As we are kind of circling and not really
reaching a final agreement, I will change my ballot from DISCUSS to ABSTAIN.

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

Special thanks as well to Jean-Michel Combes for his INT directorate review.

Regards,

-éric

# DISCUSS (only kept for archiving)

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.

# COMMENTS (only kept for archiving)

## 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.

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Wed, 6 Apr 2022 22:20:14 +0900

Hi Éric,
Thanks for your response.
I put my answers below.

On Wed, Apr 6, 2022 at 5:14 PM Éric Vyncke via Datatracker <[email-masked]>
wrote:

> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/

 => [PAUL] I will address the extension of the support of IPv6 extension
headers
       after the publication of this document as an RFC and through the
revision of the RFC
       during the 2nd phase of I2NSF WG.
       I2NSF WG is now discussing the re-chartering including this
extension for the
       support of new protocols such IPv6 extension headers, QUIC, and
HTTP/3.

> reaching a final agreement, I will change my ballot from DISCUSS to

 => [PAUL] This XOP approach of "choice layer-3" is done by RFC 8519 as
follows:

 ---------------------------------------------------------------------------------------------------
       container matches {
            ...
            choice l3 {
              container ipv4 {
                when "derived-from-or-self(/acls/acl/type, "
                   + "'acl:ipv4-acl-type')";
                if-feature "match-on-ipv4";
                uses pf:acl-ip-header-fields;
                uses pf:acl-ipv4-header-fields;
                description
                  "Rule set that matches IPv4 headers.";
              }

              container ipv6 {
                when "derived-from-or-self(/acls/acl/type, "
                   + "'acl:ipv6-acl-type')";
                if-feature "match-on-ipv6";
                uses pf:acl-ip-header-fields;
                uses pf:acl-ipv6-header-fields;
                description
                  "Rule set that matches IPv6 headers.";
              }
              description
                "Choice of either IPv4 or IPv6 headers";
            }
            ...

 ---------------------------------------------------------------------------------------------------
       Éric,
       Could you consider this convention of l3 handling in ACL in RFC8519
to determine your ballot?

       Otherwise, we authors need another "Yes" or "No Objection" from the
following ADs:
       Andrew Alston, John Scudder, Lars Eggert, and Paul Wouters

        Thanks.

        Best Regards,
        Paul

> _______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf
>