Re: [Insipid] WG Last Call: draft-ietf-insipid-logme-reqs

[Alberto Llamas <[e-mail]>]

Hi Peter, it looks very good. I just have couple of comments you would take
in consideration:


   - *In points 4.3 and 5.1 the sentence:*


logging on to the SIP entity that contains the logs

Maybe could be change for something like:

logging on to any or all SIP entity that contains the logs


   - *In points 4.3 and 5.3:*

You are referring to the 'stop event' that cause logging to stop. In this
draft and also in '*draft-ietf-insipid-logme-marking-05*' I don't find any
explanation about what a stop event is and/or how to detect it. There is a
short example that a stop event could be *"**typically expiry of a certain
amount of time*". From my point of view stop events should be defined
somewhere or at least define a single stop event as an end of the dialog.


Regards,



On Mon, Oct 3, 2016 at 4:09 PM, Dawes, Peter, Vodafone Group <
[e-mail]> wrote:

> Hello All,
> Thanks to everyone who reviewed and commented on the logme requirements
> draft, we have uploaded revision -08 (https://www.ietf.org/id/
> draft-ietf-insipid-logme-reqs-08.txt) with the changes summarized below
> that aim to resolve the issues raised. Some of the changes are taken from
> e-mail exchanges here on the insipid list but some of the text (and
> structure) is new so it would be good to hear whether the revised draft is
> now OK.
>
> (a)  Expanded REQ8 (was REQ5 in revision -07) to explicitly mention
> gateways and B2BUAs. (commented by Alberto Llamas and Paul Giralt)
> (b)  Example debugging procedure given its own subclause and simplified to
> make it clear that it is only an example and does not contain any
> requirements. (commented by Paul Kyzivat)
> (c)  Requirements split into 3 groups depending on whether they apply to
> SIP entities, the logging procedure, or the logme marker itself. (commented
> by Paul Kyzivat)
> (d)  New subclause added that defines a network boundary. (commented by
> Paul Kyzivat)
> (e)  New subclause added that defines a trust domain as it applies to
> logme (commented by Paul Kyzivat)
> (f)  All requirements in the descriptive clause moved to the requirements
> clause (commented by Paul Kyzivat)
> (g)  Changed "proxy" to "intermediary" in requirements related to whether
> SIP entities are stateful or stateless in terms of their logging behaviour.
> (commented by Paul Kyzivat and Paul Giralt)
> (h)  Reworded requirement on form of logged message to say that messages
> should be logged in the form that they appear in the signaling. (commented
> by Brett Tate)
> (i)   References to draft-insipid-session-id updated to the latest
> version. (commented by Brett Tate)
> (j)  Added the sentence: ""log me" marking SHOULD be applied to in-dialog
> requests and responses in either direction. " to the requirement about
> per-dialog granularity. (commented by Paul Giralt)
> (k)  Changed wording in introduction to use a more general description
> than "service providers" to include enterprises and other operators of SIP
> networks. (commented by Paul Giralt)
> (l)  Wording changed to "Header fields SHOULD be logged in the form in
> which they appear in the message, they SHOULD NOT be converted between long
> and compact forms..." (commented by Paul Giralt)
> (m)  Added the sentence ""log me" marking SHOULD be applied to in-dialog
> requests and responses in either direction." (commented by Paul Giralt)
> (n)  Section 6.2.1 revised to capitalize normative words (MUST etc.). Also
> text related to sending logged information to a server removed. (commented
> by Paul Giralt)
> (o)  Changed text in "Trust Domain" subclause of the "Security" clause to
> say SHOULD NOT rather than "might not": "If a prior agreement to log
> sessions exists with the next hop network then the "log me" marker SHOULD
> NOT be removed". (authors change)
> (p)  Revised the 6.2.2 "Sending Logged Information" to "Logged
> Information" and changed the description to state that unauthorized parties
> should not have access to the logged information. (Related to comment by
> Paul Giralt on solutions draft)
> (q)  Changed the format of cross references so that the reference name is
> not repeated. (Related to comment by Paul Giralt on solutions draft)
> (r)  REQ5 (was REQ8 in revision -07) updated to have test identifier as a
> random value instead of human readable name due to Session-ID privacy
> requirements defined in REQ 4 of RFC7206. (commented by Paul Giralt)
> (s)  REQ9 (was REQ6 in revision -07) updated with an additional use case
> in which intermediaries continue to mark logme for related sessions.
> (commented by Paul Giralt)
> (t)  Acknowledgments updated to include reviewers who provided comments
> during last call.
>
>
> Thanks and regards,
> Peter (on behalf of the co-authors)
>
>
>
> From: Paul Giralt (pgiralt) [mailto:[e-mail]]
> Sent: 29 September 2016 19:15
> To: Arun Arunachalam (carunach)
> Cc: Gonzalo Salgueiro (gsalguei); [e-mail]; [e-mail];
> Dawes, Peter, Vodafone Group
> Subject: Re: [Insipid] WG Last Call: draft-ietf-insipid-logme-reqs
>
> Looks good to me.
>
> -Paul
>
> On Sep 29, 2016, at 2:13 PM, Arun Arunachalam (carunach) <
> [e-mail]> wrote:
>
> Thanks Paul !
>
> (1) Agree, let’s have a random test id given REQ 4 of RFC 7206.
>
> (2) We can update REQ 6 as shown below to incorporate your comment:
>
>  REQ6: A SIP intermediary MAY insert a "log me" marker into requests and
>       responses.  The typical case for which a intermediary needs to
> insert a
>       "log me" marker is for compatibility with UAs that have not
>       implemented "logme" marking, i.e. when a UA has not marked a
>       request or when responses received on a dialog of interest for
>       logging do not contain an echoed "log me" marker.  Another use
>       case is when the session origination UA that inserted log me marker
>       is no longer participating in the session (e.g: call transfer
> scenarios)
>       and the intermediary adds "log me" marker in related sessions to
> enable
>       end-to-end signaling analysis. In these cases, the entity that
> inserts a
>       "log me" marker is stateful inasmuch as it must remember when a
> dialog is
>       of interest for logging.  An entity that inserts a "log me" marker
>       SHOULD also log the SIP request or response as per REQ4.
>
>
> Arun
>
>
>
>
> On Sep 29, 2016, at 11:57 AM, Paul Giralt (pgiralt) <[e-mail]>
> wrote:
>
> Hi Arun,
>
> Sorry for not replying earlier. Inline…
>
>
> On Sep 22, 2016, at 10:13 AM, Arun Arunachalam (carunach) <
> [e-mail]> wrote:
>
> Hi Paul,
>
> Please see inline.
>
> On Sep 14, 2016, at 7:30 PM, Paul Giralt (pgiralt) <[e-mail]>
> wrote:
>
> Thanks Arun. See below…
>
> On Sep 14, 2016, at 6:36 PM, Arun Arunachalam (carunach) <
> [e-mail]> wrote:
>
> REQ8: Should update to latest session-id draft. Also, I have some concerns
> about using Session-ID as the test case identifier. The Session-ID can
> change (in fact will change for every session because the initial INVITE
> will have a null remote UUID).
>
> How about using the local UUID of the Session-ID generated by the
> originating UA / proxy as a test identifier (if the admin wants the system
> to auto-generate a test ID)?
>
>
> I think using just the local UUID makes more sense because this will be
> consistent throughout the life of the session as long as the originating
> endpoint is still in the call. It’s possible that some B2BUA could remove
> the originator from the session (e.g. call gets transferred) but at that
> point, the device that requested the session be logged is no longer in an
> active session anyway.
>
> That said, what if the admin doesn’t want the system to auto-generate a
> test ID? Where would that go? The local UUID must be in a very specific
> format to comply with drafy-ietf-insipid-session-id, so you can’t put any
> arbitrary text in for the local UUID. I think either you need to stipulate
> that the test ID will always be automatically generated or find some other
> place to put it.
>
> I think there is value in giving the admin the ability to specify their
> own identifier.
>
> One option would be to have a user defined test identifier as shown below:
>
>    test-identifier = (alphanum / "_") *(alphanum "_")
>
> If the user defined test identifier is not present, the log analysis
> server would use the local UUID of the originator’s Session-ID as the test
> identifier.
>
>
>
> I like this in concept. The concern I have is whether it meets the privacy
> requirements stipulated for additional parameters in the Session-ID header.
> If someone puts a value of the person’s name or perhaps a ticket number,
> that could be considered personally identifiable information which is not
> allowed to be present in the Session-ID header. I’m not sure how we’d
> reconcile these requirements. We may have to just live with the test ID
> being something random.
>
>
>
>
> Also, should intermediaries be required to or at least allowed to continue
> indicating log me markings on other messages related to the session even if
> the originating device is no longer participating in the session?
>
> This will be useful to perform an end-to-end call flow analysis.
>
> The good thing about originator based log me marking is the “ability /
> control” to disable logging simply by disconnecting the call at the
> originator (the device requesting to enable logging).
>
> This control no longer exists if we allow the intermediaries to continue
> marking even after the originator is no longer in the session.
>
> I guess this could be left up to the implementation of the intermediary.
> It is free to add a logme marker to whatever it wants to, so even if the
> originator drops off, there is no reason why it can’t add the identifier to
> related sessions. This is probably something worth mentioning in the draft,
> but might not be necessary in the requirements doc.
>
> -Paul
>
>
>
>
>


-- 
Alberto Llamas
Phone: [phone]
Telecommunications Engineer
Digium Certified Asterisk Professional (dCap)