Re: I-D Action: draft-ietf-rtgwg-yang-vrrp-05.txt

[Robert Wilton <[e-mail]>]

Hi draft-ietf-rtgwg-yang-vrrp draft authors,

I have a couple of comments on the latest revision of this draft:

1) The top level "vrrp container" has the right name, but can be "config 
false" since it doesn't hold any configuration today. This is noting 
that RFC 7950 allows the "vrrp container" to become "config true" as a 
backwards compatible change in future if required.

2) I've also noticed that this draft defined two separate versions of 
the VRRP YANG module.  The second version in the appendix is for 
pre-NMDA implementations:

    <CODE BEGINS> file "[e-mail]"
    module ietf-vrrp {
      yang-version 1.1;
      namespace "urn:ietf:params:xml:ns:yang:ietf-vrrp";
      prefix "vrrp";

And
    <CODE BEGINS> file "[e-mail]"
    module ietf-vrrp {
      yang-version 1.1;
      namespace "urn:ietf:params:xml:ns:yang:ietf-vrrp";
      prefix "vrrp";

Generically, I don't think that it is a good idea to define two versions 
of the same YANG module in one draft.

If a backwards compatible NMDA version of a module is required, then an 
extra "-state" module should be put in the appendix instead (e.g. 
[e-mail]).  This "-state" module could be used in 
conjunction with [e-mail] until NMDA implementations 
are available.

Alternatively, if you must define an existing pre NMDA version of the 
VRRP module then it should definitely be given a different module name, 
e.g. [e-mail].  But I believe that this 
would be an inferior solution since, compared to a separate "-state" 
module, it will make it harder for clients to migrate to the NMDA 
modules in future.

Finally, having actually read at the main VRRP module, then on the 
assumption that VRRP is always configured before it is used, then the 
"NMDA version" may well be sufficient to use on both existing NETCONF 
implementations and NMDA compatible NETCONF implementations.  The only 
thing that you can't see when using the NMDA version of the module on a 
"pre NMDA" implementation is the applied VRRP configuration.  Whether 
this is important enough to not define the extra "-state" module is 
unclear, but my instinct would be that it is better to just leave it out.

Thanks,
Rob


On 30/09/2017 15:12, [e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Routing Area Working Group WG of the IETF.
>
>          Title           : A YANG Data Model for Virtual Router Redundancy Protocol (VRRP)
>          Authors         : Xufeng Liu
>                            Athanasios Kyparlis
>                            Ravi Parikh
>                            Acee Lindem
>                            Mingui Zhang
> 	Filename        : draft-ietf-rtgwg-yang-vrrp-05.txt
> 	Pages           : 68
> 	Date            : 2017-09-30
>
> Abstract:
>     This document describes a data model for Virtual Router Redundancy
>     Protocol (VRRP).  Both version 2 and version 3 of VRRP are covered.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-vrrp/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-rtgwg-yang-vrrp-05
> https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-yang-vrrp-05
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-yang-vrrp-05
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> rtgwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtgwg
> .
>