Subject: [I2nsf] AD Review follow-up on draft-ietf-i2nsf-nsf-facing-interface-dm-15

From: Roman Danyliw <[email-masked]>
Date: Tue, 2 Nov 2021 18:59:57 +0000

Hi!

Thanks for all of the work on draft versions -13 to -15.  To make thing easier to track, I'm starting a new thread on this -15 version of the document to comment on my AD review of -12 (https://mailarchive.ietf.org/arch/msg/i2nsf/_cKk5mUXKGgmNeVWPxfAIn79X70/).  Unless otherwise noted below, please consider previously feedback as resolved.

As these are modest edits, please handle them during or with the rest of the IETF LC feedback.  After IETF LC, given the dependence of this document on draft-ietf-i2nsf-capability-data-model, I want to progress them to the IESG together (i.e., place them on the same telechat).

** YANG module.  Identity {invoke-signaling, tunnel-encapsulation, forwarding, and redirection} need an explanation.

[Roman on -12] -- "identity {invoke-signaling, tunnel-encapsulation, forwarding, and redirection}" have no descriptions or references themselves; the parent "leaf egress-action" description simply restates the names of these identities; leaving a reliance on the reference in "container packet-action" and "container flow-action" which has citations to RFC8329 and draft-ietf-i2nsf-capability-data-model-15

RFC8329 contains the following in Section 7.2:

   "o  Actions performed on egress packets, such as invoke signaling,
      tunnel encapsulation, packet forwarding, and/or transformation."

draft-ietf-i2nsf-capability-data-model-15 has an "identity {invoke-signaling, forwarding, and redirection}" which cites RFC8329.  It has no definition of "identity tunnel-encapsulation".

It seems like some reference in the I2NSF ecosystem needs to be produced to describe what these actions do.

[Paul per -13] The identity tunnel-encapsulation is added to the NSF-Facing Interface data model along with invoke-signaling, forwarding, transformation, and redirection to properly accommodate egress actions in RFC 8329.

[Roman on -15]  Understood.  I appreciate that Section 7.2 of RFC8329 uses those words and as a result they are enumerated here.  The concern I have is that I don't know what "invoke signaling" means.  Could a descriptive sentence please be added to each of these identifies (i.e., invoke-signaling, forwarding, and redirection).  In ietf-i2nsf-capability-data-model-17, improved descriptions were added for mirror, rate limit, etc.  Could something similar be done?

** Section 6.  Per "For security requirements ... described in Appendix A", there is no Appendix A in this document.

[Roman on -12] Thanks for the edits.  It introduced a reference typo s/ described in Section Configuration Examples of [I-D.ietf-i2nsf-capability-data-model]/ described in Appendix A of [I-D.ietf-i2nsf-capability-data-model]/

[Roman on -15] Another typo was introduced here.

OLD
   For security requirements, we assume
   that the NSFs (i.e., General firewall, Time-based firewall, URL
   filter, VoIP/VoLTE filter, and http and https flood mitigation )
   described in of [I-D.ietf-i2nsf-capability-data-model] are registered

NEW
For security requirements, we assume that the NSFs (i.e., General firewall, Time-based firewall, URL filter, VoIP/VoLTE filter, and http and https flood mitigation) described in Appendix A of [I-D.ietf-i2nsf-capability-data-model] are registered ...

** Idnits returned
== Unused Reference: 'IANA-ICMPv6-Parameters' is defined on line 3734, but
     no explicit reference was found in the text

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Sun, 14 Nov 2021 01:12:46 +0900

Hi Roman,
Here is the revision of the I2NSF NSF-Facing Interface Data Model Draft:
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-facing-interface-dm-16

I attach the revision letter.

Thanks for your support.

Best Regards,
Paul

On Wed, Nov 3, 2021 at 4:01 AM Roman Danyliw <[email-masked]> wrote:

> Hi!
>
> Thanks for all of the work on draft versions -13 to -15.  To make thing
> easier to track, I'm starting a new thread on this -15 version of the
> document to comment on my AD review of -12 (
> https://mailarchive.ietf.org/arch/msg/i2nsf/_cKk5mUXKGgmNeVWPxfAIn79X70/).
> Unless otherwise noted below, please consider previously feedback as
> resolved.
>
> As these are modest edits, please handle them during or with the rest of
> the IETF LC feedback.  After IETF LC, given the dependence of this document
> on draft-ietf-i2nsf-capability-data-model, I want to progress them to the
> IESG together (i.e., place them on the same telechat).
>
> ** YANG module.  Identity {invoke-signaling, tunnel-encapsulation,
> forwarding, and redirection} need an explanation.
>
> [Roman on -12] -- "identity {invoke-signaling, tunnel-encapsulation,
> forwarding, and redirection}" have no descriptions or references
> themselves; the parent "leaf egress-action" description simply restates the
> names of these identities; leaving a reliance on the reference in
> "container packet-action" and "container flow-action" which has citations
> to RFC8329 and draft-ietf-i2nsf-capability-data-model-15
>
> draft-ietf-i2nsf-capability-data-model-15 has an "identity
> {invoke-signaling, forwarding, and redirection}" which cites RFC8329.  It
> has no definition of "identity tunnel-encapsulation".
>
> [Paul per -13] The identity tunnel-encapsulation is added to the
> NSF-Facing Interface data model along with invoke-signaling, forwarding,
> transformation, and redirection to properly accommodate egress actions in
> RFC 8329.
>
> [Roman on -15]  Understood.  I appreciate that Section 7.2 of RFC8329 uses
> those words and as a result they are enumerated here.  The concern I have
> is that I don't know what "invoke signaling" means.  Could a descriptive
> sentence please be added to each of these identifies (i.e.,
> invoke-signaling, forwarding, and redirection).  In
> ietf-i2nsf-capability-data-model-17, improved descriptions were added for
> mirror, rate limit, etc.  Could something similar be done?
>
> ** Section 6.  Per "For security requirements ... described in Appendix
> A", there is no Appendix A in this document.
>
> [Roman on -12] Thanks for the edits.  It introduced a reference typo s/
> described in Section Configuration Examples of
> [I-D.ietf-i2nsf-capability-data-model]/ described in Appendix A of
> [I-D.ietf-i2nsf-capability-data-model]/
>
> For security requirements, we assume that the NSFs (i.e., General
> firewall, Time-based firewall, URL filter, VoIP/VoLTE filter, and http and
> https flood mitigation) described in Appendix A of
> [I-D.ietf-i2nsf-capability-data-model] are registered ...
>
> ** Idnits returned
> _______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf
>

---

From: Roman Danyliw <[email-masked]>
Date: Sun, 14 Nov 2021 19:38:25 +0000

Hi Paul!

Many thanks for these edits to address  the last of my feedback.

From the auto-generated scheduling information from the datatracker, IETF LC will continue to run till 2021-11-23 awaiting further community input.

Regards,
Roman

From: Mr. Jaehoon Paul Jeong <[email-masked]>
Sent: Saturday, November 13, 2021 11:13 AM
To: Roman Danyliw <[email-masked]>
Cc: [email-masked]; skku-iotlab-members <[email-masked]>; Mr. Jaehoon Paul Jeong <[email-masked]>
Subject: Re: [I2nsf] AD Review follow-up on draft-ietf-i2nsf-nsf-facing-interface-dm-15

Hi Roman,

Thanks for your support.

Best Regards,
Paul

On Wed, Nov 3, 2021 at 4:01 AM Roman Danyliw <[email-masked]<mailto:[email-masked]>> wrote:
Hi!

OLD

NEW

** Idnits returned

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