[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
- [domainrep] / DRAFT / Repute WG Shepherd Document… Dave Crocker