On 5/13/16 08:17, Les Ginsberg (ginsberg) wrote:
Joe -
Something like the attached file perhaps?
Thanks. We have posted rev -10 of this draft that should address all of
your comments.
Joe
Les
-----Original Message-----
From: Joe Clarke (jclarke)
Sent: Wednesday, May 11, 2016 3:21 PM
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/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
