Interface to the Routing System (I2RS) Security-Related Requirements
draft-ietf-i2rs-protocol-security-requirements-17

Thanks for addressing my DISCUSS and COMMENTs.

I have the same concerns as others around the secure transport, but I'm not putting in a DISCUSS because the concerns are already well represented.  Just one additional comment on the topic:

I think there is a contradiction between SEC-REQ-09 ("The I2RS protocol MUST be able to transfer data over a secure transport and optionally MAY be able to transfer data over a non-secure transport") and this text from Section 3. (Security-Related Requirements): "…MUST be able to exchange data over a secure transport, but some functions may operate on a non-secure transport."  The latter text talks bout "some functions" using a non-secure transport, while SEC-REQ-09 implies that everything may use it.


Other comments from Section 3.1. (Mutual authentication of an I2RS client and an I2RS Agent) 

-- The text says that the "I2RS architecture [I-D.ietf-i2rs-architecture] sets the following requirements".  I'm not sure what you mean my "sets", as there are no requirements (labeled as such) in the architecture document.  If there are, then this section doesn't seem to be needed (as others have mentioned).  Maybe "these requirements are derived from the architecture", or something similar may be more appropriate.

-- What is a "valid identifier"?  A couple of requirements where a "valid identifier" "MUST" be confirmed are listed, but no indication as to what that may be in this document or the architecture one.   The definition of identifier doesn't help…

-- SEC-REQ-05 and SEC-REQ-06 sound the same to me.  What is the difference?  BTW, if there is a difference, instead of "IETF" I think that "standardized" may be better.

Version 8 resolved my discuss point for section 3.4. Thanks!

I don't think it resolved my discuss point for 3.2. I'm clearing anyway, because I think my point has been made. I would prefer the language to say that anything not explicitly marked as non-confidential in the relevant data model MUST be sent over a protected transport. But I will leave it to the authors to do the right thing.

I will leave my non-discuss comments below for reference. I think version 8 resolves at least some of them. Any remaining are up to you; none of them are show stoppers.

-2.1: I am on the fence about other's comments about copying definitions here--but if you do copy them here, it seems strange to not mention "client" or "agent".

I agree with Alissa about equating privacy and confidentiality.

-3.1,: 
I’m confused by the first paragraph. I don’t find strings of the form of SEC-REQ-XX in 7921. I think _this_ doc sets these requirements, right?

It’s not clear to me how 5 and 6 differ. Is it just a matter of the additional “before establishing a connection” part in 6?

-3.4: Isn't 15 simply a restatement of the third item under 14?

3.5: The  MAYs in 19 and 20 seem like statements of fact. (That is, do they simply recognize reality, or to they  grant permission?)

Thank you very much for your re-write of this draft.  It reads much better and as such, should be a more helpful document for the WG.  The requirements are more clearly listed and the new section breaks with explanations are also a positive improvement.  

I do appreciate the new language in section 3.2.  I still don't agree with the model, but I wouldn't block on the scope and method with the way this is currently written.  I favor marking when data is confidential, but you've been careful in how you have scoped this requirement.

A few comments:

1) I don't think copy&paste from RFC4949 is necessary. I would recommend to remove this part and just name the definitions that are needed.

2) The following sentence seems to indicate that the refernce to RFC4949 should be normative.
"The transfer of data via the I2RS protocol has the property of data integrity described in [RFC4949]."
As I don't think this is needed, I would recommend to rather spell out the properties here in this sentence. Also, to be honstest I not sure what this sentence tells me at all. So maybe stating clearing what you mean (instead of just having the reference) would help anyway.

3) To me it's not really clear why there are several requirments docs (that also are connected and refer each other; see e.g. section 3.6 and SEC-REQ-16). The actually context of this doc is only 4 pages (3.1-3.6). Couldn't those docs be combined to one requiremnet doc?

4) Section 3.1 says:
"The I2RS architecture [I-D.ietf-i2rs-architecture] sets the following requirements:"
Why is this needed is RFC7921 already sets these requirements?

Thanks for adding REQ-16. Comments below are unchanged
from my previous discuss ballot.

- The topic of marking things as allowing insecure read
access has been discussed a lot so I won't get into it
again.

- section 4: "Data passed over the insecure transport
channel MUST NOT contain any data which identifies a person
or any "write" transactions." I don't get what identifying a
write transaction might mean?

- 4.1: "AAA protocols MAY be used to distribute these
identifiers, but other mechanism can be used." If I'm doing
TLS with mutual-auth, then I need a private key and
certificate. I don't think AAA protocols can transport those
(and they probably ought not) so I'm not sure what's meant
here.

- 4.2: What do "valid identity" and "valid identifier" mean?
If the same then use the same terms. But I think you need to
define "validity" or else say that work needs to be done
later. 

- 4.3: I think you're saying here that the i2rs client is
trusted to simply assert the secondary identifier. If so,
then saying that would be good. If not, then I don't know
what you mean.

- 4.4: I still don't see why it'd not be better to use a
different protocol for the non-secure stuff and avoid all
the potential discussion and pitfalls of trying to do all
this in one protocol.

- 4.4: "It is mandatory to use (MTU) on any I2RS client's
Write transaction or the configuration of an Event Scope
transaction." Which "it" do you mean?

- 4.4: The BCP107 stuff is still not useful.

- 4.5: "detect when the data integrity is questionable" -
I've no idea what that means. Nor what it could mean.  Can
you explain?