Skip to main content

Last Call Review of draft-ietf-i2rs-traceability-08
review-ietf-i2rs-traceability-08-genart-lc-davies-2016-05-05-00

Request Review of draft-ietf-i2rs-traceability
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2016-04-29
Requested 2016-04-27
Authors Joe Clarke , Gonzalo Salgueiro , Carlos Pignataro
I-D last updated 2016-05-05
Completed reviews Genart Last Call review of -09 by Elwyn B. Davies (diff)
Genart Last Call review of -08 by Elwyn B. Davies (diff)
Secdir Last Call review of -08 by Watson Ladd (diff)
Opsdir Last Call review of -08 by Menachem Dodge (diff)
Rtgdir Early review of -06 by Mach Chen (diff)
Rtgdir Early review of -06 by Les Ginsberg (diff)
Assignment Reviewer Elwyn B. Davies
State Completed
Request Last Call review on draft-ietf-i2rs-traceability by General Area Review Team (Gen-ART) Assigned
Reviewed revision 08 (document currently at 11)
Result Ready
Completed 2016-05-05
review-ietf-i2rs-traceability-08-genart-lc-davies-2016-05-05-00
Hi.

I had a look at the revised diff.  Looks pretty good now.

Couple of minor points in line below.

Cheers,
Elwyn

On 11/05/2016 16:18, Joe Clarke wrote:



On 5/10/16 17:51, Elwyn Davies wrote:



s1, para 2: s/describes use cases/describe use cases/




Fixed.





s5.2, Event ID:



An event can be a Client authenticating with the Agent, a Client to
Agent operation, or a Client disconnecting from an Agent.



This is a good thing, but I am not sure that the format provides a way
to identify the authentication and disconnection events.






The intent was that these would be Operations (i.e., AUTHENTICATE 


CLIENT, DISCONNECT CLIENT).  There is nothing in the text that 


precludes this.  We can explicitly state this.



I think stating it explicitly would be a good idea.









s5.2, Starting Timestamp:
[I don't understand 'three points of prevision'.] Maybe...
OLD:
Given that many I2RS operations can occur in rapid succession, the use
of fractional seconds MUST be used to provide adequate granularity.
Fractional seconds SHOULD be expressed with at least three points of
prevision in second.microsecond format.
NEW:
Given that many I2RS operations can occur in rapid succession, the
fractional seconds element of the timestamp MUST be used to provide
adequate granularity.  Fractional seconds SHOULD be expressed with at
least three [or more?] significant digits in second.microsecond format.
END




Changed.


Do you think millisecond resolution will be good enough?  I put in three 


because of the 'three points of prevision'   but wonder if you might 


need something closer to microsecond resolution in high throughput 


routers?  I don't know what might be desirable - I have some experience 


of a similar logging system (DTN2) and full microsecond resolution is 


occasionally useful.









s5.2, Ending Timestamp:
See the comments on the Starting Timestamp - though I think you could
just refer to the words in the Starting Timestamp and avoid duplication.




Done.





s7.4/s7.4.3: Given that the I2RS pub-sub access method is
mandatory-to-implement, i think I-D.ietf-i2rs-pub-sub-requirements has
to be a Normative Reference.




Changed.



See the new text at 


https://www.marcuscom.com/draft-ietf-i2rs-traceability.txt-from-09-10.diff.html




.




Thanks again for the review!

Joe