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
