Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)

[Kent Watsen]

The last call on this draft has ended!  Thank you everyone who participated.  
There doesn’t seem to be consensus to adopt my proposal to move the -state tree 
to another module, and so we will call it rough consensus in favor of 
publishing the document as it is.   This document will be moved to the ‘WG 
Consensus: Waiting for Write-Up’ working group state shortly; the shepherd will 
take it from there.

Thanks,
Kent (and Lou)

From: netmod <netmod-boun...@ietf.org> on behalf of Kent Watsen 
<kwat...@juniper.net>
Date: Friday, August 26, 2016 at 1:54 PM
To: "netmod@ietf.org" <netmod@ietf.org>
Subject: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 
9, 2016)


This is a notice to start a two-week NETMOD WG last call for the document:

A YANG Data Model for Routing Management
https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-23

Please indicate your support or concerns by Thursday September 9, 2016.

We are not only interested in receiving defect reports, we are equally 
interested in statements of the form:

  * I have reviewed draft-ietf-netmod-routing-cfg-23 and I found no issues
  * I have implemented the data model in draft-ietf-netmod-routing-cfg-23
  * I am implementing the data model in draft-ietf-netmod-routing-cfg-23
  * I am considering to implement the data model in 
draft-ietf-netmod-routing-cfg-23

Of course, these are merely suggestions, folks can provide comments in any form 
that suits them.


Thank you,

NETMOD WG Chairs


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)

[Ladislav Lhotka]

Kent Watsen  writes:

>>Then you probably already know what the solution is going to be. I don't.
>
> It’s not that I know the exact solution.  It’s that I see this
> approach offering good options for graceful migration to an opstate
> compliant solution (for which I’m on the design team alias), without
> incurring any modelling cost, other than there being an additional
> module.  I additionally see this approach as more flexible in that, as
> you said, it would allow one module to be updated without disturbing
> the other.

The data modelling cost of splitting config and state data into
separate modules IMO is that it weakens the concept of system- and
user-controlled objects. I understand that some folks don't like it but
I am still not convinced that anything better is readily available.

And then of course another cost is that all modules depending on
ietf-routing need to be updated accordingly. So IMO we should think
twice before making this change. I would appreciate more opinions on it.

Lada

>
>
>> Anyway, if the consensus was to split config and state data into separate 
>> modules, we would have to tell all module developers who build upon the core 
>> routing model to split their augments into config and state parts as well, 
>> because otherwise the change to ietf-routing would be useless.  
>
> Yes, indeed, this would be the primary consequence.
>
>
>>Lada
>
> Kent
>
>

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)

[Kent Watsen]

>Then you probably already know what the solution is going to be. I don't.

It’s not that I know the exact solution.  It’s that I see this approach 
offering good options for graceful migration to an opstate compliant solution 
(for which I’m on the design team alias), without incurring any modelling cost, 
other than there being an additional module.  I additionally see this approach 
as more flexible in that, as you said, it would allow one module to be updated 
without disturbing the other.


> Anyway, if the consensus was to split config and state data into separate 
> modules, we would have to tell all module developers who build upon the core 
> routing model to split their augments into config and state parts as well, 
> because otherwise the change to ietf-routing would be useless.  

Yes, indeed, this would be the primary consequence.


>Lada

Kent


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)

[Ladislav Lhotka]

Rob Shakir  writes:

> Hi Kent, NETMOD,
>
> On Fri, Aug 26, 2016 at 10:54 AM, Kent Watsen  wrote:
>
>>
>>
>>
>>
>> Please indicate your support or concerns by Thursday September 9, 2016.
>>
>>
>>
>> We are not only interested in receiving defect reports, we are equally
>> interested in statements of the form:
>>
>>
>>
>>   * I have reviewed draft-ietf-netmod-routing-cfg-23 and I found no issues
>>
>>   * I have implemented the data model in draft-ietf-netmod-routing-cfg-23
>>
>>   * I am implementing the data model in draft-ietf-netmod-routing-cfg-23
>>
>>   * I am considering to implement the data model in
>> draft-ietf-netmod-routing-cfg-23
>>
>
> I'd like to add a new category to this set of statements:
>
>  * I have reviewed this draft, and will *not* be implementing the data
> model described within it.

Fair enough.

>
> I have concerns with the contents of this model and their suitability as a
> base for the wider set of models that are intended to augment it. Indeed, I
> think the elements that it tackles (e.g., arrangement of protocols within a
> routing instance) are very much lowest common denominator, and none of the
> wider issues around multi-tenancy of routing instances (especially those
> that mix VSI and VRF type semantics) on an individual device, or the way
> that protocols map to RIBs, and how they then interact/interconnect are
> tackled within the model.
>
> Whilst I understand the difficulties that the authors have been through to
> try and find a solution, I'm afraid that consensus here has led to a model
> that actually is operationally a no-op -- even the configuration for static
> routing is not sufficient for most operator use cases that we have examined
> when working on a similar problem space.

Earlier revisions of the draft (such as -16) contained more stuff that
really implemented something (framework for route filters, explicit connection 
of
routing protocols to RIBs, fancy next-hops). All of them were removed,
mainly because they aren't the lowest common denominator.

Nonetheless, I don't think that what remains is a no-op. The core
routing model does define a framework in which multiple instances of
routing protocols can coexist. And it also implements an approach to
configuration versus state data analogical to RFC 7223 (which you
probably don't like).

As for static routing, I believe it perfectly suffices for hosts and
simpler router configurations. As a proof of concept, I myself wrote
XSLT stylesheets that were able to convert this data to CLI
configurations for Cisco IOS and BIRD routing daemon. It may not be
sufficient for all use cases, but then nothing prevents you or anybody
else from developing a data model for a new "static-on-steroids"
protocol, and fit it into the core routing model.

Lada

>
> Based on this, and the lack of examination of real configurations of
> network elements to the model described within the draft, I would oppose
> progressing this model to RFC until such time as it has been proved to
> cover a operationally viable set of functionality, and there can be any
> level of confidence that further changes to the model will not be
> immediately needed to be able to accommodate the use cases that are
> required of it.  Given the historical opposition to revising models once
> they have been cast as RFCs that we have seen within the IETF, then I feel
> that avoiding incomplete models going to RFC is the best course of action.
>
> Thanks,
> r.
>
> [0]: Please note: I am speaking as an individual here, not on behalf of any
> wider set of view points.
> [1]: Please further note: This opposition to publishing this document
> completely ignores the issue of operational state. I have made my thoughts
> clear on this previously, but these comments are entirely orthogonal to
> that opposition.
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)

[Rob Shakir]

Hi Kent, NETMOD,

On Fri, Aug 26, 2016 at 10:54 AM, Kent Watsen  wrote:

>
>
>
>
> Please indicate your support or concerns by Thursday September 9, 2016.
>
>
>
> We are not only interested in receiving defect reports, we are equally
> interested in statements of the form:
>
>
>
>   * I have reviewed draft-ietf-netmod-routing-cfg-23 and I found no issues
>
>   * I have implemented the data model in draft-ietf-netmod-routing-cfg-23
>
>   * I am implementing the data model in draft-ietf-netmod-routing-cfg-23
>
>   * I am considering to implement the data model in
> draft-ietf-netmod-routing-cfg-23
>

I'd like to add a new category to this set of statements:

 * I have reviewed this draft, and will *not* be implementing the data
model described within it.

I have concerns with the contents of this model and their suitability as a
base for the wider set of models that are intended to augment it. Indeed, I
think the elements that it tackles (e.g., arrangement of protocols within a
routing instance) are very much lowest common denominator, and none of the
wider issues around multi-tenancy of routing instances (especially those
that mix VSI and VRF type semantics) on an individual device, or the way
that protocols map to RIBs, and how they then interact/interconnect are
tackled within the model.

Whilst I understand the difficulties that the authors have been through to
try and find a solution, I'm afraid that consensus here has led to a model
that actually is operationally a no-op -- even the configuration for static
routing is not sufficient for most operator use cases that we have examined
when working on a similar problem space.

Based on this, and the lack of examination of real configurations of
network elements to the model described within the draft, I would oppose
progressing this model to RFC until such time as it has been proved to
cover a operationally viable set of functionality, and there can be any
level of confidence that further changes to the model will not be
immediately needed to be able to accommodate the use cases that are
required of it.  Given the historical opposition to revising models once
they have been cast as RFCs that we have seen within the IETF, then I feel
that avoiding incomplete models going to RFC is the best course of action.

Thanks,
r.

[0]: Please note: I am speaking as an individual here, not on behalf of any
wider set of view points.
[1]: Please further note: This opposition to publishing this document
completely ignores the issue of operational state. I have made my thoughts
clear on this previously, but these comments are entirely orthogonal to
that opposition.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)

[Ladislav Lhotka]

> On 02 Sep 2016, at 21:30, Kent Watsen <kwat...@juniper.net> wrote:
> 
> It holds.  Some have FUD.  I do not.

Then you probably already know what the solution is going to be. I don't.

Anyway, if the consensus was to split config and state data into separate 
modules, we would have to tell all module developers who build upon the core 
routing model to split their augments into config and state parts as well, 
because otherwise the change to ietf-routing would be useless.  

