Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-rfc7277bis-00.txt

From: Robert Wilton <[email-masked]>
Date: Fri, 1 Sep 2017 17:34:02 +0100

Hi Martin,

I have reviewed this document (mainly as a diff against the 7277).

In summary, the transformation to NMDA looks good.   Given that it is a 
fairly formulaic conversion, I hope that the WG will be able to quickly 
move to WG adoption, and even WG last call!

I did have a few minor comments (and spotted one bug):

1. leaf "origin" under IPv4 neighbors should be marked as "config false".

2. Sometimes the YANG module description refers to "the intended 
configuration datastore" or "the operational state datastore", but I 
think that it would be better to just refer to "intended configuration" 
and "operational state".  I.e. I think that it is OK for the draft to 
reference the different datastores, but I think that it might be better 
if the YANG modules don't.  This is partly in the sense that the YANG 
modules are just schema for configuration and state data, and that I see 
the use of datastores is effectively an IETF decision on how that 
configuration/state is instantiated.

To take the analogy further, I think that the it is conceivable that the 
source OpenConfig YANG models could also be usefully structured in the 
same NMDA style.  This would allow the OpenConfig models to work better 
with NETCONF/RESTCONF implementations that support NMDA.  An alternative 
implementation choice would be to use a script to convert NMDA style 
OpenConfig YANG models to equivalent existing OpenConfig style with 
their split config/state containers.

A second justification (if you don't like the one above), is that the 
configurable leaves could also be set via a dynamic configuration 
datastore such as via I2RS, hence it wouldn't necessarily always be via 
the intended datastore.

3. I think that it might be useful to add a comment to the IPv6 
link-layer-address leaf description to indicate that it wouldn't expect 
to be populated if the associated "state" is set to "incomplete".

Thanks,
Rob

On 21/08/2017 13:06, Martin Bjorklund wrote:
> Hi,
>
> This document defines an NMDA-compliant update to the IP model
> (RFC 7277).
>
> I would like to ask the WG to adopt this individual draft as a working
> group document.
>
>
> /martin
>
>
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 04 Sep 2017 10:14:59 +0200 (CEST)

Hi,

Thanks for reviewing this document!

Robert Wilton <[email-masked]> wrote:
> In summary, the transformation to NMDA looks good.   Given that it is
> a fairly formulaic conversion, I hope that the WG will be able to
> quickly move to WG adoption, and even WG last call!
> 
> 

Fixed.

> think that it would be better to just refer to "intended
> configuration" and "operational state".

Yes I agree, and I actually inteded to use the term "intended
configuration" and "operational state", but missed that.

The terminology should be aligned in all our documents, so I'll make
sure to use this terminology also in the hardware (entity) draft, and
the interfaces draft.

>   I.e. I think that it is OK
> for the draft to reference the different datastores, but I think that
> it might be better if the YANG modules don't.  This is partly in the
> sense that the YANG modules are just schema for configuration and
> state data, and that I see the use of datastores is effectively an
> IETF decision on how that configuration/state is instantiated.
> 
> To take the analogy further, I think that the it is conceivable that
> the source OpenConfig YANG models could also be usefully structured in
> the same NMDA style.  This would allow the OpenConfig models to work
> better with NETCONF/RESTCONF implementations that support NMDA.  An
> alternative implementation choice would be to use a script to convert
> NMDA style OpenConfig YANG models to equivalent existing OpenConfig
> style with their split config/state containers.
> 
> datastore such as via I2RS, hence it wouldn't necessarily always be
> via the intended datastore.
> 
> 
> link-layer-address leaf description to indicate that it wouldn't
> expect to be populated if the associated "state" is set to
> "incomplete".

Ok, done.

/martin