Thanx Joe - looks good. Les
> -----Original Message----- > From: Joe Clarke (jclarke) > Sent: Friday, May 13, 2016 8:36 AM > To: Les Ginsberg (ginsberg); [email protected] > Cc: [email protected]; [email protected]; [email protected] > 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); [email protected] > >> Cc: [email protected]; [email protected]; > >> [email protected] > >> 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); [email protected] > >>>> Cc: [email protected]; [email protected]; > >>>> [email protected] > >>>> 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); [email protected] > >>>>>> Cc: [email protected]; [email protected]; > >>>>>> [email protected] > >>>>>> 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 > >>> > > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
