[Gen-art] Gen-ART review of lemonade drafts in IESG review

[Lakshminath Dondeti <[e-mail]>]

Drafts under review:

Internet Message Access Protocol (IMAP) CATENATE Extension (Proposed 
Standard) - 2 of 10
<http://www.ietf.org/internet-drafts/draft-ietf-lemonade-catenate-05.txt>draft-ietf-lemonade-catenate-05.txt 

Internet Message Access Protocol (IMAP) - URLAUTH Extension (Proposed Standard)
<http://www.ietf.org/internet-drafts/draft-ietf-lemonade-urlauth-07.txt>draft-ietf-lemonade-urlauth-07.txt 

Message Submission BURL Extension (Proposed Standard)
<http://www.ietf.org/internet-drafts/draft-ietf-lemonade-burl-02.txt>draft-ietf-lemonade-burl-02.txt


Background for those who may be unaware of GenART:

GenART is the Area Review Team for the General Area of the IETF.
We advise the General Area Director (i.e., the IETF/IESG chair) by
providing more in depth reviews than he could do himself of documents
that come up for final decision in IESG telechat.  I was selected as the
GenART member to review this document.  Below is my review, which was
written specifically with an eye to the GenART process, but since I
believe that it will be useful to have these comments more widely
distributed, others outside the GenART group are included.

Summary:  Generally ready for publication ...  I see some discuss comments 
already, and I have some questions/comments myself.

BURL
-------

No additional issues other than those on the tracker already.

What does BURL stand for?

There are some typos toward the end of the security considerations 
section.  Please run a spell check.  Also, the RFC ed process will take 
care of it too.

Lemonda-Catenate:
------------------------

Note: The author of this draft, Pete Resnick and I are colleagues, however 
I was not aware of this work until I read the draft for the first time to 
review it for Gen-ART.

*) I would like to see more in the security considerations section.  I 
understand that the draft says the proposal does not introduce any 
threats.  However, this is in contradiction to the BURL draft's sec 
considerations section.  I think that the first part of that section might 
be appropriate in this draft as well.

*) The draft says "Responses behave just as the original APPEND command 
described in IMAP [1]."
But the examples are somewhat inconsistent (may be I am being too picky):
In Example 1:
S: A003 OK catenate append completed

In Example 3:
A003 OK append Completed

In Example 4:
... CATENATE append has failed, one message expunged

Should they all use the keyword APPEND?  Is the keyword CATENATE allowed in 
responses?  I realize it is allowed in capabilities as specified in Section 5.

URLauth
-----------

* I am uncomfortable with the word Authorization and the mechanisms for it 
in this draft.  However, it is late in the process to have a philosophical 
discussion.  Since this is a WG consensus, I can live with it.

   To explain: The first sentence notes that RFC 2192 requires authorization

My reading of that RFC is that it is talking about authenticating a user 
and then verifying whether the user is authorized to 
read/read-write.  Authorization comes from local policy and enforced after 
authenticating the user.

Section 1.4 concerns me.  First, I am not sure I understand the use of 
HMAC-SHA-1 as an authorization mechanism.  More importantly, the draft only 
recommends something such as that algorithm and notes that there is no way 
to change the algorithm without severe consequences.  While HMAC is holding 
up, there are concerns about SHA-1 already; I am not sure about advancing 
protocol specs in which algorithms cannot be updated.


best regards,
Lakshminath



_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art