Shepherd Write-Up (Date: 2017-05-17)
draft-baeuerle-netnews-cancel-lock-04
1) Type of RFC
==============
The intended category of this document will be "Standards Track".
The intended status of this document will be "Proposed Standard".
This is the proper type of RFC because this document specifies a
long-standing authentication system that has been in use for more than
20 years with regards to Netnews articles.
2) Document Announcement Write-Up
=================================
Technical Summary
-----------------
This document defines an extension to the Netnews Article Format that
may be used to authenticate the cancelling and superseding of existing
articles. If approved, this document updates RFC 5537.
Working Group Summary
---------------------
The draft was reviewed by a few NNTP and Netnews experts in
<news:news.software.nntp> and <news:de.comm.software.newsserver>.
Document Quality
----------------
Implementations of the mechanism already exist, like the canlock C
library or Perl hooks available for news servers.
News clients like Gnus, flnews, slrn or tin natively implement it.
Document Shepherd: Julien Elie
Responsible Area Director: Alexey Melnikov
3) Briefly describe the review of this document
===============================================
I have reviewed the document and checked that it correctly describes the
behaviour of existing implementations. I reckon it is ready for
publication.
4) Shepherd concerns
====================
No concerns.
5) Further document review
==========================
Two questions (in Sections 4 and 7) are inline in the document for the
Security directorate review. They were risen during discussions about
the document and just await for the validation by the Security directorate.
6) Document issues
==================
No issues (beyond the two remaining minor questions for the Security
directorate).
7) IPR disclosures
==================
The author confirmed that there is no IPR involved.
8) Has an IPR disclosure been filed that references this document?
==================================================================
Nothing known.
9) Consensus of the interested community behind this document?
==============================================================
There is consensus that the work Simon Lyall began in 1998 in
draft-ietf-usefor-cancel-lock should be updated to current usage and
standardized. It will help future implementers.
At the same time, the insecure MD5 algorithm is phased out. A IANA
registry is created to permit new algorithm names to be easily reserved
and used with this mechanism.
10) Has anyone threatened an appeal or indicated extreme discontent?
====================================================================
No.
11) ID nits
===========
== Too long line in Section 5.2
Maybe rewrite "uid+mid used as data, sec as secret key" as "uid+mid is
data, sec is secret key"?
== The document seems to contain a disclaimer for pre-RFC5378 work [...]
If you are able to get all authors (current and original) to grant those
rights, you can and should remove the disclaimer
I think Simon is still answering his mails. He should be asked whether
he is willing to grant his rights so that the final document can be
released without the disclaimer. Of course, if he does not want to, the
disclaimer should remain.
== Possible downref: Non-RFC (?) normative reference: ref. 'SHA'
As the "sha256" scheme is mandatory to implement, a reference to its
definition should be normative.
I suggest to move [SHA] to informative, and [RFC6234] (specifying
SHA-256) to normative. Though RFC 6234 is Informational, it is present
in the Downref registry <https://datatracker.ietf.org/doc/downref/>, so
it is fine.
12) Required formal review criteria
===================================
N/A.
13) Identification of all references as either normative or informative?
========================================================================
Yes.
14) Normative references to documents not ready for advancement?
================================================================
None.
15) Are there downward normative references (see RFC 3967)?
======================================================================
With RFC 6234 in the normative Section (see my previous comment in
question 11), it is a downref, already present in the Downref registry.
16) Status change of any existing RFCs?
=======================================
It updates RFC 5537 as noted in the title page header, listed in the
Abstract, and discussed in the Introduction.
17) Document Shepherd's review of the IANA Considerations Section
=================================================================
The IANA Considerations Section is consistent with the body of the
document. The two new header field names and the four new algorithm
names are properly associated with a reservation in IANA registries.
The two referenced IANA registries are clearly identified. The initial
contents of the algorithm names registry is detailed; allocation
procedures for future registrations are defined, and the name for the
registry is reasonable.
18) IANA registries that require Expert Review for future allocations
=====================================================================
None.
19) Reviews and automated checks performed to validate formal languages
=======================================================================
No automated checks, only a manual review.