On 6/10/2017 5:42 AM, Kent Watsen wrote:

Yes, let's rewrite 6.23 completely to state more helpfully what's in the guidelines draft.

I don't expect the guidelines doc is going to progress independently.
Agreed.

Regards, B.

Kent. // shepherd


On Jun 9, 2017, at 1:06 PM, Andy Bierman <a...@yumaworks.com <mailto:a...@yumaworks.com>> wrote:

Hi,

I am trying to complete rfc6087bis.
It has been held up waiting for this draft.
It is not clear to me how sec. 6.23 (Operational Data) needs to change.
Should the whole section be replaced by an informative reference to this new draft?


Andy


On Fri, Jun 9, 2017 at 6:56 AM, Benoit Claise <bcla...@cisco.com <mailto:bcla...@cisco.com>> wrote:

    Dear all,

    Now that the new NETMOD and NETCONF charters have been approved,
    it's time to think about the guidelines for YANG module authors.

    The Network Management Datastore Architecture (NMDA) addresses
    the so-called "OpState problem" that has been the subject of much
    discussion in the IETF. NMDA is still in development, and there
    will be a transition period before NMDA solutions are universally
    available.

    The NETMOD Datastore Design Team and the Routing Yang
    Architecture Design Team have worked with Alia and Benoit to
    create initial guidelines for how the NMDA, as defined in
    draft-ietf-netmod-revised-datastores
    <https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/>,
    impacts Yang models. The draft-dsdt-nmda-guidelines
    <https://datatracker.ietf.org/doc/draft-dsdt-nmda-guidelines/>
    individual draft was foundational in helping creating those
    guidelines.

    If you have questions or concerns on how these guidelines should
    apply to work of interest, please contact your WG Chairs or ADs.

    It is our strong recommendation, as ADs with agreement from the
    NETMOD WG Chairs, that models SHOULD move as quickly as possible
    to the NMDA. The specific approach to be taken for models being
    developed now and during the NMDA transition period should be
    based on both the expected usage and the maturity of the data model.

    1. New models and models that are not concerned with the
    operational state of configuration information SHOULD immediately
    be structured to be NMDA-compatible.

    2. Models that require immediate support for "in use" and "system
    created" information SHOULD be structured for NMDA. Then derived
    versions of these models SHOULD be created, either by hand or
    with suitable tools, that follow the current modeling strategies.
    In some cases, the non-NMDA model may be an existing model and
    not derived from the NMDA model. In all cases, the NMDA and
    non-NMDA modules SHOULD be published in the same document, with
    NMDA modules in the document main body and the non-NMDA modules
    in an Appendix. The use of the non-NMDA model will allow
    temporary bridging of the time period until NMDA implementations
    are available. The non-NMDA module names should include ’-state’
    appended.

    We would like to thank Kent Watsen, Lou Berger, Rob Wilton,
    Martin Bjorklund, Phil Shafer, Acee Lindem, Chris Hopps, Juergen
    Schoenwaelder, and all others who helped develop these guidelines.

    Regards,
    Alia Atlas, Routing AD
    Deborah Brungard, Routing AD
    Alvaro Retana, Routing AD
    Warren Kumari, Operations & Management AD
    Benoit Claise, Operations & Management AD

    _______________________________________________
    netmod mailing list
    netmod@ietf.org <mailto:netmod@ietf.org>
    https://www.ietf.org/mailman/listinfo/netmod
    <https://www.ietf.org/mailman/listinfo/netmod>


_______________________________________________
netmod mailing list
netmod@ietf.org <mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod

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

Reply via email to