Re: [Gen-art] Gen-ART review of draft-ietf-i2rs-architecture-07

["Susan Hares" <[e-mail]>]

Russ:

It is my recollection at version -09 of the architecture document answered
these issues.  Please confirm this fact.  

 We are heading for a version-10 to resolve the security review given to us
in April. 

Sue 

-----Original Message-----
From: Russ Housley [mailto:[e-mail]] 
Sent: Monday, December 15, 2014 7:02 PM
To: [e-mail]
Cc: IETF Gen-ART
Subject: Gen-ART review of draft-ietf-i2rs-architecture-07

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

This review is in response to a request for early Gen-ART review.

Document: draft-ietf-i2rs-architecture-07
Reviewer: Russ Housley
Review Date: 2014-12-15
IETF LC End Date: unknown
IESG Telechat date: unknown

Summary: Almost Ready.

Major Concerns:

The different between an identity and a role is not clear to me.
Does each identity have exactly one role?  It would help for this to be
covered in section 2, and it may need to be expanded upon in section 4.

Section 4.2 talks about "groups or roles."  Groups needs to be defined, even
if it is just a list of identities.

Section 6.4 include a sentence that begins, "When a full implementation is
not mandatory, an I2RS Service should ..."  What determines if an
implementation must be "full"?  I think you can make this point without
having to delve into this question.  I suggest: "When a implementation does
offer all of the capabilities specified for an I2RS Service, the
implementation should include a capability model so that peers can determine
which parts of the service are supported."

Section 7.4 says: "Each I2RS Client will have a unique identity; it can also
have secondary identities to be used for troubleshooting."  The definition
in in section 2 offer a proxy-related reason for secondary identities.

Perhaps all of the discussion of identities can be placed in one section.
Right now it is split into sections 4 and 7.4.

Minor Concerns:

The document seems to use "confidentiality" and "privacy" to mean the same
thing.  They are different.  See RFC 2828 for definitions.  I think that
this document should use confidentiality throughout.

The last paragraph in section 1.2 says that the "detection and avoidance of
such interactions is outside the scope of the I2RS work," and that seems
fine, except for one point.  I assume that when there are two overlapping
write operations, one of them will get an error.  The previous paragraph
says that "errors should produce predictable behaviors."  So, the write
operation that fails needs to get an error that will allow the application
to take appropriate action.

In section 4.1, is the reference to "accounting" also a call for audit
trail?  If so, please be explicit.  The need for audit log comes up later in
section 6.2.

Section 7.1 begins: "As agreed by the I2RS working group, this I2RS
architecture assumes ..."  I am sure this was important at one time to say
this, but it seems odd in the final RFC.  I suggest: "The I2RS architecture
assumes ..."

Other Comments:

In the abstract, please spell out I2RS.

Several places starting in the Abstract: s/internet/Internet/

In section 1, it says: "... for registering for and requesting ..."; it
should say: "... for registering and for requesting ...".

In section 1, is says: "... in domain other than routing, ...".
s/domain/domains/

Typo: s/E.g./e.g./