Subject: [secdir] review of draft-ietf-netconf-nmda-restconf-04

From: Daniel Harkins <[email-masked]>
Date: Tue, 03 Jul 2018 11:32:35 -0700

Hello,

   I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

   The summary of the review is "Ready with nits".

   This draft defines two new capability identifier URNs for use in
the RESTCONF protocol and also some new behavioral requirements on
servers implementing it. My nit is on that last bit. In sections
3.2.1 and 3.2.2 present the new query parameters and say that they
are "optional to support" and then go on saying what behavior is
needed if it is supported. I think those need to be changed to be
RFC 2119 words, either SHOULD or MAY depending on the reasons that
might exist for not implementing them (basically conform to what
the words mean in RFC 2119).

   Other than that, the draft is pretty simple and straightforward.
The security considerations are basically a punt but given the
nature of this draft that's probably fine.

   regards,

   Dan.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 4 Jul 2018 14:41:28 +0200

> the words mean in RFC 2119).

I am not sure where exactly we are asked to use SHOULD and MAY and why
that would be necessary. Note that we follow the wordings in RFC 8040
(search for optional), which this document updates.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Daniel Harkins <[email-masked]>
Date: Wed, 04 Jul 2018 11:08:10 -0700

> (search for optional), which this document updates.

   I'm suggesting SHOULD _or_ MAY and I thought where would be obvious.
