Subject: [i2rs] Jari Arkko's No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT)

From: "Jari Arkko" <[email-masked]>
Date: Thu, 17 Mar 2016 02:01:22 -0700

Jari Arkko has entered the following ballot position for
draft-ietf-i2rs-architecture-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Russ Housley's Gen-ART review raised the following question and editorial
comments. I believe it would be useful for the authors to think about the
question at least, but I have not seen a response yet:

---

Minor Concerns:

Section 4.2 talks about authorization.  I would expect policy to
dictate that some writes come from a specific source, but it is
unclear to me whether I2RS can require that a particular write
request arrive on a particular channel.  Is this desirable?  If so,
please expand the discussion of authorization to cover this point.

Nits:

Sometimes you say "i2rs architecture", but it should say "I2RS
architecture" to be consistent throughout the document.

Sometimes you say "I2RS Agent" and other times you say "I2RS agent".
Please pick one and use it consistently.

Sometimes you say "I2RS Client" and other times you say "I2RS client".
Please pick one and use it consistently.

Section 3: s/ may may vary based / may vary based /

Section 6.3: s/ the yang data model / the YANG data model /

Section 6.4.2: some bullets have periods, but others do not.

Section 7.1: s/ Yang / YANG / (more than one place)

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 22 Mar 2016 22:50:23 -0400

Jari,

> please expand the discussion of authorization to cover this point.

This may be beneficial.  However, since a goal of i2rs is to utilize as much
as possible in existing transports such as netconf/restconf, a better
question should be whether the mechanism should be introduced there?

In my opinion, this may be a useful feature but is not a blocking item.  As
noted in my response to Stephen's COMMENT, binding to role already exists in
a form courtesy of mechanisms such as NACM or similar local privilege
configuration.

-- Jeff