Subject: [i2rs] IETF 91 meeting requested - call for agenda; status reports?

From: Jeffrey Haas <[email-masked]>
Date: Thu, 25 Sep 2014 14:00:55 -0400

Your chairs have been a bit over-busy recently with travel to unicast people
doing various bits of chartered work.  This means we've been behind on some
of our goals in terms of getting regular design sessions running.  I know
that at least a couple calls have happened that I've missed that Sue Hares
has done, so some progress is being made.

We've requested a 1 hour time slot for IETF 91 in Honolulu to give us a
chance to talk.  This is a call for agenda slots.

This is also a call for status reports.

We've had some productive discussion about requests to netmod/netconf,
albeit ones that haven't converged yet.

What have you been up to?

-- Jeff & Ed

---

From: Dean Bogdanovic <[email-masked]>
Date: Thu, 25 Sep 2014 18:43:48 +0000

Jeff,

To kickstart the discussions

looking at what is needed in NETMOD and NETCONF for I2RS

datastore for I2RS (use cases for ephemeral data store)

working on ACL YANG model - with ACL model available and draft-ietf-netmod-routing-cfg-15 being fixed, PBR info model (draft-kini-i2rs-pbr-info-model-00) can be extended into data model. I'll try to submit the draft by the deadline (it is dependent on new draft-ietf-netmod-routing-cfg, probably draft-ietf-netmod-routing-cfg-16, being published)

Dean

On Sep 25, 2014, at 2:00 PM, Jeffrey Haas <[email-masked]> wrote:

> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 26 Sep 2014 23:36:05 -0400

Jeff: 

Please add to the agenda the following drafts: I2RS yang Data and
Information models for ISIS, OSPF, Basic Network Policy (BNP), PBR and BGP.
PBR and BGP will be uploaded next week after some internal review.   

The PBR model is the information model that is a collaboration between the
PBR (draft-kini-i2rs-pbr-info-model-00) and the
(draft-hares-i2rs-policy-info-model).   We hoped to have the agreement on
the text early next week (just 1 technical discussion).   The author team
has had meetings in August and September.   

Please add the use case to the agenda. 

One question - should I be submitting these I2RS configuration IM/DM as
netmod models? If so, I will do this as well. 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Dean Bogdanovic
Sent: Thursday, September 25, 2014 2:44 PM
To: Jeffrey Haas
Cc: [email-masked]
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status
reports?

Jeff,

working on ACL YANG model - with ACL model available and
draft-ietf-netmod-routing-cfg-15 being fixed, PBR info model
(draft-kini-i2rs-pbr-info-model-00) can be extended into data model. I'll
try to submit the draft by the deadline (it is dependent on new
draft-ietf-netmod-routing-cfg, probably draft-ietf-netmod-routing-cfg-16,
being published)

Dean

On Sep 25, 2014, at 2:00 PM, Jeffrey Haas < <mailto:[email-masked]>
[email-masked]> wrote:

> Your chairs have been a bit over-busy recently with travel to unicast 

> people doing various bits of chartered work.  This means we've been 

> behind on some of our goals in terms of getting regular design 

> sessions running.  I know that at least a couple calls have happened 

> that I've missed that Sue Hares has done, so some progress is being made.

> We've requested a 1 hour time slot for IETF 91 in Honolulu to give us 

> a chance to talk.  This is a call for agenda slots.

>  <mailto:[email-masked]> [email-masked]

>  <https://www.ietf.org/mailman/listinfo/i2rs>

i2rs mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/i2rs>
https://www.ietf.org/mailman/listinfo/i2rs

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 26 Sep 2014 23:37:18 -0400

Jeff:

Just to confirm that you requested only a 1 hour instead of a 2.5 hour slot?

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Dean Bogdanovic
Sent: Thursday, September 25, 2014 2:44 PM
To: Jeffrey Haas
Cc: [email-masked]
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status
reports?

Jeff,

Dean

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 27 Sep 2014 07:32:13 +0200

> netmod models? If so, I will do this as well. 

Hi,

one I-D is enough, multiple I-Ds only create confusion. If you want to
make NETMOD people aware of these I2RS I-Ds (probably a good thing),
send a short message to the NETMOD mailing list with pointers to the
I-Ds.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 27 Sep 2014 19:57:57 +0000

From: Susan Hares <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 26, 2014 at 11:36 PM
To: Jeff Haas <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports?

Jeff:

Please add to the agenda the following drafts: I2RS yang Data and Information models for ISIS, OSPF, Basic Network Policy (BNP), PBR and BGP.  PBR and BGP will be uploaded next week after some internal review.

HI Sue,
We are currently have drafts for the OSPF and ISIS YANG models and have multi-vendor design teams contributing to them. This works is being done in the OSPF and ISIS WG groups. You are welcome to review it but please don’t create confusion with alternate drafts.

Thanks,
Acee

The PBR model is the information model that is a collaboration between the PBR (draft-kini-i2rs-pbr-info-model-00) and the (draft-hares-i2rs-policy-info-model).   We hoped to have the agreement on the text early next week (just 1 technical discussion).   The author team has had meetings in August and September.

One question – should I be submitting these I2RS configuration IM/DM as netmod models? If so, I will do this as well.

Sue

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Dean Bogdanovic
Sent: Thursday, September 25, 2014 2:44 PM
To: Jeffrey Haas
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports?

Jeff,

Dean

> [email-masked]<mailto:[email-masked]>

i2rs mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 27 Sep 2014 16:32:08 -0400

Acee:

Was this work announced on any list at IETF for general contribution?  I
don't see an announcement on the ospf list or the ISIS list?  Perhaps you
could point me to the list where this was announced? 

Sue 

