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

[Benoit Claise <[e-mail]>]

On 4/22/2016 4:02 AM, 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).
>
That's an improvement.
At least, it removes the discrepancy between the charter description and 
the previous draft abstract.

Regards, Benoit
>
> 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
>
> >>>
>
> >> .
>
> >>
>
> >
>