Subject: [i2rs] Consensus on I2RS data modeling language and protocol

From: Jeffrey Haas <[email-masked]>
Date: Wed, 21 May 2014 16:36:05 -0400

Working Group,

We committed to spend the weeks following last session in London for IETF 89
to look at our proposed data modeling languages and protocols in more
detail.  While that conversation on the mail list didn't yield an explicit
set of requirements (but thanks to Jamal for taking the first formal try at
it), significant discussion occurred comparing and contrasting the benefits
of FORCES and Netconf/Yang.  Part of that discussion helped clarify gaps in
both proposals that would need to be addressed for use by I2RS.

Each proposed mechanism had a few benefits in contrast to its counterpart,
but none of these were overwhelming in scope.

Our judgment of group consensus is that while both FORCES and Netconf/Yang
could serve I2RS that there is substantially more support for the
Netconf/Yang proposal.  Part of this consideration includes elements of
expediency such as existing open source tool chains and implementation
experience of I2RS-like mechanisms in other organizations and vendors.

Our near-term goals are to formally document the observed gaps in
Netconf/Restconf and Yang with regard to I2RS uses and take them to their
home working groups to be worked upon.  After discussing this detail with
our ADs, we can do so either in the form of documenting this upon the wiki
or in the form of a requirements Internet-Draft.  We welcome the chance to
choose our form of agility for this effort.

We will be forming a design team in the near future to work on the gap
analysis and try to bring the necessary work to closure in short order.

-- Ed and Jeff

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 22 May 2014 11:22:47 -0400

Jeff/Ed,

First of all I want to thank you both; i think you both tried hard to
provide the
opportunity given the constraints.
Second: I have no qualms with the WG moving forward - I understand progress MUST
be made. Andy, no hard feelings I hope.

Having said that, I would like to speak my mind. I am disappointed and
I would like to address
the two points described as cause for the decision.

On the "more support" for netconf/yang:
================================
My view is this boils down to popularity contest as opposed to
engineering requirements.
I wouldnt call this a process breakdown in I2RS - just that in general
the IETF allows the system
to be very hackable. It is like money in politics. While I empathize with folks
who have implemented netconf/yang and feel that is the path forward -
i would argue the
voting system is highly stacked. I know this is how the "game" has
been played over the
years - but for sometime now I feel like we need a new system for
voting. Things should not be
judged based on a simple +1 or a hum (I should have advertised
somewhere for people to
show up and "vote" for ForCES which would have been dishonest).
Voting would  have more more sense if there were clear requirements to
begin with from which
a clear checklist could be derived.
There were no specific requirements. I am sure there was intent but
assumptions were made
that netconf/yang is the way to go from the get-go.
There was not even effort to match against some requirements for
netconf/restconf/yang
when I put out a wiki update. There was not even an attempt to
dis/credit what i listed as requirements.
>From day one at the BOF, netconf and Yang were being presented as the answer.
I remember standing up at the BOF mike and asking why solutions were
being presented before
requirements - IIRC the answer was i could present my own favorite
protocol if i wanted to
and that process would be  followed. An engineering task requires
explicit call out of requirements
first.

Note: I am not arguing for ForCES here - but it aint
Netconf/restconf/Yang and neither do i think
those will require a minor surgery to work (as per my view of the
requirements). And from that
perspective I am unhappy - I wish we actually used a matrix of some
sort to prove me wrong
but the answer seems like "we'll fix it".

On "open source availability"
=======================
The notion that because there is some open source implementation it qualifies
some solution as legit is a red herring. 90% of IETF standards dont
pass that smell test.
There is no such requirement anywhere.
There is *absolutely* no open source implementation of I2RS using
netconf/restconf/yang.
I *doubt* there is one in any organization anywhere on the globe. So
this boils down to be
a marketing gimmick in an engineering organization. Which is where my
frustration comes in.
Perhaps the starting point at IETF is to go back to the old days of
implementing first as open
source variant, get cohesion around it and then standardizing.

 I hope my views arent too harsh (I just wanted to feed that elephant
in the room some peanuts).

cheers,
jamal

On Wed, May 21, 2014 at 4:36 PM, Jeffrey Haas <[email-masked]> wrote:
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs

---

From: John E Drake <[email-masked]>
Date: Thu, 22 May 2014 16:13:26 +0000

The other possibility is that FORCES is simply NQR.

Sent from my iPhone

> On May 22, 2014, at 11:24 AM, "Jamal Hadi Salim" <[email-masked]> wrote:
> 
> Jeff/Ed,
>

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Thu, 22 May 2014 16:19:26 +0000

Hi Jamal,

