Hi Sue,

Thanks for the update.

This version looks good to me, except one editorial comment.


> 4) This is just an edit, but in page.10,

>    "Requirements SEC-REQ-13 and SEC-REQ-14" should be

>    "Requirements SEC-REQ-14 and SEC-REQ-15".

>

> --- Thank you for the editorial comment

Now, text is “Requirements SEC-REQ-14 and SEC-REQ-16”, but it should be 
“Requirements SEC-REQ-14 and SEC-REQ-15”.
(Again, this is just an editorial comment.)

Thanks,
Tomonori Takeda

From: Susan Hares [mailto:sha...@ndzh.com]
Sent: Friday, May 20, 2016 11:06 PM
To: Tomonori Takeda(武田知典); rtg-...@ietf.org
Cc: rtg-...@ietf.org; 
draft-ietf-i2rs-protocol-security-requirements....@ietf.org; i2rs@ietf.org
Subject: RE: [i2rs] RTG-DIR QA review: 
draft-ietf-i2rs-protocol-security-requirements-04.txt


Takeda-san:



Thank you for your excellent review.  My responses to your comments are below.  
I’ve released a version-05 to address your comments.



Sue



-----Original Message-----

From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Tomonori Takeda

Sent: Thursday, May 19, 2016 12:39 PM

To: rtg-...@ietf.org<mailto:rtg-...@ietf.org>

Cc: 'rtg-...@ietf.org'; 
'draft-ietf-i2rs-protocol-security-requirements....@ietf.org'; 
i2rs@ietf.org<mailto:i2rs@ietf.org>

Subject: [i2rs] RTG-DIR QA review: 
draft-ietf-i2rs-protocol-security-requirements-04.txt



Hi,



I have been selected as the Routing Directorate QA reviewer for this draft.



Document: draft-ietf-i2rs-protocol-security-requirements-04.txt

Reviewer: Tomonori Takeda

Review Date: May 20, 2016

Intended Status: Standards Track



I am not following I2RS work closely, but in the spirit of QA review, this is 
OK in my understanding.

https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa



Here are my comments.



I think it is very important to have documents dedicated for security for new 
protocols such as I2RS protocols.

Overall, I think the document is well organized and clear what are security 
requirements for I2RS.



Some specific comments.



1) The document is intended to be Standards Track. I do not think it is common 
for requirement drafts to be Standards Track.



Sue: You are correct.  This is my error. I should have changed it this morning.



2) In Section 3.1, requirements are mentioned that are set in 
draft-ietf-i2rs-architecture-15.

   Some of these requirements are not directly mentioned in 
draft-ietf-i2rs-architecture-15,

   but rather implied.



   For example, draft-ietf-i2rs-architecture-15 mentions identifier for I2RS 
client,

   but does not mention identifier for I2RS agent (IMO).

   Please note that I think requirements mentioned in Section 3.1. makes sense 
and valid.

   I am just commenting on the way of writing.



Sue: You are correct that the mutual identification implies an identity for the 
agent.

Also in Section 2 of draft-ietf-i2rs-architecture-15 mentions:

   role or security role:   A security role specifies the scope,

      resources, priorities, etc. that a client or agent has.  If a

      identity has multiple roles in the security system, the identity

      is permitted to perform any operations any of those roles permit.

      Multiple identities may use the same security role.





3) I think there is dependency on requirements mentioned in this document.

   Specifically, if mutual authentication (Section 3.1), secure transport 
(Section 3.2),

   and role-based security (Section 3.3) are met, confidentiality (Section 3.3) 
and

   integrity (Section 3.4) can be achieved (expect SEC-REQ-16: traceability 
requirement).



   Perhaps, it depends on in which aspects security requirements should be 
written

   (in terms of mechanisms or in terms of features). Again, I am just commenting

   on the way of writing.



Sue: You make an excellent point:

I have added to the first part section 3.0 after the first paragraph:

New/

<t>There are dependencies in some of the requirements below.  For

confidentiality (section 3.3) and integrity (section 3.4) to be achieved, the

client-agent must have mutual authentication (section 3.1) and secure transport 
(section 3.2).   I2RS allows the use of an insecure transport for portions of 
data models that clearly indicate insecure transport.  If insecure transport is 
used, then confidentiality and integrity cannot be achieved.

</t>

4) This is just an edit, but in page.10,

   "Requirements SEC-REQ-13 and SEC-REQ-14" should be

   "Requirements SEC-REQ-14 and SEC-REQ-15".



--- Thank you for the editorial comment



Thanks,

Tomonori Takeda



_______________________________________________

i2rs mailing list

i2rs@ietf.org<mailto:i2rs@ietf.org>

https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Reply via email to