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

[Lakshminath Dondeti <[e-mail]>]

I was clued in earlier today that the OK responses as specified in the 
-catenate- I-D are semantically correct.  Apologies for my ignorance of the 
format of those messages.  (I was using the examples in the RFCs in the 
area as my reference, and didn't look for the formal syntax)

regards,
Lakshminath

At 02:08 AM 9/1/2005, Lakshminath Dondeti wrote:
>cc'ing the WG chairs, and noting that
>
>Iin the URLAUTH I-D, the following reference needs to be updated:
>
>
>
>[BURL]     Newman, C., "Message Submission BURL Extension",
>                draft-newman-lemonade-burl-00.txt (work in progress),
>                March 2004.
>
>thanks and regards,
>Lakshminath
>
>At 01:57 AM 9/1/2005, Lakshminath Dondeti wrote:
>>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