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
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
