Subject: [i2rs] info-model for traceability and accountability??

From: Alia Atlas <[email-masked]>
Date: Wed, 14 Aug 2013 15:26:15 -0400

I am pulling this into a separate thread because I think that it merits
some discussion.
There seems to be a strong desire for easy
traceability/accountability/troubleshooting that is better than just syslog
or screen-scraping - something that is vendor-agnostic.

The idea of having the I2RS Agent store all the operations and attribution
done is not appealing.  Clearly, the most recent writer of data will need
to be stored.

Perhaps an info-model would be useful - and then an I2RS agent could write
the data to a file in a structured format?  Perhaps there needs to be some
specific interactions with the files - ability to fetch, rotate, clear?
 I'm not sure what's needed.

Should this be the same info-model that describes the connections to the
I2RS agent and relevant information and counters?

Do we have anyone motivated and interested in this particular area enough
to write up a short/quick draft and drive discussion?

Thanks,
Alia

On Wed, Aug 14, 2013 at 1:49 PM, Joe Marcus Clarke <[email-masked]>wrote:

> On 8/13/13 4:58 PM, Alia Atlas wrote:
> > I am going to publish an updated version of
> > draft-atlas-i2rs-architecture without fully addressing this point.
> >
> > I did add in a new subsection (6.4.1 Client Redundancy) under 6.4
> > Identity and Security Role that says:
> >
> > "I2RS must support client redundancy.  At the simplest, this can be
> > handled by having a primary and a backup network application that both
> > use the same client identity and can successfully authenticate as
> > such.  Since I2RS does not require a continuous transport connection
> > and supports multiple transport sessions, this can provide some basic
> > redundancy.  However, it does not address concerns for troubleshooting
> > and accountability about knowing which network application is actually
> > active.  At a minimum, basic transport information about each
> > connection and time can be logged with the identity.  Further
> > discussion is necessary to determine whether additional client
> > identification information is necessary.[[Editor's
> > note: This requires more discussion in the working group.]]"
>
> This is fine as a start.  I would want to strengthen the language to
> ensure that an I2RS Agent always stores Client connection information
> with a timestamp.  This information should be queriable via I2RS (with
> appropriate read scope).
>
> Joe
>
> >
> > Alia
> >
> >
> > On Thu, Aug 1, 2013 at 7:28 PM, Joe Marcus Clarke <[email-masked]
> > <mailto:[email-masked]>> wrote:
> >
> >     On 8/1/13 11:19 AM, Alia Atlas wrote:
> >     > Joe,
> >     >
> >     > Ok - so what I hear from you is needed is the
> >     >    client role
> >     >    client identity
> >     >    sub-client identity?
> >     >
> >     > Where the permissions and ownership of state is tied to the client
> >     role?
> >     >  Does that match to what you are saying?  I believe we're assuming
> >     that
> >     > the ownership of state is tied to the client identity - and you are
> >     > suggesting that if so, we need a client sub-identity or such?
> >
> >     Yes, I think that is in line with what I'm suggesting.  If we can
> allow
> >     Client A to assume the identity of Client B using the same
> credentials,
> >     I would want some way to know that this is indeed Client B now
> acting on
> >     behalf of either itself or some northbound controller.
> >
> >     Joe
> >
> >     >
> >     > Alia
> >     >
> >     >
> >     > On Thu, Aug 1, 2013 at 11:15 AM, Joe Marcus Clarke
> >     <[email-masked] <mailto:[email-masked]>
> >     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> >     >
> >     >     On 8/1/13 11:11 AM, Joel Halpern wrote:
> >     >     > The client is the entity that is authenticated and
> >     authorized. If the
> >     >     > client is acting on behalf of someone else, we assume that
> the
> >     >     > authentication and authorization of that party is the task
> >     of the
> >     >     client
> >     >     > and outside our scope. However we include that identity so
> that
> >     >     actions
> >     >     > can be easily correlated with originators.
> >     >
> >     >     Right.  I get that.  I had thought we were talking about two
> >     clients
> >     >     that might be redundant to each other where Client 1 dies and
> >     Client 2
> >     >     assumes its identity to make changes possibly driven by
> northbound
> >     >     actors.  Even in this case, I feel Client 2 still needs to
> >     maintain a
> >     >     unique identification to the I2RS agent so that one can trace
> the
> >     >     operation back to the specific I2RS client (in addition to the
> >     >     northbound actor).
> >     >
> >     >     Joe
> >     >
> >     >     >
> >     >     > Yours,
> >     >     > Joel
> >     >     >
> >     >     > Sent from my Android phone using TouchDown
> >     (www.nitrodesk.com <http://www.nitrodesk.com>
> >     >     <http://www.nitrodesk.com>)
> >     >     >
> >     >     > -----Original Message-----
> >     >     > *From:* Joe Marcus Clarke [[email-masked]
> >     <mailto:[email-masked]>
> >     >     <mailto:[email-masked] <mailto:[email-masked]>>]
> >     >     > *Received:* Thursday, 01 Aug 2013, 17:07
> >     >     > *To:* Alia Atlas [[email-masked]
> >     <mailto:[email-masked]> <mailto:[email-masked]
> >     <mailto:[email-masked]>>]
> >     >     > *CC:* Lou Berger [[email-masked] <mailto:[email-masked]>
> >     <mailto:[email-masked] <mailto:[email-masked]>>];
> >     >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> >     <mailto:[email-masked]>> [[email-masked] <mailto:[email-masked]>
> >     >     <mailto:[email-masked] <mailto:[email-masked]>>]; Joel
> >     >     > Halpern [[email-masked]
> >     <mailto:[email-masked]> <mailto:[email-masked]
> >     <mailto:[email-masked]>>]
> >     >     > *Subject:* Re: [i2rs] Provisions for Client Redundancy/Fault
> >     Tolerance
> >     >     > in draft-atlas-i2rs-architecture-01
> >     >     >
> >     >     > On 8/1/13 7:51 AM, Alia Atlas wrote:
> >     >     >> Not to answer for Joel, but my view is that a client is
> >     identified by
> >     >     >> its identity.  A different application can take over from
> the
> >     >     first by
> >     >     >> using the same identity.  Loss of a transport session does
> >     not cause
> >     >     >> existing client state to be removed (in the architecture) -
> so
> >     >     there is
> >     >     >> the ability for a new application to take over.
> >     >     >>
> >     >     >> Does that help?
> >     >     >
> >     >     > That worries me without more discussion about authentication.
> >     >     > Additionally, from a troubleshooting standpoint, if I can
> >     assume the
> >     >     > same identity as another client, how can I be absolutely
> >     sure which
> >     >     > client does what to the agent?  I feel there needs to be
> more to
> >     >     ensure
> >     >     > accountability of what client does what, certainly from a
> >     security
> >     >     > perspective, but also from a troubleshooting perspective.
> >     >     >
> >     >     > Joe
> >     >     >
> >     >     >>
> >     >     >> Alia
> >     >     >>
> >     >     >>
> >     >     >> On Thu, Aug 1, 2013 at 7:40 AM, Lou Berger
> >     <[email-masked] <mailto:[email-masked]>
> >     >     <mailto:[email-masked] <mailto:[email-masked]>>
> >     >     >> <mailto:[email-masked] <mailto:[email-masked]>
> >     <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
> >     >     >>
> >     >     >>     Hi Joel,
> >     >     >>             In today's session, I asked about provisions in
> the
> >     >     architecture
> >     >     >>     (document) for Client Redundancy/Fault Tolerance. I
> believe
> >     >     you stated
> >     >     >>     that "it's not needed" and that you'd elaborate on the
> >     list.
> >     >     >>
> >     >     >>     I believe you also answered a latter question by
> >     stating that
> >     >     clients
> >     >     >>     are free to coordinate between themselves to provide
> >     >     redundancy. Is this
> >     >     >>     the simple answer?  If not, can you elaborate?
> >     >     >>
> >     >     >>     Thanks,
> >     >     >>     Lou
> >     >     >>     _______________________________________________
> >     >     >>     i2rs mailing list
> >     >     >>     [email-masked] <mailto:[email-masked]>
> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked]
> >     <mailto:[email-masked]>
> >     >     <mailto:[email-masked] <mailto:[email-masked]>>>
> >     >     >>     https://www.ietf.org/mailman/listinfo/i2rs
> >     >     >>
> >     >     >>
> >     >     >>
> >     >     >>
> >     >     >> _______________________________________________
> >     >     >> i2rs mailing list
> >     >     >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> >     <mailto:[email-masked]>>
> >     >     >> https://www.ietf.org/mailman/listinfo/i2rs
> >     >     >>
> >     >     >
> >     >     >
> >     >     > --
> >     >     > Joe Marcus Clarke, CCIE #5384,         |          |
> >     >     > SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
> >     >     > Distinguished Services Engineer ..:|||||||||::|||||||||:..
> >     >     > Phone: +1 (919) 392-2867 <tel:%2B1%20%28919%29%20392-2867>
> >     <tel:%2B1%20%28919%29%20392-2867>
> >     >     c i s c o  S y s t e m s
> >     >     > Email: [email-masked] <mailto:[email-masked]>
> >     <mailto:[email-masked] <mailto:[email-masked]>>
> >     >     >
> >     >     >
> >     >
> >
> ----------------------------------------------------------------------------
> >     >
> >     >
> >     >     --
> >     >     Joe Marcus Clarke, CCIE #5384,         |          |
> >     >     SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
> >     >     Distinguished Services Engineer ..:|||||||||::|||||||||:..
> >     >     Phone: +1 (919) 392-2867 <tel:%2B1%20%28919%29%20392-2867>
> >     <tel:%2B1%20%28919%29%20392-2867>         c
> >     >     i s c o  S y s t e m s
> >     >     Email: [email-masked] <mailto:[email-masked]>
> >     <mailto:[email-masked] <mailto:[email-masked]>>
> >     >
> >     >
> >
> ----------------------------------------------------------------------------
> >     >
> >     >
> >
> >
> >     --
> >     Joe Marcus Clarke, CCIE #5384,         |          |
> >     SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
> >     Distinguished Services Engineer ..:|||||||||::|||||||||:..
> >     Phone: +1 (919) 392-2867 <tel:%2B1%20%28919%29%20392-2867>         c
> >     i s c o  S y s t e m s
> >     Email: [email-masked] <mailto:[email-masked]>
> >
> >
> ----------------------------------------------------------------------------
> >
> >
> >
> >
> > _______________________________________________
> > i2rs mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/i2rs
> >
>
>
> --
> Joe Marcus Clarke, CCIE #5384,         |          |
> SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
> Distinguished Services Engineer ..:|||||||||::|||||||||:..
> Phone: +1 (919) 392-2867         c i s c o  S y s t e m s
> Email: [email-masked]
>
>
> ----------------------------------------------------------------------------
>

