Re: [Insipid] Review of draft-ietf-insipid-logme-marking-07

["Vijay K. Gurbani" <[e-mail]>]

Paul, Peter: Thank you for the feedback.

Peter, since Paul's recollection is on the spot, it appears to be
reasonable to use his text as a starting point.  S3.2 can be clarified
by replacing the existing paragraph to something like the following
(please feel free to discard, edit, or adopt):

  A user agent or proxy adds a "log me" marker in a request or response
  for two reasons: either it is configured to do so or it has detected
  that a dialog is being "log me" marked, causing it to maintain state
  to ensure that all requests and responses in the dialog are "log me"
  marked.

  When a user agent or proxy is configured to add a "log me" marker in
  messages, the duration that the user agent or proxy will be so
  configured is out of the scope of this document.  For instance, the
  user agent client or proxy could be configured to add a "log me"
  marker for a certain number of requests, or it could be configured to
  mark messages with a temporal scope (i.e., 9:00am - 10:00am every
  day), or it could be configured to mark messages when it encounters a
  specific "User-Agent" header.

  On the other hand, when a user agent or proxy detects that a dialog-
  initiating request is being "log me" marked, the scope of such marking
  extends to the lifetime of the dialog.  In addition, as discussed in
  Section 3.7, "log me" marked dialogues that create related dialogues
  (REFER) may transfer the marking to the related dialogues.  In such
  cases, the entire "session", identified by the Session-ID header, is
  "log me" marked.

Thanks,

On 06/15/2017 05:30 AM, Dawes, Peter, Vodafone Group wrote:
> Hello Vijay, Paul,
> Paul's summary is correct and the review comment from Vijay indicates that section 3.2 needs to be clearer on configuration vs. per-dialog scope of "log me" marking.
> 
> An example of configuration is that a service provider might have a test terminal programmed to run through a set of SIP sessions (call, call re-directed at set up, call transfer) and this terminal would be configured to "log me" mark all of them. An example of per-dialog scope is a SIP terminating user agent, which needs to be aware that a dialog is being "log me" marked (i.e. it needs to be stateful) in order to mark any in-dialog requests that it sends (e.g. BYE). Such a terminating UA knows that when the dialog ends it can close its signalling log for that dialog and stop marking requests that it sends. Such a user agent does not use configuration to perform "log me" marking.
> 
> We will clarify S3.2 in the next revision. 
> 
> Regards,
> Peter
> 
>> -----Original Message-----
>> From: insipid [mailto:[e-mail]] On Behalf Of Paul Kyzivat
>> Sent: 14 June 2017 22:17
>> To: [e-mail]
>> Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-marking-07
>>
>> On 6/14/17 3:18 PM, Vijay K. Gurbani wrote:
>>> Hello,
>>>
>>> I was asked by the authors to review
>>> draft-ietf-insipid-logme-marking-07.  My review is below.
>>>
>>> Summary: good stuff, but some issues need to be addressed as
>>> documented next.
>>>
>>> MAJOR:
>>>
>>> - S3.2: So, it appears from the last sentence that "log me" is scoped by
>>>    the dialogue.  If through some configuration, a SIP UA is configured
>>>    to insert the "logme" parameter, then the UA will continue inserting
>>>    the parameter for all dialogues created by the UA until configured to
>>>    stop inserting the parameter, right?
>>>
>>>    If so, then the scope of the "logme" parameter is driven by
>>>    configuration more than a dialogue.  This should be made clear in the
>>>    text, as there are many places that state that "logme" is scoped to a
>>>    dialogue (S6.4.5, for instance).
>>>
>>>    I believe this is an important aspect to clarify: Is the "logme"
>>>    scoped by a dialogue or through configuration, as time limited as that
>>>    configuration may be?  My reading of the draft suggests that the
>>>    scoping is through configuration, and S6.4.5 appears to support this
>>>   (in my reading, at least).
>>
>> I'm not an author, so this can be a test of how clear they have been.
>>
>> IIUC, a given logme "session" is dialog scoped. (Though not exactly, since in
>> the presence of B2BUAs it becomes a set of related dialogs.) This is identified
>> by the SessionID. Those entities that did not initiate the logging need to keep
>> state for that duration. And of course this then is tied to the resulting logs.
>>
>> Some entities may also have some other state that causes them to initiate
>> logging "sessions". The duration of that state is undefined.
>>
>> Now the authors can say if I got it right.
>>
>> 	Thanks,
>> 	Paul
>>
>> _______________________________________________
>> insipid mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/insipid
> 
> _______________________________________________
> insipid mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/insipid
> 


- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Nokia Networks
Email: [e-mail] / [e-mail]
Web: https://www.bell-labs.com/usr/vijay.gurbani
Calendar: http://goo.gl/x3Ogq