Skip to main content

Telechat Review of draft-baeuerle-netnews-cancel-lock-06

Request Review of draft-baeuerle-netnews-cancel-lock
Requested revision No specific revision (document currently at 09)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-09-26
Requested 2017-09-13
Authors Michael Bäuerle
I-D last updated 2017-09-21
Completed reviews Genart Last Call review of -05 by Paul Kyzivat (diff)
Secdir Last Call review of -05 by David Mandelberg (diff)
Genart Telechat review of -06 by Paul Kyzivat (diff)
Secdir Telechat review of -06 by David Mandelberg (diff)
Opsdir Telechat review of -06 by Joel Jaeggli (diff)
Assignment Reviewer Paul Kyzivat
State Completed
Request Telechat review on draft-baeuerle-netnews-cancel-lock by General Area Review Team (Gen-ART) Assigned
Reviewed revision 06 (document currently at 09)
Result On the Right Track
Completed 2017-09-21
I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please wait for direction from your document 
shepherd or AD before posting a new version of the draft. For more 
information, please see the FAQ at 

Document: draft-baeuerle-netnews-cancel-lock-06
Reviewer: Paul Kyzivat
Review Date: 2017-09-21
IETF LC End Date: 2017-06-28
IESG Telechat date: 2017-09-26


This draft is on the right track but has open issues, described in the 

General Comments:

I have not attempted to validate the security properties of this 
document - leaving that to a security review.

I have also not attempted to verify the operational suitability of this 
mechanism because I don't have the experience needed to do so.


Major: 1
Minor: 0
Nits:  0

(1) MAJOR:

In Section 2, the ABNF syntax provided does not do what you want it to. 
You supply:

        fields =/ *( cancel-lock / cancel-key )

as an extension to the definition in RFC5536:

     fields          =/ *( approved /
                           archive /
                           control /
                           distribution /
                           expires /
                           followup-to /
                           injection-date /
                           injection-info /
                           lines /
                           newsgroups /
                           organization /
                           path /
                           summary /
                           supersedes /
                           user-agent /
                           xref )

and that in turn extends RFC5322:

     fields          =   *(trace
                           *optional-field /
                           *(resent-date /
                            resent-from /
                            resent-sender /
                            resent-to /
                            resent-cc /
                            resent-bcc /
                         *(orig-date /
                         from /
                         sender /
                         reply-to /
                         to /
                         cc /
                         bcc /
                         message-id /
                         in-reply-to /
                         references /
                         subject /
                         comments /
                         keywords /

     message         =   (fields / obs-fields)
                         [CRLF body]

RFC5536 got this wrong, and the new draft continues the mistake. The 
problem is with the way things are grouped. Let me give a simpler example:

     foo = *("a" / "b") / *("c" / "d")

This means the following are valid: ab aabb bab cd ccdd dcd
But the following are not: abcd ac

The latter is what you want, for which the syntax would be:

     foo = *("a" / "b" / "c" / "d")

It isn't easy to do a valid syntax extension like this because of way 
the ABNF of RFC5322 is structured. However, after offline discussion, we 
realized that RFC5322 already has an extension point for new headers via 
the <optional-field> rule. Along with that, RFC3864 established a 
process for registering header fields with IANA.

So, my recommendation is that to fix this, remove from section 2 the 
extension of the <fields> rule:

       fields =/ *( cancel-lock / cancel-key )

Instead, simply rely on the text to specify the newly defined header 
fields, and the IANA registration to link them to RFC5322. This will 
probably require some minor tweaking of the text. I won't try to do the 
wordsmithing here.