Shepherd writeup
rfc7070-10

{ This is the formal shepherding submission for this draft. It uses a
variant of an experimental form being developed by Barry Leiba. /d }
{re-wrapped /pr}

> == 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
Back