Lada

> 
> K.
> 
> 
> On 9/2/16, 4:35 AM, "Ladislav Lhotka" <lho...@nic.cz> wrote:
> 
>Hi Stephane,
> 
>if we do any changes to the core routing module, then I am afraid all 
> modules that depend on it will have to follow suit. In particular, if we put 
> config and state data into separate modules, protocol modules should do the 
> same.
> 
>I don't like the idea of putting the core routing model and all work that 
> depends on it on hold until we reach a decision regarding opstate. So, *if* 
> the separation of config and state data gives a reasonable guarantee that at 
> least the config part will be compatible with the ultimate opstate solution 
> (whatever it is), it IMO makes sense to do it. But I am not even sure that 
> the premise holds.
> 
>Lada
> 
>> On 02 Sep 2016, at 10:16, <stephane.litkow...@orange.com> 
>> <stephane.litkow...@orange.com> wrote:
>> 
>> Hi,
>> 
>> As this model is a base for multiple routing modules, it would be good to 
>> align the op-state modeling between this model and the existing routing 
>> related modules (so we can also close the work on multiple routing yang 
>> models).
>> So if core routing model uses foo:/foo foo:/foo-state, do we keep this 
>> modeling also for our protocol models and close the work ? 
>> 
>> Best Regards,
>> 
>> Stephane
>> 
>> 
>> -Original Message-----
>> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Juergen 
>> Schoenwaelder
>> Sent: Wednesday, August 31, 2016 20:41
>> To: Kent Watsen
>> Cc: netmod@ietf.org
>> Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 
>> (until Sep 9, 2016)
>> 
>> On Wed, Aug 31, 2016 at 06:11:14PM +, Kent Watsen wrote:
>>> [as a contributor]
>>> 
>>> My only comment on this draft is that I’d prefer it if the “routing-state” 
>>> tree were moved into another YANG module, so that it could be more easily 
>>> deprecated when the opstate solution comes.   I suggested this before, with 
>>> regards to rfc6087bis Section 5.23, but that thread seemed to have petered 
>>> out, but now here we are and my opinion remains the same.
>>> 
>> 
>> We already have foo:/foo /foo:foo-state modules and while we can now start a 
>> series of foo:/foo and foo-state:/foo-state modules in the hope that this 
>> will eventually 'easier' in the future, it might also be that we just create 
>> more variation and confusion.
>> 
>> /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/>
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> 
>> _
>> 
>> Ce message et ses pieces jointes peuvent contenir des informations 
>> confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
>> ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
>> electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
>> falsifie. Merci.
>> 
>> This message and its attachments may contain confidential or privileged 
>> information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and 
>> delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been 
>> modified, changed or falsified.
>> Thank you.
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> 
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
> 
> 
> 
> 
> 
> 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)

[Kent Watsen]

Amendment: previous message as a contributor.  

K.


On 9/2/16, 3:30 PM, "netmod on behalf of Kent Watsen" <netmod-boun...@ietf.org 
on behalf of kwat...@juniper.net> wrote:

It holds.  Some have FUD.  I do not.

K.


On 9/2/16, 4:35 AM, "Ladislav Lhotka" <lho...@nic.cz> wrote:

Hi Stephane,

if we do any changes to the core routing module, then I am afraid all 
modules that depend on it will have to follow suit. In particular, if we put 
config and state data into separate modules, protocol modules should do the 
same.

I don't like the idea of putting the core routing model and all work 
that depends on it on hold until we reach a decision regarding opstate. So, 
*if* the separation of config and state data gives a reasonable guarantee that 
at least the config part will be compatible with the ultimate opstate solution 
(whatever it is), it IMO makes sense to do it. But I am not even sure that the 
premise holds.

Lada

> On 02 Sep 2016, at 10:16, <stephane.litkow...@orange.com> 
<stephane.litkow...@orange.com> wrote:
> 
> Hi,
> 
> As this model is a base for multiple routing modules, it would be 
good to align the op-state modeling between this model and the existing routing 
related modules (so we can also close the work on multiple routing yang models).
> So if core routing model uses foo:/foo foo:/foo-state, do we keep 
this modeling also for our protocol models and close the work ? 
> 
> Best Regards,
> 
> Stephane
> 
> 
> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Juergen 
Schoenwaelder
> Sent: Wednesday, August 31, 2016 20:41
    > To: Kent Watsen
    > Cc: netmod@ietf.org
    > Subject: Re: [netmod] WG Last Call for 
draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)
> 
> On Wed, Aug 31, 2016 at 06:11:14PM +, Kent Watsen wrote:
>> [as a contributor]
>> 
>> My only comment on this draft is that I’d prefer it if the 
“routing-state” tree were moved into another YANG module, so that it could be 
more easily deprecated when the opstate solution comes.   I suggested this 
before, with regards to rfc6087bis Section 5.23, but that thread seemed to have 
petered out, but now here we are and my opinion remains the same.
>> 
> 
> We already have foo:/foo /foo:foo-state modules and while we can now 
start a series of foo:/foo and foo-state:/foo-state modules in the hope that 
this will eventually 'easier' in the future, it might also be that we just 
create more variation and confusion.
> 
> /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/>
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 
> 
_
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous 
avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les 
messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, 
deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or 
privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender 
and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have 
been modified, changed or falsified.
> Thank you.
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C






___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)

[Kent Watsen]

It holds.  Some have FUD.  I do not.

K.


On 9/2/16, 4:35 AM, "Ladislav Lhotka" <lho...@nic.cz> wrote:

Hi Stephane,

if we do any changes to the core routing module, then I am afraid all 
modules that depend on it will have to follow suit. In particular, if we put 
config and state data into separate modules, protocol modules should do the 
same.

I don't like the idea of putting the core routing model and all work that 
depends on it on hold until we reach a decision regarding opstate. So, *if* the 
separation of config and state data gives a reasonable guarantee that at least 
the config part will be compatible with the ultimate opstate solution (whatever 
it is), it IMO makes sense to do it. But I am not even sure that the premise 
holds.

Lada

> On 02 Sep 2016, at 10:16, <stephane.litkow...@orange.com> 
<stephane.litkow...@orange.com> wrote:
> 
> Hi,
> 
> As this model is a base for multiple routing modules, it would be good to 
align the op-state modeling between this model and the existing routing related 
modules (so we can also close the work on multiple routing yang models).
> So if core routing model uses foo:/foo foo:/foo-state, do we keep this 
modeling also for our protocol models and close the work ? 
> 
> Best Regards,
> 
> Stephane
> 
> 
> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Juergen 
Schoenwaelder
> Sent: Wednesday, August 31, 2016 20:41
    > To: Kent Watsen
    > Cc: netmod@ietf.org
    > Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 
(until Sep 9, 2016)
> 
> On Wed, Aug 31, 2016 at 06:11:14PM +, Kent Watsen wrote:
>> [as a contributor]
>> 
>> My only comment on this draft is that I’d prefer it if the 
“routing-state” tree were moved into another YANG module, so that it could be 
more easily deprecated when the opstate solution comes.   I suggested this 
before, with regards to rfc6087bis Section 5.23, but that thread seemed to have 
petered out, but now here we are and my opinion remains the same.
>> 
> 
> We already have foo:/foo /foo:foo-state modules and while we can now 
start a series of foo:/foo and foo-state:/foo-state modules in the hope that 
this will eventually 'easier' in the future, it might also be that we just 
create more variation and confusion.
> 
> /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/>
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 
> 
_
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 
recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme 
ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged 
information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and 
delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have 
been modified, changed or falsified.
> Thank you.
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C






___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)

[Ladislav Lhotka]

Hi Stephane,

if we do any changes to the core routing module, then I am afraid all modules 
that depend on it will have to follow suit. In particular, if we put config and 
state data into separate modules, protocol modules should do the same.

I don't like the idea of putting the core routing model and all work that 
depends on it on hold until we reach a decision regarding opstate. So, *if* the 
separation of config and state data gives a reasonable guarantee that at least 
the config part will be compatible with the ultimate opstate solution (whatever 
it is), it IMO makes sense to do it. But I am not even sure that the premise 
holds.

Lada

> On 02 Sep 2016, at 10:16, <stephane.litkow...@orange.com> 
> <stephane.litkow...@orange.com> wrote:
> 
> Hi,
> 
> As this model is a base for multiple routing modules, it would be good to 
> align the op-state modeling between this model and the existing routing 
> related modules (so we can also close the work on multiple routing yang 
> models).
> So if core routing model uses foo:/foo foo:/foo-state, do we keep this 
> modeling also for our protocol models and close the work ? 
> 
> Best Regards,
> 
> Stephane
> 
> 
> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Juergen 
> Schoenwaelder
> Sent: Wednesday, August 31, 2016 20:41
> To: Kent Watsen
> Cc: netmod@ietf.org
> Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 
> (until Sep 9, 2016)
> 
> On Wed, Aug 31, 2016 at 06:11:14PM +, Kent Watsen wrote:
>> [as a contributor]
>> 
>> My only comment on this draft is that I’d prefer it if the “routing-state” 
>> tree were moved into another YANG module, so that it could be more easily 
>> deprecated when the opstate solution comes.   I suggested this before, with 
>> regards to rfc6087bis Section 5.23, but that thread seemed to have petered 
>> out, but now here we are and my opinion remains the same.
>> 
> 
> We already have foo:/foo /foo:foo-state modules and while we can now start a 
> series of foo:/foo and foo-state:/foo-state modules in the hope that this 
> will eventually 'easier' in the future, it might also be that we just create 
> more variation and confusion.
> 
> /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/>
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 
> _
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)

[stephane.litkowski]

Hi,

As this model is a base for multiple routing modules, it would be good to align 
the op-state modeling between this model and the existing routing related 
modules (so we can also close the work on multiple routing yang models).
So if core routing model uses foo:/foo foo:/foo-state, do we keep this modeling 
also for our protocol models and close the work ? 

Best Regards,

Stephane


-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, August 31, 2016 20:41
To: Kent Watsen
Cc: netmod@ietf.org
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until 
Sep 9, 2016)

On Wed, Aug 31, 2016 at 06:11:14PM +, Kent Watsen wrote:
> [as a contributor]
> 
> My only comment on this draft is that I’d prefer it if the “routing-state” 
> tree were moved into another YANG module, so that it could be more easily 
> deprecated when the opstate solution comes.   I suggested this before, with 
> regards to rfc6087bis Section 5.23, but that thread seemed to have petered 
> out, but now here we are and my opinion remains the same.
>

We already have foo:/foo /foo:foo-state modules and while we can now start a 
series of foo:/foo and foo-state:/foo-state modules in the hope that this will 
eventually 'easier' in the future, it might also be that we just create more 
variation and confusion.

/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/>

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)

[Juergen Schoenwaelder]

On Wed, Aug 31, 2016 at 06:11:14PM +, Kent Watsen wrote:
> [as a contributor]
> 
> My only comment on this draft is that I’d prefer it if the “routing-state” 
> tree were moved into another YANG module, so that it could be more easily 
> deprecated when the opstate solution comes.   I suggested this before, with 
> regards to rfc6087bis Section 5.23, but that thread seemed to have petered 
> out, but now here we are and my opinion remains the same.
>

We already have foo:/foo /foo:foo-state modules and while we can now
start a series of foo:/foo and foo-state:/foo-state modules in the
hope that this will eventually 'easier' in the future, it might also
be that we just create more variation and confusion.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)

[Kent Watsen]

[as a contributor]

My only comment on this draft is that I’d prefer it if the “routing-state” tree 
were moved into another YANG module, so that it could be more easily deprecated 
when the opstate solution comes.   I suggested this before, with regards to 
rfc6087bis Section 5.23, but that thread seemed to have petered out, but now 
here we are and my opinion remains the same.

Thanks,
Kent

From: netmod <netmod-boun...@ietf.org> on behalf of Kent Watsen 
<kwat...@juniper.net>
Date: Friday, August 26, 2016 at 1:54 PM
To: "netmod@ietf.org" <netmod@ietf.org>
Subject: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 
9, 2016)


This is a notice to start a two-week NETMOD WG last call for the document:

A YANG Data Model for Routing Management
https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-23

Please indicate your support or concerns by Thursday September 9, 2016.

We are not only interested in receiving defect reports, we are equally 
interested in statements of the form:

  * I have reviewed draft-ietf-netmod-routing-cfg-23 and I found no issues
  * I have implemented the data model in draft-ietf-netmod-routing-cfg-23
  * I am implementing the data model in draft-ietf-netmod-routing-cfg-23
  * I am considering to implement the data model in 
draft-ietf-netmod-routing-cfg-23

Of course, these are merely suggestions, folks can provide comments in any form 
that suits them.


Thank you,

NETMOD WG Chairs


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)

[Kent Watsen]

This is a notice to start a two-week NETMOD WG last call for the document:

A YANG Data Model for Routing Management
https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-23

Please indicate your support or concerns by Thursday September 9, 2016.

We are not only interested in receiving defect reports, we are equally 
interested in statements of the form:

  * I have reviewed draft-ietf-netmod-routing-cfg-23 and I found no issues
  * I have implemented the data model in draft-ietf-netmod-routing-cfg-23
  * I am implementing the data model in draft-ietf-netmod-routing-cfg-23
  * I am considering to implement the data model in 
draft-ietf-netmod-routing-cfg-23

Of course, these are merely suggestions, folks can provide comments in any form 
that suits them.


Thank you,

NETMOD WG Chairs


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod