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); rtg-...@ietf.org > Cc: rtg-...@ietf.org; draft-ietf-i2rs-traceabil...@ietf.org; i2rs@ietf.org > 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); rtg-...@ietf.org > >> Cc: rtg-...@ietf.org; draft-ietf-i2rs-traceabil...@ietf.org; > >> i2rs@ietf.org > >> 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 i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