From: i2rs [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Saturday, September 27, 2014 3:58 PM
To: Susan Hares; 'Jeffrey Haas'
Cc: [email-masked]
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status
reports?

From: Susan Hares <[email-masked]>
Date: Friday, September 26, 2014 at 11:36 PM
To: Jeff Haas <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status
reports?

Jeff: 

HI Sue,

We are currently have drafts for the OSPF and ISIS YANG models and have
multi-vendor design teams contributing to them. This works is being done in
the OSPF and ISIS WG groups. You are welcome to review it but please don't
create confusion with alternate drafts. 

Thanks,

Acee 

 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Dean Bogdanovic
Sent: Thursday, September 25, 2014 2:44 PM
To: Jeffrey Haas
Cc: [email-masked]
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status
reports?

Jeff,

Dean

i2rs mailing list

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 27 Sep 2014 21:06:27 +0000

Sue:

Did you look at the archives for the OSPF and ISIS WGs? Both drafts were presented at IETF 90 in Toronto. We intend to cross review the OSPF YANG model in both the netmod and OSPF WGs. The ISIS YANG Model is already being accepted as an ISIS WG document.

http://www.ietf.org/proceedings/90/slides/slides-90-isis-0.pdf
http://www.ietf.org/proceedings/90/slides/slides-90-ospf-8.pdf

Acee

From: Susan Hares <[email-masked]<mailto:[email-masked]>>
Date: Saturday, September 27, 2014 at 4:32 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>, Jeff Haas <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [i2rs] IETF 91 meeting requested - call for agenda; status reports?

Acee:

Was this work announced on any list at IETF for general contribution?  I don’t see an announcement on the ospf list or the ISIS list?  Perhaps you could point me to the list where this was announced?

Sue

Jeff:

HI Sue,

Thanks,
Acee

Sue

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Dean Bogdanovic
Sent: Thursday, September 25, 2014 2:44 PM
To: Jeffrey Haas
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports?

Jeff,

Dean

i2rs mailing list

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 27 Sep 2014 18:16:33 -0400

Acee:

I'm confused by this email thread because these slides state the authors are
looking for co-authors for netmod drafts. Are you as the co-chair of OSPF
declaring consensus on the OSPF yang model draft? Would you point me to the
email that indicates the WG Adoption call and conclusion? 

The drafts I suggested are I2RS drafts for the I2RS datastore that allow it
to configure the routing agent directly. The only way these two drafts
interact is if the option 4 proposed by the Yang 1.1 interim (created
9/19/14) works.  It is unclear if it will work - that's under discussion.
There is no reason to stop the I2RS DM/IM models required by I2RS charter
work while we find out if option 4 works. 

And out of curiosity, if we are now considering option 4 why don't you want
more input and collaboration that provides insight from people who looked at
the OSPF for the I2RS use that option 4 suggests?  We have complete IM and
DM (yang compiled) for the configuration we thought was necessary for I2RS
if the agent talked directly to the routing process (the assumption of all
I2RS with unique data store).  

Sue 

PS - the ISIS Draft is not listed as approved or listed on the ISIS mail
list as approved. It has not been updated since 6/27/14.  If you believe it
should be listed that way, you might want to talk to the ISIS co-chairs. 

From: Acee Lindem (acee) [mailto:[email-masked]] 
Sent: Saturday, September 27, 2014 5:06 PM
To: Susan Hares; 'Jeffrey Haas'
Cc: [email-masked]
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status
reports?

Sue: 

Did you look at the archives for the OSPF and ISIS WGs? Both drafts were
presented at IETF 90 in Toronto. We intend to cross review the OSPF YANG
model in both the netmod and OSPF WGs. The ISIS YANG Model is already being
accepted as an ISIS WG document. 

Acee 

From: Susan Hares <[email-masked]>
Date: Saturday, September 27, 2014 at 4:32 PM
To: Acee Lindem <[email-masked]>, Jeff Haas <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [i2rs] IETF 91 meeting requested - call for agenda; status
reports?

Acee:

Sue 

 

Jeff: 

HI Sue,

Thanks,

Acee 

 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Dean Bogdanovic
Sent: Thursday, September 25, 2014 2:44 PM
To: Jeffrey Haas
Cc: [email-masked]
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status
reports?

Jeff,

Dean

i2rs mailing list

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 27 Sep 2014 22:32:21 +0000

Date: Saturday, September 27, 2014 at 6:16 PM

Acee:

I’m confused by this email thread because these slides state the authors are looking for co-authors for netmod drafts. Are you as the co-chair of OSPF declaring consensus on the OSPF yang model draft?

Yes – and there are now multi-vendor design teams in place.

Would you point me to the email that indicates the WG Adoption call and conclusion?

We haven’t adopted yet in OSPF. ISIS adoption is in progress. I already searched the proceedings for the presentations. Note that the list archives offer a search capability… Anyway, here is the ISIS message:

http://www.ietf.org/mail-archive/web/isis-wg/current/msg03679.html

The drafts I suggested are I2RS drafts for the I2RS datastore that allow it to configure the routing agent directly. The only way these two drafts interact is if the option 4 proposed by the Yang 1.1 interim (created 9/19/14) works.  It is unclear if it will work – that’s under discussion. There is no reason to stop the I2RS DM/IM models required by I2RS charter work while we find out if option 4 works.

And out of curiosity, if we are now considering option 4 why don’t you want more input and collaboration that provides insight from people who looked at the OSPF for the I2RS use that option 4 suggests?  We have complete IM and DM (yang compiled) for the configuration we thought was necessary for I2RS if the agent talked directly to the routing process (the assumption of all I2RS with unique data store).

Please review the OSPF and ISIS drafts with respect to option 4.

Thanks,
Acee

Sue

PS – the ISIS Draft is not listed as approved or listed on the ISIS mail list as approved. It has not been updated since 6/27/14.  If you believe it should be listed that way, you might want to talk to the ISIS co-chairs.

Sue:

Acee

Acee:

Sue

Jeff:

HI Sue,

Thanks,
Acee

Sue

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Dean Bogdanovic
Sent: Thursday, September 25, 2014 2:44 PM
To: Jeffrey Haas
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports?

Jeff,

Dean

i2rs mailing list

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 27 Sep 2014 19:22:33 -0400

Acee: 

Thank you for the pointer to the message in ISIS.  Perhaps since Chris just
declared consensus Friday the 9/19/14 that he will get around to posting
these drafts. 

To be clear, I understand from your work that you are declaring consensus on
the yang models for OSPF model based on your knowledge of the private
multi-vendor design team.  You are stating at the OSPF chair that those
models have the front seat in looking at the I2RS models without reading any
of the I2RS IM/DM drafts we have prepared.  Please confirm that I understand
this message so that I can determine the next steps to take with these
drafts. 

Sue 

From: Acee Lindem (acee) [mailto:[email-masked]] 
Sent: Saturday, September 27, 2014 6:32 PM
To: Susan Hares; 'Jeffrey Haas'
Cc: [email-masked]
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status
reports

Acee:

I'm confused by this email thread because these slides state the authors are
looking for co-authors for netmod drafts. Are you as the co-chair of OSPF
declaring consensus on the OSPF yang model draft? 

Yes - and there are now multi-vendor design teams in place. 

Would you point me to the email that indicates the WG Adoption call and
conclusion?

We haven't adopted yet in OSPF. ISIS adoption is in progress. I already
searched the proceedings for the presentations. Note that the list archives
offer a search capability. Anyway, here is the ISIS message:

 

Thanks,

Acee 

 

Sue 

Sue: 

Acee 

Acee:

Sue 

 

Jeff: 

HI Sue,

Thanks,

Acee 

 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Dean Bogdanovic
Sent: Thursday, September 25, 2014 2:44 PM
To: Jeffrey Haas
Cc: [email-masked]
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status
reports?

Jeff,

Dean

i2rs mailing list

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 27 Sep 2014 23:37:22 +0000

Date: Saturday, September 27, 2014 at 7:22 PM

Acee:

Thank you for the pointer to the message in ISIS.  Perhaps since Chris just declared consensus Friday the 9/19/14 that he will get around to posting these drafts.

I’m not sure why you are suggesting that these drafts have not been previously posted.

https://datatracker.ietf.org/doc/draft-litkowski-isis-yang-isis-cfg/
https://datatracker.ietf.org/doc/draft-yeung-netmod-ospf/

To be clear, I understand from your work that you are declaring consensus on the yang models for OSPF model based on your knowledge of the private multi-vendor design team.

As you noted, both the presentations at IETF 90 called for participation. These design teams are much less private than the OSPF/ISIS IM/DM drafts you submitted yesterday.

You are stating at the OSPF chair that those models have the front seat in looking at the I2RS models without reading any of the I2RS IM/DM drafts we have prepared.

The work on the OSPF and ISIS YANG models pre-dated the drafts you have submitted yesterday by quite some time so I don’t see we should consider replacing it.

 Please confirm that I understand this message so that I can determine the next steps to take with these drafts.

Your next step should be to review the OSPF/ISIS drafts.

Thanks,A
Acee

Sue

Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports

Acee:

Thanks,
Acee

Sue

Sue:

Acee

Acee:

Sue

Jeff:

HI Sue,

Thanks,
Acee

Sue

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Dean Bogdanovic
Sent: Thursday, September 25, 2014 2:44 PM
To: Jeffrey Haas
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports?

Jeff,

Dean

i2rs mailing list

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 27 Sep 2014 20:21:40 -0400

Acee:

I think we are still confused. The different streams (i2RS/config) that may
or may not be merged (under debate).  Both i2rs/config streams had open
calls at IETF 90 for contributions and collaborators based on pre-IETF 90
work. On that portion of topic after this message, let's declare rat hole.  

My key question is still unanswered:  "Do I understand is that you as
co-chair of OSPF are stating you recommend not reading or reviewing the I2RS
OSPF drafts I and my-authors created for the I2RS stream and instead you
recommend figuring out if your existing configuration drafts fit I2RS?"  I
appreciate your bluntness so I can figure where to put our next efforts in
I2RS.  

Thank you, 

Sue 

From: Acee Lindem (acee) [mailto:[email-masked]] 
Sent: Saturday, September 27, 2014 7:37 PM
To: Susan Hares; 'Jeffrey Haas'
Cc: [email-masked]
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status
reports?

Acee: 

I'm not sure why you are suggesting that these drafts have not been
previously posted. 

Acee - my message indicates the isis drafts had not been posted as:
draft-isis-yang-isis-cfg, and that draft-yeung-netmod-ospf was not the ospf
web page or netmod web page.   It is a polite indication between chairs that
if this is important .. you might want to catch up with your housekeeping.  

To be clear, I understand from your work that you are declaring consensus on
the yang models for OSPF model based on your knowledge of the private
multi-vendor design team.  

As you noted, both the presentations at IETF 90 called for participation.
These design teams are much less private than the OSPF/ISIS IM/DM drafts you
submitted yesterday. 

Acee - this is simply not true.  See the above information - it had the same
level of call at IETF 90.  

You are stating at the OSPF chair that those models have the front seat in
looking at the I2RS models without reading any of the I2RS IM/DM drafts we
have prepared.

The work on the OSPF and ISIS YANG models pre-dated the drafts you have
submitted yesterday by quite some time so I don't see we should consider
replacing it.    

Acee - I'm afraid you rare confusing the I2RS work with the configuration
work.  Only on 9/19/14 at a yang 1.1 interim (no standing with I2RS), was
there a suggestion these might work.   

 Please confirm that I understand this message so that I can determine the
next steps to take with these drafts.

Thanks,A

Acee 

 

Sue 

 

Acee:

 

 

Thanks,

Acee 

 

Sue 

Sue: 

Acee 

Acee:

Sue 

 

Jeff: 

HI Sue,

Thanks,

Acee 

 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Dean Bogdanovic
Sent: Thursday, September 25, 2014 2:44 PM
To: Jeffrey Haas
Cc: [email-masked]
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status
reports?

Jeff,

Dean

i2rs mailing list

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sun, 28 Sep 2014 16:59:07 +0000

Sue,

See inline.

Date: Saturday, September 27, 2014 at 8:21 PM

Acee:

I think we are still confused. The different streams (i2RS/config) that may or may not be merged (under debate).  Both i2rs/config streams had open calls at IETF 90 for contributions and collaborators based on pre-IETF 90 work. On that portion of topic after this message, let’s declare rat hole.

My key question is still unanswered:  “Do I understand is that you as co-chair of OSPF are stating you recommend not reading or reviewing the I2RS OSPF drafts I and my-authors created for the I2RS stream and instead you recommend figuring out if your existing configuration drafts fit I2RS?”  I appreciate your bluntness so I can figure where to put our next efforts in I2RS.

Note the IESG statement on YANG models independent of I2RS:

http://www.ietf.org/iesg/statement/writable-mib-module.html

We have been working on YANG models for some time in both OSPF and ISIS. The ISIS model is already being adopted and we will request WG OSPF adoption upon the next refresh. I can’t help it if you are not following the WGs for which you are proposing models. For your next efforts, I'd recommend better coordination and awareness of WG activities.

Thanks,
Acee

Thank you,

Sue

Acee:

Acee – my message indicates the isis drafts had not been posted as: draft-isis-yang-isis-cfg, and that draft-yeung-netmod-ospf was not the ospf web page or netmod web page.   It is a polite indication between chairs that if this is important .. you might want to catch up with your housekeeping.

Acee – this is simply not true.  See the above information – it had the same level of call at IETF 90.

Acee – I’m afraid you rare confusing the I2RS work with the configuration work.  Only on 9/19/14 at a yang 1.1 interim (no standing with I2RS), was there a suggestion these might work.

Thanks,A
Acee

Sue

Acee:

Thanks,
Acee

Sue

Sue:

Acee

Acee:

Sue

Jeff:

HI Sue,

Thanks,
Acee

Sue

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Dean Bogdanovic
Sent: Thursday, September 25, 2014 2:44 PM
To: Jeffrey Haas
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports?

Jeff,

Dean

i2rs mailing list

---

From: Alia Atlas <[email-masked]>
Date: Sun, 28 Sep 2014 20:54:20 -0400

Acee,

It is NOT OK to tell anyone that they should not contribute a draft -
because it may muddy the water
or for ANY other non-technical reason.  Individual drafts or desire to
request WG adoption do not change
this.  I do not ever want to see or hear something like this on an IETF
mailing list.

Very very few drafts start perfect and different models have different
perspectives.  The IETF has a
consensus process, as you well know of course, to resolve differences
between perspectives and drafts.

Second, a NETMOD interim with tentative ideas on how it might be nice to
carry out requests in an
individual draft  does not in any way dictate how I2RS should proceed.
I2RS is in Routing
because we understand the work and details to be done.  The desire that
there can be only one model for
any and all purposes is interesting but it isn't clear that is feasible.

I d not have any more polite words to discuss this.

Alia

On Sun, Sep 28, 2014 at 12:59 PM, Acee Lindem (acee) <[email-masked]> wrote:

> I think we are still confused. The different streams (i2RS/config) that
> may or may not be merged (under debate).  Both i2rs/config streams had open
> work. On that portion of topic after this message, let’s declare rat hole.
>
>
>
> My key question is still unanswered:  “Do I understand is that you as
> co-chair of OSPF are stating you recommend not reading or reviewing the
> I2RS OSPF drafts I and my-authors created for the I2RS stream and instead
> you recommend figuring out if your existing configuration drafts fit I2RS?”
>  I appreciate your bluntness so I can figure where to put our next efforts
> in I2RS.
>
>
>  We have been working on YANG models for some time in both OSPF and ISIS.
> The ISIS model is already being adopted and we will request WG OSPF
> adoption upon the next refresh. I can’t help it if you are not following
> the WGs for which you are proposing models. For your next efforts, I'd
> recommend better coordination and awareness of WG activities.
>
>  Thanks,
> Acee
>
>
>
>
>
>
>
> Thank you,
>
>
>
> Sue
>
>
>
> *From:* Acee Lindem (acee) [mailto:[email-masked] <[email-masked]>]
> *Sent:* Saturday, September 27, 2014 7:37 PM
> *To:* Susan Hares; 'Jeffrey Haas'
> *Cc:* [email-masked]
> *Subject:* Re: [i2rs] IETF 91 meeting requested - call for agenda; status
> reports?
>
>
>
>
>
>
>
> *From: *Susan Hares <[email-masked]>
> *Date: *Saturday, September 27, 2014 at 7:22 PM
> *To: *Acee Lindem <[email-masked]>, Jeff Haas <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *RE: [i2rs] IETF 91 meeting requested - call for agenda; status
> reports?
>
>
>
>  Acee:
>
>
>
> Thank you for the pointer to the message in ISIS.  Perhaps since Chris
> just declared consensus Friday the 9/19/14 that he will get around to
> posting these drafts.
>
>
>
> Acee – my message indicates the isis drafts had not been posted as:
> web page or netmod web page.   It is a polite indication between chairs
> that if this is important .. you might want to catch up with your
> housekeeping.
>
>
>
>
>
> To be clear, I understand from your work that you are declaring consensus
> on the yang models for OSPF model based on your knowledge of the private
> These design teams are much less private than the OSPF/ISIS IM/DM drafts
> you submitted yesterday.
>
>
>
>  You are stating at the OSPF chair that those models have the front seat
> in looking at the I2RS models without reading any of the I2RS IM/DM drafts
> we have prepared.
>
>
>
> submitted yesterday by quite some time so I don’t see we should consider
> replacing it.
>
>
>
> Acee – I’m afraid you rare confusing the I2RS work with the configuration
>   Please confirm that I understand this message so that I can determine
> the next steps to take with these drafts.
>
>
>
> *From:* Acee Lindem (acee) [mailto:[email-masked] <[email-masked]>]
> *Sent:* Saturday, September 27, 2014 6:32 PM
> *To:* Susan Hares; 'Jeffrey Haas'
> *Cc:* [email-masked]
> *Subject:* Re: [i2rs] IETF 91 meeting requested - call for agenda; status
> reports
>
>
>
>
>
> *From: *Susan Hares <[email-masked]>
> *Date: *Saturday, September 27, 2014 at 6:16 PM
> *To: *Acee Lindem <[email-masked]>, Jeff Haas <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *RE: [i2rs] IETF 91 meeting requested - call for agenda; status
> reports?
>
>
>
>  Acee:
>
>
>
> I’m confused by this email thread because these slides state the authors
> are looking for co-authors for netmod drafts. Are you as the co-chair of
> OSPF declaring consensus on the OSPF yang model draft?
>
>
>
> We haven’t adopted yet in OSPF. ISIS adoption is in progress. I already
> offer a search capability… Anyway, here is the ISIS message:
>
>
>
> The drafts I suggested are I2RS drafts for the I2RS datastore that allow
> it to configure the routing agent directly. The only way these two drafts
> 9/19/14) works.  It is unclear if it will work – that’s under discussion.
> And out of curiosity, if we are now considering option 4 why don’t you
> want more input and collaboration that provides insight from people who
> looked at the OSPF for the I2RS use that option 4 suggests?  We have
> complete IM and DM (yang compiled) for the configuration we thought was
> necessary for I2RS if the agent talked directly to the routing process (the
> assumption of all I2RS with unique data store).
>
>
>
> PS – the ISIS Draft is not listed as approved or listed on the ISIS mail
> *From:* Acee Lindem (acee) [mailto:[email-masked] <[email-masked]>]
> *Sent:* Saturday, September 27, 2014 5:06 PM
> *To:* Susan Hares; 'Jeffrey Haas'
> *Cc:* [email-masked]
> *Subject:* Re: [i2rs] IETF 91 meeting requested - call for agenda; status
> reports?
>
>
>
> Sue:
>
>
>
> *From: *Susan Hares <[email-masked]>
> *Date: *Saturday, September 27, 2014 at 4:32 PM
> *To: *Acee Lindem <[email-masked]>, Jeff Haas <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *RE: [i2rs] IETF 91 meeting requested - call for agenda; status
> reports?
>
>
>
>  Acee:
>
>
>
> don’t see an announcement on the ospf list or the ISIS list?  Perhaps you
> *From:* i2rs [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Acee Lindem (acee)
> *Sent:* Saturday, September 27, 2014 3:58 PM
> *To:* Susan Hares; 'Jeffrey Haas'
> *Cc:* [email-masked]
> *Subject:* Re: [i2rs] IETF 91 meeting requested - call for agenda; status
> reports?
>
>
>
>
>
>
>
> *From: *Susan Hares <[email-masked]>
> *Date: *Friday, September 26, 2014 at 11:36 PM
> *To: *Jeff Haas <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [i2rs] IETF 91 meeting requested - call for agenda; status
> reports?
>
>
>
>  Jeff:
>
>
>
> Information models for ISIS, OSPF, Basic Network Policy (BNP), PBR and
> BGP.  PBR and BGP will be uploaded next week after some internal review.
>
>
>
> HI Sue,
>
> the OSPF and ISIS WG groups. You are welcome to review it but please don’t
> One question – should I be submitting these I2RS configuration IM/DM as
> From: i2rs [mailto:[email-masked] <[email-masked]>] On
> Behalf Of Dean Bogdanovic

---

From: Thomas Narten <[email-masked]>
Date: Mon, 29 Sep 2014 14:44:46 -0400

> It is NOT OK to tell anyone that they should not contribute a draft - because
> it may muddy the water
> or for ANY other non-technical reason.  Individual drafts or desire to request
> WG adoption do not change

Let me defend Acee here a bit and try to chart a course a bit more
down the middle. When a WG has an effort underway that is intended to
lead to a WG document (and that is what I read the current "design
team" effort to be), it is IMO often not helpful to have yet more IDs
submitted on the same topic. Rather than complementing the existing
work towards a concensus result, additional IDs can be a distraction
and require folk to spend time figuring out how the other ID relates
to the WG effort. I.e., it's much more constuctive to say "here is
what is defficient in the current model, and here is what I think we
should do instead". It is much less constructive to have a standalone
ID that (probably) overlaps with the other IDs and doesn't focus on
the *differences* from the other work that already has a head start.

It is the case that the IETF mantra is "submit a draft", but frankly,
I think that is a bit of a sound bite that we would do well to not
spit out as often as we seem to because it too often misses what
really should happen, namely, how best to contribute to reaching
consensus in a WG. We have a huge problem today where there are
overlapping/competing drafts that WGs have to sort through. And in
many of those cases, additional IDs have very little additional
content than what already exists. But since we go around telling folk
to "submit an ID", we shouldn't be surprise that we get them beyond
the point of diminishing returns. (And I am NOT saying that the draft
at issue here is one of those.)

In this case (and I personally don't have any skin in the game), it
seems to that both parties are making honest efforts to do the right
thing, but unfortunately, the state of play was not fully known to all.

> Very very few drafts start perfect and different models have
> different perspectives.  The IETF has a consensus process, as you
> well know of course, to resolve differences between perspectives and
> drafts.

I didn't hear anyone say that consensus has already been called.  My
take away is that we have a WG making an honest effort to move forward
in a particular direction and it is doing exactly what it should be in
terms of getting behind a design team effort. And IMO, once you have a
WG design team working on an effort, having others submit drafts in
the same space is not always what we should be encouraging people to
do.

Does that mean we should not allow additional IDs? Of course not. Does
it mean we won't look at them and give them consideration"? Of course
not. But we should also be honest that if a WG has an official
document or has a DT working on a document, having additional
"competing" documents show up is often not the most constructive way
to contribute. Unless news IDs really are clear about how they relate
to the other efforts and what those other efforts are lacking.

Thomas

---

From: Joe Clarke <[email-masked]>
Date: Mon, 29 Sep 2014 14:55:21 -0400

> What have you been up to?

I think the list knows about the traceability "shoe" that's been waiting 
to drop.  Question is, can it be settled on the list, should we ask in 
Honolulu?  Does it need an agenda item or can the chairs raise the 
point?  Thanks.

Joe

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 29 Sep 2014 20:49:01 +0000

Thanks Much Thomas! Given that I was the victim of considerable back-door
escalations and machinations, I was giving myself a ³cooling off² period
prior responding. However, you expressed my sentiments with much more
patience than I could have myself. Moving forward, we are going to have to
agree on a home for these protocol models drafts. Of course, my preference
would be to keep them in the protocol WGs with I2RS and I2RS review. Given
the IESG statement on YANG models replaced MIBs
(<http://www.ietf.org/iesg/statement/writable-mib-module.html>), I had
viewed this as self-evident.

Acee

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 29 Sep 2014 17:08:01 -0400

[Context for the WG, I spent some time talking to Sue about the topics here
over lunch.  I don't think anything has gone wrong beyond a need for greater
communication of the involved parties.  Picking this email to provide
context...]

> email that indicates the WG Adoption call and conclusion? 

As discussed later on in thread and also over my conversation with Sue,
there is existing work for OSPF and ISIS for defining yang modules.  That's

> work while we find out if option 4 works. 

The issue I2RS has had over the lingering ambiguity of what the I2RS
ephemeral config was going to look like meant that the only instructions
those who were going to do I2RS models was to take their best effort.  Sue's
analysis, similar to that of others, was that a configuration and
operational model was going to be required.

Note that while I haven't read the drafts, the comment above suggests that
part of the work in there was to identify the insertion points that I2RS
would need for I2RS functionality in the model.  This is definitely work
that we need as a WG.

My own impression of the OSPF and ISIS work was while it was active, it was
not necessarily that visible and may be happening in the context of a design
team.  If so, the impression may have been that the work has stalled.

One of the discussion points at the last IETF with Benoit and the netmod
chairs during their tutorial session was that the IETF is in need of a
discussion list covering active efforts.  This would serve to help solve
some of the common modeling issues along with tracking work that may be
common across models and deserving refactoring into a shared IETF module.
An example of such work is the ACL work.

I'm under the impression we have yet to create such a coordinating list?

Further response later in thread...
-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 29 Sep 2014 17:16:49 -0400

Thomas,

[using your reply to continue my response...]

On Mon, Sep 29, 2014 at 02:44:46PM -0400, Thomas Narten wrote:
> > or for ANY other non-technical reason.? Individual drafts or desire to request
> > this.? I do not ever want to see or hear something like this on an IETF
> > mailing list.
> 

I generally agree, but would also offer a counter point:  As we go through
our standardization efforts in the various routing protocol modules, some of
the vendors will have created an internal model of their implementation.
Having such a model is highly useful in the sense that it provides an
overall view of how a given implementation functions.

The challenge that will come is taking our individual models and reconciling
them to a common IETF model.  Obviously OSPF at least has made some progress
toward such an implementation.

BFD has recently kicked off its yang modeling work.  One of the things I
recommended as we start our analysis is that we simply provide the inputs in
the github repository that was established for the work (currently in a
repository based from my account) all contributions that help establish
configuration and operational context.  We currently have the BFD MIBs along
with a contribution from Huawei.  Juniper will be contributing its BFD yang
as well and we're expecting others.

I'd suggest that it might be good for the other protocol yang work to
establish practices for vendor models for comparison purposes.  Choose
whatever place - github, or the I-D repository - you find handy. :-)

> overlapping/competing drafts that WGs have to sort through.

In speaking with Sue, I don't believe there was any intended affront to
existing efforts.  I think you'll find her happy to help coordinate that
analysis and generate appropriate diffs.

And I think we'll also find the benefit of having the I2RS cases considered
as part of that work.

> thing, but unfortunately, the state of play was not fully known to all.

Exactly.  I think the feeling of people "getting their toes stepped upon"
comes from some over-reactions.  Hopefully we'll reset our levels and
continue working on good standards.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 29 Sep 2014 17:20:42 -0400

On Mon, Sep 29, 2014 at 08:49:01PM +0000, Acee Lindem (acee) wrote:
> escalations and machinations, I was giving myself a ?cooling off? period
> would be to keep them in the protocol WGs with I2RS and I2RS review.

Speaking ex oficio, I2RS is aware that protocol work MUST of necessity
happen in the individually appropriate working groups.  There is a strong
need to avoid re-inventing various modeling constructs simply to satisfy the
I2RS use case.  This means that there's incentive for I2RS WG members to
participate in a given WGs design efforts.

Much like writing software, if we end up with copy and pasted content
between modules, we've probably done it wrong.

We may want to spend a portion of the upcoming rtg-area meeting discussing
how to coordinate these efforts.  As mentioned earlier in-thread, we've had
discussions with Benoit and the netmod chairs about some form of this.

-- Jeff

---

From: Alia Atlas <[email-masked]>
Date: Mon, 29 Sep 2014 17:21:30 -0400

Thomas,

> the *differences* from the other work that already has a head start.

First, I have been encouraging the routing WGs to work on and consider YANG
models.
I have been quite clear in discussing with Benoit that they should be homed
in the Routing
area and that I don't think it makes sense to create a separate working
group to just work
on YANG models.

Second, the assumption that we have had with I2RS is that it will need
different and possibly
more limited models than would be used for configuration of a particular
protocol.  A reasonable
approach could be doing the I2RS-specific models in I2RS and having them
cross-reviewed in
the relevant protocol working-groups.  This is the path that, as I
understand it, Sue was working on.
It would allow review of the interactions between the different models for
their I2RS aspects (assuming
that the WG believes that there are some).

Third, individuals have been working an individual draft
(draft-yeung-netmod-ospf-01) for an OSPF configuration YANG model.  This
was discussed in OSPF last IETF.  I agree that the updated draft, when
posted, is likely to be an excellent candidate for the OSPF WG.

However, regardless of whom may be working on writing
draft-yeung-netmod-ospf-01 or who may have been going behind the scenes
pushing and encouraging (and I am also quite happy and eager and
encouraging to see good YANG models for routing functionality), this is not
an official design team
effort.

Deliberately writing a competing draft may not be constructive.  That is
not what happened here and
it was the combination of trying to incorrectly privilege an (expired)
individual draft that was written to solve a different problem and asking
for someone  who had done work to produce a draft towards a different
problem that caused me to be extremely displeased.

 I realize that one of the topics of discussion since the netmod interim
has been whether it makes sense to have one YANG model that can be used by
NetConf and I2RS for writing and reading.  However, I have not heard
discussed much less agreed upon that approach in I2RS and it is
inappropriate to presuppose the answer and punt work that it is quite
reasonable to assume (and examine to determine) will move the WG forward.

> at issue here is one of those.)

Please let's not try to conflate one specific case with its own concerns
with
generalities.  That is not constructive.

> thing, but unfortunately, the state of play was not fully known to all.

Yes, this is communication and clear communication is needed.

> the same space is not always what we should be encouraging people to

There IS NOT a WG Design Team in OSPF working on the YANG model.  There
are individuals, whom were encouraged to work together, but that does not
make it
a design team.  IFF there were an announced WG Design Team and IFF there
were
consensus in I2RS that I2RS would use exactly the same YANG models, then
this
point might hold water.   Since neither are the case, I do not believe that
it does so.

> to the other efforts and what those other efforts are lacking.

Yes - and official WG design teams are different from a group of
individuals.  To be
extremely clear yet again, this is a group of individuals.

Regards,
Alia

Thomas

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 29 Sep 2014 17:25:19 -0400

On Mon, Sep 29, 2014 at 02:55:21PM -0400, Joe Clarke wrote:
> I think the list knows about the traceability "shoe" that's been
> waiting to drop.  Question is, can it be settled on the list, should
> we ask in Honolulu?  Does it need an agenda item or can the chairs
> raise the point?  Thanks.

This chair admits he's been a slacker even though oversubscribed.  

One of the reasons why this has been left to linger slightly is the detail
that we've left the architecture document unpublished as an RFC to permit
some time to reconcile the ephemeral datastore question.  The answer to that
question may have impact on the architecture.  Aside from that, the document
is past WGLC and was ready to be submitted for publication.

Since the architecture draft is still open, do you believe that the traceability
draft should be incorporated into the architecture document or left
separately?

This question obviously is for the WG to answer.  Once we have that answer,
we'll either look for the edits to the architecture or simply do an adoption
call.  We saw good support for the idea that traceability is something we
should have.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 29 Sep 2014 17:27:21 -0400

Alia,

On Mon, Sep 29, 2014 at 05:21:30PM -0400, Alia Atlas wrote:
> different and possibly more limited models than would be used for
> configuration of a particular protocol.  A reasonable approach could be
> doing the I2RS-specific models in I2RS and having them cross-reviewed in

As noted in a prior message, this path is complicated by not having settled
on what I2RS config looks like in an ephemeral datastore.  

-- Jeff

---

From: Alia Atlas <[email-masked]>
Date: Mon, 29 Sep 2014 17:33:23 -0400

Acee,

> viewed this as self-evident.

First, I really appreciate that you gave yourself a cooling-off period
before responding.
I did exactly the same thing before responding.  The last thing that is
needed or desired
is escalations.  I think this is an excellent practice when email
conversations get heated.

Second, what I have been encouraging is absolutely that the YANG
configuration models
should go to each protocol group.  What is confusing the situation here is
that the I2RS related
models are not/have not been assumed to be the same thing.  Instead, the
assumption has been
that they would be more limited and perhaps have I2RS specifics (such as
for events) - and
therefore would happen in I2RS and also be discussed in the specific
protocol WG.

Third, there was discussion on the mailing list and at the interim about
"option 4" which is
pushing I2RS to use exactly the same YANG models.  I have seen discussion
trying to understand
what this would look like but certainly nothing around consensus that that
should be the case.

My strong reaction and email was to several things that I saw happening
together:
    a) Efforts to privilege an individual draft (expired) and push away
other approaches.  I do understand that it was very well received last
IETF, that a new version will be out soon, and that you can't ask for WG
adoption in OSPF until that occurs.
    b) A claim that the draft targeted at a config model for OSPF was all
