Re: [i2rs] Benoit Claise's No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT)

["Joel M. Halpern" <[e-mail]>]

That improves the abstract, and works for me.
Thank you,
Joel

On 4/21/16 10:02 PM, Susan Hares wrote:
> Joel:
>
> I will need to resolve this before I can provide a final for the RFC
> editor.   Here's the way I understand these issues:
>
> 1) draft-ietf-i2rs-architecture-13.txt - is a high-level architecture
> with building blocks.
>
> 2) It provides only general ideas on we are using "X, Y, and Z" in ways
> "A, B, and C" to
>
> solve the "I2RS problem".
>
> 3) detailed requirements on what the I2RS protocol and interface should
> be are contained in
>
>     the i2rs requirements set
>
> ·Pub/sub requirements - draft-ietf-i2rs-pub-sub-requirements-06  (at
> IESG publication)
>
> ·Traceability requirements - draft-ietf-i2rs-traceability-08 (at IESG
> publication)
>
> ·Protocol Security requirements -
> draft-ietf-i2rs-protocol-security-requirements-03
>
> ·Ephemeral State requirements - draft-ietf-i2rs-ephemeral-state-05
>
> ·Data Flow Requirements  - draft-hares-i2rs-dataflow-req-03
>
> ·I2RS security requirements for environment -
> draft-ietf-i2rs-security-environment-reqs-01
>
> The protocol strawman is the proposal for using "X, Y, and Z" in ways
> "A,B, and C" in order
>
> to solve the I2RS problem.
>
> 4) The architecture document and use cases were useful in creating the
> key informational models:
>
> 1)I2RS RIB Information model
>
> 2)I2RS FB-RIB informational model (under WG Adoption)
>
> 3)I2RS generic network model (draft-ietf-i2rs-yang-network-topo-02
> <https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/>) –
> which has formed the basis for most of the I2RS, TEAS and CCAMP ideas on
> models.
>
> Therefore, I think we followed the charter.
>
> What we really need to revise is the abstract.  To bring the
> expectations for the architecture closer to task 1.
>
> *How about changing the abstract to: *
>
> This document describes the IETF architecture for a standard,
>
> programmatic interface for state transfer in and out of the Internet
>
> routing system.  It describes the high-level architecture, the building
>
> blocks of this high-level architecture, and their interfaces with
>
> particular focus on those to be standardized
>
> as part of the Interface to Routing System (I2RS).
>
> Sue
>
> -----Original Message-----
> From: Joel M. Halpern [mailto:[e-mail]]
> Sent: Thursday, March 24, 2016 9:07 AM
> To: Benoit Claise; Susan Hares; 'The IESG'
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: [i2rs] Benoit Claise's No Objection on
> draft-ietf-i2rs-architecture-13: (with COMMENT)
>
> Now I understand your confusion.
>
> Putting aside the abstract, I thought we were focused om task 1 (from
> the charter) in writing.  I think we probably crept into task 2,
> resulting in a document which is confusing about its scope.
>
> Not sure how to resolve this.
>
> Yours,
>
> Joel
>
> On 3/24/16 9:03 AM, Benoit Claise wrote:
>
>  > Joel,
>
>  >
>
>  > Thanks, that's helpful.
>
>  >
>
>  > 1. Let's look at the charter
>
>  >
>
>  >     The I2RS working group works to develop a high-level architecture
> that
>
>  >     describes the basic building-blocks necessary to enable the specific
>
>  >     use
>
>  >     cases, and that will lead to an understanding of the abstract
>
>  >     informational models and requirements for encodings and protocols
>
>  >     for the I2RS interfaces.
>
>  >
>
>  > 2. Let's review the draft abstract
>
>  >
>
>  >         This document describes the IETF architecture for a standard,
>
>  >         programmatic interface for state transfer in and out of the
> Internet
>
>  >         routing system.  It describes the basic architecture, the
> components,
>
>  >         and their interfaces with particular focus on those to be
>
>  >         standardized as part of the Interface to Routing System (I2RS).
>
>  >
>
>  > Reading 1., I understand your point of view.
>
>  > However, I read 2. as this draft is about "we are using pieces X, Y,
>
>  > and Z, in ways A, B, and C, to solve the I2RS problem."
>
>  > I reviewed the draft content looking for 1., and could not find it.
>
>  >
>
>  > Do you understand my confusion?
>
>  >
>
>  > Regards, Benoit
>
>  >> 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
>
>  >>> [e-mail] <mailto:[e-mail]>
>
>  >>> https://www.ietf.org/mailman/listinfo/i2rs
>
>  >>>
>
>  >> .
>
>  >>
>
>  >
>