Hi,
I have not have enough time to work on this draft yet, but here are my
initial concerns.
I won't comment on the details yet.
1) datastores
There is an opstate design team working on everything except ephemeral.
We need 1 RPC defining the datastore framework and each specific datastore
(known
Ben:
This is wise idea. I will suggest some text to Eric and you in the morning.
Sue
Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone Original
message From: Ben Campbell Date: 5/6/2016 2:38 PM
(GMT-06:00) To: Susan Hares Cc: Eric Voit ,
The IESG , i2rs@ietf.org
On 06/05/16 21:28, Joe Clarke wrote:
> On 5/4/16 18:11, Stephen Farrell wrote:
>> Hi Joe,
>>
>> Those are all fine changes. Couple of tweaks suggested below.
>
> Thank you for your suggestions, Stephen. Please find a new proposed set
> of text changes at
> http://www.marcuscom.com/draft-ietf-i2
On 5/4/16 18:11, Stephen Farrell wrote:
Hi Joe,
Those are all fine changes. Couple of tweaks suggested below.
Thank you for your suggestions, Stephen. Please find a new proposed set
of text changes at
http://www.marcuscom.com/draft-ietf-i2rs-traceability.txt-from-09-10.diff.html
. We beli
Hi Susan,
To be clear, I do not object to the wider context per se. My concern is
that the security and privacy requirements are left as implicit, based
on the more narrow i2rs/netconf context. I only mentioned the potential
of restricting the contextas one possible way forward; I am certainly
The text at the end of this section talks about the I2RS agent
re-evaluating a set of writes done by a client when the assigned
priority of the client changes. Dealing with such changes makes sense.
I am confused by the specific proposal. What is being reevaluated, and
why are notifications
Section 3.1.3 requirements 6 and 7 introduce the marking that the
protocol used by YANG / NetConf is i2RS specific. From one important
angle, this makes good sense. It avoids confusing the I2RS
communication with other NetConf or RestConf usage.
On the other hand, it seems to create a diffic
Reading the latest revision, in section 3.1.1, the text in bullet 5 says
that the data model indicates which portions are ephemeral. That makes
sense to me.
Then bullet 6 says that the management protocol needs to signal (in its
yang library) which parts are ephemeral.
Why the second requir
I disagree with many things in the document. For example, a data model
must not detail things like
o encoding [XML | JSON]
o protocol [RESTCONF | NETCONF]
o protocol-transport [ssh, tls, tcp]
o transport-ports [ports]
because of layering and modularity concerns and of deploymen
I have a hard time with this document. Section 3 is labelled
requirements but it actually details solution and I disagree with a
significant number of the solution elements. To name an example:
Indicating in a data model with which protocols it should be used and
which secure transports underneath
10 matches
Mail list logo