that was needed for I2RS (prejudging the situation)

I know that we want to get really great YANG models out of this and
encourage more
people to work in this space and also want to see I2RS make actual progress.

I also agree that there are better ways for people to collaborate than to
go away and write a competing draft - but I do not think that was the
intent or what happened here.

Regards,
Alia

---

From: Alia Atlas <[email-masked]>
Date: Mon, 29 Sep 2014 17:36:25 -0400

Jeff,

> on what I2RS config looks like in an ephemeral datastore.

Absolutely - and since I2RS is still doing info models until there is a
clear
direction, split of the work, and recharter.

Alia

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 29 Sep 2014 17:40:30 -0400

On Mon, Sep 29, 2014 at 05:36:25PM -0400, Alia Atlas wrote:
> clear direction, split of the work, and recharter.

Per prior discussions and our last session, the WG was suggested to go forth
and start writing data models - knowing that they'll be incomplete until
this is settled.  Info models were okay to generate from the data models if
a separate info model provided no additional useful context.

Yes, your chairs are behind on sending the recharter request from this
discussion.

-- Jeff

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 29 Sep 2014 21:41:09 +0000

From: Alia Atlas <[email-masked]<mailto:[email-masked]>>
Date: Monday, September 29, 2014 at 5:33 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: Thomas Narten <[email-masked]<mailto:[email-masked]>>, Jeff Haas <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Susan Hares <[email-masked]<mailto:[email-masked]>>
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports?

