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

[Joe Clarke <[e-mail]>]

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