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

[Andy Bierman <[e-mail]>]

On Mon, Aug 21, 2017 at 9:22 AM, Kent Watsen <[e-mail]> wrote:

> 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?
>
>
>
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
>
>
>
>