Acee,

On Mon, Sep 29, 2014 at 4:49 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:

First, I really appreciate that you gave yourself a cooling-off period before responding.
I did exactly the same thing before responding.  The last thing that is needed or desired
is escalations.  I think this is an excellent practice when email conversations get heated.

Second, what I have been encouraging is absolutely that the YANG configuration models
should go to each protocol group.  What is confusing the situation here is that the I2RS related
models are not/have not been assumed to be the same thing.  Instead, the assumption has been
that they would be more limited and perhaps have I2RS specifics (such as for events) - and
therefore would happen in I2RS and also be discussed in the specific protocol WG.

Third, there was discussion on the mailing list and at the interim about "option 4" which is
pushing I2RS to use exactly the same YANG models.  I have seen discussion trying to understand
what this would look like but certainly nothing around consensus that that should be the case.

I would hope that we have a single model for NETCONF and I2RS or at least a core OSPF model that contains the large intersection.

My strong reaction and email was to several things that I saw happening together:
    a) Efforts to privilege an individual draft (expired) and push away other approaches.  I do understand that it was very well received last IETF, that a new version will be out soon, and that you can't ask for WG adoption in OSPF until that occurs.
    b) A claim that the draft targeted at a config model for OSPF was all that was needed for I2RS (prejudging the situation)

