[sip-clf] Publication Request for draft-ietf-sipclf-problem-statement

Peter Musgrave <musgravepj@gmail.com> Sun, 17 July 2011 14:10 UTC

Return-Path: <musgravepj@gmail.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 3F59A21F861D for <sip-clf@ietfa.amsl.com>; Sun, 17 Jul 2011 07:10:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.565
X-Spam-Level:
X-Spam-Status: No, score=-3.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 kFkLvmUtlTuh for <sip-clf@ietfa.amsl.com>; Sun, 17 Jul 2011 07:10:09 -0700 (PDT)
Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE0921F85EC for <sip-clf@ietf.org>; Sun, 17 Jul 2011 07:10:05 -0700 (PDT)
Received: by fxe4 with SMTP id 4so6059012fxe.27 for <sip-clf@ietf.org>; Sun, 17 Jul 2011 07:09:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=/OCylPi3Xjq1NO8kzgHiD/tm4BJ9Tfx9PO3Z6yUyqc4=; b=wlRtUn4h9BcdD29NDiSwYq11q3/kVmBuEud+XLeA1EQ2xAZsz1bDubrS325ns3fJYE R+bf+6boJ+ufyco6wc26uPQ+DLeLPqXQ+mx1MaTBM4YPs1XrLjHk3CBTyCtiQ7ETwLUq 781F/2OlhCg/mmcC+mfNB+M3k+sREH+JrE/h8=
MIME-Version: 1.0
Received: by 10.223.16.210 with SMTP id p18mr3821701faa.71.1310911772153; Sun, 17 Jul 2011 07:09:32 -0700 (PDT)
Received: by 10.223.103.71 with HTTP; Sun, 17 Jul 2011 07:09:32 -0700 (PDT)
Date: Sun, 17 Jul 2011 10:09:32 -0400
Message-ID: <CAJH01tbV2OD0W6zVuAxgkm3fkW6bLFD1k0OsAteF32S-GCyOGw@mail.gmail.com>
From: Peter Musgrave <musgravepj@gmail.com>
To: sip-clf@ietf.org
Content-Type: multipart/alternative; boundary=00151748de7c82d73104a8446e61
Subject: [sip-clf] Publication Request for draft-ietf-sipclf-problem-statement
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: Sun, 17 Jul 2011 14:10:10 -0000

https://datatracker.ietf.org/doc/draft-ietf-sipclf-problem-statement/  has
been submitted for IESG publication.


Publication request text:


 (1.a) Who is the Document Shepherd for this document? Has the

        Document Shepherd personally reviewed this version of the

        document and, in particular, does he or she believe this

        version is ready for forwarding to the IESG for publication?


Peter Musgrave is the document shephard and has read version -07. This
version is ready for publication subject to the correction of two nits after
AD review.



  (1.b) Has the document had adequate review both from key WG members

        and from key non-WG members? Does the Document Shepherd have

        any concerns about the depth or breadth of the reviews that

        have been performed?


Yes. Over the past 18 months the document has seen significant input from a
number of people with strong background in SIP.


  (1.c) Does the Document Shepherd have concerns that the document

        needs more review from a particular or broader perspective,

        e.g., security, operational complexity, someone familiar with

        AAA, internationalization or XML?


No.


  (1.d) Does the Document Shepherd have any specific concerns or

        issues with this document that the Responsible Area Director

        and/or the IESG should be aware of? For example, perhaps he

        or she is uncomfortable with certain parts of the document, or

        has concerns whether there really is a need for it. In any

        event, if the WG has discussed those issues and has indicated

        that it still wishes to advance the document, detail those

        concerns here. Has an IPR disclosure related to this document

        been filed? If so, please include a reference to the

        disclosure and summarize the WG discussion and conclusion on

        this issue.

No.


  (1.e) How solid is the WG consensus behind this document? Does it

        represent the strong concurrence of a few individuals, with

        others being silent, or does the WG as a whole understand and

        agree with it?

The consensus for the fields which any format solution needs to log have
been uncontroversial. The minimal set of fields are basic to any SIP record
keeping and an extension mechanism allows customization by those who need
more.




  (1.f) Has anyone threatened an appeal or otherwise indicated extreme

        discontent? If so, please summarise the areas of conflict in

        separate email messages to the Responsible Area Director. (It

        should be in a separate email because this questionnaire is

        entered into the ID Tracker.)

No.


  (1.g) Has the Document Shepherd personally verified that the

        document satisfies all ID nits? (See the Internet-Drafts
Checklist<http://www.ietf.org/id-info/checklist.html>


        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are

        not enough; this check needs to be thorough. Has the document

        met all formal review criteria it needs to, such as the MIB

        Doctor, media type and URI type reviews?

There are two minor nits (There are 2 instances of lines with
non-RFC5735-compliant IPv4 addresses). These will be addressed after AD
review.



  (1.h) Has the document split its references into normative and

        informative? Are there normative references to documents that

        are not ready for advancement or are otherwise in an unclear

        state? If such normative references exist, what is the

        strategy for their completion? Are there normative references

        that are downward references, as described in [RFC3967]? If

        so, list these downward references to support the Area

        Director in the Last Call procedure for them [RFC3967].

Yes.


  (1.i) Has the Document Shepherd verified that the document IANA

        consideration section exists and is consistent with the body

        of the document? If the document specifies protocol

        extensions, are reservations requested in appropriate IANA

        registries? Are the IANA registries clearly identified? If

        the document creates a new registry, does it define the

        proposed initial contents of the registry and an allocation

        procedure for future registrations? Does it suggest a

        reasonable name for the new registry? See [RFC5226]. If the

        document describes an Expert Review process has Shepherd

        conferred with the Responsible Area Director so that the IESG

        can appoint the needed Expert during the IESG Evaluation?

This section exists. There are no IANA considerations


  (1.j) Has the Document Shepherd verified that sections of the

        document that are written in a formal language, such as XML

        code, BNF rules, MIB definitions, etc., validate correctly in

        an automated checker?

There are no such sections.


  (1.k) The IESG approval announcement includes a Document

        Announcement Write-Up. Please provide such a Document

        Announcement Write-Up? Recent examples can be found in the

        "Action" announcements for approved documents. The approval

        announcement contains the following sections:


     Technical Summary

   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.  This document provides motivation

   for a common format and defines the mandatory fields for such a log as

   well as a need to allow extensions.


     Working Group Summary

        The problem statement was not contentious.


     Document Quality

        During the review process two implementations were developed by two
different implementors.

        These helped clarify some of the details in this document.