Re: [Insipid] draft-dawes-dispatch-logme-reqs-02 (repost to insipid)

"Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com> Fri, 18 October 2013 17:31 UTC

Return-Path: <gsalguei@cisco.com>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04DA611E8231 for <insipid@ietfa.amsl.com>; Fri, 18 Oct 2013 10:31:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.41
X-Spam-Level:
X-Spam-Status: No, score=-10.41 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227]
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 jnmBxQZBW3lt for <insipid@ietfa.amsl.com>; Fri, 18 Oct 2013 10:31:30 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBA311E826F for <insipid@ietf.org>; Fri, 18 Oct 2013 10:31:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3275; q=dns/txt; s=iport; t=1382117486; x=1383327086; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=KNwPvMPWlh0TNh3k7CKu2mDK/54oFONiTsGCMQGV0A8=; b=Q8FIz+ZezoNGCWqWN4pAqbewx6/a95UN/adQvFwzFkI5YnAHMrw8kr6q X+S09K/o3591whlhazpuxikizIC0IAiX30TEEEjSBFDoqvm4asVE9LJ0V DCnqS2MR/c+BJPyQGjz9F2DZeSdgee68JP+0XDobIz7KDOxDlwzYYEzqF g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag4FAEFvYVKtJXG8/2dsb2JhbABaDoJ5OFK9WUuBIRZ0giUBAQEDAQEBATc0CwwEAgEIDgMEAQELFAkHJwsUCQgCBA4FCBOHZQYMwRYEjyMCMQcGgxmBCgOqEIJlP4Ip
X-IronPort-AV: E=Sophos;i="4.93,524,1378857600"; d="scan'208";a="273826886"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 18 Oct 2013 17:31:01 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9IHV1K6030994 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Oct 2013 17:31:01 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Fri, 18 Oct 2013 12:31:01 -0500
From: "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Thread-Topic: [Insipid] draft-dawes-dispatch-logme-reqs-02 (repost to insipid)
Thread-Index: AQHOzCNWGf3fTJI8hUe/mT1XtHhuh5n7CyoA
Date: Fri, 18 Oct 2013 17:31:00 +0000
Message-ID: <D85334BB1373A34AA5FF84F9A623928A1F1B82DB@xmb-rcd-x04.cisco.com>
References: <51EDEF82.3060908@alum.mit.edu> <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE917CA@VOEXM31W.internal.vodafone.com> <526168D3.7050200@alum.mit.edu>
In-Reply-To: <526168D3.7050200@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.116.132.54]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <BC7B30ACE0F73542A6437D33EEB2C8FB@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>, "insipid@ietf.org" <insipid@ietf.org>
Subject: Re: [Insipid] draft-dawes-dispatch-logme-reqs-02 (repost to insipid)
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Session-ID discussion list <insipid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/insipid>, <mailto:insipid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/insipid>
List-Post: <mailto:insipid@ietf.org>
List-Help: <mailto:insipid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/insipid>, <mailto:insipid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Oct 2013 17:31:35 -0000

<snip>

>> 
>> 3) For protocol to transmit the logs, RFC 6872 "The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model" has been suggested so I will look into this.
> 
> That defines a file format, not a protocol. You could potentially specify a protocol that can carry a file in CLF format.

Just a nit:  6872 defines the Information Model, whereas 6873 defines the actual file format.

Cheers,

Gonzalo

> 
>> 4) For " trust by the server doing the logging of the log server, and authorization by the log server of those sending logs " I think mechanisms exist for mutual authentication of sender and receiver so I can add something.
> 
> This is entangled with choosing the protocol for transmission.
> 
>> I will also try to ensure that the descriptions of proposed solutions cover all aspects of the draft (log server, test case id) and thanks for spotting the syntax error in Fig. 3.
> 
> 	Thanks,
> 	Paul
> 
>> Regards,
>> Peter
>> 
>> -----Original Message-----
>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Paul Kyzivat
>> Sent: 23 July 2013 04:51
>> To: insipid@ietf.org
>> Subject: [Insipid] draft-dawes-dispatch-logme-reqs-02 (repost to insipid)
>> 
>> Some questions about this draft:
>> 
>> The requirements and other discussion imply certain behavior by servers that support this. I'd like to hear more explicit discussion of what that expected behavior is, within the potential solutions.
>> 
>> E.g., when some servers are expected to be dialog stateful. Also if logging is to stop after some period of time.
>> 
>> Section 7.1:
>> 
>> This says the header is first inserted by the UAC. There might be reason to have it inserted by the UAS in some cases, or even a proxy or B2BUA based on policy for debugging a UA that can't be controlled.
>> 
>> Is free text good enough for identifying test cases? Isn't there possibility of collision? Since there is likely to be resistance to meaningful names that might tunnel information, perhaps these should be random numbers.
>> 
>> I want to hear more about sending the address of the server collecting logs. For this to be useful there must be an explicit or implicit protocol used to transmit the logs. Is there one such protocol or many?
>> If many, how do you know which will be supported? What about trust by the server doing the logging of the log server, and authorization by the log server of those sending logs? Will all servers doing logging want to use a server chosen by the one inserting the logme request?
>> 
>> Section 7.2:
>> 
>> Where does the test case id go with this solution?
>> 
>> In Figure 3 the call-info in the figure is syntactically incorrect. The parameter is a domain name, but it is required to be a URL.
>> 
>> 	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