---

From: "Russ White" <[email-masked]>
Date: Fri, 16 Aug 2013 08:56:03 -0400

> done is not appealing.  

Why not? If the data model on the wire is efficient, then the only thing
left to add efficiency to the file sizes would be aggregating the
information somehow. It seems, to me, that it's easiest just to store the
data in the on-the-wire tlv format, and have locally configurable filters
about what to save or not, etc. These might want to be really intelligent
filters, like, "only save the last five instances of this specific state
change," rather than, "save the last four hundred state changes of any
type," but the WG doesn't need to address these filters at all --they would
be implementation specific.

Russ

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 16 Aug 2013 09:12:13 -0400

If an implementation wants to store the data, more power to them.  If 
there is a syslog format or a file dump format defined outside I2RS for 
reporting the data, great.
But I do not want I2RS mandating storage or reporting of the data.  That 
is not our job.

Yours,
Joel

---

From: "Russ White" <[email-masked]>
Date: Fri, 16 Aug 2013 09:26:19 -0400

> If an implementation wants to store the data, more power to them.  If
there
> is a syslog format or a file dump format defined outside I2RS for
reporting the
> data, great.
is not
> our job.

Agreed --but I think the question is --should I2RS create a new format for
storing such data? IMHO, the answer is no. If the on-the-wire representation
is efficient, then we've already created a way to store the data for anyone
who wants to.