It is the places that say "optional to support" in 3.2.1. and 3.2.2 as
I indicated. For example, 3.2.1 says,

    The "with-defaults" query parameter ([RFC8040], Section 4.8.9 <https://tools.ietf.org/html/rfc8040#section-4.8.9>) is
    optional to support when interacting with {+restconf}/ds/ietf-
    datastores:operational.

3.2.2 has similar text. As to why, it is for consistency and clarity in
expressing what you want.

   Dan.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 4 Jul 2018 20:34:36 +0200

> expressing what you want.

What is unclear about 'optional to support'? RFC 8040 uses similar
language and I do not recall that anyone had a problem with this so
far.

/js

---

From: Daniel Harkins <[email-masked]>
Date: Wed, 04 Jul 2018 12:46:10 -0700

> language and I do not recall that anyone had a problem with this so

   If you want to reject my comment then just reject my comment. It was made
in the spirit of improving your draft which apparently you take issue with
for some bizarre reason. If someone outside the RFC 8040 bubble you seem 
to be
living in found the wording lacking in clarity then it would seem logical to
infer that maybe others might too. Just a thought.

   Dan.

---

From: Kent Watsen <[email-masked]>
Date: Thu, 5 Jul 2018 14:46:09 +0000

I think that the current wording is okay, but I'm okay with changing
it too. How about this?

OLD:
   The "with-defaults" query parameter ([RFC8040], Section 4.8.9) is
   optional to support when interacting with {+restconf}/ds/ietf-
   datastores:operational.  The associated capability to indicate a
   server's support is identified with the URI:

NEW:
   The "with-defaults" query parameter ([RFC8040], Section 4.8.9) 
   MAY be supported for the operational state datastore.  Support
   for the "with-defaults" query parameter for the operational
   state datastore is identified with the URI:

OLD:
   The "with-origin" query parameter is optional to support.  It is
   identified with the URI:

NEW:
   The "with-origin" query parameter MAY be supported.  Support
   for the "with-origin" query parameter is identified with the
   URI:

FWIW, elsewhere in the draft is another "optional" usage that could
be changed:

 OLD:
   An NMDA-compliant server MUST implement {+restconf}/ds/ietf-
   datastores:operational.  Other datastore resources are optional to
   implement.

 NEW:
   An NMDA-compliant server MUST implement {+restconf}/ds/ietf-
   datastores:operational.  Other datastore resources MAY be
   implemented.

Comments?

Kent  // co-author

On 7/4/18 11:34 AM, Juergen Schoenwaelder wrote:
>>     The "with-defaults" query parameter ([RFC8040], Section 4.8.9 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8040-23section-2D4.8.9&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=fApqY-LnEgjm4NbObNcu5L44jAZ2UYJz0CWl5q4U0YE&s=r65kakpgV3OSbY6iIzByXMmqvV-45Vo9wkXZHji8jlk&e=>) is

   Dan.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 9 Jul 2018 11:40:50 +0200

On Wed, Jul 04, 2018 at 12:46:10PM -0700, Daniel Harkins wrote:
> for some bizarre reason. If someone outside the RFC 8040 bubble you seem to
> be

Thanks for your comments.

/js

---

From: Daniel Harkins <[email-masked]>
Date: Mon, 09 Jul 2018 09:03:12 -0700

>     datastores:operational.  Other datastore resources MAY be

   Looks fine, thanks.

   Dan.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 9 Jul 2018 17:48:53 -0700

There have been a few comments that have been made to the version of the draft that has been submitted to IESG. While we wait for other comments to be provided, and direction of when an update should be provided, who amongst the authors is updating GitHub with these changes? 

I am concerned we might lose track of the changes that need to be made.

Here are the changes that I am aware of for nmda-restconf. I can compile a similar list for nmda-netconf if needed.

Kent’s comment on nmda-restconf operations (thread <https://www.ietf.org/mail-archive/web/netconf/current/msg14998.html> from today).
Dan’s comment on this thread (also from today, but is not on netconf mailing list)
Russ’s Genart review (thread <https://www.ietf.org/mail-archive/web/netconf/current/msg14834.html> from June 28)
Rohit’s change-2 comments provided for nmda-netconf, that are applicable for nmda-restconf (thread <https://www.ietf.org/mail-archive/web/netconf/current/msg14607.html> from June 1)

Anything else that I missing?

Mahesh Jethanandani // as document shephard

> On Jul 9, 2018, at 9:03 AM, Daniel Harkins <[email-masked]> wrote:
> 
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 16 Jul 2018 12:42:25 +0200

> Here are the changes that I am aware of for nmda-restconf. I can compile a similar list for nmda-netconf if needed.

Having a list of outstanding edits for nmda-netconf would be nice as well
so we can make the edits on github.
 
> Kent’s comment on nmda-restconf operations (thread <https://www.ietf.org/mail-archive/web/netconf/current/msg14998.html> from today).

Given that lock and unlock require session semantics, I think the
resolution should be to add.

   A RESTCONF server supporting NMDA datastores MAY implement the
   "ietf-netconf-nmda" [I-D. ietf-netconf-nmda-netconf] module to
   enable the NETCONF operations defined in this draft to appear
   under the {+restconf}/operations resource.

But then, what is the value of this? You do not need get-data and
edit-data with RESTCONF since you can send GET/POST/PATCH straight to
the datastore resources. I guess I am still unclear which problem we
are trying to solve by adding this (or a similar) statement.

> Dan’s comment on this thread (also from today, but is not on netconf mailing list)

Not sure which one you mean.

> Russ’s Genart review (thread <https://www.ietf.org/mail-archive/web/netconf/current/msg14834.html> from June 28)

Not sure what the resolution is, removing the example text or trying
to better explain that this is example text.

> Rohit’s change-2 comments provided for nmda-netconf, that are applicable for nmda-restconf (thread <https://www.ietf.org/mail-archive/web/netconf/current/msg14607.html> from June 1)

The inclusion of an example showing the usage of
negated-origin-filter? This was an nmda netconf command. We do not
seem to have an origin filter in nmda restconf, this is an nmda
netconf only feature?

> Anything else that I missing?

Not that I recall.

/js

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 26 Jul 2018 15:08:11 -0700

[Adding Russ Housley]

> On Jul 16, 2018, at 3:42 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Let me compile a list of edits that are applicable for nmda-netconf.

> are trying to solve by adding this (or a similar) statement.

I am responding to the last sentence that was made on that thread, where Kent asked the question.

> So, adding something like this to nmda-restconf would be good?

It likely does not hurt to be clear that this option of using NETCONF
operations in RESTCONF exists.
/js
If you and the authors now believe that the clarification is not needed, then please state so.

> Not sure which one you mean.

I mean all the the OLD and NEW suggestions from Kent. Basically replace “optional to support” with RFC 2119 use of MAY.

> to better explain that this is example text.

I believe either of the options would be ok with Russ. I have added him to confirm.

> seem to have an origin filter in nmda restconf, this is an nmda

Again, I am responding to the last comment that Robert made on the follow up e-mail where he proposed changes for NETCONF and said:

Similar updates will need to also be done to RESTCONF, but let's agree the NETCONF text first.

Maybe he can clarify what he had in mind for RESTCONF.

Cheers.

>> Anything else that I missing?

Mahesh Jethanandani
[email-masked]