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 +0000, 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
