Subject: [apps-discuss] draft-santos-smtpgrey-02: SMTP Service Extension for Greylisting Operations

From: Hector Santos <[email-masked]>
Date: Sat, 01 Feb 2014 12:52:18 -0500

I am wondering if it worth further pursuing this 2012 draft SMTPGREY 
SMTP extension proposal.

     SMTP Service Extension for Greylisting Operations
     http://tools.ietf.org/html/draft-santos-smtpgrey-02

    Abstract

    GREYLIST is a SMTP extension to formalize the widely supported
    Greylisting mail filtering method and to help support SMTP rejected
    transports by following a new formal structured 4yz server temporary
    rejection response by including a "retry=time-delay" tag string which
    SMTP clients can use to optimize the rescheduling of the mail
    delivery attempts.  With adoption, network overhead reduction in
    wasteful mail delivery attempts will be realized.

This has been implemented and deployed among our deployed base of 
WCSMTP installations and has proven to be 100% successful in 
optimizing Send/Queuing scheduling retry logics.

Back in 2012, the plan was to update the draft to rev 03 with interop 
field practice information. It was already a year in the field with 
high proof of concept and success rate. But for various reasons, 
further work and the draft update was put on the back burner.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 1 Feb 2014 10:03:05 -0800

On Sat, Feb 1, 2014 at 9:52 AM, Hector Santos <[email-masked]> wrote:

> I am wondering if it worth further pursuing this 2012 draft SMTPGREY SMTP
> extension proposal.
> [...]
>

Do you have any implementation or interoperability data you can provide?

-MSK, APPSAWG co-chair

---

From: Hector Santos <[email-masked]>
Date: Sat, 01 Feb 2014 13:39:07 -0500

On 2/1/2014 1:03 PM, Murray S. Kucherawy wrote:
> On Sat, Feb 1, 2014 at 9:52 AM, Hector Santos <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     I am wondering if it worth further pursuing this 2012 draft
>     SMTPGREY SMTP extension proposal.
>     [...]
>
>

For our own implementation and deployments of WCSMTP.

No collections from other packages was made from a client standpoint.

Many Greylisting servers do issue a time hint in their 45x greylisting 
responses in various forms.   We can only speculate if other clients 
are parsing this non-standard information and leveraging it for their 
outbound mail retry scheduling logic.  Our client parses for the 
common format seen out there, including the proposed format.

The criteria for proof of concept would be a reduction of retries to a 
minimum of one try with the minimum amount of delivery delay.  I can 
show that proof of concept with our logs of this occurring.  For 
servers that issues a time hint, we have this minimum set.  For 
others, there are redundant retries and longer delivery times.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 2 Feb 2014 17:14:35 -0800

> No collections from other packages was made from a client standpoint.

Does anyone else have current or planned implementations of this draft
they'd like to discuss?

> responses in various forms.   We can only speculate if other clients are
> parsing this non-standard information and leveraging it for their outbound
> mail retry scheduling logic.  Our client parses for the common format seen
> out there, including the proposed format.
>

Can you point to some of the server implementations that do this?  Are they
following the syntax in this draft?

---

From: Ned Freed <[email-masked]>
Date: Sun, 02 Feb 2014 22:57:39 -0800 (PST)

> Does anyone else have current or planned implementations of this draft

We see greylisting as something best done by a milter, so we're unlikely to
implement direct support in our MTA. That said, a milter has the ability to set
the SMTP response string to anything it wants. The only problem a milter would
have is changing the EHLO response to include the GREYLISTING extension. AFAIK
that is not a milter capability. We have a way to do that outside of milter but
I don't know if other milter-supporting MTAs do.

> following the syntax in this draft?

milter-greylist has the ability to return SMTP responses containing the retry
time. The format is settable, so it should be able to generate something that
conforms to this RFC. 

There are various other milters that support greylisting; I don't know about
their capabilites.

				Ned

---

From: Hector Santos <[email-masked]>
Date: Mon, 03 Feb 2014 08:41:33 -0500

On 2/2/2014 8:14 PM, Murray S. Kucherawy wrote:
> On Sat, Feb 1, 2014 at 10:39 AM, Hector Santos <[email-masked]

I have also wondered if the servers (see below) that do expose time 
hints have package companion clients that support it.

>
>     Many Greylisting servers do issue a time hint in their 45x
>     greylisting responses in various forms. � We can only speculate if
>     other clients are parsing this non-standard information and
>     leveraging it for their outbound mail retry scheduling logic. �Our
>     client parses for the common format seen out there, including the
>     proposed format.
>
>
> Can you point to some of the server implementations that do this?� Are
> they following the syntax in this draft?

I can't tell you of brands, but section 2.4, summaries the ones I have 
collected in the wild (from our outbound logs) that issue retry time 
hints in their temporary reject responses.

   http://tools.ietf.org/html/draft-santos-smtpgrey-02#section-2.4

   421 This server implements greylisting, please try again in # seconds
   450 4.7.1 <RCPT>: Recipient address rejected: Greylisted for # minutes
   450 4.7.1 <RCPT>: Recipient address rejected: Greylisted for # seconds
   451 4.7.1 Greylisting in action, please come back in HH:MM:SS
   451 Greylisted for # seconds

So the intent is there by greylisting servers to provide "information" 
for future clients to use when possible.

In practice, I have found the servers do honor and are correct with 
the times.  I have not found any instance of the info being wrong.  If 
it said wait X mins, your client waited X mins and there was no more 
delivery blocks/delays. If I have found any instance where it was just 
wrong, then I wouldn't had bother with this.

Thanks

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Mon, 03 Feb 2014 08:30:33 -0500

> I don't know if other milter-supporting MTAs do.

The service extension keyword was made optional

http://tools.ietf.org/html/draft-santos-smtpgrey-02#section-3.1.1

The intent was to offer a method to expose a retry=time-delay (the 
blocking time) via the keyword and not depend on servers adding and 
clients parsing of 45x response text.

> There are various other milters that support greylisting; I don't know about

Yes, for servers, getting the response in is the easy part. The 
benefit is for the client to leverage it for their existing 
rescheduling logic.  Those that do should see a benefit in minimizing 
retries and delivery delays.

-- 
HLS

---

From: "John Levine" <[email-masked]>
Date: 3 Feb 2014 18:14:52 -0000

>There are various other milters that support greylisting; I don't know about

My greylister calls out to a daemon, which just returns one bit,
accept or softfail.  I couldn't implement this even if I thought it
were a good idea.

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Mon, 03 Feb 2014 09:06:50 -0800 (PST)

Sorry, I should have commented on the client rescheduling aspect of this
in my first response.

First of all, this is trivially easy for us to implement, at least in
principle. All we have to do is parse out the value from the response and then
make a single subroutine call. It really is just that easy with our queue
manager.

But as always, the devil is in the details. Obviously you can't fully trust the
value you get since there are obviously ways small (or large) values could be
used to enhance a service denial attack.

So there have to be allowed ranges for the values. But is that enough control?
I don't know if it is or not. In particular, should MT-PRIORITY be tied into
this, and if so, how should it be done? (Different allowed ranges for different
priorities is the obvious answer, and may be a reasonable starting point.)

And then there's the message versus host issue. We have the ability to either
reschedule this one message or reschedule all the messages headed to a
particular host. Which one makes sense depends on what sort of greylisting is
being done: Is it purely based on the sending host or is it based on some
characteristics of the specific message?  And before anyone says that you can
determine that by the phase at which the greylisting occurs, sorry, no you
can't. In my experience it's not at all uncommon for IP-level greylisting to
happen as late as RCPT TO phase, and I wouldn't be surprised if it can happen
at the end of data.

And if you get this one wrong use of this extension could easily increase
rather than decrease delivery times with greylisting schemes that penalize
overly aggressive retries at the sending host level.

The obvious way to address this is to add some enhanced status codes to say
whether or not the retry value is intended to apply to this one message or to
the sending host as a whole. But I have to wonder if people setting this up
would understand the distinction, and I also have to wonder if other queue
managers are capable of making use of it.

And finally, we have to take the least astonishment principle into account. For
whatever reason some sites obsess over the predictability of message retry
intervals: Any time they see what they regard as unusual behavior in this
regard, they get very excited and demand an analysis be done. Our support
people then have to waste time digging in to what invariably turns out to be
have a perfectly reasonable explanation: a queue backlog, an unresponsive
destination, bad configuration setting, etc. etc.

Unfortunately, given their obsession with delivery times such sites are likely
to be first in line to enable such functionality if it is available. The
possible consequences of this in terms of support time should be obvious.

The bottom line is that if this is standardized, given how easy this is for us
to support we'd probably implement it. But given the risks we might have to
make it a restricted option, which would substantially lessen the liklihood of
sites actually using it.

Finally, I missed the optional nature of the GREYLIST extension. I have to
say I'm not comfortable with assigning semantics to the content of a response
line absent a clear indication of what the contents of that line mean.

				Ned

---

From: Hector Santos <[email-masked]>
Date: Mon, 03 Feb 2014 16:05:21 -0500

On 2/3/2014 1:14 PM, John Levine wrote:

> accept or softfail.

Keep in mind there are two parts to this:

    1) Helping OTHER systems improve delivery,
    2) Helping YOUR system improve delivery.

For #1, you can do this by changing your response to include a fixed 
blocking time related to your GreyList mfilter setup.  This is mostly 
an administrator, sysop level work requirement.

For #2, that is more software work on the sender-MTA where you 
parse/extract the time hint, if any, from the temporary reject 
responses and pass that TIME to your MTA Send/Queuing logic and 
algorithm.  So this requires code change most likely, code developers, 
systems folks, even administrators.

Except for the response template change, it wouldn't have anything to 
do with a GREYLIST mfilter, shim, callout, blackbox true/false 
process, handling of incoming calls.  It is about the mail sender who 
is getting hit with other greylisting server forcing delays.  Its 
about improving SENDER QUEUE/RETRY LOGIC and minimizing delivery 
delays in dealing with a current reality and wide existence of 
Greylisting Servers.

All good and practical ideas to consider if delays is something you 
wish to address associated to forced temporary reject block delays.

Most systems have a progressive retry logic where delays increase or 
vary with more tries.  This proposed method has proven to shown over 
time to reduce all delays to the bare minimum number of retries which 
is two with no extra time delays than necessary.

> I couldn't implement this even if I thought it were a good idea.

Your reasoning would be insightful.

Would there be a technical problem, a security problem and/or 
feasibility problem?

-- 
HLS

---

From: Derek Diget <[email-masked]>
Date: Mon, 03 Feb 2014 17:24:58 -0500 (EST)

On Feb 2, 2014 at 22:57 -0800, Ned Freed wrote:
=>> On Sat, Feb 1, 2014 at 10:39 AM, Hector Santos <[email-masked]> wrote:
=>> > For our own implementation and deployments of WCSMTP.
=>> >
=>> > No collections from other packages was made from a client standpoint.
=>
=>> Does anyone else have current or planned implementations of this draft
=>> they'd like to discuss?
=>
=>We see greylisting as something best done by a milter, so we're unlikely to
=>implement direct support in our MTA. That said, a milter has the ability to set
=>the SMTP response string to anything it wants. The only problem a milter would
=>have is changing the EHLO response to include the GREYLISTING extension. AFAIK
=>that is not a milter capability. We have a way to do that outside of milter but
=>I don't know if other milter-supporting MTAs do.

FYI, we use Ned's software and have the following defined in our 
ORIG_MAIL_ACCESS mapping (based on the Comms Suite Greylisting Wiki page 
at 
<https://wikis.oracle.com/display/CommSuite/Implementing+Greylisting+by+Using+MeterMaid>)

! Check the source IP address only using the first three octets in the 
! string passed to MeterMaid, sender (canonicalized via X-CORRESPONDENT 
! mapping recursion lookup), and recipient in MeterMaid's greylist 
! table.
!
! If the call to greylisting() returns success, then Messaging Server 
! should return a temporary rejection. If the call fails, then the 
! greylisting check has passed and other access control checks can continue

  TCP|$@*|$@*|$D*.$D*.$D*.$@*|$@*|SMTP$@*|MAIL|tcp_mx|*|l|*|true $C$[IMTA_LIB:check_metermaid.so,greylisting,greylist,$0.$1.$2|$|X-CORRESPONDENT;$3||$4]$N$X4.7.1|Temporary$ greylist$ rejection$ -$ retry$ in$ retry=00:03:00$ $E

Which causes the following SMTP response:

  451 4.7.1 Temporary greylist rejection - retry in retry=00:03:00 : RECIPIENT@RECIPIENT-DOMAIN

I don't have any data on how many clients then following our suggestion.

I know we are less than a grain of sand on the mail flow beach, but 
thought that I would speak up as one receiver. :)