Russ

---

From: Alia Atlas <[email-masked]>
Date: Fri, 16 Aug 2013 09:39:04 -0400

Russ,

The on-the-wire representation is insufficient.  It doesn't include things
like time, client identity, transport connection information, etc.

Alia

---

From: "Russ White" <[email-masked]>
Date: Fri, 16 Aug 2013 09:55:21 -0400

> The on-the-wire representation is insufficient.  It doesn't include things
like
> time, client identity, transport connection information, etc.

Two points to consider:

1. As I've said elsewhere, we need to focus our scope if we're to make
progress.

2. It seems, to me, that these are actually problems that are general in
nature, and therefore applicable to every possible protocol in the same way
(not just I2RS). I think we (the IETF and the community at large) have
defined solutions to these very same problems many times --maybe it's time
to define a format that includes these in the management area, with a set of
open ended tlv spaces and a corresponding registry that could be used for
any protocol (OSPF, IS-IS, I2RS, BGP, etc.), so we don't continuously
reinvent the wheel in this space.

Just a thought.

Russ

---

From: Alia Atlas <[email-masked]>
Date: Fri, 16 Aug 2013 10:29:30 -0400

> 1. As I've said elsewhere, we need to focus our scope if we're to make

[Alia] Yes, absolutely.  I've said it is a second-order problem - but if
there is someone who
wants to work on it, that's fine.

