[netmod] WG documents for I2RS Protocol - WG calls 5/27 to 6/9

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

The following I2RS Protocol Requirements will be passed to NETCONF later
this week 

 

https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs
(adopted by I2RS WG) 

   (will be sent as draft-ietf-i2rs-ephemeral-state-reqs) 

http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ ( WG
LC completed, consensus)  

http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/  WG LC
complete, consensus  

 

Come and discuss these at the I2RS Interim before the documents are passed
to NETCONF. 

 

Below are 10 requirements that NETCONF SHOULD meet.  There has been debate
on the I2RS list whether NETCONF can provide requirement 2.  If you have an
opinion on these requirements,  the interim tomorrow is your chance to
provide feedback before the requirements go to NETCONF.  

 

Sue Hares

=============================================

 

 1.   The I2RS protocol SHOULD support highly reliable notifications (but
not perfectly reliable notifications) from an I2RS agent to an  I2RS client.

 2.   The I2RS protocol SHOULD support a high bandwidth, asynchronous
interface, with real-time guarantees on getting data from an I2RS  agent by
an I2RS client. 

3.  The I2RS protocol will operate on data models which may be protocol
independent or protocol dependent.

 

4. I2RS Agent needs to record the client identity when a node is created or
modified. The I2RS Agent needs to be able to read the client identity of a
node and use the client identity's associated priority to resolve conflicts.
The secondary identity is useful for traceability and may also be recorded.

 5.   Client identity will have only one priority for the client identity. A
collision on writes is considered an error, but priority is utilized to
compare requests from two different clients in order to modify an existing
node entry.  Only an entry from a client which is higher priority can modify
an existing entry (First entry wins). Priority only has meaning at the time
of use.  

6.   The Agent identity and the Client identity should be passed outside of
the I2RS protocol in a authentication and authorization  protocol (AAA).
Client priority may be passed in the AAA protocol.  The values of identities
are originally set by operators, and not  standardized.  

 7.  An I2RS Client and I2RS Agent mutually authenticate each other based on
pre-established authenticated identities.  

 8. Secondary identity data is read-only meta-data that is recorded by the
I2RS agent associated with a data model's node is written, updated or
deleted. Just like the primary identity, the secondary identity is only
recorded when the data node is written or updated or deleted.  

 9.   I2RS agent can have a lower priority I2RS client attempting to modify
a higher priority client's entry in a data model.  The filtering out of
lower priority clients attempting to write or modify a higher priority
client's entry in a data model SHOULD be effectively handled and not put an
undue strain on the I2RS agent.  

Note:  Jeff's suggests that priority is kept at the NACM at the client level
(rather than the path level or the group level) will allow these lower
priority clients to be filtered out using an extended NACM approach. This is
only a suggestion of a method to provide the requirement 9.  

10.  The I2RS protocol MUST support the use of a secure transport. However,
certain functions such as notifications MAY use a non-secure transport.
Each model or service (notification, logging) must define within the model
or service the valid uses of a non-secure transport.