-- 
***********************************************************************
Derek Diget                            Office of Information Technology
Western Michigan University - Kalamazoo  Michigan  USA - www.wmich.edu/
***********************************************************************

---

From: Hector Santos <[email-masked]>
Date: Tue, 04 Feb 2014 00:42:19 -0500

Hi Derek, any mail being sent from our clients (Wildcat! SMTP) to 
receivers using Ned's software would honor this assuming 
retry=HH:MM:SS format for scheduling the next (2nd) attempt.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 3 Feb 2014 22:13:02 -0800

> destination, bad configuration setting, etc. etc.

So is it your view that undertaking standardization work here would help
you with this pain point (predictable retries), or make it worse (something
new for everyone to understand)?

If you can't tell, I'm fishing for some answers to the predictable "Should
APPSAWG consider taking on this work?" question.

-MSK

---

From: Ned Freed <[email-masked]>
Date: Tue, 04 Feb 2014 09:28:51 -0800 (PST)

> new for everyone to understand)?

My point was that respecting retry values intrduces yet another variable
that support will have to deal with.

I don't think this is an argument for or against standardization, however. The
overarching goal of improving timely delivery of mail trumps the cost of
dealing with the obsessions some sites have. IMO this protocol needs to be
assessed almost entirely on the basis of whether or not it improves the
situation surrounding greylisting.

> APPSAWG consider taking on this work?" question.

I think taking it on is a good idea. Whether or not it turns into a
standard depends on how the discussion goes.

And while I agree that our time is valuable and should not be wasted, I'm not
sure I'd go as far as to say that WGs should only ever take on work when the
production of a standard at the end is practically guaranteed. Sometimes
crippling problems only emerge after close scrutiny. Mind you, email
is sufficiently mature and we have sufficient experience with greylisting
that such an outcome is unlikely here. But we've been surprised before.

				Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 4 Feb 2014 11:30:31 -0800

> that such an outcome is unlikely here. But we've been surprised before.

My concern is more that we've taken on work in which interest has petered
out leaving us with nearly dead documents.  One way to avoid doing that is
to favor taking on work that addresses a real pain point for more than just
a couple of people, and for which we can find people dedicated to seeing
the work through to completion, and for which there is ample support (e.g.,
implementations, for something on the standards track).  I believe
something lacking that kind of support should really be looking at the ISE
or AD sponsorship rather than APPSAWG.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 4 Feb 2014 19:33:12 -0000

>situation surrounding greylisting.

In my experience, the amount of real mail that is delayed at all by a
reasonable greylister is insignificant.

Once you know that an IP has successfully retried, there's no point in
further greylisting, so you add it to the greylist whitelist (pale
grey list?)  This means that the only non-bot mail that gets
greylisted is the first one or two from an IP that hasn't sent mail
before, and that just isn't very many IPs or very much mail.  It's
certainly not worth a new SMTP extension and extra state in mail
servers.

I realize there are extreme greylisters that greylist everything on
the theory that a mail server might be sharing its IP with a bot, or
if they wait long enough the sender will show up on a blacklist, or
something.  That's certainly not a basis to standardize anything.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Tue, 04 Feb 2014 15:44:50 -0500

> reasonable greylister is insignificant.

This spec only attempts to document the basic framework of greylisting 
based on [HARRIS] and also offers a method to minimize GLS 
(GreyListing Server) forced client mail delivery delays.

> grey list?)

It might be good if the growing amount GLS out there would permanently 
IP whitelist the sender from future unnecessary GL based delays. 
However, this is not generally the case. SMTPGREY includes a concept 
of an expiration period which was part the original 2003 [HARRIS] 
greylisting specification where most systems, if not all, were based 
on. So its more of a temporary whitelisting concept.

Your suggestion would be this make this a permanent whitelist.  I 
think this would be local level policy idea for GL implementators to 
offer to operators -- make it optional.  GL can help feed into these 
additional automated white listing intelligence.  Perhaps also couple 
it with a DKIM signature requirement before it can get pass a greylist 
requirement.  I think these considerations could be part of an 
appendix, but not the basic protocol.

I will venture that most systems that have implemented Greylisting has 
done so with plug and play fashion, using best establish values for 
blocking and expiring.   There is much experiences in these values and 
the values have worked out of the box. Operators don't usually adjust 
the defaults. But if they have, that would be something to learn about.

> This means that the only non-bot mail that gets

None of this is a problem -- it is an optimization to minimize mail 
delivery delays that is increasingly caused my GL servers. With bulk 
transmissions, there are more IP congestion/load limits and following 
retry hints has helped remove some of the randomness in retry/bulk 
mail delivery delays.

Its not a problem because retry/bulk strategies are necessary w/o 
greylisting.  SMTPGREY addresses a certain portion of the temporary 
rejection spectrum that do cause mail delivery delays by design.   The 
mail will get out eventually, maybe after 3-5 wasted attempts over 
long extended mins, even hours.   SMTPGREY has proven to show to cut 
all waste to the bare minimum, which can be an extra retry at the 
lowest possible time offered by the server.

Keep in mind NULLMX proposal is not a problem and we about to take on 
this work as a standard.  In fact, if NULLMX, why not SMTPGREY while 
we are in a SMTP CHANGE mode mindset.

One suggest a successful MX lookup with PREFERENCE=0 as a means to 
remove a queued item from the outbound queue and immediately activate 
a bounce process.

The other suggest a RETRY HINT from the temporary rejection GL server 
as a way to override the next delivery attempt time with a shared 
client/server handshake time value.

Both are good ideas to do help improve with mail delivery and queuing 
strategies.

> something.  That's certainly not a basis to standardize anything.

This proposal attempts to not deal with the poor implementations of 
greylisting. It uses [HARRIS] as the original method most GL systems 
are based on to document the basic framework and its options 
available.  SMTPGREY deals with what exist in the market place - a 
higher degree of hitting HARRIS-like GL servers with temporary 
rejections and many of the different GL servers already provide a 
Retry Hint which client can leverage.

-- 
HLS

   [HARRIS]   Harris, E., "The Next Step in the Spam Control War:
               Greylisting", 2003, <http://projects.puremagic.com/
               greylisting/whitepaper.html>.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 4 Feb 2014 13:59:16 -0800

On Tue, Feb 4, 2014 at 12:44 PM, Hector Santos <[email-masked]> wrote:

> Keep in mind NULLMX proposal is not a problem and we about to take on this
> work as a standard.  In fact, if NULLMX, why not SMTPGREY while we are in a
> SMTP CHANGE mode mindset.
>
>
Two points on this:

(1) The issue is not the current mode (or mood) of the working group, but
rather (a) whether there's room in the WG for this new work (currently
there is not) and (b) whether there is adequate support for accepting and
working on it.  The nullmx draft is still in an open call for adoption,
although so far there clearly appears to be support for working on it in
appsawg.

(2) It's not necessary for this document to be in a "done" state or close
to it to be adopted.  It might need a lot of work, but it only needs to be
a good starting point for what the WG will ultimately produce via the usual
consensus process.

-MSK

---

From: Ned Freed <[email-masked]>
Date: Tue, 04 Feb 2014 18:02:33 -0800 (PST)

> or AD sponsorship rather than APPSAWG.

I think we may have somewhat different standards for what constitutes
sufficient interest. I checked and there appear to be six active documents at
present, and every one of them has been at least 5 times since it was initially
posted. (Yes, there's a -00 and a -01 in the mix, but this fails to count the
versions that came out before the document was adopted by the WG. I
categorically reject the notion that attention paid prior to WG adoption,
possibly on some other list, doesn't count.) As far as I'm concerned these
numbers make a prima facie case for sufficient interest.

That said, opinions appear to be mixed about the likely utility of this draft.
But I've said my piece; time for others to weigh in.

				Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 4 Feb 2014 18:28:34 -0800

> But I've said my piece; time for others to weigh in.

Those aren't the only metrics in play here.

Attention on other lists is wonderful, but a WGLC that draws not even a
simple "Looks good, let's go" from a single person on any list doesn't
exactly make us feel comfortable with the notion that it's ready to go to
the IESG or that we could demonstrate WG consensus behind the current
content if asked.  There could be fifty versions that demonstrate ample
past work and interest on this or some other list, but that doesn't
automatically imply this WG (the one processing it, after all) is happy
with it in its current form.  This is especially true if there's current
unanswered feedback from someone posted to the list, or if an author said
"You're right, I'll put that in the next version" but that hasn't
appeared.  Of course, this begs the question of how those documents became
WG items in the first place, an issue we aim to address with the current
"mini-charter" experiment.

Anything short of requiring some or all of the above, and we're essentially
just an abject end-run around AD sponsorship, which seems utterly bogus to
me.

So: Are we wrong to have such criteria?

-MSK

---

From: Ned Freed <[email-masked]>
Date: Tue, 04 Feb 2014 18:40:21 -0800 (PST)

> content if asked.

Sorry, I don't buy this _at_ _all_. If a document has seen extensive discussion
somewhere else, isn't it just faintly possible that it's in good shape and
people don't see the need for further commentary? (Mind you, I'm not saying
that this applies to the entire current crop of documents. I'm talking about
general criteria here.)

IETF management also appears to be more than a little confused about what's
needed or wanted here. It wasn't too long ago that Pete Resnick got all hot and
bothered about "empty expressions of support" on this very list - from me in
particular - even going so far as to say that he simply ignores such things and
at least implying that he expects others to do so as well. Yet that's exactly
what you're asking people to provide here.

I can't speak for anyone else, but I was told that such things would be ignored
I basically stopped posting all straightforward expressions of support of
drafts nearing or during last call. So if you were expecting me to post a
"seems OK" comment about, say, draft-ietf-appsawg-xml-mediatypes - and yes, I
have read it carefully and have nothing further to say about it - sorry, that
wasn't about to happen.

> There could be fifty versions that demonstrate ample
> with it in its current form.

I'd buy this argument with most WGs, which are chartered for a specific
purpose and goal. In such contexts it's important that all of the drafts
that receive WG blessing have a certain degree of self-consistency.

But this is the Apps Area WG, which is chartered to process stuff that doesn't
quite fit anywhere else and which doesn't merit a WG of its own. And sure
enough, if we look at the current set of active drafts, we have one on URI
design principles, one on XML media types, one defining an XML patch format,
one defining a JSON patch format, one defining the form data format, and one
defining a Sieve extension. And soon to be a draft about MX record handling and
perhaps one on greylisting.

If there's a theme there other than "random apps stuff" I'm not seeing it. I
therefore see the notion that there's a common WG understanding acting as a
gating factor for inchoate collection as nothing short of absurd.

> This is especially true if there's current
> appeared.

What does this have to do with the topic at hand? A document that's 
"waiting for revision" is obviously not ready to go. And incidentally,
has clearly seen some review by the WG...

> Of course, this begs the question of how those documents became

> just an abject end-run around AD sponsorship, which seems utterly bogus to

Sorry, this sort of stuff never really resonated with me when I was an AD, and
it means absolutely nothing to me now. All I care about is getting work done;
just provide me with a reasonable and consistent process and a little guidance
for how to operate it and I could not care less about the details. Tell me to
use a special WG and that's what I'll do, tell me to spin up a mini-WG, that's
fine too, tell me I need to seek AD sponsorship, then that's what I'll ask for.

> So: Are we wrong to have such criteria?

Given the situation as it stands, yes, you absolutely are.

More generally, IETF management has provided what are effectively contradictory
guidelines for what's expected from participants, and is now reaping what it
sowed. My sympathy level is low.

				Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 4 Feb 2014 21:07:26 -0800

> that this applies to the entire current crop of documents. I'm talking

Sure, it's faintly possible.  But I also think it's ambiguous when there's
not an iota of feedback after a new version is posted even if only to
confirm that all previous raised issues have been addressed.  I think it's
telling if an entire WG can't even be arsed to write two or three words
doing that or expressing any kind of support whatsoever for the progress of
a document.  I certainly don't feel comfortable handing such a thing to the
IESG claiming "this has consensus" in those conditions.

If we have this completely wrong and the ADs want to correct us, fine.  But
this is where my experience with the IETF and other working groups has led
me, and I'll be surprised if the guidance is "If nobody says anything when
you ask if it's ready, the only logical conclusion is that it's ready."  If
instead the WG simply can't be bothered, we send it up and it comes back
with a stack of DISCUSSes, then what?

