Les, Thank you very much for your review.
Joe, Thanks for following up. I'll get this on the IESG telechat for next Thurs. Regards, Alia On Fri, Apr 29, 2016 at 1:43 PM, Joe Clarke <[email protected]> wrote: > 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? > > 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? > > >> >> >> 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. > > >> >> >> 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? > > >> >> >> 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
