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

Amendment: previous message as a contributor.  

K.

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

    It holds.  Some have FUD.  I do not.

    K.

    On 9/2/16, 4:35 AM, "Ladislav Lhotka" <lhotka@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.litkowski@orange.com> <stephane.litkowski@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-bounces@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