The latest OSPF model includes operational state as well as configuration and this is one reason why it has taken a long time to publish.

Thanks,
Acee

I know that we want to get really great YANG models out of this and encourage more
people to work in this space and also want to see I2RS make actual progress.

I also agree that there are better ways for people to collaborate than to go away and write a competing draft - but I do not think that was the intent or what happened here.

Regards,
Alia

Acee

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 29 Sep 2014 17:44:43 -0400

> I would hope that we have a single model for NETCONF and I2RS or at least a core OSPF model that contains the large intersection.

That's why option 4 was suggested.  Given that you now have a body of work
representing config for OSPF and knowing that I2RS may want to add state
into it, please take a look the option 4 discussion and see if it's a good
fit.

A reminder to the wider WG: "Option 4" was simply the line of discussion
from the netmod interim.  As seen in its thread it's either not fully
explained well or there's still confusion among the interim participants
what it actually means.  It's not settled that this is what we'll be doing,
but it is currently the method that has received the most discussion.

-- Jeff

---

From: Dean Bogdanovic <[email-masked]>
Date: Mon, 29 Sep 2014 22:57:32 +0000

To keep with the existing topic of the discussion (OSPF model), here is my question:

Why would you have two different OSPF models on a single device? That device has certain OSPF capabilities that are implemented and are represented by a data model. Configuration can be created based on it and written into a data store. Once you have a base model, you can decide to create other model, but it can be only subset of the base model. There is nothing preventing you to create a private model, but it has to be based on the base model.
Why do you need different model for I2RS? I strongly believe that a single data model is needed, but having different config stores to save different configuration parts. In my mind, I2RS has to provide a good mechanism that allows non-vendor owner of the device to define what can be changed on the device. The 3rd party should be able to decide that all of device capabilities can be changed through I2RS (I would then argue why do you really want to do that) or they can decide to go as minimal as changing ACLs, but allowing only ACE to be added/deleted from ACL (which makes much more sense IMO).
In I2RS we can focus on "light weight templates", that fills in specific stuff across multiple config snippets. L3VPN is such an example. It would fill in configs in BGP, routing instances, interfaces. It would all be based on the standard models.
Another thing could be a proprietary data model like vCPE. Device owner creates private "light weight templates" and it allows I2RS clients to manage vCPEs. The proprietary vCPE template is a subset of device base model. Based on vCPE model, configuration is created and stored in a data store, which ever is supported by the device and decided by the owner.
Now we have to figure out error handling, what happens when you populate a template, and the commit fails due to underlying config issue, how do you propagate such things back to the upper layer? IMO, all the minimum required configuration should be copied into ephemeral datastore, so if something breaks in the underlying config store, it is still viable, and there are no interdependencies between data stores. This is how the running config is created

(cfg A || cfg eph) = cfg running

Base config and ephemeral config are overlaid, ephemeral is see through to the base config, but device can function correctly by reading most of the config from ephemeral data store to certain extent. 

Dean

---

From: Alia Atlas <[email-masked]>
Date: Mon, 29 Sep 2014 19:12:37 -0400

On Mon, Sep 29, 2014 at 5:08 PM, Jeffrey Haas <[email-masked]> wrote:

> it

Yes - I spoke with Benoit about creating a rtg-yang-interest mailing list.
It hadn't
made it to the top of my priority queue, but I plan on working on that this
Friday.

Alia

---

From: Alia Atlas <[email-masked]>
Date: Mon, 29 Sep 2014 19:16:41 -0400

> a separate info model provided no additional useful context.

Absolutely - that was the direction I encouraged and what I was expecting to
consider as part of a recharter.

> discussion.

It's ok - I've found other charters to go rewrite ;-)
This discussion (or rather the one about "option 4") and understanding what
differences
would be, if any, for I2RS data models is very very useful to have before
touching the charter.

Alia

---

From: Alia Atlas <[email-masked]>
Date: Mon, 29 Sep 2014 19:22:11 -0400

On Mon, Sep 29, 2014 at 5:41 PM, Acee Lindem (acee) <[email-masked]> wrote:

>
>
>   From: Alia Atlas <[email-masked]>
> To: Acee Lindem <[email-masked]>
> Cc: Thomas Narten <[email-masked]>, Jeff Haas <[email-masked]>, "
> [email-masked]" <[email-masked]>, Susan Hares <[email-masked]>
>  I would hope that we have a single model for NETCONF and I2RS or at
> least a core OSPF model that contains the large intersection.
>

Yes, one of the things that Jeff has been actively working on is
coordination between models, understanding what should be groups for reuse,
etc.  The desire to have a large intersection defined only once is part of
why getting good IM/DM from the I2RS perspective is really useful too.

For something like the RIB DM, it's easy to talk about events
(active/inactive, etc) that one doesn't see or expect in a non-I2RS model.
Whether we have the similar events and other examples for OSPF is the
question.

