Hi Adrian,
thanks for the thorough review. Your comments are addressed below. Please
note that I can NOT find reviews of this draft by Christian and Med. I did
search the archive. I found comments on the terminology draft from
Christian.
regards,
John
ALL comments were accepted, except as noted below.
In 2.2, the term used in
is "I2NSF Consumer"
I suggest you write
Consumer: Equivalent to "I2NSF Consumer"
<jcs>
This should be I2NSF Consumer according to the terminology draft, so I made
that change throughout this document.
</jcs>
---
I'm struggling a little with ....
3.3. Registration Interface
NSFs provided by different vendors may have different capabilities.
In order to automate the process of utilizing multiple types of
security functions provided by different vendors, it is necessary to
have an interface for vendors to define the capabilities of their
NSFs. This Interface Group is called the Registration Interface
Group.
An NSF's capabilities can either be pre-configured or retrieved
dynamically through the Registration Interface Group. If a new
function that is exposed to the consumer is added to an NSF, then
those capabilities SHOULD be notified to security controllers via the
Registration Interface Group.
There is definitely an ambiguity about this. Is the section talking
about the "Registration Interface Group"? What are the component
interfaces in this group?
<jcs>
Terminology defines an Interface Group, but not a Registration Interface
Group. I have changed this to "I2NSF Registration Interface".
Here is the rewritten paragraph:
3.3. I2NSF Registration Interface
NSFs provided by different vendors may have different capabilities.
In order to automate the process of utilizing multiple types of
security functions provided by different vendors, it is necessary to
have a dedicated interface for vendors to define the capabilities of
(i.e., register) their NSFs. This Interface is called the
I2NSF Registration Interface.
An NSF's capabilities can either be pre-configured or retrieved
dynamically through the I2NSF Registration Interface. If a new
function that is exposed to the consumer is added to an NSF, then
those capabilities should be notified to security controllers via the
I2NSF Registration Interface.
</jcs>
---
6.1. Network Connecting I2NSF Users and I2NSF Controller
[TBD: should we add the Remote Attestation to this section?]
I think you have added remote attestation and can remove this note.
<jcs>
Not yet - see earlier note. Since there are at least two different
approaches to remote attestation in the IETF, I think the WG still needs to
decide what to do here. I see no reason why we can't push this framework
draft forward and then have the remote attestation work (which still isn't
even a WG draft) add on and augment later. Hence, no action has yet been
taken.
</jcs>
---
6.2
The network connection between the Security Controller and NSFs can
rely either on:
Should you be making clear that in the open environment anything from a
few up to all of the NSFs can be hosted in external administrative
domains. Thus "closed" is very tightly defined, and "open" is anything
that is not completely closed.
<jcs>
Here is the rewrite:
o Open environments, where one or more NSFs can be hosted in one or
more external administrative domains that are reached via secure
external network connections. This requires more restrictive
security control to be placed over the I2NSF interface. The
information over the I2NSF interfaces shall be exchanged used
trusted channels as described in the previous section.
When running in an open environment, I2NSF needs to rely on
interfaces to properly verify peer identities (e.g., through an AAA
framework). The implementations of identity management functions,
as well as the AAA framework, are out of scope for I2NSF.
</jcs>
---
I can't help thinking that section 9.2 is way too detailed for this
document. I don't think there is anything wrong in what it says, but it
looks more like an information model for a specific capability exchange
than something that belongs in a general framework.
Can you see whether there is a different document that this belongs in?
<jcs>
This COULD be folded into the Capability Interface document, and then this
(the Framework) document could reference the Capability interface document.
However, that document is not yet accepted by the WG. So, would you like me
to:
1) leave as is, so the Framework document can proceed to last call, or
2) move this entire section to the Capability document, or
3) do something other than 1) or 2)?
</jcs>
--
regards,
John
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf
