On 5/13/16 16:43, Elwyn Davies wrote:
Hi, Joe.
Thanks for the heads up.
Apologies - I missed one question that I should have asked. You have
removed the idea that the specified fields are mandatory in s5.2. My
original issue with this was about whether you would envisage that
implementors could add additional, optional fields to the basic set, and
if so would it be good to mention/explain how this would be handled.
No problem. Revision numbers are cheap :-).
The current state gives a rigid set of fields in each trace report with
no flexibility (or at least not within the specification). Is this
what the authors intended?
We set out to list those things that we wanted to see from a baseline,
all-vendor point of view. Your point was raised more than once, but I
personally was worried that a broad, "plus anything else" statement
might also receive some criticism.
Do you have any examples we might add as an "e.g." to set context?
Things that crossed my mind were Client vendor (think User-Agent type
data) and Agent stats like free memory. The former isn't part of the
architecture, but could be implemented by a vendor. The latter might be
useful in certain support scenarios.
Joe
Cheers,
Elwyn
On 13/05/2016 16:36, Joe Clarke wrote:
On 5/11/16 15:11, Elwyn Davies wrote:
Hi.
I had a look at the revised diff. Looks pretty good now.
Couple of minor points in line below.
Thanks, Elwyn. We have posted rev -10 of the draft, which should
address all of your comments.
Joe
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
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
