From vkg@bell-labs.com Tue Apr 12 14:08:44 2011 Return-Path: X-Original-To: sip-clf@ietfc.amsl.com Delivered-To: sip-clf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 21424E08F6 for ; Tue, 12 Apr 2011 14:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.099 X-Spam-Level: X-Spam-Status: No, score=-105.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id latOFbZ46UGx for ; Tue, 12 Apr 2011 14:08:43 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfc.amsl.com (Postfix) with ESMTP id 28DB5E0906 for ; Tue, 12 Apr 2011 14:08:43 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p3CL8gvD019233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 12 Apr 2011 16:08:42 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3CL8fZt014860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 12 Apr 2011 16:08:42 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.233]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p3CL8fm2008229 for ; Tue, 12 Apr 2011 16:08:41 -0500 (CDT) Message-ID: <4DA4BFD3.3070608@bell-labs.com> Date: Tue, 12 Apr 2011 16:10:43 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9 MIME-Version: 1.0 To: "sip-clf@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: [sip-clf] problem-statement and logging arbitrary SIP fields X-BeenThere: sip-clf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Common Log File format discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 21:08:44 -0000 Folks: In the Prague IETF, it was decided that we will allow the capability to log arbitrary SIP header fields and header elements (like the Reason-Phrase) that are not already part of the mandatory fields. I am ratifying this decision on the list; pragmatically, what this means to the problem-statement draft is that it will undergo a change as follows: OLD: (Section 8) The data model supports extensibility by providing the capability to log "optional fields". Optional fields are those SIP header fields (or field components) that are not mandatory (see Section 8.1 for the mandatory field list). A specific representation format MAY decide to explicitly maintain a representation-specific list of fields (or field components) to log. All other fields that do not appear in the list of mandatory fields (Section 8.1), nor do they appear in the representation-specific list of optional fields, MUST be logged using a vendor-specific extension mechanism (through the use of private enterprise numbers). The specific syntax and semantics to be accorded to optional fields, whether they are representation-specific or use vendor-extension mechanisms MUST be defined by the specific representation format used to generate the SIP CLF record. Finally, [I-D.ietf-sipclf-format] is an example of a representation format draft that provides an ASCII-based encoding scheme. NEW: (Section 8) The data model supports extensibility by providing the capability to log "optional fields". Optional fields are those SIP header fields (or field components) that are not mandatory (see Section 8.1 for the mandatory field list). Optional fields may contain SIP headers or other elements present in a SIP message (for example, the Reason- Phrase element from the Status-Line production rule in RFC 3261 [RFC3261]). Optional fields may also contain additional information that a particular vendor desires to log. The specific syntax and semantics to be accorded to optional fields MUST be defined by the specific representation format used to generate the SIP CLF record. Finally, [I-D.ietf-sipclf-format] is an example of a representation format draft that provides an ASCII-based encoding scheme. In the new text, I have decided to stay away from specifying private enterprise numbers for optional fields in the problem-statement draft and am leaving it to the specific representation format to outline this in more detail. Clearly, to ensure the least ambiguity and most interoperability, it is in the best interest of a representation format to choose a mechanism like the private enterprise number (and draft-ietf-sipclf-format already does so). Please let me know of any comments for proceeding as outlined above for the problem-statement draft. This is the last open issue in problem-statement, and once we close this, the draft is in a shape to be moved ahead. Thank you, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From eburger@standardstrack.com Wed Apr 13 10:40:46 2011 Return-Path: X-Original-To: sip-clf@ietfc.amsl.com Delivered-To: sip-clf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 57FD2E0869 for ; Wed, 13 Apr 2011 10:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lNdLGimoV-A for ; Wed, 13 Apr 2011 10:40:45 -0700 (PDT) Received: from karma.cs.georgetown.edu (karma.cs.georgetown.edu [141.161.20.3]) by ietfc.amsl.com (Postfix) with ESMTP id 2F96AE0860 for ; Wed, 13 Apr 2011 10:40:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by karma.cs.georgetown.edu (Postfix) with ESMTP id 7FE702FCC1; Wed, 13 Apr 2011 13:40:44 -0400 (EDT) Received: from karma.cs.georgetown.edu ([127.0.0.1]) by localhost (karma.cs.georgetown.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07647-08; Wed, 13 Apr 2011 13:40:44 -0400 (EDT) Received: from [192.168.15.171] (ip68-100-199-8.dc.dc.cox.net [68.100.199.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by karma.cs.georgetown.edu (Postfix) with ESMTP id E7EAC2FC45; Wed, 13 Apr 2011 13:40:43 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-23-139212075; protocol="application/pkcs7-signature"; micalg=sha1 From: Eric Burger In-Reply-To: <4DA4BFD3.3070608@bell-labs.com> Date: Wed, 13 Apr 2011 13:40:42 -0400 Message-Id: <2919F671-DDDC-40BD-BE9A-6D15896FB82E@standardstrack.com> References: <4DA4BFD3.3070608@bell-labs.com> To: Vijay K.Gurbani X-Mailer: Apple Mail (2.1084) X-Virus-Scanned: by amavisd-new at cs.georgetown.edu Cc: "sip-clf@ietf.org" Subject: Re: [sip-clf] problem-statement and logging arbitrary SIP fields X-BeenThere: sip-clf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Common Log File format discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 17:40:46 -0000 --Apple-Mail-23-139212075 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii WFM On Apr 12, 2011, at 5:10 PM, Vijay K. Gurbani wrote: > Folks: In the Prague IETF, it was decided that we will allow > the capability to log arbitrary SIP header fields and > header elements (like the Reason-Phrase) that are not > already part of the mandatory fields. > > I am ratifying this decision on the list; pragmatically, > what this means to the problem-statement draft is that it > will undergo a change as follows: > > OLD: (Section 8) > > The data model supports extensibility by providing the capability to > log "optional fields". Optional fields are those SIP header fields > (or field components) that are not mandatory (see Section 8.1 for the > mandatory field list). A specific representation format MAY decide > to explicitly maintain a representation-specific list of fields (or > field components) to log. All other fields that do not appear in the > list of mandatory fields (Section 8.1), nor do they appear in the > representation-specific list of optional fields, MUST be logged using > a vendor-specific extension mechanism (through the use of private > enterprise numbers). The specific syntax and semantics to be > accorded to optional fields, whether they are representation-specific > or use vendor-extension mechanisms MUST be defined by the specific > representation format used to generate the SIP CLF record. > Finally, [I-D.ietf-sipclf-format] is an example of a representation > format draft that provides an ASCII-based encoding scheme. > > NEW: (Section 8) > > The data model supports extensibility by providing the capability to > log "optional fields". Optional fields are those SIP header fields > (or field components) that are not mandatory (see Section 8.1 for the > mandatory field list). Optional fields may contain SIP headers or > other elements present in a SIP message (for example, the Reason- > Phrase element from the Status-Line production rule in RFC 3261 > [RFC3261]). Optional fields may also contain additional information > that a particular vendor desires to log. The specific syntax and > semantics to be accorded to optional fields MUST be defined by the > specific representation format used to generate the SIP CLF record. > Finally, [I-D.ietf-sipclf-format] is an example of a representation > format draft that provides an ASCII-based encoding scheme. > > In the new text, I have decided to stay away from specifying private > enterprise numbers for optional fields in the problem-statement > draft and am leaving it to the specific representation format to > outline this in more detail. Clearly, to ensure the least ambiguity > and most interoperability, it is in the best interest of a > representation format to choose a mechanism like the private enterprise > number (and draft-ietf-sipclf-format already does so). > > Please let me know of any comments for proceeding as outlined > above for the problem-statement draft. This is the last open issue > in problem-statement, and once we close this, the draft is in > a shape to be moved ahead. > > Thank you, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > sip-clf mailing list > sip-clf@ietf.org > https://www.ietf.org/mailman/listinfo/sip-clf --Apple-Mail-23-139212075 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggY6MIIFIqAD AgECAhEAxcM7lN0zgrA71mfq+sG6xjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDA5MDgwMDAw MDBaFw0xMTA5MDgyMzU5NTlaMIHhMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v ZG8gTGltaXRlZDEUMBIGA1UEAxMLRXJpYyBCdXJnZXIxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJA c3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqeauFkEq 5Pj7AIAaDRbUWIpoblTKyrjcSfXRaHvjk0jWBTsBPe6oOZjudMK0Vo9A1Sl52BixDgf1/qb2Z+PT 7M0mqSOOsSucEBid48IMvGi79xmKKAVf5jiyFNNAaTZWn76dwNLMkKd/+Ki0fn8kEbb2zG+gGKyZ MNHiNX+GQfPpHyzo2MTwnb16lXMfGJrGv4uLZS/pY9PENdFQnwV0ASZoqX+ArtLY2xeuC+rYG9xQ Cz7qiLbJhCJzWsEGETyHLDjE5bN4HB9DsJKtGFLQuOdTanwGigNz9cVH9pLFNQxiotavAouXgqS4 wGvcq4mGP9w9zTychoUqIKsEg9OD1wIDAQABo4ICHDCCAhgwHwYDVR0jBBgwFoAUiYJnfcSdJnAA S7RQSHzePa4Ebn0wHQYDVR0OBBYEFAlgEOVj6Hl0La8sPRP388HEMiWvMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWls LmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRw Oi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmNvbW9kb2NhLmNvbTAlBgNVHREEHjAcgRplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNv bTANBgkqhkiG9w0BAQUFAAOCAQEACRTppSEc5DMYn8YXcbfX36iTaNBGw1gUvTNam0U8pXH0E7H3 2d4cTq6DEMu5ifEvxMGBqhUyv0sKxQ7+UvtDwrk7Kiy2L6TUC4zNEklZbtDqY7+Wd7EQZkN4k/zx kMLlz2VIIRL/Cg48NrBKP5bo1la78NTJx8m4+VForLseEBabxMQoWB/GOVC7WpO/+RCgd93gz6H/ RzW1hnK0Uvu5H3Kz7HEC3R1Qk/sE9nXVzTfoJOMJRnyMS5Ut61mgoWSm/kUtczAlRRYh6IBOhzAl awoXz+yk9hMCheYRAWx0EamBBpSzvqXj0N2vXYc62v3e3ddcLZncjiB0pYIfCE3s4DGCA/8wggP7 AgEBMIHEMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBD aXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cu dXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAxcM7lN0zgrA71mfq+sG6xjAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA0MTMxNzQwNDNaMCMGCSqGSIb3DQEJ BDEWBBS4pMUEZj0jUCvwGxu6YIjpqonwAjCB1QYJKwYBBAGCNxAEMYHHMIHEMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEAxcM7 lN0zgrA71mfq+sG6xjCB1wYLKoZIhvcNAQkQAgsxgceggcQwga4xCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1Qg TmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDFwzuU3TOCsDvWZ+r6 wbrGMA0GCSqGSIb3DQEBAQUABIIBAI/eYI+qCffBvMeVB5JcB7PuDVnRN1uqIg/WcFdTsL4ywzJM Z0SUB1DgZWp7vUjPyvBrUv+Lbjk2tsdMH/xT1IEO5/HEsvWwuHUvNHrD7WGh7FYomaD11s4F7xGa K09l3kuBgvM9s/TuemJlP0cefBSMEdQsXYMyDwttSBd79XfZ0/kLwRTEwk4Na5/nnasr0N/3VJ4N rM0ik30I5ZTY9yXjYWTAT3P4bKorTdItwKly08pZuNlj8GI9sRhLXGxLvlSeHk51WIRarQ6AMT9t IrAEpZRwZS8NPHA1rqf2ANqKU2IqhoMJJ4YGuZk41iM9VXYSntB8LhUroVzDp/QGl0YAAAAAAAA= --Apple-Mail-23-139212075-- From peter.musgrave@magorcorp.com Wed Apr 13 10:46:39 2011 Return-Path: X-Original-To: sip-clf@ietfc.amsl.com Delivered-To: sip-clf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 163D9E0875 for ; Wed, 13 Apr 2011 10:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gYOcyO6p3ZI for ; Wed, 13 Apr 2011 10:46:38 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfc.amsl.com (Postfix) with ESMTP id 23CD7E0841 for ; Wed, 13 Apr 2011 10:46:38 -0700 (PDT) Received: by qyk29 with SMTP id 29so2682032qyk.10 for ; Wed, 13 Apr 2011 10:46:37 -0700 (PDT) Received: by 10.229.8.194 with SMTP id i2mr6998285qci.190.1302716797829; Wed, 13 Apr 2011 10:46:37 -0700 (PDT) Received: from 132-177-252-96.ip.sipit.net ([132.177.252.96]) by mx.google.com with ESMTPS id s16sm541896qco.25.2011.04.13.10.46.35 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Apr 2011 10:46:36 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Peter Musgrave In-Reply-To: <4DA4BFD3.3070608@bell-labs.com> Date: Wed, 13 Apr 2011 12:46:34 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <4DA4BFD3.3070608@bell-labs.com> To: Vijay K. Gurbani X-Mailer: Apple Mail (2.1084) Cc: "sip-clf@ietf.org" Subject: Re: [sip-clf] problem-statement and logging arbitrary SIP fields X-BeenThere: sip-clf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Common Log File format discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 17:46:39 -0000 (as individual) I think this is ok. Peter On 2011-04-12, at 4:10 PM, Vijay K. Gurbani wrote: > Folks: In the Prague IETF, it was decided that we will allow > the capability to log arbitrary SIP header fields and > header elements (like the Reason-Phrase) that are not > already part of the mandatory fields. > > I am ratifying this decision on the list; pragmatically, > what this means to the problem-statement draft is that it > will undergo a change as follows: > > OLD: (Section 8) > > The data model supports extensibility by providing the capability to > log "optional fields". Optional fields are those SIP header fields > (or field components) that are not mandatory (see Section 8.1 for the > mandatory field list). A specific representation format MAY decide > to explicitly maintain a representation-specific list of fields (or > field components) to log. All other fields that do not appear in the > list of mandatory fields (Section 8.1), nor do they appear in the > representation-specific list of optional fields, MUST be logged using > a vendor-specific extension mechanism (through the use of private > enterprise numbers). The specific syntax and semantics to be > accorded to optional fields, whether they are representation-specific > or use vendor-extension mechanisms MUST be defined by the specific > representation format used to generate the SIP CLF record. > Finally, [I-D.ietf-sipclf-format] is an example of a representation > format draft that provides an ASCII-based encoding scheme. > > NEW: (Section 8) > > The data model supports extensibility by providing the capability to > log "optional fields". Optional fields are those SIP header fields > (or field components) that are not mandatory (see Section 8.1 for the > mandatory field list). Optional fields may contain SIP headers or > other elements present in a SIP message (for example, the Reason- > Phrase element from the Status-Line production rule in RFC 3261 > [RFC3261]). Optional fields may also contain additional information > that a particular vendor desires to log. The specific syntax and > semantics to be accorded to optional fields MUST be defined by the > specific representation format used to generate the SIP CLF record. > Finally, [I-D.ietf-sipclf-format] is an example of a representation > format draft that provides an ASCII-based encoding scheme. > > In the new text, I have decided to stay away from specifying private > enterprise numbers for optional fields in the problem-statement > draft and am leaving it to the specific representation format to > outline this in more detail. Clearly, to ensure the least ambiguity > and most interoperability, it is in the best interest of a > representation format to choose a mechanism like the private enterprise > number (and draft-ietf-sipclf-format already does so). > > Please let me know of any comments for proceeding as outlined > above for the problem-statement draft. This is the last open issue > in problem-statement, and once we close this, the draft is in > a shape to be moved ahead. > > Thank you, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > sip-clf mailing list > sip-clf@ietf.org > https://www.ietf.org/mailman/listinfo/sip-clf From gsalguei@cisco.com Wed Apr 13 19:56:49 2011 Return-Path: X-Original-To: sip-clf@ietfc.amsl.com Delivered-To: sip-clf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 72E51E07DF for ; Wed, 13 Apr 2011 19:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kE82zydgIdCl for ; Wed, 13 Apr 2011 19:56:47 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfc.amsl.com (Postfix) with ESMTP id 4AE47E066C for ; Wed, 13 Apr 2011 19:56:47 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3E2ujNs004534; Wed, 13 Apr 2011 22:56:45 -0400 (EDT) Received: from rtp-gsalguei-87112.cisco.com (rtp-gsalguei-87112.cisco.com [10.116.61.61]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3E2uiGm019386; Wed, 13 Apr 2011 22:56:44 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-41-172573883 From: Gonzalo Salgueiro In-Reply-To: <4DA4BFD3.3070608@bell-labs.com> Date: Wed, 13 Apr 2011 22:56:44 -0400 Message-Id: <989ECCE2-D6B5-425E-84AE-3CBA1C407A07@cisco.com> References: <4DA4BFD3.3070608@bell-labs.com> To: "Vijay K. Gurbani" X-Mailer: Apple Mail (2.1084) Cc: "sip-clf@ietf.org" Subject: Re: [sip-clf] problem-statement and logging arbitrary SIP fields X-BeenThere: sip-clf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Common Log File format discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 02:56:49 -0000 --Apple-Mail-41-172573883 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This seems fine. The changes seem innocuous and in line with the = discussions in Prague. Gonzalo On Apr 12, 2011, at 5:10 PM, Vijay K. Gurbani wrote: > Folks: In the Prague IETF, it was decided that we will allow > the capability to log arbitrary SIP header fields and > header elements (like the Reason-Phrase) that are not > already part of the mandatory fields. >=20 > I am ratifying this decision on the list; pragmatically, > what this means to the problem-statement draft is that it > will undergo a change as follows: >=20 > OLD: (Section 8) >=20 > The data model supports extensibility by providing the capability to > log "optional fields". Optional fields are those SIP header fields > (or field components) that are not mandatory (see Section 8.1 for = the > mandatory field list). A specific representation format MAY decide > to explicitly maintain a representation-specific list of fields (or > field components) to log. All other fields that do not appear in = the > list of mandatory fields (Section 8.1), nor do they appear in the > representation-specific list of optional fields, MUST be logged = using > a vendor-specific extension mechanism (through the use of private > enterprise numbers). The specific syntax and semantics to be > accorded to optional fields, whether they are = representation-specific > or use vendor-extension mechanisms MUST be defined by the specific > representation format used to generate the SIP CLF record. > Finally, [I-D.ietf-sipclf-format] is an example of a representation > format draft that provides an ASCII-based encoding scheme. >=20 > NEW: (Section 8) >=20 > The data model supports extensibility by providing the capability to > log "optional fields". Optional fields are those SIP header fields > (or field components) that are not mandatory (see Section 8.1 for = the > mandatory field list). Optional fields may contain SIP headers or > other elements present in a SIP message (for example, the Reason- > Phrase element from the Status-Line production rule in RFC 3261 > [RFC3261]). Optional fields may also contain additional information > that a particular vendor desires to log. The specific syntax and > semantics to be accorded to optional fields MUST be defined by the > specific representation format used to generate the SIP CLF record. > Finally, [I-D.ietf-sipclf-format] is an example of a representation > format draft that provides an ASCII-based encoding scheme. >=20 > In the new text, I have decided to stay away from specifying private > enterprise numbers for optional fields in the problem-statement > draft and am leaving it to the specific representation format to > outline this in more detail. Clearly, to ensure the least ambiguity > and most interoperability, it is in the best interest of a > representation format to choose a mechanism like the private = enterprise > number (and draft-ietf-sipclf-format already does so). >=20 > Please let me know of any comments for proceeding as outlined > above for the problem-statement draft. This is the last open issue > in problem-statement, and once we close this, the draft is in > a shape to be moved ahead. >=20 > Thank you, >=20 > - vijay > --=20 > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > sip-clf mailing list > sip-clf@ietf.org > https://www.ietf.org/mailman/listinfo/sip-clf --Apple-Mail-41-172573883 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This = seems fine. The changes seem innocuous and in line with the discussions = in Prague.

