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

["Les Ginsberg (ginsberg)" <[e-mail]>]

Joe -

Yes - this looks better to me.

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

   Les


> -----Original Message-----
> From: Joe Clarke (jclarke)
> Sent: Wednesday, May 11, 2016 8:19 AM
> To: Les Ginsberg (ginsberg); [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08
> 
> On 5/10/16 18:04, Les Ginsberg (ginsberg) wrote:
> > Joe -
> >
> > Apologies for the delayed response. I am a victim of my own email
> > infilters. :-( Inline.
> 
> 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
> 
> >
> >> -----Original Message-----
> >> From: Joe Clarke (jclarke)
> >> Sent: Friday, April 29, 2016 10:44 AM
> >> To: Les Ginsberg (ginsberg); [e-mail]
> >> Cc: [e-mail]; [e-mail];
> >> [e-mail]
> >> 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