Re: [dispatch] Proposed charter for work on logging

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Sun, 10 March 2013 17:25 UTC

Return-Path: <keith.drage@alcatel-lucent.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C856C21F8585 for <dispatch@ietfa.amsl.com>; Sun, 10 Mar 2013 10:25:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.249
X-Spam-Level:
X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4eH2j5Yij5P for <dispatch@ietfa.amsl.com>; Sun, 10 Mar 2013 10:25:50 -0700 (PDT)
Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id B7F8821F8415 for <dispatch@ietf.org>; Sun, 10 Mar 2013 10:25:49 -0700 (PDT)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2AHPlWI022264 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <dispatch@ietf.org>; Sun, 10 Mar 2013 18:25:47 +0100
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 10 Mar 2013 18:25:46 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Sun, 10 Mar 2013 18:25:45 +0100
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: "dispatch@ietf.org" <dispatch@ietf.org>
Thread-Topic: Proposed charter for work on logging
Thread-Index: Ac4LyOtf/7ujcRPHQoOZ6+wpJgfGIAR6wVFQ
Date: Sun, 10 Mar 2013 17:25:45 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8BF1BA@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <EDC0A1AE77C57744B664A310A0B23AE210701601FC@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE210701601FC@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.40]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84
Subject: Re: [dispatch] Proposed charter for work on logging
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Mar 2013 17:25:50 -0000

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