Subject: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 27 Apr 2016 21:39:39 +0000

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-i2rs-traceability<https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/>

Reviewer: Les Ginsberg

Review Date: April 27, 2016

IETF LC End Date: April 29, 2016

Intended Status: Informational

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.

Major Issues: None

Minor Issues:

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.

Along with this an additional timestamp - Processing Initiated - would be useful to indicate when processing of the request actually began.

Nits:

Section 5.1

s/Some notable elements on the architecture/ Some notable elements of the architecture

Figure 1

Not clear to me why Application IDs start at 0 but Client IDs start at 1.

Figure 1

Is the text "Op Data V" between I2RS Agent box and Routing System box intentional?

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.

Section 7.4

s/establish an vendor-agnostic/establish a vendor-agnostic

---

From: Joe Clarke <[email-masked]>
Date: Fri, 29 Apr 2016 13:43:52 -0400

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?

> s/Some notable elements on the architecture/ Some notable elements of

Fixed.  Thanks!

> 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?

> Is the text "Op Data V" between I2RS Agent box and Routing System box

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.

>
>
>
> 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?

> s/establish an vendor-agnostic/establish a vendor-agnostic

Fixed.  Thanks!

Joe

---

From: Alia Atlas <[email-masked]>
Date: Fri, 29 Apr 2016 14:55:18 -0400

Les,

Thank you very much for your review.

Joe,
Thanks for following up.  I'll get this on the IESG telechat for next Thurs.

Regards,
Alia

On Fri, Apr 29, 2016 at 1:43 PM, Joe Clarke <[email-masked]> wrote:

> Good observation.  Traceability was aimed mainly at the termination of the
> request, but I like the idea of tracing the state machine.
>
>
>>
>>
> 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?
>
>
>>
>>
>> Figure 1
>>
>>
>>
> 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.
>
> empty.  If there is an application, then whatever value is provided will be
> logged.
>