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

Hello Vijay,
Thanks for the suggested text, this seems a good approach. Also thanks for all of your other review comments which I agree need to be resolved in the next revision of the draft. I have one response regarding the following comment on S3.4.1:

>- S3.4.1: I don't see the relationship between the two sentences.
>  Perhaps simpler to say:
>
>     When a user device inserts the "log me" marker, the marker MUST be
>     be passed unchanged in the To and From headers across an edge proxy
>     or a B2BUA adjacent to the user device. 
>

The current S3.4.1 mixes two ideas, firstly that only authorized and authenticated user agents are allowed to mark signalling ("Edge proxy or B2BUA checks whether the user device is allowed to make/receive e.g. calls, based on authentication and on authorization.") and secondly that marking must be passed unchanged. As you say, the current draft is confusing so in the next revision we will try to better explain these two aspects.

Regards,
Peter

> -----Original Message-----
> From: Vijay K. Gurbani [mailto:vijay.gurbani@nokia-bell-labs.com]
> Sent: 15 June 2017 13:59
> To: Dawes, Peter, Vodafone Group <Peter.Dawes@vodafone.com>; Paul
> Kyzivat <paul.kyzivat@comcast.net>
> Cc: insipid@ietf.org; Arun Arunachalam (carunach) (carunach@cisco.com)
> <carunach@cisco.com>
> Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-marking-07
> 
> 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:insipid-bounces@ietf.org] On Behalf Of Paul
> >> Kyzivat
> >> Sent: 14 June 2017 22:17
> >> To: insipid@ietf.org
> >> 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
> >> insipid@ietf.org
> >> https://www.ietf.org/mailman/listinfo/insipid
> >
> > _______________________________________________
> > insipid mailing list
> > insipid@ietf.org
> > https://www.ietf.org/mailman/listinfo/insipid
> >
> 
> 
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Nokia Networks
> Email: vijay.gurbani@nokia-bell-labs.com / vkg@bell-labs.com
> Web: https://www.bell-labs.com/usr/vijay.gurbani
> Calendar: http://goo.gl/x3Ogq