Hi Benoit,
On 12/5/17, 8:18 AM, "Benoit Claise (bclaise)" <bcla...@cisco.com> wrote:
>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.
Agreed. Will fix as part of WG last call comments.
Thanks,
Acee
>
>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
