Subject: Re: [Netconf] RESTCONF #2: session monitoring

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Sun, 7 Dec 2014 16:32:15 +0000

All,

if there is no objection within a few days we are going to implement issue #2 as discussed and summarized below.

BR, 
Mehmet 

> -----Original Message-----
> From: Netconf [mailto:[email-masked]] On Behalf Of ext Andy Bierman
> Sent: Saturday, November 29, 2014 5:13 PM
> To: Kent Watsen
> Cc: Netconf
> Subject: Re: [Netconf] RESTCONF #2: session monitoring
> 
> Hi,
> 
> There doesn't seem to be much interest in this issue.
> The original WG decision is to just define a "restconf-tls"
> identity for the session "transport" leaf.
> 
> IMO the original consensus of "punt this until later" is confirmed.
> That would be solution S1.
> 
> 
> 
> Andy
> 
> 
> 
> On Wed, Nov 26, 2014 at 3:14 PM, Kent Watsen <[email-masked]> wrote:
> >
> >>The original task was simply to identify SSE sessions because
> >>these are the only long-lived RESTCONF "sessions".
> >
> > Tracking just SSE sessions is so non-intuitive and somewhat pointless.
> > What people want is some means to be aware of all the different "sessions"
> > going on, not just the never-ending responses.  I know we're struggling
> > with the stateless-server constraint, but the articles I linked before are
> > pretty pragmatic.
> >
> >
> >
> >>We currently store all RESTCONF sessions in the session list,
> >>because the server instrumentation can block, so even a 1 request
> >>session can be a long-lived session.  In the multi-threaded build,
> >>other sessions will still be running, and the RESTCONF session
> >>will be visible.
> >
> > You mean that each REST API entry point is something like this:
> >
> >     Foobar() {
> >       session_id = start_session();
> >
> >       // do bis logic here
> >
> >       close_session(session_id);
> >       return HTTP_response;
> >     }
> >
> > So even short-lived responses show up as a session temporarily?
> >
> >
> >
> >>IMO it is OK if a server treats 1 request as a session or N requests
> >>as a session, so picking S2 is good enough.
> >
> > Assuming cookies are needed to track sessions correctly, there would be a
> > requirement for clients to implement the "Set-Cookie" and "Cookie" header
> > fields from RFC 6265.   Can we at least say that servers MAY use cookies?
> > (i.e. clients MUST support)
> >
> >
> > Having been thru a Common Criteria certification before, I'm painfully
> > aware that every login and logout event needs to be logged, in addition to
> > the actions performed.   Without some form of a session, my understanding
> > is that BasicAuth leads to 2/3-rds of the audit log being "login" and
> > "logout" events, which doesn't match common expectations.  Others must
> > have experience with this, should we ask the Apps folks for advice?
> >
> > Thanks,
> > Kent
> >
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Sun, 7 Dec 2014 09:11:48 -0800

Hi,

So that is solution S1.
We will just define the restconf-tls identity and say
in the draft that there is no standard RESTCONF session monitoring
and the identity is defined for future use.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 7 Dec 2014 09:16:37 -0800

> and the identity is defined for future use.

This creates a normative reference to NETCONF Monitoring for no reason.
So I am proposing S0 -- do not have anything in the RESTCONF draft
about session monitoring, and do not define the restconf-tls identity
until it is needed in a standard YANG module.

If there are no comments, then S1 is still the default solution.
IMO there is no standards value in S1 but its cost is also low.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Fri, 12 Dec 2014 15:16:13 +0000

I prefer S0, only because S1 puts stuff into the standard unnecessarily.

The "cost" for S0 is just removing the import and the identity statements
(8 lines total).  These is currently no normative reference to NETCONF
Monitoring, so the cost for S1 would be to add it.  Thus it seems that S0
< S1  :)

K.

---

From: Andy Bierman <[email-masked]>
Date: Sat, 13 Dec 2014 09:00:48 -0800

> Monitoring, so the cost for S1 would be to add it.  Thus it seems that S0

I just added that imports on github, so it is not in draft-03.
There is no cost to S0.  It might be a bad idea for developers to use
this identity for proprietary sessions instead of their own identity.

It doesn't help a 3rd party client much if the same identity means
different things on every server.  It makes it hard to tell the standard
sessions from the proprietary sessions, when standard monitoring is
finally published.

Unless there are any objections, we will use solution S0.

Andy