Re: [RTG-DIR] [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08

[Joe Clarke <[e-mail]>]

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); [e-mail]
>> Cc: [e-mail]; [e-mail]; [e-mail]
>> 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