Subject: [Gen-art] Gen-ART Belated LC review of draft-freed-sieve-ihave-03

From: Ben Campbell <[email-masked]>
Date: Wed, 10 Dec 2008 17:49:59 -0600

[Apologies for the lateness of this review. I somehow mis-recorded the  
due date. Here's my review hoping late is better than never.]

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-freed-sieve-ihave-03
Reviewer: Ben Campbell
Review Date:  2008-12-10
IETF LC End Date: 2008-12-08

Summary:

This draft is ready for publication as a proposed standard.

Comments:

A few minor nits that should not block anything:

-- Is this a sieve wg submission or and individual submission? The  
title looks like an individual, but it's listed as a wg submission in  
the datatracker. (The answer to this does not change my review in any  
way; it's just a procedural question.)

-- Don't forget the new boilerplate.

-- section 4, last paragraph: It might help to put this statement up  
front in the document, since it significantly constrains the scope.

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 11 Dec 2008 09:52:40 +0000

Ben Campbell wrote:

> [Apologies for the lateness of this review. I somehow mis-recorded 
> the  due date. Here's my review hoping late is better than never.]
>
Hi Ben,
Thank you for the review.

> way; it's just a procedural question.)

It is a WG document despite the name. The document predates Sieve WG 
rechartering and we never bothered to change the name.

---

From: Ned Freed <[email-masked]>
Date: Thu, 11 Dec 2008 09:08:28 -0800 (PST)

(IETF list removed from cc list)

> way; it's just a procedural question.)

As Alexey already commented, this is a WG document despite the name. However,
given the confusion this has caused (I believe this is the third time I've seen
this question raised) I'm making a note that while it's too late for this
document, in the future it's much better to change the document name when its
WG-attachment status changes. Lesson learned.

> -- Don't forget the new boilerplate.

I haven't forgotten it, I just don't know what to do about it. This document
was processed using xml2rc 1.33, which is the latest release. There's a
preliminary version of xml2rfc for those "living on the edge" that reportedly
generates the newer-but-apparently-still-not-quite-right-and-going-to-change-again
boilerplate.

I spend much of my working life "living on the edge" in terms of running
prerelease versions of messaging software, directory servers, and even
operating systems. I have no choice in this - it's my job to do so. This
provides me with ample excitement and I really don't need or want any more. I
therefore make it a firm policy not to run betas of ANYTHING ELSE unless I'm
forced to.

IMNSHO IETF management has completely screwed the pooch on this one. Either the
new boilerplate, previously discovered but recently reported flaws
notwithstanding, is sufficiently better than the old to be worth using, or it
isn't. If it is it should be pushed out and xml2rfc 1.34 should be finalized
and released ASAP. If it isn't it should be withdrawn and all deadlines and
other bureaucratic nonsense associated with it rescinded.  Really, there is no
viable middle ground here. (John Klensin's posting on this was, if anything,
too kind.)

In any case, I'm not going to update to a beta xml2rfc unless I'm specifically
told by the IESG that I have to. And if that means the I-D thing won't accept
my revisions, so be it. And I really don't think this is an unreasonable
position to take.

> front in the document, since it significantly constrains the scope.

Actually, it doesn't really do that, but this is something you'd only know if
you followed the design philosophy and overall development arc of Sieve. So far
there have been a total of 10 Sieve extensions approved as proposed standards.
And there are about 7 more in various stages of development. Of these exactly
one document - variables - specifies something that's incompatible with being
enabled by ihave. (And to be fair, the reason use with variables is prohibited
is not because it couldn't be done, but rather that ir precludes certain forms
of precompilation we believe are useful for high performance Sieve processing.)

More generally, extensions which change the underlying grammar, while not
flatly forbidden (no reason to box ourselves in here), are so strongly
discouraged that the few times such things have been suggested they have
immediately gone down in flames. One of the key advantages of Sieve is that you
don't have to muck with your parsed in order to add support for new extensions.
This has led to far less resistance to getting extensions deployed than I've
seen in any other language I've tracked. (And before I started doing IETF
standards work I used to be involved in ANSI/ISO language standardization.)

In other words, it is actually quite likely we'll never see another extension
that is incompatible with ihave.

So unless I see some additional commentary saying this is worth promoting
to a more prominent place, I'm going to leave it alone.

				Ned

---

From: Ben Campbell <[email-masked]>
Date: Thu, 11 Dec 2008 13:20:10 -0600

> WG-attachment status changes. Lesson learned.

Okay--no problem. It certainly does not make sense to change the name  
of the draft at this stage.

> my revisions, so be it. And I really don't think this is an  

No problem here--the only reason I pointed out was to make sure people  
were thinking about it.

> to a more prominent place, I'm going to leave it alone.

Understood, no problem.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 12 Dec 2008 14:10:52 -0600

BTW, and for the record, this discussion addressed all of my comments.

Thanks!

Ben.

On Dec 11, 2008, at 1:20 PM, Ben Campbell wrote:

> Okay--no problem. It certainly does not make sense to change the  
> name of the draft at this stage.
>
>>
>>
> No problem here--the only reason I pointed out was to make sure  
> people were thinking about it.
>
>>
>>