I am aware of Pete's rants about useless feedback.  I'm sympathetic to the
idea that "+1" is pretty useless on its own, but I don't think a slightly
more detailed reply like "I read the -xx version of this draft, and prior
issues A, B, and C were all addressed.  I think it's ready." is at all
useless.  Absent that, why should I as co-chair or shepherd not conclude
that those issues are possibly still of concern, especially if it's subject
matter with which I'm not familiar?

But this is the Apps Area WG, which is chartered to process stuff that
> doesn't

> gating factor for inchoate collection as nothing short of absurd.

Huh?  I'm not claiming the current set of documents is inappropriate or out
of charter.  I'm saying the absence of review and support comments is a
problem.

The charter lists these bullet points (among others) as criteria for
accepting work:

* Whether there is a core team of WG participants with sufficient energy
and expertise to advance the proposed work item according to the proposed
schedule.

* Whether there are enough WG participants who are willing to review
the work produced by the document authors or editors.

It seems to me that your silence-is-golden notion is at odds with those;
specifically, I interpret silence as the absence of "sufficient energy" and
"willing to review".

-MSK

---

From: Claudio Allocchio <[email-masked]>
Date: Wed, 5 Feb 2014 08:26:58 +0100 (CET)

Let me add a little detail to the discussion:

if you check the statistics of the Apps WG list and see what's proposed on 
it, you will notice that practially all "SMTP related" stuff ends up here. 
There is a valid reason for this, whichi is:

  - there is no (and there is no need for a specific) SMTP 
updates/maintenance WG in the IETF;

  - most of the people interested in the topic are actually on Apps WG 
itself.

The real problem is manpower to follow up the drafts after people gives 
enough +1s to adopt them. As we are chartered quite openly (and this is ok 
for THIS WG) and of course are a mix of all Apps Area expertises, of 
course I do not presume that 60% of WG people stand up and work an any 
specific draft, just because it does not fit their own expertise area: I'd 
not stand up for an XML draft for actual work, just because I do not feel 
I'm the righ person to do that for example, but I'll put my +1 on XML 
drafts I believe are worth... and the expect the XML experts to 
contribute. Given this personal humble assumption, I'm not saying that we 
should formally "wheight" the +1s according the people's expertise area, 
but at least to think about this when we take adotion decisions.

Again, the mail problem to face, not only in the specifi Apps WG, is the 
actual manpower avilable... I've the unpleaseant feeling, also 
coordinating the AppsDir, that it is decreasing because of various 
reasons.

my little 2 cents...

all the best

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 5 Feb 2014 08:08:51 +0000

exactly here the issue is to understand how many people are really interested in the issue
and especially if the ones interested they can spend enough cycles to review and provide
comments so to let the draft progress 

/Salvatore

On Feb 5, 2014, at 9:26 AM, Claudio Allocchio <[email-masked]> wrote:

> if you check the statistics of the Apps WG list and see what's proposed on it, you will notice that practially all "SMTP related" stuff ends up here. There is a valid reason for this, whichi is:
> 
> - there is no (and there is no need for a specific) SMTP updates/maintenance WG in the IETF;
> 
> - most of the people interested in the topic are actually on Apps WG itself.
> 
> The real problem is manpower to follow up the drafts after people gives enough +1s to adopt them. As we are chartered quite openly (and this is ok for THIS WG) and of course are a mix of all Apps Area expertises, of course I do not presume that 60% of WG people stand up and work an any specific draft, just because it does not fit their own expertise area: I'd not stand up for an XML draft for actual work, just because I do not feel I'm the righ person to do that for example, but I'll put my +1 on XML drafts I believe are worth... and the expect the XML experts to contribute. Given this personal humble assumption, I'm not saying that we should formally "wheight" the +1s according the people's expertise area, but at least to think about this when we take adotion decisions.
> 
> Again, the mail problem to face, not only in the specifi Apps WG, is the actual manpower avilable... I've the unpleaseant feeling, also coordinating the AppsDir, that it is decreasing because of various reasons.
> 
> my little 2 cents...
> 
> all the best
> 
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Hector Santos <[email-masked]>
Date: Wed, 05 Feb 2014 08:41:00 -0500

I see it as a "marketing" problem.

-- 
HLS