Gonzalo

On Apr 12, = 2011, at 5:10 PM, Vijay K. Gurbani wrote:

Folks: = In the Prague IETF, it was decided that we will allow
the capability = to log arbitrary SIP header fields and
header elements (like the = Reason-Phrase) that are not
already part of the mandatory = fields.

I am ratifying this decision on the list; = pragmatically,
what this means to the problem-statement draft is that = it
will undergo a change as follows:

OLD: (Section 8)

=   The data model supports extensibility by providing the = capability to
  log "optional fields".  Optional = fields are those SIP header fields
  (or field components) = that are not mandatory (see Section 8.1 for the
=   mandatory field list).  A specific representation = format MAY decide
  to explicitly maintain a = representation-specific list of fields (or
  field = components) to log.  All other fields that do not appear in the
=   list of mandatory fields (Section 8.1), nor do they appear = in the
  representation-specific list of optional fields, = MUST be logged using
  a vendor-specific extension = mechanism (through the use of private
  enterprise = numbers).  The specific syntax and semantics to be
=   accorded to optional fields, whether they are = representation-specific
  or use vendor-extension = mechanisms MUST be defined by the specific
=   representation format used to generate the SIP CLF = record.
  Finally, [I-D.ietf-sipclf-format] is an example = of a representation
  format draft that provides an = ASCII-based encoding scheme.

