[netconf] Re: AD review of draft-ietf-netconf-netconf-client-server-29

[Kent Watsen <[e-mail]>]

Hi Mahesh,

First, I must apologize for not seeing your Apr 22 message - yikes!

The general-response is that no further discussion has occurred, wrt those items I’d noted needed more discussion.  Please see below for DISCUSS-specific responses.

Kent  // author


> On Jun 3, 2024, at 11:23 AM, Mahesh Jethanandani <[e-mail]> wrote:
> 
> Hi Kent,
> 
> I am reviewing the documents in my queue, and this document, per my understanding, is waiting for an update from you. Is that still the case?
> 
> Thanks.
> 
>> On Apr 22, 2024, at 2:45 PM, Mahesh Jethanandani <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Hi Kent,
>> 
>> I went through your responses to the AD review. Most of them were editorial, and have been addressed in your updates. However, see below.
>> 
>>> On Dec 26, 2023, at 3:02 PM, Kent Watsen <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>>> I'm assuming that the comments that I've made previously on the other drafts, in particular the RESTCONF draft, will also be taken into consideration for this document, and resolved similarly (rather than raising all my questions again).
>>>> 
>>>> - RFC editor guidance on self references [FIXED]
>>>> - Relationship diagram clarification.  [FIXED]
>>>> - Empty groupings comment   [DISCUSS]

I’m unsure what this is about, but I see that the empty "netconf-client-grouping” grouping was removed in version 30, which was posted on Dec 28, after the line above was written, so this may be fixed now.


>>>> - Support for on-demand connections rather than just persistent and periodic  [DISCUSS]

IIRC, this was Rob’s idea to support one-time connections, which doesn’t make sense to me from a configuration-perspective.  Why would anyone *configure* a client or server to initiate a connection just once?


>>>> - No endpoints container under grouping netconf-client-app-grouping/listen  [FIXED]
>>>> - "Both the "initiate" and "listen" subtrees must be enabled " is unclear comment  [FIXED]
>>>> - Query about "central" being the best prefix.  [DISCUSS]

Currently, in many drafts besides this one, the top-level container is referred to as the “central” instance, in contrast to other instances that may occur through the use of groupings.   Previously the top-level container was called the “global” instance, but “global" was changed to “central” for a similar reason.  

I don’t care what it’s called, but 1) how important is this? and 2) be aware that a change here would necessitate RFC Editor involvement, for those drafts that are now in their possession...


>>>> - Use of top level "*-supported" features vs putting them in a separate module.  [DISCUSS]

Currently, in many drafts besides this one, the “central” instance (discussed above) is enabled via a “foobar-supported” feature.  This so that clients/servers that do not want to have any of the “central” instances don’t have to have them.  Rob’s point was that we could move the central instance to its own module so that they’re toggled based on if the module is implemented rather than if a feature is defined.  Two ways for the same outcome.

Same comment as above: 1) how important is this? and 2) be aware that a change here would necessitate RFC Editor involvement, for those drafts that are now in their possession...


>>>> - Avoid describing the reason why containers and p-containers exist in the YANG descriptions.  [FIXED]
>>>> - Question about use of p-containers with lists requiring 1 or more entries (could just use a np-container and list of 0 or )  [DISCUSS]

I’m unsure if this regards more the use of the “presence” statement or the “min-elements 1” statement.

Regarding “presence”, I many times (in other drafts also) have a presence container with a comment similar to “this statement is present so the mandatory descendant nodes do not imply that this node must be configured.”.  Note that “mandatory” maps to both “mandatory true” as well as “min-elements” > 0.  This “issue” has been discussed in the past with other folks besides me feeling that manditoriness should only apply when the immediate ancestor is present.  But since RFC 7950 doesn’t say that, the same effect can be had by making the parent container a presence-container.  This use seems appropriate and good.

Regarding “min-elements 1”, this is more a stylistic thing on my part, because I hate empty lists, because 1) they are non-functional and confusing and 2) I enjoy getting helpful validation errors for when I forgot to configure a list.  


>>>> - Security considerations should list paths from groupings.  [DISCUSS]

I’m unsure what this regards any more.  I assume it relates to the Security Consideration paragraph found in all the drafts that reads:

Please be aware that this YANG module uses groupings from other YANG modules that define nodes that may be considered sensitive or vulnerable in network environments. Please review the Security Considerations for dependent YANG modules for information as to which nodes may be considered sensitive or vulnerable in network environments.

And, presumably, that it would be nice to copy/paste all of those Security Considerations, for nodes that come via groupings, into each document’s Security Consideration.  That sounds like a lot of busy work with an unknown benefit. And, besides, both SecDir and IESG seem okay with the above blurb in all of other drafts, so it is already seen to be okay.


>>>> - Include expanded groupings, e.g., in the appendix?  [DISCUSS]

These drafts are pretty strict about not including any fully-expanded tree-diagrams, because the diagrams are unreadable when line-wrapped.  FWIW, we used to have fully expanded diagrams, but took them out.   The fully-expanded tree-diagrams might look okay in the HTML format where, e.g., a horizontal scrollbar could be utilized, but the `xml2rfc` utility doesn’t do this, currently.   

Please note that currently, everywhere an unexpanded diagram appears, there is a hyperlink to the tree-diagram for the grouping that wasn’t expanded (this was a lot of effort to add).   Thus it is not hard for a reader to navigate to see what the unexpanded parts look like.  


>>> I’m aware of each issue above.  Many are addressed, while others need more discussion…
>> 
>> The question is regarding items in the following list that you have marked DISCUSS. Have all the DISCUSS items been discussed and updated? 
>> 
>> Thanks.
> 
> 
> Mahesh Jethanandani
> [e-mail] <mailto:[e-mail]>

Kent  // author