Joe -
Something like the attached file perhaps?
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
> >
+---------------+
+----------------+ |
|Application | |
|.............. | | 0 or more Applications
| Application ID | +
+----------------+
^
|
|
v
+-------------+
+-------------+ |
|I2RS Client | | 1 or more Clients
|.............| |
| Client ID | +
+-------------+
^
|
|
v
+-------------+ +-----------------------------+
|I2RS Agent |---------------->|Trace Log |
| | |.............................|
+-------------+ |Log Entry [1 .. N] |
^ |.............................|
| |Starting Timestamp |
| |Request State |
| |Client ID |
| |Client Priority |
| ^ |Secondary ID |
Operation + | Result Code |Client Address |
Op Data | |Requested Operation |
v | |Applied Operation |
| |Operation Data Present |
| |Requested Operation Data |
| |Applied Operation Data |
| |Transaction ID |
| |Result Code |
| |Ending Timestamp |
| |Timeout Occurred |
v |End Of Message |
+-------------+ +-----------------------------+
|Routing |
|System |
+-------------+
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