>  The latest OSPF model includes operational state as well as
> configuration and this is one reason why it has taken a long time to
> publish.
>

Yes - unfortunate though because I believe that it has changed
significantly from what is published and that makes it basically impossible
to review.  I do know that the authors are trying to get out a new version
very very soon; this isn't trying to push them more.   I look forward to
reviewing it (and I don't say that about many drafts these days).

Regards,
Alia

>  I also agree that there are better ways for people to collaborate than
> to go away and write a competing draft - but I do not think that was the

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 29 Sep 2014 23:39:23 +0000

Right - while there may be unique access models for the data which reflect
unique I2RS or NETCONF requirements, I don¹t see why the domain specific
(e.g., OSPF) model content would be different.

On 9/29/14, 6:57 PM, "Dean Bogdanovic" <[email-masked]> wrote:

>Why would you have two different OSPF models on a single device? That
>device has certain OSPF capabilities that are implemented and are
>represented by a data model. Configuration can be created based on it and
>written into a data store. Once you have a base model, you can decide to
>create other model, but it can be only subset of the base model. There is
>nothing preventing you to create a private model, but it has to be based
>on the base model.
>Why do you need different model for I2RS? I strongly believe that a
>single data model is needed, but having different config stores to save
>different configuration parts. In my mind, I2RS has to provide a good
>mechanism that allows non-vendor owner of the device to define what can
>be changed on the device. The 3rd party should be able to decide that all
>of device capabilities can be changed through I2RS (I would then argue
>why do you really want to do that) or they can decide to go as minimal as
>changing ACLs, but allowing only ACE to be added/deleted from ACL (which
>makes much more sense IMO).
>In I2RS we can focus on "light weight templates", that fills in specific
>stuff across multiple config snippets. L3VPN is such an example. It would
>fill in configs in BGP, routing instances, interfaces. It would all be
>based on the standard models.
>Another thing could be a proprietary data model like vCPE. Device owner
>creates private "light weight templates" and it allows I2RS clients to
>manage vCPEs. The proprietary vCPE template is a subset of device base
>model. Based on vCPE model, configuration is created and stored in a data
>store, which ever is supported by the device and decided by the owner.
>Now we have to figure out error handling, what happens when you populate
>a template, and the commit fails due to underlying config issue, how do
>you propagate such things back to the upper layer? IMO, all the minimum
>required configuration should be copied into ephemeral datastore, so if
>something breaks in the underlying config store, it is still viable, and
>there are no interdependencies between data stores. This is how the
>running config is created
>
>Base config and ephemeral config are overlaid, ephemeral is see through
>to the base config, but device can function correctly by reading most of
>the config from ephemeral data store to certain extent.
>
>Dean
>

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 29 Sep 2014 20:40:10 -0400

Joe:

By shoe dropping - I think you mean accepted of the traceability as WG
draft. 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Joe Clarke
Sent: Monday, September 29, 2014 2:55 PM
To: Jeffrey Haas; [email-masked]
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status
reports?

> What have you been up to?

I think the list knows about the traceability "shoe" that's been waiting to
drop.  Question is, can it be settled on the list, should we ask in
Honolulu?  Does it need an agenda item or can the chairs raise the point?
Thanks.

Joe

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 29 Sep 2014 22:45:50 -0400

Acee:

I think that you, Dean, and I hope to work toward a model that finds as much
common ground for device specific. As Jeff pointed out, the domain specific
configuration models need to look at all vendor yang to see we've found the
IETF I2rs/config to make sure we've found that common ground.  In my earlier
request to review, it was based on concept of discovering anything with the
OSPF models that need to be augmented for I2RS.  

Dean suggests modular models that can be used to create the final model
within the standard or proprietary - which is good.  The error handling is
key during commits or crashes. 

Thank you for active discussion,

Sue  

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Monday, September 29, 2014 7:39 PM
To: Dean Bogdanovic; Jeffrey Haas
Cc: Thomas Narten; [email-masked]; Susan Hares; Alia Atlas
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status
reports?

On 9/29/14, 6:57 PM, "Dean Bogdanovic" <[email-masked]> wrote:

>represented by a data model. Configuration can be created based on it 
>and written into a data store. Once you have a base model, you can 
>decide to create other model, but it can be only subset of the base 
>model. There is nothing preventing you to create a private model, but 
>it has to be based on the base model.
>be changed on the device. The 3rd party should be able to decide that 
>all of device capabilities can be changed through I2RS (I would then 
>argue why do you really want to do that) or they can decide to go as 
>minimal as changing ACLs, but allowing only ACE to be added/deleted 
>from ACL (which makes much more sense IMO).
>In I2RS we can focus on "light weight templates", that fills in 
>specific stuff across multiple config snippets. L3VPN is such an 
>example. It would fill in configs in BGP, routing instances, 
>interfaces. It would all be based on the standard models.
>model. Based on vCPE model, configuration is created and stored in a 
>data store, which ever is supported by the device and decided by the owner.
>Now we have to figure out error handling, what happens when you 
>populate a template, and the commit fails due to underlying config 
>issue, how do you propagate such things back to the upper layer? IMO, 
>all the minimum required configuration should be copied into ephemeral 
>datastore, so if something breaks in the underlying config store, it is 
>still viable, and there are no interdependencies between data stores. 
>This is how the running config is created
>
>to the base config, but device can function correctly by reading most 
>of the config from ephemeral data store to certain extent.
>
>Dean
>
>> That's why option 4 was suggested.  Given that you now have a body of 
>>work  representing config for OSPF and knowing that I2RS may want to 
>>add state  into it, please take a look the option 4 discussion and see 
>>if it's a good  fit.
>> 
>> A reminder to the wider WG: "Option 4" was simply the line of 
>>discussion  from the netmod interim.  As seen in its thread it's 
>>either not fully  explained well or there's still confusion among the 
>>interim participants  what it actually means.  It's not settled that 
>>this is what we'll be doing,  but it is currently the method that has 
>>received the most discussion.
>> 
>> -- Jeff
>>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 30 Sep 2014 13:48:57 +0000

Hi Sue, 

There are efforts underway to incorporate additional participants into the
IGP YANG model teams and, of course, full WG review. The direction we have
been taking is that common extensions are handled as features and strictly
proprietary extensions will be handled with models augmenting the base.

Thanks,
Acee

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 30 Sep 2014 09:52:52 -0400

On Mon, Sep 29, 2014 at 07:16:41PM -0400, Alia Atlas wrote:
> This discussion (or rather the one about "option 4") and understanding
> what differences would be, if any, for I2RS data models is very very
> useful to have before touching the charter.

My thoughts exactly. :-)

-- Jeff

---

From: Benoit Claise <[email-masked]>
Date: Tue, 30 Sep 2014 15:53:45 +0200

Dear all,

Since my name has been mentioned multiple times, let me explain what 
I've been trying to do with the YANG modeling fast track.

