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 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
