I think that the problem answering your question is that as long as the
priority gets associated with the client, I2RS does not care where the
information is. So we are open to the various alternatives that have
been suggested in this regard.
Yours,
Joel
On 5/29/15 12:25 PM, Juergen Schoenwaelder wrote:
Thanks for all the details but I am missing an answer to my question.
Shall I repeat it once more?
/js
On Fri, May 29, 2015 at 12:03:18PM -0400, Susan Hares wrote:
Juergen:
Thank you for asking the question again. I appreciate your patience as I
attempt to answer your question carefully.
Short answer: I2RS strategy is re-use of other protocols rather than invent,
and this seemed a reasonable place to put it.
Context: Jeff's document is a proposal for the requirements for I2RS to the
NETCONF/NETMOD WG on ephemeral state. Feedback on the earlier descriptions
from the I2RS group had been "too vague" so Jeff's document is providing
detailed requirements. I2RS is not designing thing for NETCONF only making
known in detailed terms our requirements to aid the NETCONF group's response
on whether the I2RS design requirements can be met.
Longer Answer: His proposal arises out of section 4.2 in the I2RS
architecture document. This section states:
An approach to a similar access control problem is defined in the NetConf
Access Control Model (NACM) [RFC6536]; it allows arbitrary access to be
specified for a data node instance identifier while defining meaningful
manipulable defaults. The identity within NACM [RFC6536] can be specifying
as either a user name or a group user name (e.g. Root), and this name is
linked a scope policy that contained in a set of access control rules.
Similarly, it is expected the I2RS identity links to one role which has a
scope policy specified by a set of access control rules. This scope policy
is can be provided via Local Config, exposed as an I2RS Service for
manipulation by authorized clients, or via some other method (e.g. AAA
service).
You can see in this point that the client identity is being linked to the
scope policy controlling read or write. Section 7.8 points out that
priority "ensures predictability" in write conditions between two I2RS
Clients trying to write data in one agent, or between an I2RS client and the
local config. Jeff's requirements flow out of these two sections in the
architecture document.
What you can do: If you have an alternate suggestion for priority for Jeff's
document, please make a suggestion and indicate why you think it fits within
the I2RS architecture document (please list sections).
Sue
-----Original Message-----
From: i2rs [mailto:[email protected]] On Behalf Of Juergen Schoenwaelder
Sent: Friday, May 29, 2015 2:10 AM
To: Susan Hares
Cc: [email protected]; [email protected]; 'Andy Bierman'; 'Alia Atlas';
'Jeffrey Haas'; 'Joel M. Halpern'
Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00
On Thu, May 28, 2015 at 08:09:23PM -0400, Susan Hares wrote:
Andy:
Thank you for your question. Let me precise.
Jeff proposes that clients specify the priority mechanism is an attribute
that is stored in the NACM list on the agent (see Section 5.2 as described
in the draft-haas-i2rs-ephemeral-state-reqs-00 (quoted below). The
client-Agent identities are load in a mechanism which is out-of-band from
the I2RS protocol these values. Into the Client, the Agent's ID is loaded.
Into the Agent, the valid client's identity is loaded along with the
client's priority. AAA (Radius/Diameter) is an example of an out-of-band
mechanism to pass the information with. IMU (in my understanding), the NACM
on the agent is created based on this AAA loading. The i2rs secondary
identity is loaded via an edit-config mechanism in a config operation (see
section 5.1 of Jeff's document.). Please let me know if my understanding of
NACM creation based on AAA input is correct.
So I will ask again: If the priority is a property of the I2RS client (this
is how I understand the I2RS architecture document), why would it be
configured as part of a NACM rule as suggestd in section 5.2 of
draft-haas-i2rs-ephemeral-state-reqs-00? Jeff's design makes the priority a
property of the scope of a NACM group.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 < <http://www.jacobs-university.de/>
http://www.jacobs-university.de/>
_______________________________________________
i2rs mailing list
<mailto:[email protected]> [email protected]
<https://www.ietf.org/mailman/listinfo/i2rs>
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
