Ekr: 

Thank you for your insightful comments.  The track has been changed to
informational in version 13.  Your comments have been fixed in version 15
(or in earlier versions).  

Sue 


-----Original Message-----
From: I2nsf [mailto:[email protected]] On Behalf Of Eric Rescorla
Sent: Friday, April 7, 2017 7:42 PM
To: The IESG
Cc: [email protected]; [email protected];
[email protected]; [email protected]
Subject: [I2nsf] Eric Rescorla's No Objection on
draft-ietf-i2nsf-problem-and-use-cases-11: (with COMMENT)

Eric Rescorla has entered the following ballot position for
draft-ietf-i2nsf-problem-and-use-cases-11: No Objection

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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/



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

I don't have any problem with this document per se, but it's a little odd
how it's written in a vacuum as if there weren't already technologies which
did a lot of the things you are talking about here (e.g., YANG) and which
the WG intends to use. I think this document would be a lot stronger if it
didn't act as if the WG was agnostic and instead called out what solutions
the WG intends to adopt for these.

Sue: Having set-up requirements for the I2RS protocol changes to YANG,
NETCONF, and RESTCONF, I respectfully disagree with you.  In writing the
document in this style, it allows other technologies (CBOR or COAP) to be
used.   We may invent other functions in the future that may better secure
mobile devices. 


I'm also somewhat surprised this is being advanced as Standards Track, given
that it doesn't have any normative content, and becaus ehte writeup says
that there isn't commitment to implement this.
I won't hold a DISCUSS on this, but I would suggest it be Informational.

Sue: It has been changed. 


S 2.
  Flow-based NSF:    An NSF which inspects network flows according to a
        security policy.  Flow-based security also means that packets are
        inspected in the order they are received,

This seems over-specific, because sometimes firewalls and the like will
store packets so that it can re-assemble them, in which case it inspects
them in logical not time order.

Sue: This specific comment summarizes a decision by the WG to define
flow-based security in this fashion.  This definition was the source of much
debate in the WG.   I agree that logical order can be used rather than time
order, but the WG focused on time order.  

S 3.1.7.
   Different policies might need different signatures or 
   profiles.  Today, the construction and use of black list databases
   can be a win-win strategy for all parties involved.

Well, except for attackers. They are involved.

Sue:  Nicely put - but 

S 3.1.9; bullet 3.
Symmetric keys and group keys are not the same type of category, so I can't
read this section. What are you trying to say here?

Agreed - symmetric keys and group keys are not the same type of category.
The point is that automated key management needs to support both.  Otherwise
requirements 1 + 2 cannot be met.  If you can suggest a better way to put
this section, please let me know.  

Section 3.1.9 - bullet 3: 
Old /Automated key management needs to support both symmetric keys and
group keys via the abstract key service provided by items 1 and
2. I2NSF controllers within the NSF required to exchange data
with NSFs may exchange data with individual NSFs using individual
symmetric keys or with a group of NSFs simultaneously using an IP
group address secured by a group security key(s). /


S 3.5.
"xamine" and "scnearios" are misspelled.

Sue: Fixed in earlier version.  My apologies for the error.  (I had the joy
of finding out my spell checker had been corrupted on my tool (notepad++)).


S 3.6.
ToR seems to be undefined.

Sue: It was changed prior to version 15. 


Figure 3.
I think this dotted circle-thing is intended to tell me that the operator
controls the stuff inside the circle, but I'm not sure. Maybe some labels
would help.

Sue: Label "Service provider is within figure 3.  Any further suggestions
would help. 


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

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

Reply via email to