On 11/3/2017 5:49 PM, Acee Lindem (acee) wrote:
Hi Vladimir,
Thanks for comments - see inline.
On 10/29/17, 8:43 PM, "netmod on behalf of Vladimir Vassilev"
<netmod-boun...@ietf.org on behalf of vladi...@transpacket.com> wrote:
Hello,
I have reviewed draft-acee-netmod-rfc8022bis-05. My conclusion is that
the YANG modules part of the draft have been successfully modified in
accordance with sec. '4.23.3 NMDA Transition Guidelines' of
draft-ietf-netmod-rfc6087bis-14. The modifications are coherent with the
ietf-interfa...@2017-08-17.yang module in
draft-ietf-netmod-rfc7277bis-00 and ietf...@2017-08-21.yang module in
draft-ietf-netmod-rfc7277bis-00.
Vladimir
Review of draft-acee-netmod-rfc8022bis-05.
Vladimir Vassilev
2017-10-30
'Abstract':
'Introduction 1':
- Both Abstract and Sec 1. contain duplicated text which can be removed
>from Abstract. The text in Sec 1. can be simplified:
OLD:
This version of these YANG modules uses new names for these YANG
models. The main difference from the first version is that this
version fully conforms to the Network Management Datastore
Architecture (NMDA). Consequently, this document obsoletes RFC 8022.
NEW:
This version of the Routing Management data model supports the Network
Management Datastore Architecture (NMDA)
[I-D.ietf-netmod-revised-datastores].
The Abstract and Introduction sections are independent and the information
is pertinent to both.
Acee,
The point (as reported by someone else to me) is that this sentence is
not correct and should be removed.
This version of these YANG modules uses new names for these YANG
models.
Regards, Benoit
'7. Routing Management YANG Module':
- Why should address-family identity be different e.g. mandatory
"false"; for system created RIBs? I think this needs some explanation
(Page 21):
...
uses address-family {
description
"Address family of the RIB.
It is mandatory for user-controlled RIBs. For
system-controlled RIBs it can be omitted; otherwise, it
must match the address family of the corresponding state
entry.";
refine "address-family" {
mandatory "false";
}
}
...
I will discuss this with my co-authors.
- Suggested change of 'base address-family;' -> 'base
rt:address-family;' for identity ipv4 and ipv6 (ref.
draft-ietf-netmod-rfc6087bis-14#section-4.2):
o The local module prefix MUST be used instead of no prefix in
all "default" statements for an "identityref" or
"instance-identifier"
data type
I added “rt:” where it was missing to the identityref statements. This
will be in the next revision.
'8. IPv4 Unicast Routing Management YANG Module'
(ietf-ipv4-unicast-rout...@2017-10-14.yang):
'9. IPv6 Unicast Routing Management YANG Module'
(ietf-ipv6-unicast-rout...@2017-10-14.yang):
- The ietf-ipv4-unicast-routing and ietf-ipv6-unicast-routing modules
import the ietf-routing without revision (ref. rfc6087#section-4.6):
o The revision-date substatement within the imports statement SHOULD
be
present if any groupings are used from the external module."
Since these modules are all in the same draft, I’d rather leave out the
revision date as it is cleaner without it. Let me discuss with my
co-authors.
'Appendix D. Data Tree Example':
- The example in the Appendix D. has not been updated and it must be
extended in order to demonstrate a usecase of operational datastore of
configuration data with different origin (intended, system, etc.)
similar to the 'Appendix C. Example Data' of
draft-ietf-netmod-revised-datastores-05.
Actually, none of the examples accessed operational state date in RFC
8022. However, I agree that this should be added and we’ll work on it.
Nits:
- s/Figures 1/Figure 1/
- s/systemindependently/system independently/
Thanks for catching - I fixed these in the -01 version of
draft-ietf-netmod-rfc8022bis-01.txt.
Thanks,
Acee
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