NEW: (Section 8)

=   The data model supports extensibility by providing the = capability to
  log "optional fields".  Optional = fields are those SIP header fields
  (or field components) = that are not mandatory (see Section 8.1 for the
=   mandatory field list).  Optional fields may contain SIP = headers or
  other elements present in a SIP message (for = example, the Reason-
  Phrase element from the Status-Line = production rule in RFC 3261
  [RFC3261]).  Optional = fields may also contain additional information
  that a = particular vendor desires to log.  The specific syntax and
=   semantics to be accorded to optional fields MUST be defined = by the
  specific representation format used to generate = the SIP CLF record.
  Finally, [I-D.ietf-sipclf-format] is = an example of a representation
  format draft that = provides an ASCII-based encoding scheme.

In the new text, I have = decided to stay away from specifying private
enterprise numbers for = optional fields in the problem-statement
draft and am leaving it to = the specific representation format to
outline this in more detail. =  Clearly, to ensure the least ambiguity
and most = interoperability, it is in the best interest of a
representation = format to choose a mechanism like the private enterprise
number (and = draft-ietf-sipclf-format already does so).

Please let me know of = any comments for proceeding as outlined
above for the = problem-statement draft.  This is the last open issue
in = problem-statement, and once we close this, the draft is in
a shape to = be moved ahead.

Thank you,

- vijay
--
Vijay K. = Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. = 9C-533, Naperville, Illinois 60566 (USA)
Email: = vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-luc= ent.com
Web:   http://ect.bell-labs.com/who/vk= g/
_______________________________________________
sip-clf = mailing list
sip-clf@ietf.org
https://www.ietf.= org/mailman/listinfo/sip-clf

