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