http://tools.ietf.org/html/draft-yeung-netmod-ospf-00 was created in in 
Oct 2013 (Then later http://tools.ietf.org/html/draft-yeung-netmod-ospf-01)
It was on the agenda for the NETMOD IETF 88, Nov 2013. See 
http://www.ietf.org/proceedings/88/minutes/minutes-88-netmod
Already at that time, there were discussions to align the OSPF and core 
routing YANG models (what became draft-ietf-netmod-routing-cfg-15 
<http://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/> later). 
See the meeting minutes.
This OSPF YANG model was discussed again during the NETMOD IETF 89 
(http://www.ietf.org/proceedings/89/minutes/minutes-89-netmod).
Read specifically this part of the meeting minutes:

    LL: It is not likely that this working group can do all data models.
           There is an OSPF module which is quite Cisco specific. I have
           one that is Bird specific. It is up to the vendors to work out a
           common model. Experience with the routing module tells us that
           the exposition to routing experts is much less here than in the
           routing area. Leave it to the domain experts to do their data
           models. We can help them but not do their work.

The above, plus the following thoughts _at that point in time_, are 
exactly what triggered my action:
     - there is clear demand for YANG models in the industry, but we 
need to gain momentum.
     - the industry/vendors can't agree ("There is an OSPF module which 
is quite Cisco specific")
     - NETMOD is not the right place for all the YANG models, because we 
don't have the technology expertise. And the other WGs don't have the 
YANG expertise.
     - the IETF is an important point in its life, with more and more 
people going to open source to avoid the heavier consensus-based SDO 
such as the IETF,
       typically opendaylight producing a lot of proprietary YANG models
    - At that time, there were no interest to standardize YANG models in 
the routing WGs.

 From there, I tried to evaluate the willingness from vendors to work 
together. I made an experiment with 3 YANG models (syslog, OSPF, and 
ACL) and 3 companies (Brocade, Juniper, Cisco). See this as closed 
author teams if you want to. IMO, the experiment has been successful.
See http://datatracker.ietf.org/doc/draft-bogdanovic-netmod-acl-model/
See http://datatracker.ietf.org/doc/draft-wildes-netmod-syslog-model/
_What I regret_, and this was mentioned to the authors: there is no 
update of http://tools.ietf.org/html/draft-yeung-netmod-ospf-01, so it 
might be perceived as: the work was abandoned or not open. However, work 
was done to first review and improve the base routing model (Lada is 
point of contact here), and to try to come up with a consistent approach 
for routing (VRF versus protocol centric view) among vendors.

At the last IETF, I've been open, and I explained those closed design teams:
     - to the routing ADs
     - to the IESG
     - during the ///YANG/ Advice and /Editing Session/ 
<http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCAQFjAA&url=http%3A%2F%2Fwww.ietf.org%2Fmeeting%2F90%2Ftutorials%2Fyang-session.html&ei=fZcoVJuaBIuwyASahIKgAg&usg=AFQjCNFwMZaR904mfhpa8RX196v_CFB6RA&bvm=bv.76247554,d.aWw>
     - to the NETMOD WG:
             See "Accelerated  Development" in the meeting minutes 
(http://www.ietf.org/proceedings/90/minutes/minutes-90-netmod)
             See the slides: 
http://www.ietf.org/proceedings/90/slides/slides-90-netmod-5.pdf

What next? (copied from slides 6 of the above presentation)
     Open up and scale up these design teams
     We will be soliciting the next set of YANG models
     The YANG editing session was a first step to list the existing YANG 
models
     Goal: Stretch goal to publish YANG model RFCs within a year
     Where? In the different WGs or in NETMOD (charter is now open)

I'm exactly in that process of collecting the interesting YANG models 
the vendors want to work on.
Why a focus on the vendors? Because I want to focus on the device-level, 
protocol-specific YANG models (the building blocks). Not the services ones.
These days, I'm compiling the list of interesting YANG models from 
multiple vendors: Juniper, Brocade, Huawei, Ericsson, Ciena, ALU, and 
Cisco. More companies are obviously welcome. The findings will be 
shared, don't worry.
 From here, the different WGs (not speaking about routing specifically) 
should organize official design teams, organized by the WG chair. For 
example, to create the version 00 of the draft. Based on my experience 
from those closed design teams, what worked well, and should be followed 
IMO.
     - one point of contact per company to work on the draft (too many 
authors dilutes the responsibility
     - this point of contact should be close the development team
     - ideally, these should different people for the different YANG 
models (we want this process to scale)
     - weekly webex proved to work efficiently
     - a willingness to implement (we learn a lot from implementation)

Is this NETMOD taking over the world of YANG models standardization?
Certainly not. My goal is to get the right experts together.
Coming back to the OSPF model, the experts are not NETMOD expert: Kent 
Leung, Dean Bogdanovic, Kiran Koushik. As you can see, these are not the 
tyipcal YANG experts in the NETMOD WG.
Also, In order to facilitate their work, I have assign a YANG doctor. 
See http://www.ietf.org/iesg/directorate/yang-doctors.html -> YANG 
review assignments 
<http://trac.tools.ietf.org/area/ops/trac/wiki/yang-doctors-review-history>
Where should these YANG models be standardized? Honestly, I don't care, 
as long as we right the right experts. Ideally they should be 
standardized in the respective WGs. Note that the NETMOD charter has 
been open to welcome the YANG models that don't have an appropriate home 
(example: syslog)

As you can see, no willingness to hide anything with this fast-track, 
simply an OPS AD who humbly tries to organize an industry/vendors/a 
community to work together. I have not coordinated enough I2RS (and I 
don't follow the I2RS mailing list, it's just archived in a folder but 
recently I had to read it :-) ), that's probably a mistake. On the other 
hand, from what I can see from the different vendors, there is a 
willingness to implement non I2RS/routing YANG models: QoS,  VLAN, AAA. 
So why warn only the I2RS WG on the not the rest of the community?
Btw, I believe that creating this mailing list for routing YANG models 
coordination would be a plus.

Regards, Benoit (OPS AD)

> Thomas,
>
> On Mon, Sep 29, 2014 at 2:44 PM, Thomas Narten <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> First, I have been encouraging the routing WGs to work on and consider 
> YANG models.
> I have been quite clear in discussing with Benoit that they should be 
> homed in the Routing
> area and that I don't think it makes sense to create a separate 
> working group to just work
> on YANG models.
>
> more limited models than would be used for configuration of a 
> particular protocol.  A reasonable
> approach could be doing the I2RS-specific models in I2RS and having 
> them cross-reviewed in
> It would allow review of the interactions between the different models 
> for their I2RS aspects (assuming
> (draft-yeung-netmod-ospf-01) for an OSPF configuration YANG model.  
> This was discussed in OSPF last IETF.  I agree that the updated draft, 
> when posted, is likely to be an excellent candidate for the OSPF WG.
>
> draft-yeung-netmod-ospf-01 or who may have been going behind the 
> scenes pushing and encouraging (and I am also quite happy and eager 
> and encouraging to see good YANG models for routing functionality), 
> this is not an official design team
> effort.
>
> Deliberately writing a competing draft may not be constructive.  That 
> is not what happened here and
> individual draft that was written to solve a different problem and 
> asking for someone  who had done work to produce a draft towards a 
> different problem that caused me to be extremely displeased.
>
>  I realize that one of the topics of discussion since the netmod 
> interim has been whether it makes sense to have one YANG model that 
> can be used by NetConf and I2RS for writing and reading.  However, I 
> have not heard discussed much less agreed upon that approach in I2RS 
> and it is inappropriate to presuppose the answer and punt work that it 
> is quite reasonable to assume (and examine to determine) will move the 
> WG forward.
>
> Please let's not try to conflate one specific case with its own 
> concerns with
> are individuals, whom were encouraged to work together, but that does 
> not make it
> a design team.  IFF there were an announced WG Design Team and IFF 
> there were
> consensus in I2RS that I2RS would use exactly the same YANG models, 
> then this
> point might hold water.   Since neither are the case, I do not believe 
> that it does so.
>

---

From: Joe Clarke <[email-masked]>
Date: Tue, 30 Sep 2014 16:55:27 -0400

> By shoe dropping - I think you mean accepted of the traceability as WG

Yes, that is correct.  We had a few signs of support, and Carlos sent an 
email out copying the chairs explicitly, but we have not heard anything 
back.

Joe

---

From: Joe Clarke <[email-masked]>
Date: Tue, 30 Sep 2014 16:58:38 -0400

> call.  We saw good support for the idea that traceability is something we

We (the authors) believe this is a separate document based on the 
previous comments.  Aside from the open questions concerning the 
ephemeral data stores, we still feel the architecture draft is 
well-baked and sets the stage nicely for this additional document.

However, as you point out, this is a question for the WG to answer. 
But, should we ask it in Honolulu via an agenda item, or is this 
something the chairs will ask in a general agenda section (as was kind 
of done in Toronto)?

Joe