= = --Apple-Mail-41-172573883-- From Internet-Drafts@ietf.org Mon Apr 18 07:30:08 2011 Return-Path: X-Original-To: sip-clf@ietfc.amsl.com Delivered-To: sip-clf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AC454E068E; Mon, 18 Apr 2011 07:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.824 X-Spam-Level: X-Spam-Status: No, score=-102.824 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-Br6Ecw70pq; Mon, 18 Apr 2011 07:30:04 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 228A8E0772; Mon, 18 Apr 2011 07:30:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110418143004.807.72505.idtracker@ietfc.amsl.com> Date: Mon, 18 Apr 2011 07:30:04 -0700 Cc: sip-clf@ietf.org Subject: [sip-clf] I-D Action:draft-ietf-sipclf-problem-statement-06.txt X-BeenThere: sip-clf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Common Log File format discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 14:30:08 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP Common Log Format Working Group of the IETF. Title : The Common Log Format (CLF) for the Session Initiation Protocol (SIP) Author(s) : V. Gurbani, et al. Filename : draft-ietf-sipclf-problem-statement-06.txt Pages : 34 Date : 2011-04-18 Well-known web servers such as Apache and web proxies like Squid support event logging using a common log format. The logs produced using these de-facto standard formats are invaluable to system administrators for trouble-shooting a server and tool writers to craft tools that mine the log files and produce reports and trends. Furthermore, these log files can also be used to train anomaly detection systems and feed events into a security event management system. The Session Initiation Protocol does not have a common log format, and as a result, each server supports a distinct log format that makes it unnecessarily complex to produce tools to do trend analysis and security detection. We propose a common log file format for SIP servers that can be used uniformly by proxies, registrars, redirect servers as well as back-to-back user agents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipclf-problem-statement-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipclf-problem-statement-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-18072824.I-D@ietf.org> --NextPart-- From vkg@bell-labs.com Mon Apr 18 07:40:51 2011 Return-Path: X-Original-To: sip-clf@ietfc.amsl.com Delivered-To: sip-clf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CD239E06D9 for ; Mon, 18 Apr 2011 07:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.399 X-Spam-Level: X-Spam-Status: No, score=-105.399 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmdwDEz9Beyj for ; Mon, 18 Apr 2011 07:40:50 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfc.amsl.com (Postfix) with ESMTP id 9AA9FE06B9 for ; Mon, 18 Apr 2011 07:40:50 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p3IEendn028371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 18 Apr 2011 09:40:49 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3IEenkR023815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 18 Apr 2011 09:40:49 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.233]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p3IEenSB018051 for ; Mon, 18 Apr 2011 09:40:49 -0500 (CDT) Message-ID: <4DAC4DEF.90602@bell-labs.com> Date: Mon, 18 Apr 2011 09:42:55 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9 MIME-Version: 1.0 To: "sip-clf@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: [sip-clf] sipclf-problem-statement-06 X-BeenThere: sip-clf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Common Log File format discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 14:40:51 -0000 Folks: Pursuant to the discussion we had on the list last week regarding logging arbitrary fields [1], I have updated the problem-statement draft to reflect the views expressed on the list. Version -06 of the problem-statement has been released and is available at [2]. [1] http://www.ietf.org/mail-archive/web/sip-clf/current/msg00488.html [2] http://tools.ietf.org/html/draft-ietf-sipclf-problem-statement-06 Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From peter.musgrave@magorcorp.com Mon Apr 18 12:12:01 2011 Return-Path: X-Original-To: sip-clf@ietfc.amsl.com Delivered-To: sip-clf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8C4A8E070C for ; Mon, 18 Apr 2011 12:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhGDtmZPUzUy for ; Mon, 18 Apr 2011 12:12:00 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfc.amsl.com (Postfix) with ESMTP id 8473AE0694 for ; Mon, 18 Apr 2011 12:12:00 -0700 (PDT) Received: by gyf3 with SMTP id 3so1920153gyf.31 for ; Mon, 18 Apr 2011 12:12:00 -0700 (PDT) Received: by 10.150.250.3 with SMTP id x3mr4965701ybh.333.1303153920145; Mon, 18 Apr 2011 12:12:00 -0700 (PDT) Received: from petermac.magor.local ([72.1.217.106]) by mx.google.com with ESMTPS id p23sm932026ybk.9.2011.04.18.12.11.58 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Apr 2011 12:11:59 -0700 (PDT) From: Peter Musgrave Content-Type: multipart/alternative; boundary=Apple-Mail-15-576686546 Date: Mon, 18 Apr 2011 15:11:57 -0400 References: <20110418143004.807.72505.idtracker@ietfc.amsl.com> To: "sip-clf@ietf.org Mailing" Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [sip-clf] WGLC:draft-ietf-sipclf-problem-statement-06.txt X-BeenThere: sip-clf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Common Log File format discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 19:12:01 -0000 --Apple-Mail-15-576686546 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings CLF-ers, I would like to start a two week WGLC on the problem statement doc (in = accordance with our discussion in Prague).=20 Please make you comments on the list by Wed. May 4th (I have added a few = days to account for the Easter break).=20 We need reviewers and fresh eyes - so if you can make time to read this = it is much appreciated! Thanks,=20 Peter Musgrave Chair, sip-clf Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: April 18, 2011 10:30:04 AM EDT > To: i-d-announce@ietf.org > Cc: sip-clf@ietf.org > Subject: [sip-clf] I-D = Action:draft-ietf-sipclf-problem-statement-06.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the SIP Common Log Format Working Group = of the IETF. >=20 >=20 > Title : The Common Log Format (CLF) for the Session = Initiation Protocol (SIP) > Author(s) : V. Gurbani, et al. > Filename : draft-ietf-sipclf-problem-statement-06.txt > Pages : 34 > Date : 2011-04-18 >=20 > Well-known web servers such as Apache and web proxies like Squid > support event logging using a common log format. The logs produced > using these de-facto standard formats are invaluable to system > administrators for trouble-shooting a server and tool writers to > craft tools that mine the log files and produce reports and trends. > Furthermore, these log files can also be used to train anomaly > detection systems and feed events into a security event management > system. The Session Initiation Protocol does not have a common log > format, and as a result, each server supports a distinct log format > that makes it unnecessarily complex to produce tools to do trend > analysis and security detection. We propose a common log file format > for SIP servers that can be used uniformly by proxies, registrars, > redirect servers as well as back-to-back user agents. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-sipclf-problem-statement-06= .txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > sip-clf mailing list > sip-clf@ietf.org > https://www.ietf.org/mailman/listinfo/sip-clf --Apple-Mail-15-576686546 Content-Type: multipart/mixed; boundary=Apple-Mail-16-576686546 --Apple-Mail-16-576686546 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Date: April 18, 2011 10:30:04 AM EDT
Subject: [sip-clf] I-D = Action:draft-ietf-sipclf-problem-statement-06.txt

=
A New Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the SIP Common Log Format = Working Group of the IETF.


Title =           : The Common = Log Format (CLF) for the Session Initiation Protocol (SIP)
Author(s) =       : V. Gurbani, et al.
Filename =        : = draft-ietf-sipclf-problem-statement-06.txt
Pages =           : = 34
= Date =            : = 2011-04-18

Well-known web servers such as Apache and web proxies = like Squid
support event logging using a common log format.  The = logs produced
using these de-facto standard formats are invaluable to = system
administrators for trouble-shooting a server and tool writers = to
craft tools that mine the log files and produce reports and = trends.
Furthermore, these log files can also be used to train = anomaly
detection systems and feed events into a security event = management
system.  The Session Initiation Protocol does not = have a common log
format, and as a result, each server supports a = distinct log format
that makes it unnecessarily complex to produce = tools to do trend
analysis and security detection.  We propose a = common log file format
for SIP servers that can be used uniformly by = proxies, registrars,
redirect servers as well as back-to-back user = agents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipclf-proble= m-statement-06.txt

