[sip-clf] problem-statement and logging arbitrary SIP fields

["Vijay K. Gurbani" <[e-mail]>]

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} / [e-mail]
Web:   http://ect.bell-labs.com/who/vkg/