Re: [Netconf] Yangdoctors last call review of draft-ietf-netconf-restconf-client-server-04

[Kent Watsen <[e-mail]>]

Hi Andy,

Trimming down to just the still-open discussion points.

Thanks,
Kent


>>> You know I am not a big fan of YANG conformance.
>>> We have nothing in between "always mandatory" and "purely optional,
>>> server developer's choice".  We have nothing like conditionally
>>> mandatory "If the RESTCONF server supports listening on TLS , then
>>> the listen-tls feature MUST be supported."
>>
>>This seems unnecessary.  Already the 'if-feature' statements will
>>force the server to advertise the features - or else they're not
>>configurable!
>
> Nothing forces the server to developer to implement a particular object,
> because features are purely optional. The description-stmt in the feature
> can make this conditional requirement.  But not a big deal
> because the IETF is too server-centric to care about the client POV
> of YANG conformance.

I don't see this as a big deal.  Regardless, it's not for this draft
to resolve, right? 
 






>>>>> C5:
>>>>
>>>> It should be clear that the client would have to issue a GET
>>>> or maybe POST to initiate the sending of stored data like logs
>>>
>>> Okay, how about this?
>>>
>>>   "Periodically connect to the RESTCONF server, so that,
>>>    e.g., the RESTCONF client can collect data (logs)
>>>    from the RESTCONF server.  The RESTCONF client must
>>>    close the connection when it is ready to release it.
>>>    Once the connection is closed, the RESTCONF client
>>>    restarts its timer until the next connection.";
>>
>> Not sure this is needed.
>> RESTCONF does not define any interactions that are not initiated
>> by the client, but if that changes, then no reason to constrain
>> this text. I would change 'must' to 'SHOULD' in the 2nd sentence.
>
> Oh, now I see your concern, how about this?  (I removed the sentence
> altogether):
>
>     "Periodically connect to the RESTCONF client, so that
>      the RESTCONF client may deliver messages pending for
>      the RESTCONF server.  Once the connection has been
>      closed, for whatever reason, the server will restart
>      its timer until the next connection.";
>
> I would change messages to requests

Done.

 


>>>>> This is 1 exception -- another is close-session.
>>>>>
>>>>>   POST /restconf/operations/ietf-netconf:close-session
>>>>>
>>>>> Is this supposed to do anything in RESTCONF?
>>>>
>>>> First, I don't view the above as an exception.  With regards to
>>>> 'close-session', does it even have a meaning in RESTCONF?  - and
>>>> is this actually an issue for RFC 8040?
>>>
>>> RESTCONF does not specify any behavior for specific operation
>>> resources.  It is left as an implementation detail.  Our server
>>> treats each RESTCONF request as a new management session, so a
>>> NETCONF operation like <lock> is granted and then released right
>>> afterwards by the server because the session is terminated.  I
>>> think any standard behavior for application layer sessions would
>>> need to be defined in a new versions of RESTCONF.
>>
>> Okay, but can you connect this to the draft?  Are you asking for
>> a change, or are you actually thinking about a clarification
>> needed for RFC 8040?
>
> not asking for a change.
> It is currently up to the implementation.
> For example CGI will call the server once for each request but
> Fast-CGI will call the thin-client once for each HTTP session
> and call the server over and over for each request on that
> session.

Okay, I'll consider this issue closed then.



> Andy

Kent