RP partial comments on draft-ietf-netconf-restconf-09

[abierman]

https://www.ietf.org/mail-archive/web/netconf/current/msg10906.html

[abierman]

not removing marketing intro 8209 chars -- make sure doc generated without these chars

expand RESTCONF acronym ?

sec 1.1 -- look at removing comparison to NETCONF "does not need to ..." Assign to Kent

edits usually applied -- remove last sentence of this paragraph

define term REST

sec 1.2 comments -- Kent will look into fixing text or explain why we kept it

1.3 change 'a edit' to each edit'

1.3: after: not specified how long this takes on an implementation

2.3: Kent will clarify text (MAY to MUST)

2.5: Kent to clarify MUST A or B or both 3rd para: user name -- Kent to clarify this terminology (check sec. considerations sec.) Do not understand comment about distinction between client identity and user identity

3: within the device; remove this sentence 2nd para: 'conceptual data' -- refer to instance of a YANG subtree remove word 'conceptual' 3rd para: replace its own with a 4th: change resource to resource types last para: not sure what mount comments mean

section just before root resource discovery: remove text about no resource discovery change to use YANG library; not links

[got as far as 3.1]

[abierman]

removed 2nd para in 1.2 intro

tend to agree section is total crap

[abierman]

removed much of 1.2 text; tend to agree it is marketing BS not well motivated; not very useful; did not clarify datastore issue

[abierman]

OPEN FOR KENT TO RESOLVE

sec 1.2 comments -- Kent will look into fixing text or explain why we kept it

2.3: Kent will clarify text (MAY to MUST)

2.5: Kent to clarify MUST A or B or both 3rd para: user name -- Kent to clarify this terminology (check sec. considerations sec.) Do not understand comment about distinction between client identity and user identity

[abierman]

IGNORED: Last paragraph: I'm not able to reconcile this paragraph with the immediately following section, number 3.1. If this paragraph is correct, how does it interract with the various moutn point proposals?

[abierman]

IGNORED:

3.4 I'm having a hard time reconciling the straightforward notion of datastore presumed by this section with the rather baroque facilities needed to support some of the alternatives being discussed with regard to operational / state data. In particular, I'm worried about the "all" in the statement that "[t]he RESTCONF datastore resource is a conceptual collection of all configuration and operational data that is present". To me this implies the ability to explicity distinguish / access, for example, both "intended" and "applied" versions of a configuration parameter. The phrase "on the device" seems to be intended to exclude use with proxy technologies.

ED NOTE: OPSTATE IS FUTURE WORK; NOT WILLING TO POLLUTE RESTCONF WITH OPSTATE

[abierman]

IGNORED: 3.4.1 This is in the datastore resource section, but talks about the data resources. This seems odd. Why are two mechanisms mandated? Why is no comparable mechanism provided for non-configuration data?

[abierman]

IGNORED:

3.4.1.1 The text describing the maintenance of last-modified seems incomplete. As a read the current text, in a server maintaining only a timestamp for a parent resource, modification of a child resource's configuration data doesn't cause the parent's timestamp to change. I think these algorithms make some big unspoken assumptions about timestamp propagation within a tree.

[abierman]

IGNORED

3.4.1.2 Same comment as for 3.4.1.1

[abierman]

REMOVED MUCH OF THE DATA RESOURCE TEXT FROM THE DATASTORE SECTION

[abierman]

MOSTLY IGNORED: This, too, seems odd. Why is the message-body optional for actions/ rpcs with output statements? What does it mean when the message body is omitted in such cases? Why is the MUST NOT necessary? What breaks if an unexpected (empty) message-body is sent?

[abierman]

"If the operation is not successfully invoked, then a message-body SHOULD be sent by the server, containing an "errors" resource, as defined in Section 3.9."

CHANGED SHOULD TO MUST

[abierman]

3.6.3 is what is here called an '"errors" data structure' the same thing as what is called an '"errors" resource' earlier in the document?

CHANGED data structure to media type

[abierman]

3.9 How does one reconcile this explanation with earlier references in the document to an '"errors resource"?

CHANGED TO BE MEDIA TYPE NOT A RESOURCE

[abierman]

4.3 Third paragraph: "an error response containing a "403 Forbidden" or "404 Not Found" status-line is returned to the client." How does the server decide which of these two? Consistently returning 404 would fit the SNMP world-view.

STILL NO USEFUL TEXT HELPING SERVER DEVELOPER PICK.

[abierman]

IGNORED:

Section 10: This section strikes me as rather odd. It feels like it's using some HTTP-specific hacks to accomplish query optimizations that more properly should have been done through the information model.

[abierman]

Section 12 Last paragraph: "Note that authorization information can be exchanged in the form of configuration information, which is all the more reason to ensure the security of the connection." I think "authentication" rather than "authorization" is intended here.

NO CHANGES -- KENT TO VERIFY IF authentication is correct instead of authorization

[kwatsen]

Regarding the note in Section 12, it could be and perhaps should be both.

That is, authentication info can be configured (a la server-model) and authorization info can be configured (a la NACM).

However this paragraph regards authorization, so I'm thinking the note is worded correctly as is.

[kwatsen]

sec 1.2 comments -- Kent will look into fixing text or explain why we kept it

[KENT] Fixed.

2.3: Kent will clarify text (MAY to MUST)

[KENT] Fixed.

2.5: Kent to clarify MUST A or B or both

[KENT] I don't see the issue here.

3rd para: user name -- Kent to clarify this terminology (check sec. considerations sec.)

[KENT] Fixed.

Do not understand comment about distinction between client identity and user identity

[KENT] I converted everything to RESTCONF username

[abierman]

Issue: The text describing the maintenance of last-modified seems incomplete.

A new sub-section has been added to specify the update procedure for entity tags and timestamps.

[abierman]

closed in draft-10