> reinvent the wheel in this space.

[Alia] In the I2RS case, we will have the advantage of structured data and
protocol-specific information that can be easily articulated.  Maybe
NetConf has already solved some of this?  I don't personally know yet.  If
someone wants to take the fairly specific case of having structured storage
of actions for I2RS and generalize it for network management, I don't think
that would be in the scope of I2RS.

Alia

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Fri, 16 Aug 2013 10:31:55 -0400

There is no doubt that it isn't sufficient. But I think the overarching goal in this case should be agility and expeditiousness, so scope should be constrained to something manageable that might facilitate that.  There is precedent to doing such work (long) after the core work has been done.  In fact, in RAI we formed a WG specifically for defining a data model and logging format (RFC 6872 and 6873) for SIP several years after the fact.  Couldn't we lessen our current burden and do something similar here?

Gonzalo

On Aug 16, 2013, at 9:39 AM, Alia Atlas <[email-masked]>
 wrote:

> Russ,
> 
> The on-the-wire representation is insufficient.  It doesn't include things like time, client identity, transport connection information, etc.
> 
> Alia
> 
>

---

From: Alia Atlas <[email-masked]>
Date: Fri, 16 Aug 2013 10:41:16 -0400

Hi Gonzalo,

If there are people who want to go off and brainstorm up an info-model that
would augment any other info-model to put in the information necessary for
storing a meaningful operations history, that could be very interesting to
read.

Whether it is required, in-scope, the highest priority to work on, etc. are
different questions.

Hearing the lessons learned and why RAI felt the need to do the work for
SIP after and what would have been easier had it been done first might be
interesting to hear on the list.

Alia

On Fri, Aug 16, 2013 at 10:31 AM, Gonzalo Salgueiro <[email-masked]>wrote:

> There is no doubt that it isn't sufficient. But I think the overarching
> goal in this case should be agility and expeditiousness, so scope should be
> constrained to something manageable that might facilitate that.  There is
> precedent to doing such work (long) after the core work has been done.  In
> fact, in RAI we formed a WG specifically for defining a data model and
> logging format (RFC 6872 and 6873) for SIP several years after the fact.
>  Couldn't we lessen our current burden and do something similar here?
>
> Gonzalo
>
>
> > The on-the-wire representation is insufficient.  It doesn't include
> things like time, client identity, transport connection information, etc.
> >
> > Alia
> >
> >

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Fri, 16 Aug 2013 10:51:00 -0400

Hi Alia - 

On Aug 16, 2013, at 10:41 AM, Alia Atlas <[email-masked]> wrote:

> Hi Gonzalo,
> 
> If there are people who want to go off and brainstorm up an info-model that would augment any other info-model to put in the information necessary for storing a meaningful operations history, that could be very interesting to read.
> 
> Whether it is required, in-scope, the highest priority to work on, etc. are different questions.
> 
> Hearing the lessons learned and why RAI felt the need to do the work for SIP after and what would have been easier had it been done first might be interesting to hear on the list.

It was done after the fact for reasons of scope containment and, as is typically the case with such troubleshooting efforts (right or wrong), it was considered lower priority than the core protocol work.  It also time sync'ed nicely with some ongoing discussions of how short-lived WGs with a very clear and directed purpose with a reasonable number milestones were the preferred model.

Gonzalo

> 
> Alia
> 
> 
> On Fri, Aug 16, 2013 at 10:31 AM, Gonzalo Salgueiro <[email-masked]> wrote:

---

From: Alia Atlas <[email-masked]>
Date: Fri, 16 Aug 2013 11:00:40 -0400

Hi Gonzalo,

Ok - that doesn't tell me that it was the wrong decision :-) or that I2RS
should do something differently.

Alia

On Fri, Aug 16, 2013 at 10:51 AM, Gonzalo Salgueiro <[email-masked]>wrote:

> > If there are people who want to go off and brainstorm up an info-model
> that would augment any other info-model to put in the information necessary
> for storing a meaningful operations history, that could be very interesting
> to read.
> >
> It was done after the fact for reasons of scope containment and, as is
> typically the case with such troubleshooting efforts (right or wrong), it
> was considered lower priority than the core protocol work.  It also time
> sync'ed nicely with some ongoing discussions of how short-lived WGs with a
> very clear and directed purpose with a reasonable number milestones were
> the preferred model.
>
> Gonzalo
>
> >
> > Alia
> >
> >

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Fri, 16 Aug 2013 11:17:21 -0400

Hi Alia - 

On Aug 16, 2013, at 11:00 AM, Alia Atlas <[email-masked]> wrote:

> Hi Gonzalo,
> 
> Ok - that doesn't tell me that it was the wrong decision :-) or that I2RS should do something differently.

No, nor am I ;-)

I was merely offering up the historical precedent for doing this work after the fact considering the effects of scope creep and delay. I don't argue that an investigation into an information model and log format of such structured data would be an interesting read.  In fact, I agree that it certainly would.  I just worry that each such effort, even if ad-hoc and done outside WG purview, could reduce cycles best applied to the core work.

Gonzalo

> 
> Alia
> 
> 
> On Fri, Aug 16, 2013 at 10:51 AM, Gonzalo Salgueiro <[email-masked]> wrote:
> Hi Alia -
>

---

From: Alia Atlas <[email-masked]>
Date: Fri, 16 Aug 2013 12:22:04 -0400

Thanks, Gonzalo.  That was what I was trying to understand.

I would also prefer focus on the core work.  In particular, augmenting and
nailing down our use-cases, starting on the other protocol-related info
models, and starting to define the protocol requirements and data-modeling
requirements would be very helpful.

We'll need to be discussing the protocol and data-modeling requirements
and, hopefully, which protocols and data-modeling languages can support
them and what extensions might be required.  I'd really like to see I2RS
ready to do that in sophisticated detail by November.

As a reminder, our milestones are:

  Jul 2013 - Request publication of an Informational document defining
the problem statement
  Jul 2013 - Request publication of an Informational document defining
the high-level architecture
  Aug 2013 - Request publication of Informational documents describing use cases
  Sep 2013 - Request publication of an Informational document defining
the protocol requirements
  Sep 2013 - Request publication of an Informational document defining
encoding language requirements
  Feb 2014 - Request publication of Standards Track documents
specifying information models
  Feb 2014 - Request publication of an Informational document
providing an analysis of existing IETF and other protocols and
encoding languages against the requirements
  Feb 2014 - Consider re-chartering

Alia

On Fri, Aug 16, 2013 at 11:17 AM, Gonzalo Salgueiro <[email-masked]>wrote:

> I was merely offering up the historical precedent for doing this work
> after the fact considering the effects of scope creep and delay. I don't
> argue that an investigation into an information model and log format of
> such structured data would be an interesting read.  In fact, I agree that
> it certainly would.  I just worry that each such effort, even if ad-hoc and
> done outside WG purview, could reduce cycles best applied to the core work.
>
> Gonzalo
>
>
> >
> > Alia
> >
> >
> > > Hearing the lessons learned and why RAI felt the need to do the work
> for SIP after and what would have been easier had it been done first might
> be interesting to hear on the list.
> >
> > > There is no doubt that it isn't sufficient. But I think the
> overarching goal in this case should be agility and expeditiousness, so
> scope should be constrained to something manageable that might facilitate
> that.  There is precedent to doing such work (long) after the core work has
> been done.  In fact, in RAI we formed a WG specifically for defining a data
> model and logging format (RFC 6872 and 6873) for SIP several years after
> the fact.  Couldn't we lessen our current burden and do something similar
> here?
> > >
> > > Gonzalo
> > >
> > >