Sue,
>Two of the existing protocols which the
> which may be re-used are NETCONF [RFC6241] and RESTCONF
> [I-D.ietf-netconf-restconf].
editorial "may be reused". / I will check with RFC editor (some
people say
reused /re-used).
What does it mean? I was hoping that an architecture documents
would at
least tell me which protocols are used.
On my side this architecture is flexible (NETCONF or RESTCONF),
on the
other side unclear (YANG 1.0 or
YANG1.1), and in some cases, a complete specification (for example the
notification)
Sue: NETCONF and RESTCONF will be supported as part of the I2RS
protocols.
The architecture does out rule out other data transfer protocols,
but says
the WG will design I2RS as a higher level protocol that combines other
protocols (NETCONF/RESTCONF + x).
This is what I could not understand with the draft sentence: "Two of the
existing protocols which the which may _be re-used_ are NETCONF
[RFC6241] and RESTCONF > [I-D.ietf-netconf-restconf]."
Sure many things could be reused. I'm expecting from an architecture
document to explain which pieces are used and how they are used.
The I2RS requirements documents and
protocol strawman will state is if any other protocols will be used
for a
particular version of I2RS with a particular scope for data modules.
Probably, my issue stems from the fact that I2RS produces an
architecture before fixing requirements.
I am sorry if this is not what you excepted, but it was my direction
from my
AD on how to approach this work.
At this time, we are closing in on the last of the requirements
documents -
the requirements for other data flows.
draft-hares-i2rs-dataflow-req-02 that gives the potential scope of data
flows, but IMO the first version of the I2RS is likely to stay with
just
NETCONF/RESTCONF with ephemeral state, push pub/sub support, syslog
module
library, and some yang changes.
To handle I2RS Agent failure, the I2RS Agent must use two
different
notifications.
NOTIFICATION_I2RS_AGENT_STARTING: This notification signals to the
I2RS Client(s) that the associated I2RS Agent has
started. It
includes an agent-boot-count that indicates how many
times the
I2RS Agent has restarted since the associated routing
element
restarted. The agent-boot-count allows an I2RS Client to
determine if the I2RS Agent has restarted. (Note: This
notification will be only transmitted to I2RS clients
which are
know in some way after a reboot.)
No comment on "the I2RS Agent _must _use two different notifications"?
This one is clear spec.
- editorial:
Optionally, a routing element may permit a priority to be to be....
For the case when the I2RS ephemeral state always wins for a data
model, if there is an I2RS ephemeral state value it is installed
instead of the local configuration state.
Again, I read that sentence multiple times, and could not
understand it
Sue: Reasonable editorial comment. This was added to address another
comment,
But it looks like we broken something. Text change below.
Old/ Optionally, a routing element may permit a priority to be to be
configured on the device for the Local Configuration mechanism
interaction with the I2RS model. The policy mechanism would
compare
the I2RS client's priority with that priority assigned to the Local
Configuration in order to determine whether Local Configuration or
I2RS wins.
For the case when the I2RS ephemeral state always wins for a data
model, if there is an I2RS ephemeral state value it is installed
instead of the local configuration state. The local configuration
information is stored so that if/when I2RS client removes I2RS
ephemeral state the local configuration state can be restored.
/
New:
Optionally, a routing element may permit a priority to be to be
to be to be
configured on the device for the Local Configuration mechanism
interaction with the I2RS model. The policy mechanism would
compare
the I2RS client's priority with that priority assigned to the Local
Configuration in order to determine whether Local Configuration or
I2RS wins.
For the case when the configured priority of the I2RS ephemeral
Is higher than the Local Configuration's policy, the
The I2RS ephemeral state value it is installed
remove "it"
instead of the local configuration state. The local configuration
information is stored so that if/when I2RS client removes I2RS
ephemeral state the local configuration state can be restored.
/
figure 2. "The initial services included in the I2RS architecture
are as
follows."
Are these really the initial services for I2RS. I2RS is really dealing
with all these: interfaces, policy, QoS, ...
Maybe I should review the I2RS charter?
Sue: Our charter is wide, but only ephemeral layer deep. Due to the
excellent people in the NETCONF/NETMOD, routing area (rtgwg) and
TEAS - we
are focusing on allowing ephemeral to be added to any data model.
I2RS WG
is focused first on the I2RS protocol and protocol independent modules.
After this, I2RS purpose is to simply support other WGs in creating
data
modules with ephemeral state.
The I2RS protocol may need to use several underlying transports
(TCP,
SCTP
(stream control transport protocol), DCCP (Datagram Congestion
Control Protocol)), with suitable authentication and integrity
protection mechanisms
Do you really want to have define transports?
Sue: We indicate that I2RS will use these protocols. Each protocol we
mention has to be then validated with requirements (see protocol
security
requirement and security environment requirements).
So I2RS will publish a second architecture doc when the requirements are
validated and the protocols (transport, config, notifications) are
finally selected?
Regards, Benoit
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
