Re: [dispatch] Proposed charter for work on logging

Hello All,
Following on from the comments at IETF#86 (http://www.ietf.org/proceedings/86/minutes/minutes-86-dispatch), where there was mild support for working on logging, I have updated the log me requirements draft with 3 potential solutions (in clause 7) which can meet the requirements (http://www.ietf.org/internet-drafts/draft-dawes-dispatch-logme-reqs-02.txt). Opinions and comments on these or any other potential solutions would be very welcome.

It was commented at IETF#86 that a security analysis is needed so I would like to understand if any scenarios exist with potential security threats in order to add them to requirements. In many cases, a network simply logs the signalling that passes through it so no new security issues are created. Collecting end-to-end logging for signalling that crosses multiple networks must not compromise security or privacy, but I would expect networks to remove any security sensitive fields before forwarding signalling regardless of whether that signalling is of interest to logging. Also, as far as I can see no final decision was made whether INSIPID could be a home for the logging topic. I think INSIPID would be a good working group to discuss a log me indicator since troubleshooting is one possible use of session-id.

Regards,
Peter

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith)
Sent: 10 March 2013 17:26
To: dispatch@ietf.org
Subject: Re: [dispatch] Proposed charter for work on logging

Peter has suggested a minor modification to the charter text (which he also plans to make to the abstract of the requirements document).

   SIP networks use signalling monitoring tools to diagnose user
   reported problem and for regression testing if network or client
   software is upgraded.  As networks grow and become interconnected,
   including connection via transit networks, it becomes impractical to
   predict the path that SIP signalling will take between clients, and
   therefore impractical to monitor SIP signalling end-to-end.

   This work will provide for adding an indicator to the SIP
   protocol which can be used to mark signalling as of interest to logging.
   Such marking will typically be applied as part of network testing
   controlled by the network operator and not used in regular client
   signalling.  However, such marking can be carried end-to-end
   including the SIP terminals, even if a session originates and
   terminates in different networks.

The change is in the 2nd paragraph, changing "subject to" to "of interest to".

Regards

Keith

> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On 
> Behalf Of DRAGE, Keith (Keith)
> Sent: 15 February 2013 22:08
> To: dispatch@ietf.org
> Subject: [dispatch] Proposed charter for work on logging
> 
> Peter Dawes has submitted
> 
> https://datatracker.ietf.org/doc/draft-dawes-dispatch-logme-reqs/
> 
> as a set of requirements that will work with the session identifier 
> produced by the INSIPID working group to enable identification of 
> loggable sessions.
> 
> The INIPID WG did consider this work, but considered it was out of 
> scope of the work they are currently chartered to do.
> 
> I propose the following scope for DISPATCH to consider based on the 
> Abstract of the above document.
> 
>    SIP networks use signalling monitoring tools to diagnose user
>    reported problem and for regression testing if network or client
>    software is upgraded.  As networks grow and become interconnected,
>    including connection via transit networks, it becomes impractical to
>    predict the path that SIP signalling will take between clients, and
>    therefore impractical to monitor SIP signalling end-to-end.
> 
>    This work will provide for adding an indicator to the SIP
>    protocol which can be used to mark signalling as subject to logging.
>    Such marking will typically be applied as part of network testing
>    controlled by the network operator and not used in regular client
>    signalling.  However, such marking can be carried end-to-end
>    including the SIP terminals, even if a session originates and
>    terminates in different networks.
> 
> 
> Milestones
> 
> Dec 2013	Requirements for marking SIP sessions for logging to IESG
> (Informational)
> Mar 2014	Protocol for marking SIP sessions for logging to IESG
> (Proposed standard)
> 
> I would note that the work does not necessarily need a new working 
> group, it could for example be an extension of the work of either the 
> SIPCORE WG or the INSIPID WG, but that is for the discussion to decide.
> 
> Your comments and proposals for revision are welcome.
> 
> For information there have been a number of previous documents on the 
> subject, but these might or might not form part of the proposed 
> solution, particularly given that some of them predate the INSIPID work.
> 
> http://tools.ietf.org/html/draft-dawes-sipping-debug-id-01
> http://tools.ietf.org/html/draft-dawes-sipping-debug-event-01
> http://tools.ietf.org/html/draft-kaithal-dispatch-sip-log-information-
> 00
> http://tools.ietf.org/html/draft-dawes-sipping-debug-05
> http://tools.ietf.org/html/draft-dawes-dispatch-debug-00
> http://tools.ietf.org/html/draft-kaithal-sipclf-sip-log-information-00
> 
> 
> Regards
> 
> Keith
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch