Enhancing the protocol strawman to provide that seems sensible to me.
Yours,
Joel
On 4/21/16 9:34 PM, Susan Hares wrote:
Joel:
Follow-up on this stream after IETF. In many ways, the protocol strawman
is the document which proposes using pieces X, Y, and Z in ways A, B, and C
to solve the I2RS problem. Perhaps, the protocol strawman should have a
section that summarizes the requirements and solutions.
Sue
-----Original Message-----
From: Joel M. Halpern [mailto:[email protected]]
Sent: Thursday, March 24, 2016 8:17 AM
To: Benoit Claise; Susan Hares; 'The IESG'
Cc: [email protected]; [email protected]; [email protected];
[email protected]; [email protected]
Subject: Re: [i2rs] Benoit Claise's No Objection on
draft-ietf-i2rs-architecture-13: (with COMMENT)
Benoit, you seem to be looking for a level of specificity in the
architecture that the working group never intended. The charter calls for a
high level architecture.
I believe your comment calls out an interesting gap in the charter, as there
is no document called out which actually says "we are using pieces X, Y, and
Z, in ways A, B, and C, to solve the I2RS problem."
We could have tried to use the architecture document for that, but the
intention was to use the architecture document to guide the selection of
protocol and mechanisms.
Yours,
Joel
On 3/24/16 6:53 AM, Benoit Claise wrote:
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
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