On 5/22/14, 8:22 AM, "Jamal Hadi Salim" <[email-masked]> wrote:

>The notion that because there is some open source implementation it
>qualifies some solution as legit is a red herring. 90% of IETF standards
>don¹t pass that smell test. There is no such requirement anywhere. There
>is *absolutely* no open source implementation of I2RS using
>netconf/restconf/yang. I *doubt* there is one in any organization
>anywhere on the globe. So this boils down to be a marketing gimmick in an
>engineering organization. Which is where my frustration comes in. Perhaps
>the starting point at IETF is to go back to the old days of implementing
>first as opensource variant, get cohesion around it and then
>standardizing.
>

Jeff¹s email states: "Part of this consideration includes elements of
expediency such as existing open source tool chains and implementation
experience of I2RS-like mechanisms in other organizations and vendors.²

I don¹t think that Jeff is saying that there exists an open source I2RS
implementation - he is saying that there is and *I2RS-like* mechanism in
open source (I think we all agree that NC/Y qualifies as *I2RS-like*). The
point is that these open source NC/Y implementations (there are multiple)
will provide developers and protocols designers with a platform (and a
starting point) that will allow them to extend the existing functionality
towards I2RS, and to quickly prototype new protocol functionality that
will be defined in the I2RS WG.

Thanks,
Jan

---

From: Andy Bierman <[email-masked]>
Date: Thu, 22 May 2014 09:43:54 -0700

Hi,

Sorry I ran out of time to work on I2RS requirements.
I tried to get some others to work on the wiki, but no takers.

I think if you ask an engineer whose job depends how well
they implement I2RS vs. an engineer who has no plans at all
to implement it, you might get different answers. The initial
and ongoing costs of the solution path really matter to vendors.

Even if tools are ignored, there is the problem of I2RS interaction
with the local config. That seems clearly more complicated
with separate solutions for each one.  YANG extensions
are also significant because they allow the language to be customized
instantly, without waiting for NETMOD or FORCES WG to be
rechartered to change their data modeling language.

Andy

On Thu, May 22, 2014 at 8:22 AM, Jamal Hadi Salim <[email-masked]> wrote:

> qualifies

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 22 May 2014 13:22:10 -0400

> The other possibility is that FORCES is simply NQR.

Use something better than an Iphone if you want to make a meaningful comment.
Nothing is QR for I2RS.
I am talking about process here not a specific protocol.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 22 May 2014 13:33:11 -0400

Hi Jan,

> Hi Jamal,
[..]

> implementation -

Agreed.
My argument is that the only time you can make a claim about virtues
of open source is if the implementation in fact exists.

>he is saying that there is and *I2RS-like* mechanism in
> open source (I think we all agree that NC/Y qualifies as *I2RS-like*).

It does qualify like you say as *I2RS-like* (as does ForCES arch)  -
unfortunately
since requirements are not clear, i am not sure how far we can stretch
the *like* part.

>The

I disagree. I dont think netconf/restconf/yang without acrobatics will resolve
the requirements; not saying it couldnt be made to with a lot of
effort and refactored.
I dont consider the presence of open source to be a reasonable input
unless the majority use the same code (reminds me of OF "interop" where
95% of the vendors have exactly the same implementation of OVS).

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 22 May 2014 13:43:47 -0400

> I tried to get some others to work on the wiki, but no takers.

Thanks for at least attempting that or even thinking about it.

> and ongoing costs of the solution path really matter to vendors.

I think this is a reasonable requirement.
This is why i said i empathized with whoever has already implemented.
But i would have felt more satisfied if a reasonable process was followed.
Maybe it will cost more to refactor netconf/yang and it is cheaper to create
something new.

> rechartered to change their data modeling language.

I never looked at config/data store to be a requirement for I2RS.
That could be a separate independent service.

cheers,
jamal

---

From: John E Drake <[email-masked]>
Date: Thu, 22 May 2014 18:04:11 +0000

Comments inline.

Yours Irrespectively,

John

> -----Original Message-----
> From: Jamal Hadi Salim [mailto:[email-masked]]
> Sent: Thursday, May 22, 2014 10:22 AM
> To: John E Drake
> Cc: Jeffrey Haas; [email-masked]
> Subject: Re: [i2rs] Consensus on I2RS data modeling language and protocol
> 

[JD]  Now that's a meaningful comment.  

> I am talking about process here not a specific protocol.

[JD]  Right, any process that does not select FORCES is by definition intrinsically flawed. 

