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

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

Thanx Joe - looks good.

   Les



> -----Original Message-----
> From: Joe Clarke (jclarke)
> Sent: Friday, May 13, 2016 8:36 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/13/16 08:17, Les Ginsberg (ginsberg) wrote:
> > Joe -
> >
> > Something like the attached file perhaps?
> 
> Thanks.  We have posted rev -10 of this draft that should address all of your
> comments.
> 
> Joe
> 
> >
> >    Les
> >
> >
> >> -----Original Message-----
> >> From: Joe Clarke (jclarke)
> >> Sent: Wednesday, May 11, 2016 3:21 PM
> >> 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/11/16 17:39, Les Ginsberg (ginsberg) wrote:
> >>> Joe -
> >>>
> >>> Yes - this looks better to me.
> >>>
> >>> What about the "shadow boxes" for Applications/Clients?
> >>
> >> Do you have an example draft I could look at for that?
> >>
> >> Joe
> >>
> >>>
> >>>    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
> >>>
> >