[domainrep] / DRAFT / Repute WG Shepherd Document Writeup: draft-ietf-repute-model-03

Dave Crocker <dhc@dcrocker.net> Mon, 25 February 2013 23:26 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: domainrep@ietfa.amsl.com
Delivered-To: domainrep@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1C121E815D for <domainrep@ietfa.amsl.com>; Mon, 25 Feb 2013 15:26:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 UkPYi-xbNIRM for <domainrep@ietfa.amsl.com>; Mon, 25 Feb 2013 15:26:57 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1329B21E814E for <domainrep@ietf.org>; Mon, 25 Feb 2013 15:26:57 -0800 (PST)
Received: from [172.19.126.234] (64.125.189.90.t00817-23.above.net [64.125.189.90] (may be forged)) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r1PNQrZ7032555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Feb 2013 15:26:53 -0800
Message-ID: <512BF33A.1010909@dcrocker.net>
Date: Mon, 25 Feb 2013 15:26:50 -0800
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: Pete Resnick <presnick@qti.qualcomm.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 25 Feb 2013 15:26:56 -0800 (PST)
Cc: "domainrep@ietf.org" <domainrep@ietf.org>, draft-ietf-repute-model.all@tools.ietf.org
Subject: [domainrep] / DRAFT / Repute WG Shepherd Document Writeup: draft-ietf-repute-model-03
X-BeenThere: domainrep@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: Domain Reputation discussion list <domainrep.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/domainrep>, <mailto:domainrep-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/domainrep>
List-Post: <mailto:domainrep@ietf.org>
List-Help: <mailto:domainrep-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/domainrep>, <mailto:domainrep-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Feb 2013 23:26:58 -0000

G'day.

This is the formal shepherding submission for this draft.  It uses a 
variant of an experimental form being developed by Barry Leiba.

I'm separately posting a review of the document.  The shepherd writeup 
copies the summary of the review.


d/


> == Document Writeup ==

> === 1. Summary ===
>
> Who is the document shepherd?

   D. Crocker


> Who is the responsible Area Director?

   P. Resnick


> Explain briefly what the intent of the document is (the document's
> abstract is usually good for this), and why the working group has
> chosen the requested publication type (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic).

    Using work on SPF and DKIM for motivation, the draft builds upon 
recent work in email authentication. The document describes a basic 
architecture for reputation queries.  It defines reputation as "the 
estimation in which an identifiable actor is held, especially by the 
community or the Internet public generally."  The document sets the 
stage for detailed specifications by providing:

     o  Vocabulary for the current work and work of this type;
     o  The types and content of queries that can be supported;
     o  The extensible range of response information that can be
        provided;
     o  A query/response protocol;
     o  Query/response transport conventions.

    The document is well-organized, defines its scope and is usable in 
its current form.  Detailed comments are offered below, merely as 
possible enhancement.

    As a model document, the document is appropriate for Informational 
status.  { Given that it contains terminology definitions that are key 
to the remaining work, I could imagine Proposed making sense?  /d }


> === 2. Review and Consensus ===
>
> Explain how actively the document was reviewed and discussed, by the
> working group and external parties, and explain in a general sense
> how much of the interested community is behind the document.  Explain
> anything notable about the discussion of the document.

The document has gone through multiple drafts, over a period of time, 
that were discussed in the working group.  Discussion was mild and 
supportive, with no significant controversy. The working group 'style' 
was mostly of a small, collaborative set of active participants.

The document includes some core material published previously, which 
means that it is already well-established.  Equally, the document's 
terminology, model and discussion are reasonably straightforward and not 
controversial.

[ Commentary about the experimental Shepherd's form solicited the 
Shepherd's personal comfort with the document:  My comfort is reasonably 
high.  The material and reasonably simple, straightforward and 
intuitively likely to be useful. ]


> === 3. Intellectual Property ===
>
> Confirm that each author has stated that their direct, personal
> knowledge of any IPR related to this document has already been
> disclosed, in conformance with BCPs 78 and 79.  Explain briefly the
> working group discussion about any IPR disclosures regarding this
> document, and summarize the outcome.

[ Discussion about this part of the experimental form mostly highlighted 
the challenges of making it be useful.  So I'll recast it as:  Discuss 
the basis for believing that there has been sufficient due diligence 
with the authors, concerning document IPR. ]

The author is highly experienced with IETF work and the document IPR 
standard is the default.  No IPR concerns are anticipated.


> === 4. Other Points ===

None noted.


> === Checklist ===
>
> This section is not meant to be submitted, but is here as a useful
> checklist of things the document shepherd is expected to have
> verified '''before''' publication is requested from the responsible
> Area Director.  If the answers to any of these is "no", please
> explain the situation in the body of the writeup.
>
> * Does the shepherd stand behind the document and think the document
> is ready for publication?

yes.

> * Is the correct RFC type indicated in the title page header?

Minor point. Might be worth reviewing.

> * Is the abstract both brief and sufficient, and does it stand alone
> as a brief summary?

Yes.  Review suggests small enhancement, for small improvement.


> * Is the intent of the document accurately and adequately explained
> in the introduction?

Yes.

> * Have all required formal reviews (MIB Doctor, Media Type, URI,
> etc.) been requested and/or completed?

None needed.

> * Has the shepherd performed automated checks -- idnits (see
> http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist),
> checks of BNF rules, XML code and schemas, MIB definitions, and so on
> -- and determined that the document passes the tests?  (In general,
> nits should be fixed before the document is sent to the IESG. If
> there are reasons that some remain (false positives, perhaps, or
> abnormal things that are necessary for this particular document),
> explain them.)

Yes.

> * Has each author stated that their direct, personal knowledge of any
> IPR related to this document has already been disclosed, in
> conformance with BCPs 78 and 79?

Yes.

> * Have all references within this document been identified as either
> normative or informative, and does the shepherd agree with how they
> have been classified?

Yes.

> * Are all normative references made to documents that are ready for
> advancement and are otherwise in a clear state?

Yes.

> * If publication of this document changes the status of any existing
> RFCs, are those RFCs listed on the title page header, and are the
> changes listed in the abstract and discussed (explained, not just
> mentioned) in the introduction?

NA.

> * If this is a "bis" document, have all of the errata been
> considered?

NA.

> * IANA Considerations:

NA.



d/

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net