Re: [sip-clf] AD review: draft-ietf-sipclf-problem-statement-07

Robert Sparks <rjsparks@nostrum.com> Thu, 04 August 2011 21:30 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: sip-clf@ietfa.amsl.com
Delivered-To: sip-clf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78FC15E800E for <sip-clf@ietfa.amsl.com>; Thu, 4 Aug 2011 14:30:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.514
X-Spam-Level:
X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HxM53wtCFqn for <sip-clf@ietfa.amsl.com>; Thu, 4 Aug 2011 14:30:32 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D1C445E800D for <sip-clf@ietf.org>; Thu, 4 Aug 2011 14:30:31 -0700 (PDT)
Received: from [192.168.2.105] (pool-173-71-50-10.dllstx.fios.verizon.net [173.71.50.10]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p74LUkAp094725 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 4 Aug 2011 16:30:46 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Robert Sparks <rjsparks@nostrum.com>
In-Reply-To: <856A6315-BB66-4575-9EFB-8725A9278DC9@nostrum.com>
Date: Thu, 4 Aug 2011 16:30:46 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <15E26452-E508-42E8-A341-BCFA6D33CC5A@nostrum.com>
References: <856A6315-BB66-4575-9EFB-8725A9278DC9@nostrum.com>
To: Robert Sparks <rjsparks@nostrum.com>
X-Mailer: Apple Mail (2.1084)
Received-SPF: pass (nostrum.com: 173.71.50.10 is authenticated by a trusted mechanism)
Cc: SIP-CLF Mailing List <sip-clf@ietf.org>
Subject: Re: [sip-clf] AD review: draft-ietf-sipclf-problem-statement-07
X-BeenThere: sip-clf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Common Log File format discussion list <sip-clf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sip-clf>, <mailto:sip-clf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip-clf>
List-Post: <mailto:sip-clf@ietf.org>
List-Help: <mailto:sip-clf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip-clf>, <mailto:sip-clf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Aug 2011 21:30:33 -0000

(As an individual contributor)

Following up on:

> 3) The presentation of requirements on devices that forward requests and responses
>   is under-documented. The notion of "UAS-half" is not explained. Looking at what
>   we ended up with for Table 1 from the "new reader" perspective, I suggest that
>   the document doesn't actually need it. The whole section can be simplified 
>   with the details focusing on handling R-RUI, Status, Server-Txn, and Client-Txn

Here is some proposed text that could replace the description of Table 1 and Table 1
itself in section 8.2:

In the following cases, an element will not have a sensical value to provide
for one of these fields, even though the field is mandatory. For these cases, the
encoding of the model must define how to represent "not applicable". The R-URI
field is not applicable when logging a response. The Status field is not applicable
when logging a request.

The Client-Txn field is always applicable to a UAC. The Server-Txn
field does not apply to a UAC unless the element is also acting as a UAS, and 
the message associated to this log record corresponds to a message
handled by that UAS. For instance, a proxy forwarding a request will
populate both the Client-Txn and Server-Txn fields in the record
corresponding to the forwarded request.

The Server-Txn field is always applicable to a UAS. The Client-Txn
field does not apply to a UAS unless the element is also acting as a UAC,
and the message associated to this log record corresponds to a message
handled by that UAC. For instance, a proxy forwarding a response will
populate both the Server-Txn and Client-Txn fields in the record corresponding
to the forwarded response. However, a proxy would only populate the Client-Txn
field when creating a log record corresponding to a request.