> >> provide the opportunity given the constraints.
> >> Second: I have no qualms with the WG moving forward - I understand
> >> progress MUST be made. Andy, no hard feelings I hope.
> >>
> >> Having said that, I would like to speak my mind. I am disappointed
> >> and I would like to address the two points described as cause for the
> >> decision.
> >>
> >> I wouldnt call this a process breakdown in I2RS - just that in
> >> general the IETF allows the system to be very hackable. It is like
> >> money in politics. While I empathize with folks who have implemented
> >> netconf/yang and feel that is the path forward - i would argue the
> >> been played over the years - but for sometime now I feel like we need
> >> a new system for voting. Things should not be judged based on a
> >> simple +1 or a hum (I should have advertised somewhere for people to
> >> Voting would  have more more sense if there were clear requirements
> >> to begin with from which a clear checklist could be derived.
> >> assumptions were made that netconf/yang is the way to go from the
> >> get-go.
> >> netconf/restconf/yang when I put out a wiki update. There was not
> >> even an attempt to dis/credit what i listed as requirements.
> >> being presented before requirements - IIRC the answer was i could
> >> present my own favorite protocol if i wanted to and that process
> >> would be  followed. An engineering task requires explicit call out of
> >> requirements first.
> >>
> >> Netconf/restconf/Yang and neither do i think those will require a
> >> minor surgery to work (as per my view of the requirements). And from
> >> that perspective I am unhappy - I wish we actually used a matrix of
> >> some sort to prove me wrong but the answer seems like "we'll fix it".
> >>
> >> qualifies some solution as legit is a red herring. 90% of IETF
> >> standards dont pass that smell test.
> >> this boils down to be a marketing gimmick in an engineering
> >> organization. Which is where my frustration comes in.
> >> implementing first as open source variant, get cohesion around it and
> >> then standardizing.
> >>
> >>> We committed to spend the weeks following last session in London for
> >>> IETF 89 to look at our proposed data modeling languages and
> >>> protocols in more detail.  While that conversation on the mail list
> >>> didn't yield an explicit set of requirements (but thanks to Jamal
> >>> for taking the first formal try at it), significant discussion
> >>> occurred comparing and contrasting the benefits of FORCES and
> >>> Netconf/Yang.  Part of that discussion helped clarify gaps in both proposals
> that would need to be addressed for use by I2RS.
> >>>
> >>> Each proposed mechanism had a few benefits in contrast to its
> >>> counterpart, but none of these were overwhelming in scope.
> >>>
> >>> Our judgment of group consensus is that while both FORCES and
> >>> Netconf/Yang could serve I2RS that there is substantially more
> >>> support for the Netconf/Yang proposal.  Part of this consideration
> >>> includes elements of expediency such as existing open source tool
> >>> chains and implementation experience of I2RS-like mechanisms in other
> organizations and vendors.
> >>>
> >>> Netconf/Restconf and Yang with regard to I2RS uses and take them to
> >>> their home working groups to be worked upon.  After discussing this
> >>> detail with our ADs, we can do so either in the form of documenting
> >>> this upon the wiki or in the form of a requirements Internet-Draft.
> >>> We welcome the chance to choose our form of agility for this effort.
> >>>
> >>> We will be forming a design team in the near future to work on the
> >>> gap analysis and try to bring the necessary work to closure in short order.
> >>>
> >>> -- Ed and Jeff
> >>>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 22 May 2014 14:12:26 -0400

> [JD]  Right, any process that does not select FORCES is by definition intrinsically flawed.

Seriously?
Is your reading patience at the same terseness as your writing?

cheers,
jamal

---

From: Alia Atlas <[email-masked]>
Date: Thu, 22 May 2014 14:21:50 -0400

Jamal,

I really appreciate your participating in the discussion and trying to
pull the requirements out of the
architecture draft.  Here are a few of my observations of the full
discussion, though.

a) Technically, both NetConf/RestConf/YANG and ForCES could work with
some modifications.
b) Where there is overlap between I2RS and network configuration,
using YANG will allow shared model groups
that should decrease the work needed.
c) Active contributors from three different companies that are
planning or working on implementing I2RS said
that they'd prefer to start from NetConf/RestConf/YANG for I2RS.
d) There are several existing tool-chains to facilitate YANG model
development.  There are multiple
implementations of NetConf and planned of RestConf that can be used as
a starting point for I2RS.  Some of
these happen to be open source; those planning implementations have
ready access to a choice of tool-chains.

Unfortunately, sometimes rough consensus means that arguments for one
thing are heard, considered, and
still do not change the outcome.  It is critical to ensure that those
arguments are heard and fairly discussed.
There is a difference between X could do this and only X could do this.

Personally, I do not think that there are unwritten requirements for
I2RS; I think the basics are clearly articulated
in the architecture draft.  I do think that the gap analysis for YANG
and for RestConf/NetConf will be quite interesting
and needs to be done quickly to be timed with the work on-going in
NetMod and NetConf.

Regards,
Alia

---

From: John E Drake <[email-masked]>
Date: Thu, 22 May 2014 18:23:02 +0000

I have read every post to the I2RS mailing list since its inception.  As a general comment, sending the same email repeatedly does not make one's point more meaningful.

Yours Irrespectively,

John

> Sent: Thursday, May 22, 2014 11:12 AM
> To: John E Drake

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 22 May 2014 14:46:38 -0400

Alia,

You make reasonable arguement and i would agree there are requirements
scattered all over the place not totally missing. I didnt think that
my arguements
were "heard and considered" as you describe. My main of arguement was to use
a requirements matrix. I dont think that was considered (Andy says he heard).
I understand the desire to move fast - thats why i am not disagreeing on
moving forward.

On your points, I empathize with #c. I am pretty sure that is the main driver.
I didnt quiet get #b - is sharing a requirement or a good-to-have at all?

On #d:
My challenge is accepting something without seeing a gap analysis first.
To me this overrides the economics of #c.
So i am going to wait to see how the selections actually meet
the requirements and how much refactoring is going to be needed for the
protocols before i am convinced.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 22 May 2014 14:47:46 -0400

John,

As Ed says lets end this meaningless discussion.

yours respectfully,

jamal

---

From: Alia Atlas <[email-masked]>
Date: Thu, 22 May 2014 15:15:49 -0400

Hi Jamal,

> I understand the desire to move fast - thats why i am not disagreeing on

[Alia]  If your arguments hadn't been being listened to and
considered, the decision
would have happened many months ago.   At the end of the day, despite a year of
discussion and suggestion for ForCES, others who are planning on implementing
were not persuaded nor was there a technical reason that precluded a
different choice.

> I didnt quiet get #b - is sharing a requirement or a good-to-have at all?

[Alia] Given that either technology is possible, #b is a good to have
that will simplify
learning, implementation, work to be done on many models, and probably
operations.

> protocols before i am convinced.

[Alia] There was some discussion of gap analysis earlier to give
concepts to the WG.
I would like to see it written down cleanly with reasons in either the
wiki or a draft.
I don't think that waiting for completion on each step before any
progress is made on
the others is a good idea.  It is clear from the list discussion that
there are many
interested people waiting for the WG to get on to the solutions step.

Regards,
Alia

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 22 May 2014 16:19:39 -0400

Hi Alia,

> considered, the decision would have happened many months ago.

Sorry, I dont mean to be ungrateful  but I was referring to the last 2 months
or so process where i thought the real discussion was happening. Yes, you could
have dismissed ForCES right off the bat - and we have come a long way; thanks
for at least providing that opportunity.

> At the end of the day, despite a year of

Persuading people already vested in netconf/restconf/yang could only happen
if the starting point was requirements from which the proposed solutions are
cross-checked.
Note: I recall the first time i brought it up, both yourself and Ed
made it clear
you were in favor of netconf/yang. I think i would have had a better chance
convincing people otherwise against a requirements list.

> learning, implementation, work to be done on many models, and probably

Ok.

> interested people waiting for the WG to get on to the solutions step.

Then lets please move on. Like i said i will be curiously observing.

cheers,
jamal

---

From: Alia Atlas <[email-masked]>
Date: Thu, 22 May 2014 16:29:53 -0400

Hi Jamal,

I do agree on moving on.  But, just to clarify, I didn't start I2RS
thinking that NetConf/YANG were the right answer - though RestConf comes
closer.   I also know that ForCES has a lot of really
good technology.  I do and did know of the business considerations that
were expressed
during the discussion.

I was trying to not have a strong opinion and be sure that you were given
time to articulate
why ForCES was not only possible but might be better enough technically to
be able to handle
the business considerations.   I apologize if that came across as having
made up my mind; I was trying to listen to the others in the WG as well and
those opinions were fairly uniform.

Regards,
Alia

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 22 May 2014 16:33:34 -0400

Hi Alia,

I appreciate the opportunity and want to thank you, Ed and Jeff.
It is time to move on.

cheers,
jamal

On Thu, May 22, 2014 at 4:29 PM, Alia Atlas <[email-masked]> wrote:
> Hi Jamal,
>
> I do agree on moving on.  But, just to clarify, I didn't start I2RS thinking
> that NetConf/YANG were the right answer - though RestConf comes closer.   I
> also know that ForCES has a lot of really
> good technology.  I do and did know of the business considerations that were
> expressed
> during the discussion.
>