Subject: Re: [I2nsf] comments about I2NSF framework draft://答复: Progress with draft-ietf-i2nsf-framework-05

From: John Strassner <[email-masked]>
Date: Sun, 2 Jul 2017 12:59:53 -0700

Here is my proposed resolution to these points:

1. nits: P18 " Table 1: Subject Capability Index " should change to " Table
1: Packet Content Matching Capability Index ",  P19, " Table 2: Object
Capability Index " should change to " Table 2: context matching Capability
Index ";
[Rakesh]  Makes sense to me. We should take this.
<jcs>
Done. Also fixed captions of Tables 3 and 4. :-)
</jcs>

2. Section 11 of Security Considerations: this section is a little bit
simple without considering the possible threats like: unauthenticated
connections between users and controller, and between controller and NSFs,
DoS attacks from malicious users or NSFs, etc;
[Rakesh] In my opinion, this is just a framework document. Any specific of
security considerations (such as you pointed out) should go into each
individual drafts covering client, regigttration and NSF interfaces.  If
you think it would help, we could add something like this to the section 11.
<jcs>
I agree with Frank. I think we should add text before we go to last call.
Let's discuss in Prague. No action for now (but am still going through
comments).
</jcs>

3. question: should section 7.3 move to the I2NSF gap analysis draft?
[Rakesh] I don’t have very strong opinion one way or other but it gives
some context to other sections. It is good to have.
<jcs>
I think it should stay here. No action taken.
</jcs>

4. I think remote attestation function should be described as a part into
the whole I2NSF framework;
[Rakesh] I agree with you.
<jcs>
Disagree. There is major work to be done in remote attestation. We have at
least two different approaches that will (hopefully) be merged in the near
future. This would delay the last call of this document by...pick a date..6
months minimum imho.

I don't see why remote attestation cannot reference and augment this draft.
No action taken.
</jcs>

5. Section 3.2, by my understanding, notification is just part of the
monitor functions, such as: syslog, netconf. Is it necessary to divide them
into two interfaces?
[Rakesh] In larger scheme of things, everything can be combined into one
but it is good to show differentiation since each set serve different
purpose and may require different operational characterstics.
<jcs>
I do not read the text this way. First, it describes THREE, not two,
interfaces. Second, none of the three categories are mentioned again in the
entire document. I read this as explanatory text to help the reader develop
a better conceptual understanding of the document.
No action taken.
</jcs>

regards,
John

On Thu, May 25, 2017 at 1:15 PM, Rakesh Kumar <[email-masked]> wrote:

> Hi Frank,
>
> Thanks for your review and support. We will make changes to the draft
> based on your comments and any other comments we receive in next few days.
> Please see my take on your comments below.
>
> Thanks
> Rakesh
>
> On 5/21/17, 8:32 PM, "I2nsf on behalf of Xialiang (Frank)" <
> [email-masked] on behalf of [email-masked]> wrote:
>
> Hi Adrian, I2NSFers,
> I reviewed the latest draft again and thinks it's in a very good shape
> now. So, it can be a foundation for all the other drafts.
>
> Of course, I also have some comments about it as below:
> 1. nits: P18 " Table 1: Subject Capability Index " should change to "
> Table 1: Packet Content Matching Capability Index ",  P19, " Table 2:
> Object Capability Index " should change to " Table 2: context matching
> Capability Index ";
> [Rakesh]  Makes sense to me. We should take this.
>
> 2. Section 11 of Security Considerations: this section is a little bit
> simple without considering the possible threats like: unauthenticated
> connections between users and controller, and between controller and NSFs,
> DoS attacks from malicious users or NSFs, etc;
> [Rakesh] In my opinion, this is just a framework document. Any specific of
> security considerations (such as you pointed out) should go into each
> individual drafts covering client, regigttration and NSF interfaces.  If
> you think it would help, we could add something like this to the section 11.
>
> 3. question: should section 7.3 move to the I2NSF gap analysis draft?
> [Rakesh] I don’t have very strong opinion one way or other but it gives
> some context to other sections. It is good to have.
>
> 4. I think remote attestation function should be described as a part into
> the whole I2NSF framework;
> [Rakesh] I agree with you.
>
> 5. Section 3.2, by my understanding, notification is just part of the
> monitor functions, such as: syslog, netconf. Is it necessary to divide them
> into two interfaces?
> [Rakesh] In larger scheme of things, everything can be combined into one
> but it is good to show differentiation since each set serve different
> purpose and may require different operational characterstics.
>
>
> B.R.
> Frank
>
> -----邮件原件-----
> 发件人: I2nsf [mailto:[email-masked]] 代表 Adrian Farrel
> 发送时间: 2017年5月19日 1:49
> 收件人: [email-masked]
> 主题: [I2nsf] Progress with draft-ietf-i2nsf-framework-05
>
> Hi WG,
>
> I am about to do a document shepherd review prior to starting a WG last
> call. In conversation with Linda just now I think I spotted a few areas
> where I am going to make chunky suggestions for additional text, but
> overall the document looks sound.
>
> If you care deeply about this work and haven't looked at the framework for
> a while, now would be a good time. Don't wait for WG last call.
>
> Thanks,
> Adrian
>
>
>
> _______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf
> _______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf
>
>
> _______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf
>

-- 
regards,
John