Re: [Gen-art] Gen-art telechat review of draft-ietf-i2rs-traceability-09

[Elwyn Davies <[e-mail]>]

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.

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?

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