Skip to main content

Shepherd writeup

Shepherd Write-Up (Date: 2017-05-17)

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 
<> and <>.

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 

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 

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?

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 <>, so 
it is fine.

12) Required formal review criteria

13) Identification of all references as either normative or informative?

14) Normative references to documents not ready for advancement?

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

19) Reviews and automated checks performed to validate formal languages
No automated checks, only a manual review.