Internet-Drafts are also available by = anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is = the data which will enable a MIME compliant mail = reader
implementation to automatically retrieve the ASCII version of = the
Internet-Draft.
= --Apple-Mail-16-576686546 Content-Disposition: attachment; filename="Mail Attachment" Content-Type: message/external-body; name="Mail Attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2011-04-18072824.I-D@ietf.org>

--Apple-Mail-16-576686546 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
_______________________________________________
sip-clf mailing list
sip-clf@ietf.org
https://www.ietf.org/mailman/listinfo/sip-clf

--Apple-Mail-16-576686546-- --Apple-Mail-15-576686546-- From gsalguei@cisco.com Wed Apr 20 12:24:57 2011 Return-Path: X-Original-To: sip-clf@ietfc.amsl.com Delivered-To: sip-clf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6C8C3E074D for ; Wed, 20 Apr 2011 12:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.698 X-Spam-Level: X-Spam-Status: No, score=-9.698 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyW3ToIUqzal for ; Wed, 20 Apr 2011 12:24:55 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfc.amsl.com (Postfix) with ESMTP id D186FE074B for ; Wed, 20 Apr 2011 12:24:55 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3KJOs4C002761; Wed, 20 Apr 2011 15:24:54 -0400 (EDT) Received: from rtp-gsalguei-87112.cisco.com (rtp-gsalguei-87112.cisco.com [10.116.61.61]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3KJOrWN022345; Wed, 20 Apr 2011 15:24:54 -0400 (EDT) From: Gonzalo Salgueiro Content-Type: multipart/alternative; boundary=Apple-Mail-21-750263058 Date: Wed, 20 Apr 2011 15:24:53 -0400 Message-Id: <091E2FD2-02D6-4A85-AB1C-0BC5EB86FC62@cisco.com> To: "sip-clf@ietf.org Mailing" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [sip-clf] Logging Optional Fields in the SIP CLF X-BeenThere: sip-clf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Common Log File format discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 19:24:57 -0000 --Apple-Mail-21-750263058 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks -=20 According to the discussions in Prague we decided that a single format = be used to log optional fields. The current format draft presents two = separate formats; one for logging Pre-defined optional fields and = another to log vendor-specific elements. The discussions in Prague have = indicated that a universally agreed upon list of Pre-Defined optional = fields is too restrictive. Rather, the ability to log ANY SIP header (or = header element) as well as body (or body element) should be optionally = allowed by this format. I'd like to propose the following format to log optional elements: byte 1 0x09 (Tab) byte 2-5 Tag (Hex) byte 6 0x40 ('@') byte 7-10 Vendor-ID (PEN) byte 11 0x2C (comma) byte 12-15 Length (Hex) byte 16 0x2C (comma) byte 17-... Value (variable length) Note: This format is represented graphically in the diagram at the end = of this message (view with fixed-width font). This is a TLV format for logging optional fields that can be represented = as: tag@PEN,Length,Value where: I. PEN=3D0x0000 is used to log the entire SIP message, message body, or = any non-mandatory SIP header fields plus the Reason-Phrase tag=3D0x0000 Log SIP Header Field or Reason-Phrase tag=3D0x0001 Log message body tag=3D0x0002 Log entire SIP message =20 - For the case of 0000@0000 the associated "Value" field MUST be = populated by the entire header field being logged. That is, the = field-name, the associated colon (":") and the field-value. This = mechanism provides the capability to optionally log ANY SIP header field = by identifying the field being logged in the "Value" field. - Because the Reason-Phrase in a response is part of the Status-Line and = is not identified with a field-name, it is a special case. In this = instance, the the associated "Value" field MUST be populated by the name = "Reason-Phrase" followed by a colon (":") and a single space (SP) = between the colon and the logged reason phrase value. - The corresponding "Length" field includes the length of the entire = "Value" field. This includes the field-name, the colon, and any LWS = separator. - The cases of logging the message body (0001@0000) or the entire SIP = message (0002@0000) are subject to the same field length limitation of = 4k as detailed in the Problem Statement.=20 =20 Example: Consider the SIP response: SIP/2.0 180 Ringing Via: SIP/2.0/UDP pc33.atlanta.com;branch=3Dz9hG4bKnashds8 ;received=3D192.0.2.1 To: Bob ;tag=3Da6c85cf From: Alice ;tag=3D1928301774 Call-ID: a84b4c76e66710 Contact: CSeq: 314159 INVITE Content-Length: 0 The Contact header field and the reason phrase would be logged = respectively as optional fields in the following manner: 0@0,1C,Contact: 0@0,16,Reason-Phrase: Ringing II. PEN=3DVendor-ID is used to log everything else (i.e. any vendor = specified element of a SIP header or body) tag=3Dvendor-specified tags Example: Consider the SIP message: INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=3Dz9hG4bKnashds8 To: Bob From: Alice ;tag=3D1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Date: Thu, 21 Feb 2002 13:02:03 GMT Contact: Content-Type: application/sdp Content-Length: 147 v=3D0 o=3DUserA 2890844526 2890844526 IN IP4 here.com s=3DSession SDP c=3DIN IP4 pc33.atlanta.com t=3D0 0 m=3Daudio 49172 RTP/AVP 0 a=3Drtpmap:0 PCMU/8000 =20 A vendor may choose to log the codec information from the SDP body. This = would be formatted as follows: 3@32473,14,a=3Drtpmap:0 PCMU/8000 or perhaps a vendor wants to log that this message is the n^th message = received from a peering partner. To do so, it would log this = information as: 7@32473,16,1877 example.com which would signify that this is the 1,877^th message from the peering = partner example.com Please provide any feedback on this proposal as it is one the very few = remaining open issues ti finalize the format draft. Regards, Gonzalo =20 0 7 8 15 16 23 24 31 +-----------+-----------+-----------+-----------+ | 0x09 | Tag (Hex) |\ +-----------+-----------+-----------+-----------+ \ | Tag (cont)| 0x40 | Vendor-ID | \ =20 +-----------+-----------+-----------+-----------+ \ Repeated | Vendor-ID (cont) | 0x2C | Length | \ as many +-----------+-----------+-----------+-----------+ / times as | Length (Hex) (cont) | 0x2C | / necessary +-----------+-----------+-----------+-----------+ / | Value (variable length) | / +-----------+-----------+-----------+-----------+/= --Apple-Mail-21-750263058 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Folks = - 

According to the discussions = in Prague we decided that a single format be used to log optional = fields. The current format draft presents two separate formats; one for = logging Pre-defined optional fields and another to log vendor-specific = elements. The discussions in Prague have indicated that a universally = agreed upon list of Pre-Defined optional fields is too restrictive. = Rather, the ability to log ANY SIP header (or header element) as well as = body (or body element) should be optionally allowed by this = format.

I'd like to = propose the following format to log optional elements:

byte 1 0x09 (Tab)
byte 2-5 Tag = (Hex)
byte 6 0x40 = ('@')
byte 7-10 Vendor-ID (PEN)
byte 11 0x2C = (comma)
byte 12-15 Length (Hex)
byte 16 0x2C = (comma)
byte 17-... Value (variable = length)

Note:= This format is represented graphically in the diagram at the end of = this message (view with fixed-width font).

This is a TLV format for logging = optional fields that can be represented as:

tag@PEN,Length,Value

where:

I.  PEN=3D0x0000 is used to = log the entire SIP message, message body, or any non-mandatory SIP = header fields plus the Reason-Phrase
tag=3D0x0000 Log SIP = Header Field or Reason-Phrase
tag=3D0x0001 Log message = body
tag=3D0x0002 Log entire SIP = message
   =  
- For the case of 0000@0000 the = associated "Value" field MUST be populated by the entire header field = being logged. That is, the field-name, the associated colon (":") and = the field-value. This mechanism provides the capability to optionally = log ANY SIP header field by identifying the field being logged in the = "Value" field.
- Because the Reason-Phrase in a = response is part of the Status-Line and is not identified with a = field-name, it is a special case. In this instance, the the = associated "Value" field MUST be populated by the name "Reason-Phrase" = followed by a colon (":") and a single space (SP) between the colon and = the logged reason phrase value.
- The = corresponding "Length" field includes the length of the entire "Value" = field. This includes the field-name, the colon, and any LWS = separator.
- The cases of logging the message body = (0001@0000) or the entire SIP message (0002@0000) are subject to the = same field length limitation of 4k as detailed in the Problem = Statement. 
    
Example:

Consider the SIP response:

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP = pc33.atlanta.com;branch=3Dz9hG4bKnashds8
 ;received=3D192.0.2.1
To: Bob = <sip:bob@biloxi.com>;tag=3Da6c85cf
=
From: Alice <sip:alice@atlanta.com>;tag=3D1928301= 774
Call-ID: a84b4c76e66710
Contact: <sip:bob@192.0.2.4>
CSeq: 314159 INVITE
Content-Length: = 0

The Contact = header field and the reason phrase would be logged respectively as = optional fields in the following manner:

0@0,1C,Contact: <sip:bob@192.0.2.4>
0@0,16,Reason-Phrase: Ringing


II. PEN=3DVendor-ID is used to log = everything else (i.e. any vendor specified element of a SIP header or = body)

tag=3Dvendor-specified = tags

Example:

Consider the SIP = message:

INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP = pc33.atlanta.com;branch=3Dz9hG4bKnashds8
To: Bob = <bob@biloxi.com>
From: Alice <alice@atlanta.com>;tag=3D19283017= 74
Call-ID: a84b4c76e66710
CSeq:= 314159 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 147

v=3D0
o=3DUserA 2890844526 2890844526 IN = IP4 here.com
s=3DSession SDP
c=3DIN IP4 pc33.atlanta.com
t=3D0 0
m=3Daudio 49172 RTP/AVP = 0
a=3Drtpmap:0 = PCMU/8000
    =   

A vendor may choose to log the codec = information from the SDP body. This would be formatted as = follows:

3@32473,14,a=3Drtpmap:0 PCMU/8000

or perhaps a vendor wants to = log that this message is the n^th message received from a peering = partner.  To do so, it would log this information as:

7@32473,16,1877 example.com

which would signify that this is = the 1,877^th message from the peering partner example.com

Please provide any feedback = on this proposal as it is one the very few remaining open issues ti = finalize the format draft.

Regards,

Gonzalo


 

        0     =      7 8        15 16     =   23 24         31
   =      +-----------+-----------+-----------+-----------+
        |    0x09   | =             Tag (Hex)       =       |\
       =  +-----------+-----------+-----------+-----------+ \
        | Tag (cont)|   =  0x40   |       Vendor-ID       = |  \   
       =  +-----------+-----------+-----------+-----------+   \ =  Repeated
        |   =  Vendor-ID (cont)   |    0x2C   |   Length =  |    \ as many
       =  +-----------+-----------+-----------+-----------+    / = times as
        |     =    Length (Hex) (cont)        |   = 0x2C    |   /  necessary
   =      +-----------+-----------+-----------+-----------+ =  /
        |     =        Value (variable length)       =      | /
       =  +-----------+-----------+-----------+-----------+/= --Apple-Mail-21-750263058-- From peter.musgrave@magorcorp.com Wed Apr 27 11:11:07 2011 Return-Path: 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 A6ADDE0710 for ; Wed, 27 Apr 2011 11:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.798 X-Spam-Level: X-Spam-Status: No, score=-101.798 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_LOW=-1, 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 UlTpTj483OEZ for ; Wed, 27 Apr 2011 11:11:06 -0700 (PDT) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0E150E0681 for ; Wed, 27 Apr 2011 11:11:05 -0700 (PDT) Received: by gxk28 with SMTP id 28so1106825gxk.27 for ; Wed, 27 Apr 2011 11:11:05 -0700 (PDT) Received: by 10.236.175.165 with SMTP id z25mr3008182yhl.450.1303927865295; Wed, 27 Apr 2011 11:11:05 -0700 (PDT) Received: from petermac.magor.local ([72.1.217.106]) by mx.google.com with ESMTPS id x68sm496298yhn.57.2011.04.27.11.11.03 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Apr 2011 11:11:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-25--796851502 From: Peter Musgrave In-Reply-To: <091E2FD2-02D6-4A85-AB1C-0BC5EB86FC62@cisco.com> Date: Wed, 27 Apr 2011 14:11:02 -0400 Message-Id: <5FC78793-9C05-4365-BCA6-78B5A4DCCC55@magorcorp.com> References: <091E2FD2-02D6-4A85-AB1C-0BC5EB86FC62@cisco.com> To: Gonzalo Salgueiro X-Mailer: Apple Mail (2.1084) Cc: "sip-clf@ietf.org Mailing" Subject: Re: [sip-clf] Logging Optional Fields in the SIP CLF X-BeenThere: sip-clf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Common Log File format discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 18:11:07 -0000 --Apple-Mail-25--796851502 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi,=20 This is ok by me. Simple and flexible - which is what a logging format = should be.=20 More input needed=20 PLEASE - let's get these final issues laid to rest and get these doc = done! Thanks, Peter Musgrave > Folks -=20 >=20 > According to the discussions in Prague we decided that a single format = be used to log optional fields. The current format draft presents two = separate formats; one for logging Pre-defined optional fields and = another to log vendor-specific elements. The discussions in Prague have = indicated that a universally agreed upon list of Pre-Defined optional = fields is too restrictive. Rather, the ability to log ANY SIP header (or = header element) as well as body (or body element) should be optionally = allowed by this format. >=20 > I'd like to propose the following format to log optional elements: >=20 > byte 1 0x09 (Tab) > byte 2-5 Tag (Hex) > byte 6 0x40 ('@') > byte 7-10 Vendor-ID (PEN) > byte 11 0x2C (comma) > byte 12-15 Length (Hex) > byte 16 0x2C (comma) > byte 17-... Value (variable length) >=20 > Note: This format is represented graphically in the diagram at the end = of this message (view with fixed-width font). >=20 > This is a TLV format for logging optional fields that can be = represented as: >=20 > tag@PEN,Length,Value >=20 > where: >=20 > I. PEN=3D0x0000 is used to log the entire SIP message, message body, = or any non-mandatory SIP header fields plus the Reason-Phrase >=20 > tag=3D0x0000 Log SIP Header Field or Reason-Phrase > tag=3D0x0001 Log message body > tag=3D0x0002 Log entire SIP message > =20 > - For the case of 0000@0000 the associated "Value" field MUST be = populated by the entire header field being logged. That is, the = field-name, the associated colon (":") and the field-value. This = mechanism provides the capability to optionally log ANY SIP header field = by identifying the field being logged in the "Value" field. > - Because the Reason-Phrase in a response is part of the Status-Line = and is not identified with a field-name, it is a special case. In this = instance, the the associated "Value" field MUST be populated by the name = "Reason-Phrase" followed by a colon (":") and a single space (SP) = between the colon and the logged reason phrase value. > - The corresponding "Length" field includes the length of the entire = "Value" field. This includes the field-name, the colon, and any LWS = separator. > - The cases of logging the message body (0001@0000) or the entire SIP = message (0002@0000) are subject to the same field length limitation of = 4k as detailed in the Problem Statement.=20 > =20 > Example: >=20 > Consider the SIP response: >=20 > SIP/2.0 180 Ringing > Via: SIP/2.0/UDP pc33.atlanta.com;branch=3Dz9hG4bKnashds8 > ;received=3D192.0.2.1 > To: Bob ;tag=3Da6c85cf > From: Alice ;tag=3D1928301774 > Call-ID: a84b4c76e66710 > Contact: > CSeq: 314159 INVITE > Content-Length: 0 >=20 > The Contact header field and the reason phrase would be logged = respectively as optional fields in the following manner: >=20 > 0@0,1C,Contact: > 0@0,16,Reason-Phrase: Ringing >=20 >=20 > II. PEN=3DVendor-ID is used to log everything else (i.e. any vendor = specified element of a SIP header or body) >=20 > tag=3Dvendor-specified tags >=20 > Example: >=20 > Consider the SIP message: >=20 > INVITE sip:bob@biloxi.com SIP/2.0 > Via: SIP/2.0/UDP pc33.atlanta.com;branch=3Dz9hG4bKnashds8 > To: Bob > From: Alice ;tag=3D1928301774 > Call-ID: a84b4c76e66710 > CSeq: 314159 INVITE > Max-Forwards: 70 > Date: Thu, 21 Feb 2002 13:02:03 GMT > Contact: > Content-Type: application/sdp > Content-Length: 147 >=20 > v=3D0 > o=3DUserA 2890844526 2890844526 IN IP4 here.com > s=3DSession SDP > c=3DIN IP4 pc33.atlanta.com > t=3D0 0 > m=3Daudio 49172 RTP/AVP 0 > a=3Drtpmap:0 PCMU/8000 > =20 >=20 > A vendor may choose to log the codec information from the SDP body. = This would be formatted as follows: >=20 > 3@32473,14,a=3Drtpmap:0 PCMU/8000 >=20 > or perhaps a vendor wants to log that this message is the n^th message = received from a peering partner. To do so, it would log this = information as: >=20 > 7@32473,16,1877 example.com >=20 > which would signify that this is the 1,877^th message from the peering = partner example.com >=20 > Please provide any feedback on this proposal as it is one the very few = remaining open issues ti finalize the format draft. >=20 > Regards, >=20 > Gonzalo >=20 >=20 > =20 >=20 > 0 7 8 15 16 23 24 31 > +-----------+-----------+-----------+-----------+ > | 0x09 | Tag (Hex) |\ > +-----------+-----------+-----------+-----------+ \ > | Tag (cont)| 0x40 | Vendor-ID | \ =20 > +-----------+-----------+-----------+-----------+ \ = Repeated > | Vendor-ID (cont) | 0x2C | Length | \ as many > +-----------+-----------+-----------+-----------+ / times = as > | Length (Hex) (cont) | 0x2C | / = necessary > +-----------+-----------+-----------+-----------+ / > | Value (variable length) | / > +-----------+-----------+-----------+-----------+/ > _______________________________________________ > sip-clf mailing list > sip-clf@ietf.org > https://www.ietf.org/mailman/listinfo/sip-clf --Apple-Mail-25--796851502 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Folks - 

According = to the discussions in Prague we decided that a single format be used to = log optional fields. The current format draft presents two separate = formats; one for logging Pre-defined optional fields and another to log = vendor-specific elements. The discussions in Prague have indicated that = a universally agreed upon list of Pre-Defined optional fields is too = restrictive. Rather, the ability to log ANY SIP header (or header = element) as well as body (or body element) should be optionally allowed = by this format.

I'd like to = propose the following format to log optional elements:

byte 1 0x09 (Tab)
byte 2-5 Tag = (Hex)
byte 6 0x40 = ('@')
byte 7-10 Vendor-ID (PEN)
byte 11 0x2C = (comma)
byte 12-15 Length (Hex)
byte 16 0x2C = (comma)
byte 17-... Value (variable = length)

Note:= This format is represented graphically in the diagram at the end of = this message (view with fixed-width font).

This is a TLV format for logging = optional fields that can be represented as:

tag@PEN,Length,Value

where:

I.  PEN=3D0x0000 is used to = log the entire SIP message, message body, or any non-mandatory SIP = header fields plus the Reason-Phrase
tag=3D0x0000 Log SIP = Header Field or Reason-Phrase
tag=3D0x0001 Log message = body
tag=3D0x0002 Log entire SIP = message
   =  
- For the case of 0000@0000 the = associated "Value" field MUST be populated by the entire header field = being logged. That is, the field-name, the associated colon (":") and = the field-value. This mechanism provides the capability to optionally = log ANY SIP header field by identifying the field being logged in the = "Value" field.
- Because the Reason-Phrase in a = response is part of the Status-Line and is not identified with a = field-name, it is a special case. In this instance, the the = associated "Value" field MUST be populated by the name "Reason-Phrase" = followed by a colon (":") and a single space (SP) between the colon and = the logged reason phrase value.
- The = corresponding "Length" field includes the length of the entire "Value" = field. This includes the field-name, the colon, and any LWS = separator.
- The cases of logging the message body = (0001@0000) or the entire SIP message (0002@0000) are subject to the = same field length limitation of 4k as detailed in the Problem = Statement. 
    
Example:

Consider the SIP response:

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP = pc33.atlanta.com;branch=3Dz9hG4bKnashds8
 ;received=3D192.0.2.1
To: Bob = <sip:bob@biloxi.com>;tag=3Da6c85cf
=
From: Alice <sip:alice@atlanta.com>;tag=3D1928301= 774
Call-ID: a84b4c76e66710
Contact: <sip:bob@192.0.2.4>
CSeq: 314159 INVITE
Content-Length: = 0

The Contact = header field and the reason phrase would be logged respectively as = optional fields in the following manner:

0@0,1C,Contact: <sip:bob@192.0.2.4>
0@0,16,Reason-Phrase: Ringing


II. PEN=3DVendor-ID is used to log = everything else (i.e. any vendor specified element of a SIP header or = body)

tag=3Dvendor-specified = tags

Example:

Consider the SIP = message:

INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP = pc33.atlanta.com;branch=3Dz9hG4bKnashds8
To: Bob = <bob@biloxi.com>
From: Alice <alice@atlanta.com>;tag=3D19283017= 74
Call-ID: a84b4c76e66710
CSeq:= 314159 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 147

v=3D0
o=3DUserA 2890844526 2890844526 IN = IP4 here.com
s=3DSession SDP
c=3DIN IP4 pc33.atlanta.com
t=3D0 0
m=3Daudio 49172 RTP/AVP = 0
a=3Drtpmap:0 = PCMU/8000
    =   

A vendor may choose to log the codec = information from the SDP body. This would be formatted as = follows:

3@32473,14,a=3Drtpmap:0 PCMU/8000

or perhaps a vendor wants to = log that this message is the n^th message received from a peering = partner.  To do so, it would log this information as:

7@32473,16,1877 example.com

which would signify that this is = the 1,877^th message from the peering partner example.com

Please provide any feedback = on this proposal as it is one the very few remaining open issues ti = finalize the format draft.

Regards,

Gonzalo


 

        0     =      7 8        15 16     =   23 24         31
   =      +-----------+-----------+-----------+-----------+
        |    0x09   | =             Tag (Hex)       =       |\
       =  +-----------+-----------+-----------+-----------+ \
        | Tag (cont)|   =  0x40   |       Vendor-ID       = |  \   
       =  +-----------+-----------+-----------+-----------+   \ =  Repeated
        |   =  Vendor-ID (cont)   |    0x2C   |   Length =  |    \ as many
       =  +-----------+-----------+-----------+-----------+    / = times as
        |     =    Length (Hex) (cont)        |   = 0x2C    |   /  necessary
   =      +-----------+-----------+-----------+-----------+ =  /
        |     =        Value (variable length)       =      | /
       =  +-----------+-----------+-----------+-----------+/_____= __________________________________________
sip-clf mailing list
sip-clf@ietf.org
https://www.ietf.= org/mailman/listinfo/sip-clf

= --Apple-Mail-25--796851502-- From peter.musgrave@magorcorp.com Wed Apr 27 11:43:02 2011 Return-Path: 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 27B6FE077F for ; Wed, 27 Apr 2011 11:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.698 X-Spam-Level: X-Spam-Status: No, score=-102.698 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 30KvYqW1s16Q for ; Wed, 27 Apr 2011 11:43:01 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id A68F5E0769 for ; Wed, 27 Apr 2011 11:43:00 -0700 (PDT) Received: by ywi6 with SMTP id 6so861293ywi.31 for ; Wed, 27 Apr 2011 11:43:00 -0700 (PDT) Received: by 10.151.76.18 with SMTP id d18mr2129446ybl.446.1303929779809; Wed, 27 Apr 2011 11:42:59 -0700 (PDT) Received: from petermac.magor.local ([72.1.217.106]) by mx.google.com with ESMTPS id q34sm94382ybk.18.2011.04.27.11.42.57 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Apr 2011 11:42:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-26--794937731 From: Peter Musgrave In-Reply-To: Date: Wed, 27 Apr 2011 14:42:56 -0400 Message-Id: <8CB1F01A-91E7-4A02-A984-718AEC84EE0B@magorcorp.com> References: <20110418143004.807.72505.idtracker@ietfc.amsl.com> To: Peter Musgrave X-Mailer: Apple Mail (2.1084) Cc: "sip-clf@ietf.org Mailing" Subject: Re: [sip-clf] WGLC:draft-ietf-sipclf-problem-statement-06.txt X-BeenThere: sip-clf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Common Log File format discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 18:43:02 -0000 --Apple-Mail-26--794937731 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii (as individual) Overall, I think this is in excellent shape. I have a few specific = observations/questions: Last sentence of abstract could be simplified just to SIP devices? (In = section 4 UA is explicitly mentioned - and it's not in the abstract = which has a list of SIP server type devices).=20 8.1 From/To Header Both contain the statement "it is not necessary to log any URI = parameters".=20 Perhaps this should be in normative language? URI parameters MUST NOT be = logged (they can be logged separately using an option field) R-URI: URI parameters MUST be logged? 8.2 Is it necessary to indicate what a UAS-half and UAC-half are? I can = see that for a proxy a request is both received and forwarded (although = I am not sure I would use the term UAC-half for the sent side of a = message.) As for a B2BUA I tend to think of the two sides as a UAC and a = UAS (and not a "half") [I have set aside the examples for now - I will finish reviewing that = before the WGLC ends]. Cheers,=20 Peter On 2011-04-18, at 3:11 PM, Peter Musgrave wrote: > Greetings CLF-ers, >=20 > I would like to start a two week WGLC on the problem statement doc (in = accordance with our discussion in Prague).=20 >=20 > Please make you comments on the list by Wed. May 4th (I have added a = few days to account for the Easter break).=20 >=20 > We need reviewers and fresh eyes - so if you can make time to read = this it is much appreciated! >=20 > Thanks,=20 >=20 > Peter Musgrave > Chair, sip-clf >=20 > Begin forwarded message: >=20 >> From: Internet-Drafts@ietf.org >> Date: April 18, 2011 10:30:04 AM EDT >> To: i-d-announce@ietf.org >> Cc: sip-clf@ietf.org >> Subject: [sip-clf] I-D = Action:draft-ietf-sipclf-problem-statement-06.txt >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the SIP Common Log Format Working Group = of the IETF. >>=20 >>=20 >> Title : The Common Log Format (CLF) for the Session = Initiation Protocol (SIP) >> Author(s) : V. Gurbani, et al. >> Filename : draft-ietf-sipclf-problem-statement-06.txt >> Pages : 34 >> Date : 2011-04-18 >>=20 >> Well-known web servers such as Apache and web proxies like Squid >> support event logging using a common log format. The logs produced >> using these de-facto standard formats are invaluable to system >> administrators for trouble-shooting a server and tool writers to >> craft tools that mine the log files and produce reports and trends. >> Furthermore, these log files can also be used to train anomaly >> detection systems and feed events into a security event management >> system. The Session Initiation Protocol does not have a common log >> format, and as a result, each server supports a distinct log format >> that makes it unnecessarily complex to produce tools to do trend >> analysis and security detection. We propose a common log file format >> for SIP servers that can be used uniformly by proxies, registrars, >> redirect servers as well as back-to-back user agents. >>=20 >> A URL for this Internet-Draft is: >> = http://www.ietf.org/internet-drafts/draft-ietf-sipclf-problem-statement-06= .txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. > >> _______________________________________________ >> sip-clf mailing list >> sip-clf@ietf.org >> https://www.ietf.org/mailman/listinfo/sip-clf >=20 --Apple-Mail-26--794937731 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii (as = individual)

Overall, I think this is in = excellent shape. I have a few specific observations/questions:

Last sentence of abstract could = be simplified just to SIP devices? (In section 4 UA is explicitly = mentioned - and it's not in the abstract which has a list of SIP server = type devices). 

Both contain the statement "it is not necessary = to log any URI parameters". 
Perhaps this should be in = normative language? URI parameters MUST NOT be logged (they can be = logged separately using an option field)
R-URI: URI parameters MUST be logged?

8.2 Is it necessary to indicate = what a UAS-half and UAC-half are? I can see that for a proxy a request = is both received and forwarded (although I am not sure I would use the = term UAC-half for the sent side of a message.) As for a B2BUA I tend to = think of the two sides as a UAC and a UAS (and not a "half")

[I have set aside the examples = for now - I will finish reviewing that before the WGLC ends].
Cheers, 





Greetings = CLF-ers,

I would like to start a two week WGLC on the = problem statement doc (in accordance with our discussion in = Prague). 

Please make you comments on the = list by Wed. May 4th (I have added a few days to account for the Easter = break). 

We need reviewers and fresh eyes = - so if you can make time to read this it is much = appreciated!

Thanks, 

Peter Musgrave
Chair, sip-clf

Begin = forwarded message:

Date: April 18, 2011 10:30:04 AM EDT
Subject: [sip-clf] I-D = Action:draft-ietf-sipclf-problem-statement-06.txt

=
A New Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the SIP Common Log Format = Working Group of the IETF.


Title =           : The Common = Log Format (CLF) for the Session Initiation Protocol (SIP)
Author(s) =       : V. Gurbani, et al.
Filename =        : = draft-ietf-sipclf-problem-statement-06.txt
Pages =           : = 34
= Date =            : = 2011-04-18

Well-known web servers such as Apache and web proxies = like Squid
support event logging using a common log format.  The = logs produced
using these de-facto standard formats are invaluable to = system
administrators for trouble-shooting a server and tool writers = to
craft tools that mine the log files and produce reports and = trends.
Furthermore, these log files can also be used to train = anomaly
detection systems and feed events into a security event = management
system.  The Session Initiation Protocol does not = have a common log
format, and as a result, each server supports a = distinct log format
that makes it unnecessarily complex to produce = tools to do trend
analysis and security detection.  We propose a = common log file format
for SIP servers that can be used uniformly by = proxies, registrars,
redirect servers as well as back-to-back user = agents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipclf-proble= m-statement-06.txt

Internet-Drafts are also available by = anonymous FTP at:
ftp://ftp.ietf.org/internet-d= rafts/

Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of = the
Internet-Draft.
<M= ail Attachment>
_______________________________________________
sip-= clf mailing list
sip-clf@ietf.org
https://www.ietf.= org/mailman/listinfo/sip-clf

<= /blockquote>
= --Apple-Mail-26--794937731--