Re: [apps-discuss] Apps Area review of draft-sparks-genarea-imaparch-06

[Robert Sparks <[e-mail]>]

On 5/13/13 12:27 AM, "Martin J. Dürst" wrote:
> Hello Robert,
>
> I have looked at your update, i.e. draft-sparks-genarea-imaparch-07. 
> It seems that all my concerns have been addressed, thanks very much.
>
> Thanks also for adding me to the acks section. However, please there 
> change my name from "Martin Durst" to "Martin Duerst". That's how it's 
> spelled if the "ü" character isn't available (which fortunately is 
> less and less the case).
Will do, and apologies for not getting it right the first time.

RjS

>
> Regards,   Martin.
>
> On 2013/05/02 6:25, Robert Sparks wrote:
>> On 5/1/13 4:35 AM, "Martin J. Dürst" wrote:
>>> I have been selected as the Applications Area Directorate reviewer for
>>> this draft (for background on appsdir, please see
>>> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate 
>>>
>>> ).
>>>
>>> Please resolve these comments along with any other Last Call comments
>>> you may receive. Please wait for direction from your document shepherd
>>> or AD before posting a new version of the draft.
>>>
>>> Document: draft-sparks-genarea-imaparch-06
>>> Title: IMAP Access to IETF Email List Archives
>>> Reviewer: Martin Dürst
>>> Review Date: 2013/05/01
>>>
>>>
>>> Summary: There is one main issue that's unclear to me. Otherwise, the
>>> draft is close to publication, but needs some additional work.
>>>
>>> Note: I'm not an IMAP expert, not even an IMAP user, and not somebody
>>> the Apps Area would call an email expert, although I wrote RFC 5064
>>> and quite a bit of RFC 6068. So the comments here are mostly of
>>> general nature.
>>>
>>> Main issue: It is totally unclear to me what the actual consequences
>>> of this draft are if approved.
>>
>> It will be used as input to the development of a tool providing the
>> capabilities described here.
>>
>> We are capturing input from the IETF participants on what that tool
>> needs to do.
>>
>> We've followed this approach with several other documents
>> - RFC6778 (the web-based email archive)
>> - RFC6730 (for nomcom tools)
>> - RFC6433 (milestones)
>> - RFC6292 (charters)
>>
>> The document already says
>> "This memo captures the
>> requirements for providing a service that would allow such browsing
>> and searching."
>>
>> Would it help to add "and it is intended as input to a later activity
>> for the design and development of such a tool." and would that address
>> your concern? Or is it fine as it was after seeing that other context?
>>
>> Whether this results in an IAOC funded project or is satisfied with
>> volunteer effort is not something this document needs to discuss.
>>
>>
>>> I could imagine any one of the following:
>>>
>>> - It's informational, so it doesn't have any standing, and is just a
>>> wishlist, mostly just by the author.
>>> - If and when it will be IESG-approved, it documents IETF consensus
>>> on how to best implement IMAP-based access to mailing list archives
>>> for the IETF should such access be desirable, but it does not
>>> represent an IETF consensus to actually implement this (e.g. because
>>> that needs money, and money doesn't move by IETF consensus).
>>> - If and when it will be IESG-approved, it documents IETF consensus 
>>> that
>>> IMAP-based access to IETF mailing lists is desirable, and should be
>>> implemented asap (assuming somebody can come up with the necessary
>>> resources).
>>> - An informal mixture of the above: Those in the know agree it's a good
>>> idea, but somebody said they need a document that can be referenced in
>>> an RFP.
>>>
>>> While I'm personally okay with any of the above (I won't use this kind
>>> of access in the near future, but can understand that many people are
>>> using IMAP and it would be pretty handy to have such a feature; also I
>>> won't have to pay for it), I think the fact that this unclarity exists
>>> may make it difficult for others to review the draft.
>>>
>>> So I suggest that this be clarified. Unless it's just me who's unclear
>>> on this issue, it may get close to meriting a new or prolonged last 
>>> call.
>> That will be for Jari to judge, but as I point out above, we've followed
>> this pattern, using the language in this draft before.
>>>
>>>
>>> Minor issue: The draft should reference RFC 6855 (IMAP Support for
>>> UTF-8) and require its support *at least* to the extent that RFC 6778
>>> does (see http://tools.ietf.org/html/rfc6778#section-3).
>> I will work to sew in a reference to 6855
>>>
>>>
>>> Editorial/Nits:
>>>
>>> o The interface must allow administrators to disable setting read/
>>> unread marks and other annotations, and delete any such marks or
>>> annotations on a per user basis.
>>>
>>> It's unclear how far back "on a per user basis" applies.
>>> Also, "the interface" means "an IMAP interface" (first bullet point),
>>> but it may not be possible or practical to have administrators use
>>> IMAP itself for this function. So I suggest something along the
>>> following lines:
>>>
>>> o It must be possible for administrators, on a per-user basis, to
>>> disable setting read/unread marks and other annotations and to
>>> delete any such marks or annotations.
>> I'll fold this suggestion in.
>>>
>>>
>>> "and should support multiple simultaneous extensive searches.": Is
>>> this simultaneous searches by the same user, or by different users? I
>>> suspect the later. If so, the clause should be rewritten so that it is
>>> clear that this is a dimensioning requirement, not a functionality
>>> requirement.
>> I think it's _both_, not one or the other. I will attempt to clarify.
>>>
>>> "The server should facilitate the enhanced search capabilities
>>> described in [RFC6778].": It is unclear what "facilitate" means here.
>>> Technology usually implements something or doesn't; facilitate sounds
>>> quite fuzzy. Although RFC 6778 is informational, it uses quite a bit
>>> of 'must',... On the other hand, IMAP may or may not support some of
>>> the queries listed as a 'must' in RFC 6778.
>> Would "provide" work better for you than "facilitate"?
>>>
>>>
>>> "(But it is acceptable for a user to access such archives while
>>> providing credentials).": Don't start a sentence with 'But' (use
>>> 'However'). Also, please put the final period inside the parentheses.
>> I will remove the But, and leave ). vs .) to the RFC Editor.
>>>
>>> "an LOGIN command" -> "a LOGIN command"
>> Thanks - will fix.
>>>
>>> "determined by the administrator ." -> "determined by the 
>>> administrator."
>>>
>>> "local copies all messages" -> "local copies of all messages"
>>>
>>> "maliciously crafted searches attempting to consume all available
>>> resources" -> "maliciously crafted searches attempting to consume
>>> significant available resources" (there is no need to consume all
>>> resources to result in significant DOS problems)
>>>
>>> " maliciously crafted annontations attempting to consume all storage
>>> space" -> " maliciously crafted annontations attempting to consume
>>> significant storage space"
>> Will fix all those.
>>>
>>> "The implementers should consider making it easy for the administrator
>>> to determine which users are consuming exceptional space.":
>>> "exceptional space" -> "exceptional amounts of space"; I also think
>>> "should consider" is rather too weak, and "easy to determine" seems to
>>> imply that administrators will have to actively check this (rather
>>> than getting alerts when something fishy starts).
>> The language is intended to leave latitude for design. Forcing
>> administrators to poll would not satisfy "making it easy".
>> I will try to make that clearer.
>>
>>> This may be just an implementation detail, but it may be a good idea
>>> to note that flag implementation (and annotation implementation if an
>>> annotation can be applied by the user to more than one message at
>>> once) has to be quite clever because otherwise, even benign use might
>>> use up lots of space. As an example, if the system allocates 4 bytes
>>> for each message in the system for each user that logs into the system
>>> even once, that may already create huge storage demands.
>> I will look at calling this out. However, there are many bad things that
>> an implementation _could_ do, and calling them all out is not needed
>> here. Things like this would get caught at design review or as source
>> comes in. (You can get the source for the running datatracker - see the
>> codesprint pages if you don't already know how). Such bad design will be
>> caught. Good designs are often improved at codesprints.
>>>
>>> Regards, Martin.
>>>
>>>
>>>
>>
>>