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

[Peter Musgrave <[e-mail]>]

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.