On Wed, 20 Apr 2022, Mr. Jaehoon Paul Jeong wrote:
Hi Paul,
Thanks for your review.
I have submitted the revised draft reflecting your comments and questions:
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-monitoring-data-model-18
There are my answers to your comments and questions inline below.
Thanks. Your changes and answers addressed my concerns. I've changed my ballot
to NO OBJECTION.
Paul
On Wed, Apr 20, 2022 at 12:25 AM Paul Wouters <[email protected]> wrote:
On Tue, 19 Apr 2022, Mr. Jaehoon Paul Jeong wrote:
> 2. I2NSF Monitoring Interface YANG Data Model
> -
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-nsf-monitoring-data-model/
> - Paul Wouters is holding Ben Kaduk's DISCUSS position, and needs to
check whether my revision satisfies Ben's DISCUSS or not.
> - This draft has gotten 9 supporting ballots (Yes or No Objection).
Yes it addresses most of the DISCUSS items. I am about to change it but
I have one question left:
Section 6.7.1 had comments about firewall rule counters and properties,
and the document change just removed the listed properties. I am a
little confused how this addresses Ben's point. How do people know which
properties are defined ?
=> [PAUL] As mentioned in page 3 in the revision letter, the information
(including
src-ip, dst-ip, src-port, dst-port, protocol, and app) in Section 6.7.1
was
included by mistake, since this information is not included in the YANG
data
model. The purpose of the firewall counter is to show what a security
policy
in the firewall has done. Thus, we removed the unnecessary fields from
Section 6.7.1 and updated the description.
Some review comments:
The QUIC traffic should not be treated as UDP traffic
You probably mean to say "treated as generic UDP traffic". It _is_ still
UDP traffic after all.
=> [PAUL] You are right. I have updated the sentence according to your
comments as follows:
"The QUIC traffic should not be treated as generic UDP traffic and
will be considered in the future I2NSF documents."
The cookies information needs to be kept confidential and
is not RECOMMENDED to be included in the monitoring data unless
the information is absolutely necessary to help to enhance the
security of the network.
I am not sure why this header is specifically treated compared to other
HTTP headers. Please write "NOT RECOMMENDED" (eg uppercase the 'not').
This text does address Ben's DISCUSS.
=> [PAUL] This is because cookies contain the information to degrade security
and privacy
as mentioned in RFC 6265 (HTTP State Management Mechanism).
I have updated the text about the HTTP Cookies header in Section 6.3.4 as
follows:
"o cookies: The HTTP Cookie header field of the request from the user
agent.
Note that though cookies have many historical infelicities that degrade
security and privacy, the Cookie and Set-Cookie header fields are widely
used
on the Internet [RFC6265]. Thus, the cookies information needs to be kept
confidential and is NOT RECOMMENDED to be included in the monitoring data
unless the information is absolutely necessary to help to enhance the
security of the network.
Thanks.
Best Regards,
Paul
> 3. I2NSF NSF-Facing Interface YANG Data Model
> -
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-nsf-facing-interface-dm/
> - This draft has gotten 9 supporting ballots (Yes or No Objection) and
Éric Vyncke changed his DISCUSS to ABSTAIN.
> - This draft needs another review of one among the IESG ADs with No
Record.
I will cast my ballot for this one later today after I've had a change
to review it.
Paul
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
