Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 10 May 2016 22:04:29 +0000

Joe -

Apologies for the delayed response. I am a victim of my own email infilters. :-(
Inline.

> -----Original Message-----
> From: Joe Clarke (jclarke)
> Sent: Friday, April 29, 2016 10:44 AM
> To: Les Ginsberg (ginsberg); [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08
> 
> On 4/27/16 17:39, Les Ginsberg (ginsberg) wrote:
> > Summary:  This document is a well written document - easy to understand.
> > My compliments to the authors. I believe there is one minor issue
> > which I would like to see addressed before publication.
> 
> Thanks for your comments and feedback, Les.  Please see below for some
> replies and questions.
> 
> > In Section 5.2 there is a definition of the information which is
> > required to be kept by an I2RS Agent for each I2RS interaction. I
> > would like to see the addition of "Request State" into this list.
> > Operationally each request could be in one of the following states:
> >
> >
> >
> > *         Enqueued (or pending if you prefer)
> >
> > *         In process
> >
> > *         Completed
> >
> >
> >
> > The lack of such a state seems to imply that both the queue time and
> > the processing time are insignificant. While I think this may be the
> > case for many requests, it will not always be the case. In queue time
> > may be lengthy due to other load on the Agent. Also, some requests -
> > particularly destructive requests which involve cleanup of resources -
> > may take a significant amount of time to complete.
> 
> Good observation.  Traceability was aimed mainly at the termination of the
> request, but I like the idea of tracing the state machine.
> 
> >
> >
> >
> > Along with this an additional timestamp - Processing Initiated - would
> > be useful to indicate when processing of the request actually began.
> 
> I don't know we need a new timestamp.  Perhaps we just need to rename
> "Request Timestamp" and "Result Timestamp" to "Start Timestamp" and
> "End Timestamp" to denote the time within the current state.  What do you
> think?

[Les:] My intent was to log the time at which the request began processing so that you can see whether a long delay in completion was due to enqueue  delay or actual lengthy processing time. I am not adamant about this so if you want to stay with the two timestamps that is OK.

> 
> > s/Some notable elements on the architecture/ Some notable elements of
> > the architecture
> 
> Fixed.  Thanks!
> 
> >
> >
> >
> > Figure 1
> >
> >
> >
> > Not clear to me why Application IDs start at 0 but Client IDs start at 1.
> 
> Ah.  The numbers there are not IDs.  They are the number of actual things in
> the boxes above.  For Applications, there may be 0 to N for a given client.  For
> Clients, you need at least 1.  Does that make sense?
> 
[Les:] Maybe you want to use "shadows" on the boxes to indicate there can be multiple Application boxes and multiple Client boxes?
What you say makes sense but I do not intuit that when I look at the ASSCII art.

> >
> >
> >
> > Figure 1
> >
> >
> >
> > Is the text "Op Data V" between I2RS Agent box and Routing System box
> > intentional?
> 
> Yes.  The 'V' is meant to be an arrow head pointed down.  The request
> and data go from Client to Agent whereas the Response goes from Agent to
> Client.
> 
> We are open to suggestions on how to make this clearer.

[Les:] I think it would be clearer if you had two lines - one flowing down associated with the Op Data and one flowing up with the result.

> 
> >
> >
> >
> > Section 5.2
> >
> >
> >
> > Secondary Identity
> >
> >
> >
> > This is defined to be "opaque" yet if not provided the agent is supposed
> > to insert "an UNAVAILABLE value". This seems to be a contradiction
> > unless we have a publicly defined value that clients are prohibited from
> > using. Absent that you would need a "Secondary Identity Valid" indicator.
> 
> Good observation.  I think it's fine to say that this field must be
> logged.  If there is no application, then the field will be logged as
> empty.  If there is an application, then whatever value is provided will
> be logged.
> 
> Do you feel strongly that we need a field to indicate Application Present?
>
[Les:] I am fine w your changes.

   Les
 
> >
> >
> >
> > Section 7.4
> >
> >
> >
> > s/establish an vendor-agnostic/establish a vendor-agnostic
> 
> Fixed.  Thanks!
> 
> Joe

---

From: Joe Clarke <[email-masked]>
Date: Wed, 11 May 2016 11:18:38 -0400

> Apologies for the delayed response. I am a victim of my own email infilters. :-(

Thanks, Les.  Have a look at 
https://www.marcuscom.com/draft-ietf-i2rs-traceability.txt-from-09-10.diff.html 
.  I added a new line to show the flow in both directions.

Joe

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 11 May 2016 21:39:29 +0000

Joe -

Yes - this looks better to me.

What about the "shadow boxes" for Applications/Clients?

   Les

> Sent: Wednesday, May 11, 2016 8:19 AM
> > Apologies for the delayed response. I am a victim of my own email
> > infilters. :-( Inline.
> 
> >> Thanks for your comments and feedback, Les.  Please see below for
> >> some replies and questions.
> >>
> >>> case for many requests, it will not always be the case. In queue
> >>> time may be lengthy due to other load on the Agent. Also, some
> >>> requests - particularly destructive requests which involve cleanup
> >>> of resources - may take a significant amount of time to complete.
> >>
> >> Good observation.  Traceability was aimed mainly at the termination
> >> of the request, but I like the idea of tracing the state machine.
> >>
> >>>
> >>>
> >>>
> >>> Along with this an additional timestamp - Processing Initiated -
> >>> would be useful to indicate when processing of the request actually
> began.
> >>
> >> "End Timestamp" to denote the time within the current state.  What do
> >> you think?
> >
> > [Les:] My intent was to log the time at which the request began processing
> so that you can see whether a long delay in completion was due to enqueue
> delay or actual lengthy processing time. I am not adamant about this so if you
> want to stay with the two timestamps that is OK.
> >
> >>
> >>> s/Some notable elements on the architecture/ Some notable elements
> >>> of the architecture
> >>
> >> Fixed.  Thanks!
> >>
> >>>
> >>>
> >>>
> >>> Figure 1
> >>>
> >>>
> >>>
> >> Ah.  The numbers there are not IDs.  They are the number of actual
> >> things in the boxes above.  For Applications, there may be 0 to N for
> >> a given client.  For Clients, you need at least 1.  Does that make sense?
> >>
> > [Les:] Maybe you want to use "shadows" on the boxes to indicate there
> can be multiple Application boxes and multiple Client boxes?
> >>> Is the text "Op Data V" between I2RS Agent box and Routing System
> >>> box intentional?
> >>
> >> and data go from Client to Agent whereas the Response goes from Agent
> >> to Client.
> >>
> > [Les:] I think it would be clearer if you had two lines - one flowing down
> associated with the Op Data and one flowing up with the result.
> >
> >>
> >>>
> >>>
> >>>
> >>> Section 5.2
> >>>
> >>>
> >>>
> >>> Secondary Identity
> >>>
> >>>
> >>>
> >>> This is defined to be "opaque" yet if not provided the agent is
> >>> supposed to insert "an UNAVAILABLE value". This seems to be a
> >>> contradiction unless we have a publicly defined value that clients
> >>> are prohibited from using. Absent that you would need a "Secondary
> Identity Valid" indicator.
> >>
> >> empty.  If there is an application, then whatever value is provided
> >> will be logged.
> >>

---

From: Joe Clarke <[email-masked]>
Date: Wed, 11 May 2016 18:20:58 -0400

> What about the "shadow boxes" for Applications/Clients?

Do you have an example draft I could look at for that?

Joe

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 13 May 2016 12:17:47 +0000

Joe -

Something like the attached file perhaps?

   Les

> Sent: Wednesday, May 11, 2016 3:21 PM
> >>>>> The lack of such a state seems to imply that both the queue time
> >>>>> and the processing time are insignificant. While I think this may
> >>>>> be the case for many requests, it will not always be the case. In
> >>>>> queue time may be lengthy due to other load on the Agent. Also,
> >>>>> some requests - particularly destructive requests which involve
> >>>>> cleanup of resources - may take a significant amount of time to
> complete.
> >>>>
> >>>> "End Timestamp" to denote the time within the current state.  What
> >>>> do you think?
> >>>
> >> so that you can see whether a long delay in completion was due to
> >> enqueue delay or actual lengthy processing time. I am not adamant
> >> about this so if you want to stay with the two timestamps that is OK.
> >>>
> >>>>
> >>>> things in the boxes above.  For Applications, there may be 0 to N
> >>>> for a given client.  For Clients, you need at least 1.  Does that make
> sense?
> >>>>
> >>> What you say makes sense but I do not intuit that when I look at the
> >>> ASSCII
> >> art.
> >>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Figure 1
> >>>>>
> >>>>>
> >>>>>
> >>>> Yes.  The 'V' is meant to be an arrow head pointed down.  The
> >>>> request and data go from Client to Agent whereas the Response goes
> >>>> from Agent to Client.
> >>>>
> >>>> logged.  If there is no application, then the field will be logged
> >>>> as empty.  If there is an application, then whatever value is
> >>>> provided will be logged.
> >>>>

---

From: Joe Clarke <[email-masked]>
Date: Fri, 13 May 2016 11:35:37 -0400

> Something like the attached file perhaps?

Thanks.  We have posted rev -10 of this draft that should address all of 
your comments.

Joe

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 17 May 2016 07:12:00 +0000

Thanx Joe - looks good.

   Les

> Sent: Friday, May 13, 2016 8:36 AM
> Thanks.  We have posted rev -10 of this draft that should address all of your
> comments.
> 
> Joe
> 
> >
> >    Les
> >
> >
> >>>>>>> My compliments to the authors. I believe there is one minor
> >>>>>>> issue which I would like to see addressed before publication.
> >>>>>>
> >>>>>>> required to be kept by an I2RS Agent for each I2RS interaction.
> >>>>>>> I would like to see the addition of "Request State" into this list.
> >>>>>>> and the processing time are insignificant. While I think this
> >>>>>>> may be the case for many requests, it will not always be the
> >>>>>>> case. In queue time may be lengthy due to other load on the
> >>>>>>> Agent. Also, some requests - particularly destructive requests
> >>>>>>> which involve cleanup of resources - may take a significant
> >>>>>>> amount of time to
> >> complete.
> >>>>>>
> >>>>>> Good observation.  Traceability was aimed mainly at the
> >>>>>> termination of the request, but I like the idea of tracing the state
> machine.
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> "End Timestamp" to denote the time within the current state.
> >>>>>> What do you think?
> >>>>>
> >>>>>> Ah.  The numbers there are not IDs.  They are the number of
> >>>>>> actual things in the boxes above.  For Applications, there may be
> >>>>>> 0 to N for a given client.  For Clients, you need at least 1.
> >>>>>> Does that make
> >> sense?
> >>>>>>
> >>>>> What you say makes sense but I do not intuit that when I look at
> >>>>> the ASSCII
> >>>> art.
> >>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Figure 1
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Is the text "Op Data V" between I2RS Agent box and Routing
> >>>>>>> System box intentional?
> >>>>>>
> >>>>>> request and data go from Client to Agent whereas the Response
> >>>>>> goes from Agent to Client.
> >>>>>>
> >>>>>>> contradiction unless we have a publicly defined value that
> >>>>>>> clients are prohibited from using. Absent that you would need a
> >>>>>>> "Secondary
> >>>>>> Good observation.  I think it's fine to say that this field must
> >>>>>> be logged.  If there is no application, then the field will be
> >>>>>> logged as empty.  If there is an application, then whatever value
> >>>>>> is provided will be logged.
> >>>>>>