Subject: [Netconf] AD review of draft-ietf-netconf-rfc6536bis-05

From: Benoit Claise <[email-masked]>
Date: Thu, 5 Oct 2017 10:13:14 +0200

Dear all,

Here is my AD review for draft-ietf-netconf-rfc6536bis-05.

There are no YANG module dependencies to publish this document:
https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-netconf-acm 
=> select "Dependencies only"
The YANG module validates correctly:
https://www.yangcatalog.org/yang-search/module_details.php?module=[email-masked]
No more issues:
     https://github.com/netconf-wg/rfc6536bis
The diffs with RFC 6536 are minor.
http://www.ietf.org/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/rfc/rfc6536.txt&url2=https://tools.ietf.org/id/draft-ietf-netconf-rfc6536bis-05.txt

Very good so far.

There are however two issues:
- You should either remove NETCONF or add RESTCONF to the document title.
- Update the Security Considerations based on the new template.

Editorial:
This document thought of the NMDA/revised datastore architecture 
[I-D.ietf-netmod-revised-datastores 
<https://tools.ietf.org/html/draft-ietf-netconf-rfc6536bis-05#ref-I-D.ietf-netmod-revised-datastores>]. 
After all, it's a normative reference ... just for the definition. 
However, I don't clearly see this message. Should we clearly mention 
that point in section 2.4 or section 3.2/3.2.1.
For example:

    The same access control rules apply to all datastores that support
    NACM, for example, the candidate configuration datastore or the
    running configuration datastore.

NEW:

    The same access control rules apply to all datastores that support
    NACM, including the ones following the Network Management Datastore
    Architecture [I-D.ietf-netmod-revised-datastores 
<https://tools.ietf.org/html/draft-ietf-netconf-rfc6536bis-05#ref-I-D.ietf-netmod-revised-datastores>], for example ...

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Fri, 6 Oct 2017 17:39:05 +0200

Dear all,

Investigating further, one more point.

       3.2.2
        <https://tools.ietf.org/html/draft-ietf-netconf-rfc6536bis-05#section-3.2.2>.
        Access Rights

    A small set of hard-wired datastore access rights is needed to
    control access to all possible NETCONF protocol operations, including
    vendor extensions to the standard protocol operation set.

    The "CRUDX" model can support all NETCONF protocol operations:

    o  Create: allows the client to add a new data node instance to a
       datastore.

    o  Read: allows the client to read a data node instance from a
       datastore or receive the notification event type.

    o  Update: allows the client to update an existing data node instance
       in a datastore.

    o  Delete: allows the client to delete a data node instance from a
       datastore.

    o  eXec: allows the client to execute the operation.

What is the link with RESTCONF?
I guess I don't understand (the idea behind) this section.

Regards, Benoit
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 9 Oct 2017 09:56:58 -0700

> On Oct 5, 2017, at 1:13 AM, Benoit Claise <[email-masked]> wrote:
> 
> Dear all,
> 
>     https://www.yangcatalog.org/yang-search/impact_analysis.php?modules <https://www.yangcatalog.org/yang-search/impact_analysis.php?modules>[]=ietf-netconf-acm => select "Dependencies only"
>     https://www.yangcatalog.org/yang-search/module_details.php?module=[email-masked] <https://www.yangcatalog.org/yang-search/module_details.php?module=[email-masked]>
> No more issues:
>     https://github.com/netconf-wg/rfc6536bis <https://github.com/netconf-wg/rfc6536bis>
>     http://www.ietf.org/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/rfc/rfc6536.txt&url2=https://tools.ietf.org/id/draft-ietf-netconf-rfc6536bis-05.txt <http://www.ietf.org/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/rfc/rfc6536.txt&url2=https://tools.ietf.org/id/draft-ietf-netconf-rfc6536bis-05.txt>
> 
> Very good so far.
> 

There was an effort to disentangle NACM from NETCONF protocol here <https://www.ietf.org/mail-archive/web/netconf/current/msg12966.html>. I guess we missed it in the title. What would form a good title? "Network Configuration Access Control Module”?

That still leaves us with the acronym NACM currently defined as NETCONF Access Control Module. Shouldn't that be updated too?

> This document thought of the NMDA/revised datastore architecture [I-D.ietf-netmod-revised-datastores <https://tools.ietf.org/html/draft-ietf-netconf-rfc6536bis-05#ref-I-D.ietf-netmod-revised-datastores>]. After all, it's a normative reference ... just for the definition. However, I don't clearly see this message. Should we clearly mention that point in section 2.4 or section 3.2/3.2.1. 
> For example: 
>    Architecture [I-D.ietf-netmod-revised-datastores <https://tools.ietf.org/html/draft-ietf-netconf-rfc6536bis-05#ref-I-D.ietf-netmod-revised-datastores>], for example ... 
The question of referencing the datastore draft was brought up by Andy here <https://www.ietf.org/mail-archive/web/netconf/current/msg12743.html>, and the agreement (from Tom) was that a normative reference would be just fine, along with the change in the statement that references the candidate and running datastores as examples.
> Regards, Benoit

Mahesh Jethanandani
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Mon, 9 Oct 2017 10:08:39 -0700

On Mon, Oct 9, 2017 at 9:56 AM, Mahesh Jethanandani <[email-masked]
> wrote:

>     https://www.yangcatalog.org/yang-search/module_details.
> php?module=[email-masked]
> No more issues:
>     http://www.ietf.org/rfcdiff/rfcdiff.pyht?url1=https://
> tools.ietf.org/rfc/rfc6536.txt&url2=https://tools.ietf.
> org/id/draft-ietf-netconf-rfc6536bis-05.txt
>
> Very good so far.
>
> There was an effort to disentangle NACM from NETCONF protocol here
> <https://www.ietf.org/mail-archive/web/netconf/current/msg12966.html>. I
> guess we missed it in the title. What would form a good title? "Network
> Configuration Access Control Module”?
>
>
fine

> That still leaves us with the acronym NACM currently defined as NETCONF
> Access Control Module. Shouldn't that be updated too?
>
>

no

The acronym has been out there for a long time
and some people know what it means.

> This document thought of the NMDA/revised datastore architecture [
> I-D.ietf-netmod-revised-datastores
> After all, it's a normative reference ... just for the definition. However,
> I don't clearly see this message. Should we clearly mention that point in
> section 2.4 or section 3.2/3.2.1.
> For example:
>
> The question of referencing the datastore draft was brought up by Andy
> here <https://www.ietf.org/mail-archive/web/netconf/current/msg12743.html>,
> and the agreement (from Tom) was that a normative reference would be just
> fine, along with the change in the statement that references the candidate
> and running datastores as examples.
>

I don't think the new text helps or solves any ambiguity

> Regards, Benoit

Andy

---

From: Benoit Claise <[email-masked]>
Date: Mon, 9 Oct 2017 22:43:06 +0200

On 10/9/2017 7:08 PM, Andy Bierman wrote:
>
>
> On Mon, Oct 9, 2017 at 9:56 AM, Mahesh Jethanandani 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>>     On Oct 5, 2017, at 1:13 AM, Benoit Claise <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>     Dear all,
>>
>>     https://www.yangcatalog.org/yang-search/impact_analysis.php?modules
>>     <https://www.yangcatalog.org/yang-search/impact_analysis.php?modules>[]=ietf-netconf-acm
>>     <https://www.yangcatalog.org/yang-search/module_details.php?module=[email-masked]>
>>     No more issues:
>>     <https://github.com/netconf-wg/rfc6536bis>
>>     <http://www.ietf.org/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/rfc/rfc6536.txt&url2=https://tools.ietf.org/id/draft-ietf-netconf-rfc6536bis-05.txt>
>>
>>     Very good so far.
>>
>     <https://www.ietf.org/mail-archive/web/netconf/current/msg12966.html>.
>     I guess we missed it in the title. What would form a good title?
>     "Network Configuration Access Control Module”?
>
>
> fine
Fine with me too.
>
>     That still leaves us with the acronym NACM currently defined as
>     NETCONF Access Control Module. Shouldn't that be updated too?
>
>
>
> no
>
ok.
>>     After all, it's a normative reference ... just for the
>>     definition. However, I don't clearly see this message. Should we
>>     clearly mention that point in section 2.4 or section 3.2/3.2.1.
>>     <http://3.2.1.>
>>     For example:
>     The question of referencing the datastore draft was brought up by
>     Andy here
>     <https://www.ietf.org/mail-archive/web/netconf/current/msg12743.html>,
>     and the agreement (from Tom) was that a normative reference would
>     be just fine, along with the change in the statement that
>     references the candidate and running datastores as examples.
>
>
>
Ok, let's leave the text as it was.

Regards, Benoit
>>     [email-masked] <mailto:[email-masked]>
>>     <https://www.ietf.org/mailman/listinfo/netconf>
>
>     Mahesh Jethanandani
>     [email-masked] <mailto:[email-masked]>
>
>
>
>
>
> Andy
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/netconf>
>
>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 9 Oct 2017 17:36:31 -0700

Andy,

Please address the comment from Radek in the updated draft along with the changes agreed to in this draft.

Thanks.

> On Oct 9, 2017, at 10:08 AM, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> On Mon, Oct 9, 2017 at 9:56 AM, Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On Oct 5, 2017, at 1:13 AM, Benoit Claise <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Dear all,
>> 
>> This document thought of the NMDA/revised datastore architecture [I-D.ietf-netmod-revised-datastores <https://tools.ietf.org/html/draft-ietf-netconf-rfc6536bis-05#ref-I-D.ietf-netmod-revised-datastores>]. After all, it's a normative reference ... just for the definition. However, I don't clearly see this message. Should we clearly mention that point in section 2.4 or section 3.2/3.2.1. <http://3.2.1./> 
>> For example: 
>> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
> 
> Mahesh Jethanandani
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
> 
> 

Mahesh Jethanandani
[email-masked]

---

From: Benoit Claise <[email-masked]>
Date: Wed, 11 Oct 2017 08:38:06 +0200

Dear all,

The comment below has not been discussed and I don't see any changes 
part of draft-ietf-netconf-rfc6536bis-06.
However, I'm sending the document to IETF LC now, with a tentative IESG 
telechat date on Oct 26th.
Please discuss (and resolve, if necessary) this comment.

Regards, Benoit

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 12 Oct 2017 18:24:23 -0700

> On Oct 10, 2017, at 11:38 PM, Benoit Claise <[email-masked]> wrote:
> 
> Dear all,
> 
> The comment below has not been discussed and I don't see any changes part of draft-ietf-netconf-rfc6536bis-06.
> However, I'm sending the document to IETF LC now, with a tentative IESG telechat date on Oct 26th.
>>        <https://tools.ietf.org/html/draft-ietf-netconf-rfc6536bis-05#section-3.2.2> <https://tools.ietf.org/html/draft-ietf-netconf-rfc6536bis-05#section-3.2.2>.
>>        Access Rights
>> 
>> 
>> 

The section itself is a carryover from RFC 6536. 

But I guess your question is whether the same access rights apply to RESTCONF also, and if so where does it say that. Looking at RFC 8040, I see the following statements there. 

   Access control mechanisms are used to limit what CRUD operations can
   be used.  In particular, RESTCONF is compatible with the NETCONF
   Access Control Model (NACM) [RFC6536 <https://tools.ietf.org/html/rfc6536>], as there is a specific mapping
   between RESTCONF and NETCONF operations.

Would it help to quote something similar here? Maybe something like this:

   RESTCONF is compatible with the NETCONF Access Control Model (NACM) defined in this draft and the 
   CRUDX operations used to enforce access control mechanisms, as there is a specific mapping between
   RESTCONF and NETCONF operations.

Thanks

Mahesh Jethanandani
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Thu, 12 Oct 2017 18:30:25 -0700

> The section itself is a carryover from RFC 6536.
How about just removing the 2 instances of the word "NETCONF"?
Maybe it can be an instruction to the RFC Editor and fixed later.

Andy

But I guess your question is whether the same access rights apply to
> RESTCONF also, and if so where does it say that. Looking at RFC 8040, I see
> the following statements there.
>
> Netconf mailing [email-masked]://www.ietf.org/mailman/listinfo/netconf
>
>
>
>
> Netconf mailing [email-masked]://www.ietf.org/mailman/listinfo/netconf
>
>

---

From: Benoit Claise <[email-masked]>
Date: Fri, 13 Oct 2017 13:40:23 +0200

Andy,
>
>
> On Thu, Oct 12, 2017 at 6:24 PM, Mahesh Jethanandani 
>>     On Oct 10, 2017, at 11:38 PM, Benoit Claise <[email-masked]
>>     The comment below has not been discussed and I don't see any
>>     changes part of draft-ietf-netconf-rfc6536bis-06.
>>     However, I'm sending the document to IETF LC now, with a
>>     tentative IESG telechat date on Oct 26th.
>>>             <https://tools.ietf.org/html/draft-ietf-netconf-rfc6536bis-05#section-3.2.2>
That works for me.
> Maybe it can be an instruction to the RFC Editor and fixed later.
The draft is right now in IETF LC (and on the IESG telechat on Oct 26th).
Let's see if we get some other feedback.

Regards, B.
>
>
> Andy
>
>
>     But I guess your question is whether the same access rights apply
>     to RESTCONF also, and if so where does it say that. Looking at RFC
>     8040, I see the following statements there.
>
>>>>     This document thought of the NMDA/revised datastore
>>>>     architecture [I-D.ietf-netmod-revised-datastores
>>>>     definition. However, I don't clearly see this message. Should
>>>>     we clearly mention that point in section 2.4 or section
>>>>     3.2/3.2.1. <http://3.2.1.>
>>>>     For example: