Subject: [apps-discuss] Comments on draft-ietf-appsawg-received-state

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 6 Jun 2012 22:27:53 -0700

Some private comments I've received on this draft (reminder: it's in WGLC!)
have led to the following updates which Dave and I agree to, and will
appear in the next version of the document as long as the working group
agrees.

1) Change the IANA rules for registering new states to Expert Review.
Specification Requires is overkill.  (Expert Review might be too, but I
didn't feel totally comfortable busting it down that far.  What do others
think?)

2) Provide more discussion of what the "value" token in the ABNF is for,
including examples.  The general idea is to include additional unstructured
data about the state the message has entered, such as "quarantine/spam" or
"moderation/not-subscribed".  The token is optional.

3) Add a reference to Section 7.6 of RFC5321 to Security Considerations.

-MSK, as document editor

---

From: Barry Leiba <[email-masked]>
Date: Thu, 7 Jun 2012 06:59:34 -0400

> didn't feel totally comfortable busting it down that far.  What do others

I think this is a good idea.  I think FCFS would also be adequate, and
encourage the WG to use that.  The reason is that it's far better to
encourage people to register status codes that they want to use, and not to
put barriers in the way.  The usual reluctance to use FCFS is concern that
people will register a bunch of garbage.  In fact, (1) this hasn't ever
happened and (2) IANA would ask the IESG to intervene if they got a
suspicious flood of registration requests.

In any case, you're going to need to change the template if you don't
require a specification.   I suggest this:

OLD
Specification: The specification document that defines the queue state
being registered.

NEW
Specification: A pointer to a specification document that defines the queue
state being registered, if one exists; else, a more detailed description of
the queue state, to aid in interoperable usage.

Barry

---

From: Dave Crocker <[email-masked]>
Date: Thu, 07 Jun 2012 13:12:35 +0200

On 6/7/2012 12:59 PM, Barry Leiba wrote:
> encourage people to register status codes that they want to use, and not
> to put barriers in the way.  The usual reluctance to use FCFS is concern
> that people will register a bunch of garbage.  In fact, (1) this hasn't
> ever happened and (2) IANA would ask the IESG to intervene if they got a

+1

The justification for expert is "quality control".  The side-effect is a 
disincentive to register.

Do we make it easier and let in some cruft along with the good stuff or 
do we make it harder and keep out some good stuff because registering is 
too much hassle?

I think the latter is the better choice, because the cruft doesn't 
actually hurt anything and there's a very, very large namespace that can 
afford to be wasted.

As Barry notes, the actual 'threat' is quite small and the damage from 
its being realized is also negligible.

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 7 Jun 2012 07:01:13 -0700

On Thu, Jun 7, 2012 at 4:12 AM, Dave Crocker <[email-masked]> wrote:

> Do we make it easier and let in some cruft along with the good stuff or do
> we make it harder and keep out some good stuff because registering is too
> much hassle?
>
> As Barry notes, the actual 'threat' is quite small and the damage from its
> being realized is also negligible.
>
>
OK, I'll take it down to FCFS for the version that goes to the IESG.
Unless there's objection I'll try to get that posted this weekend, which is
about half way through WGLC.

Thanks,
-MSK

---

From: Dave Crocker <[email-masked]>
Date: Thu, 07 Jun 2012 16:21:51 +0200

> actually hurt anything and there's a very, very large namespace that can

Murray correctly interpreted what I meant, but I feel compelled to 
correct the email and archive by noting that I meant former and not 
latter...

d/

---

From: Ned Freed <[email-masked]>
Date: Thu, 07 Jun 2012 19:19:50 -0700 (PDT)

> suspicious flood of registration requests.

I'm OK with moving to expert review, but the idea of going to FCFS makes me
pretty uncomfortable.

The problem here is that it's possible to think about MTA states in a lot of
different ways, some of which don't map well if at all onto actual
implementations. While the risk is low, I think expert review is needed to make
sure things stay sane.

> the queue state, to aid in interoperable usage.

Sounds about right to me.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Thu, 07 Jun 2012 19:24:31 -0700 (PDT)

> > ever happened

Um, in the case of media types at least, it hasn't happened *because* of
expert review. I can point at several examples of registration attempts
that didn't make any sense and which were rejected for that reason.

> and (2) IANA would ask the IESG to intervene if they got a

> disincentive to register.

Er, not really. From a registrant's point of view the process is essentially
the same with or without expert review: Fill in a form, submit it, wait
for a response.

What matters is the *content* of the form and the *timliness* of the response.
We initially screwed up both of those with media types: The rules for filling
out the form were much too strict, we didn't define the form content
adequately, and when the form was submitted responses were nowhere near timely
and in fact sometimes there was no response at all. Oh, and we called for
mailing list review of all proposals, and then didn't respond to review
requests in a timely way.

And I'm not seeing overly onerous content requirements here. So the
only factor is whether or not an expert can be found that can review
in a timely way. If that proves to be impossible then maybe FCFS makes
sense, but if not I'd prefer to see expert review remain.

> do we make it harder and keep out some good stuff because registering is

In this particular case cruft has a potential negative consequence:
Someone looks at the registry and says "why doesn't your product produce
this state". And they may not like the response that the state doesn't
make a lick of sense.

> its being realized is also negligible.

The threat is indeed very small. Not so sure about the damage.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Thu, 07 Jun 2012 21:37:04 -0700 (PDT)

> about half way through WGLC.

If that's the consensus then I won't object. As I say, I think the liklihood
of there being a problem is low, but I do think the possibility for a problem
exists.

Oh, and my bad for not catching the original specification required
requirement, which was clearly overkill.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Fri, 08 Jun 2012 07:09:19 +0200

> implementations. While the risk is low, I think expert review is needed to make

Ned,

You are of course right that one can get the choice(s) very wrong. And 
I've no trouble believe that some form of getting it wrong could have a 
toxic effect.  My question is what the actual damage of that is likely 
to be in the real world, /over time/.

That is, not just what is the likelihood that a site will use one of 
these potentially damaging values, but what is the likelihood that it 
will persist?

The world of MTA software developers is small enough to prompt me to 
believe that even if one of them gets this seriously wrong, a) it will 
get corrected quickly through natural forces, or b) they will have a 
plethora of other serious problems with their software and worrying 
about this one isn't worth the effort.

In contrast, Expert Review imposes quite an expensive /ongoing/ load on 
/us/, for every registration, nevermind on the folk who want to do the 
registering.

I see that as a very poor value proposition, especially in terms of 
community resources.  Which is why I favor FCFS.

d/

---

From: Dave Crocker <[email-masked]>
Date: Sat, 09 Jun 2012 02:51:01 +0200

On 6/8/2012 4:24 AM, Ned Freed wrote:
>> The justification for expert is "quality control". The side-effect
>> is a disincentive to register.
>
> Er, not really. From a registrant's point of view the process is
> essentially the same with or without expert review: Fill in a form,
> submit it, wait for a response.

Whether, that's not correct.  The structure isn't even the same.

When there is review, there is a sub-process that is absent from FCFS. 
That's a significant difference in form.

> What matters is the *content* of the form and the *timliness* of the

Right.  And since we don't to empty processes, the process entails 
dealing with that review, either by the potentially chilling effect of 
spending significant time trying to anticipate objections and respond to 
them, or in reactively responding to actual concerns of the reviewer.

Hence, both the politics and the effort are substantially different.

> And I'm not seeing overly onerous content requirements here.

Of course not.  You're an informed and reasonable guy.  Not all 
reviewers are like that.  And not all submitters know enough to 
anticipate the concerns of reviewers.

So the
> in a timely way. If that proves to be impossible then maybe FCFS
> makes sense, but if not I'd prefer to see expert review remain.

But this assumes a point I'm suggesting we consider carefully:  Having 
the process of finding the reviewer and managing the review process 
isn't free.  These are not like alternative routing algorithms: 
screwups have contained damage.  That makes the cost/benefit tradeoff 
questionable.

>> Do we make it easier and let in some cruft along with the good
>> stuff or do we make it harder and keep out some good stuff because
>> registering is too much hassle?
>
> Someone looks at the registry and says "why doesn't your product
> produce this state". And they may not like the response that the
> state doesn't make a lick of sense.

the word 'might' undermines the strength of this point.

>> actually hurt anything and there's a very, very large namespace
>> that can afford to be wasted.
>
>> As Barry notes, the actual 'threat' is quite small and the damage
>> from its being realized is also negligible.
>

I think the strategic media content threat is from bad media types, not 
bad registrations.  By bad media types, I mean bad technologies that get 
into a position of market leverage.  And we can't do anything about them.

---

From: Barry Leiba <[email-masked]>
Date: Sat, 9 Jun 2012 04:52:08 -0400

> I think the strategic media content threat is from bad media types, not
bad
> registrations.  By bad media types, I mean bad technologies that get into
a
> position of market leverage.  And we can't do anything about them.

Exactly, and that's my point: having the registrations is the important
point.  Not allowing registrations is not likely to prevent usage.  If
someone wants to start using a silly, ill-advised status code, with a poor
definition, they can and will do so whether we allow them to register it or
not.  If it's really stupid, it won't get any uptake. If it catches on, we
should have registered it.

I think that we need to use more FCFS registrations, in general, and not
have to have a designated expert (or worse, write new RFCs) for every
registration in every registry.  For some it absolutely makes sense.  For
media types, it's often hard to get the details right, and the expert
review helps people along with that.  I don't think it makes sense for this
particular one.

Barry

---

From: Ned Freed <[email-masked]>
Date: Sat, 09 Jun 2012 01:44:16 -0700 (PDT)

> That's a significant difference in form.

Again, this isn't as apparent as you seem to think.

> Hence, both the politics and the effort are substantially different.

The evidence says otherwise. For example, the private SNMP MIB registration
used to be FCFS (and apparently no longer exists), yet we struggled mightily to
figure out how to do it. Port numbers, OTOH, were a snap, even though they
involve expert review.

> anticipate the concerns of reviewers.

Fair point. There is always a chance of the reviewer being unreasonable.

> screwups have contained damage.  That makes the cost/benefit tradeoff

I think the number of these is certain to be very small so the cost
will be low.

> the word 'might' undermines the strength of this point.

The claim that "The reviewwer might be slow or unreasonable." has similar
issues.

> into a position of market leverage.  And we can't do anything about them.

I wasn't talking about media types.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Sat, 09 Jun 2012 02:33:23 -0700 (PDT)

> review helps people along with that.  I don't think it makes sense for this

As I said before, if the consensus is for FCFS, I'm willing to go along since
the number of this is likely to be small and so is the risk.

				Ned

---

From: Barry Leiba <[email-masked]>
Date: Sat, 9 Jun 2012 10:50:21 -0400

> the number of this is likely to be small and so is the risk.

And so I'd like to hear from more people about this.  The document said
Specification Required, and we're talking about changing it to either
Expert Review or First Come First Served.  You've seen the arguments on
both sides so far, but we've only heard from me, Dave, and Ned.

Will others give opinions, please?

Barry

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 9 Jun 2012 08:28:41 -0700

> Will others give opinions, please?
Ultimately either of the two is fine with me.  However, I'm leaning towards
FCFS since I agree that the number of these being registered beyond the set
already listed in the document is likely to be very small, and the damage
done by a bogus registration is really quite minimal since this is trace
data unlikely to be parsed by machines.

-MSK

---

From: t.petch <[email-masked]>
Date: Tue, 12 Jun 2012 10:34:14 +0100

----- Original Message -----
From: "Barry Leiba" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, June 09, 2012 3:50 PM
> > As I said before, if the consensus is for FCFS, I'm willing to go
along
> since

I am a fan of Expert Review.  It is a question of where the expertise is
likely to be should it be needed to get technical aspects of the request
into good shape; the originator of the request, IANA or the Expert.
Expert Review gives us another bite of the cherry, FCFS assumes that the
originator and IANA have all the necessary skills.

Tom Petch

---

From: Barry Leiba <[email-masked]>
Date: Tue, 12 Jun 2012 16:53:46 +0200

> originator and IANA have all the necessary skills.

Or that the review isn't necessary.  IANA is never expected to do such
review.
The arguments for FCFS here aren't that IANA can do it, but that for this
registry review isn't necessary.

Barry

---

From: Dave Crocker <[email-masked]>
Date: Tue, 12 Jun 2012 07:59:05 -0700

> originator and IANA have all the necessary skills.

On a separate list, abut 5 minutes ago, there is a discussion about 
Expert Review that just started.  I found myself asserting that Expert 
Review will be used as a quality control for 'goodness' rather than 
protection against danger.  The latter is actually the claimed purpose 
of Expert Review, not the former.

This confusion is one of a number of reasons I think Expert Review needs 
to be limited to situations in which wayward specs can do systemic 
damage only.

The received-state spec is not one of those.

d/

---

From: SM <[email-masked]>
Date: Thu, 14 Jun 2012 08:14:25 -0700

At 07:59 12-06-2012, Dave Crocker wrote:
>  just started.  I found myself asserting that Expert Review will be 
> used as a quality control for 'goodness' rather than protection 
> against danger.  The latter is actually the claimed purpose of 
> Expert Review, not the former.
>
>This confusion is one of a number of reasons I think Expert Review 
>needs to be limited to situations in which wayward specs can do 
>systemic damage only.

I read Section 6.2 of -01.  Murray mentioned that the choice is 
between Expert Review and First Come, First Served.  The draft 
already populates the sub-registry with entries to cover various use 
cases.  FCFS would provide an easy registration path without having 
to argue about the quality of a specification.

In Section 6.2:

  "Use:  One of "current" (the state keyword is in current use),
       "deprecated" (the state keyword is in use but not recommended for
       new implementations), or "historic" (the state keyword is no
       longer in substantial current use).

The draft does not mention anything about how "deprecated" or 
"historic" are to be handed.  If the WG decides for FCFS, for 
example, how will the "Use" be handled?

As a nit I suggest updating the dates and MTA version numbers in the examples.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 14 Jun 2012 11:00:13 -0700

On Thu, Jun 14, 2012 at 8:14 AM, SM <[email-masked]> wrote:

> The draft does not mention anything about how "deprecated" or "historic"
> are to be handed.  If the WG decides for FCFS, for example, how will the
> "Use" be handled?
>
>

Well now that's an interesting question.  Can we say something like "FCFS,
except IANA should probably check with ADs when they receive requests for
status changes"?  Has that been done before?

-MSK

---

From: SM <[email-masked]>
Date: Thu, 14 Jun 2012 11:29:01 -0700

Hi Murray,
At 11:00 14-06-2012, Murray S. Kucherawy wrote:
>Well now that's an interesting question.  Can we say something like 
>"FCFS, except IANA should probably check with ADs when they receive 
>requests for status changes"?  Has that been done before?

I don't recall seeing that before.  There is an IESG override for 
IANA policies.  That could be invoked by the ADs to handle such requests.

Instead of looking into how to reclassify, I suggest discussing what 
is considered as deprecated and what is considered as historic.  It 
can be used to assess whether the cost is worthwhile.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 14 Jun 2012 11:41:33 -0700

Hi SM,

On Thu, Jun 14, 2012 at 11:29 AM, SM <[email-masked]> wrote:

> I don't recall seeing that before.  There is an IESG override for IANA
> policies.  That could be invoked by the ADs to handle such requests.
>
> Instead of looking into how to reclassify, I suggest discussing what is
> considered as deprecated and what is considered as historic.  It can be
> used to assess whether the cost is worthwhile.
>
>
Even if we got rid of one of the two states, the question about moving from
"current" to the remaining one is unresolved.

Based on what you said, we could do "FCFS" and just encourage IANA to
interact with the IESG if they have any doubts at all about the request.

The simplest solution is to remove the "Status" column altogether, but I'd
prefer to keep it if we can find a way to work within our own IANA
procedures.

-MSK

---

From: SM <[email-masked]>
Date: Thu, 14 Jun 2012 12:24:50 -0700

Hi Murray,
At 11:39 14-06-2012, Murray S. Kucherawy wrote:
>Based on what you said, we could do "FCFS" and just encourage IANA 
>to interact with the IESG if they have any doubts at all about the request.

In an ideal world, yes. :-)

>The simplest solution is to remove the "Status" column altogether, 
>but I'd prefer to keep it if we can find a way to work within our 
>own IANA procedures.

Expert Review may be easier then.  It can be aligned with the Message 
Header Fields registry.  I'd use deprecated instead of deprecated and 
historic.  The ietf-message-headers mailing list can be reused to 
process the requests.  I don't have a strong preference.

Regards,
-sm

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 14 Jun 2012 21:49:35 +0100

On 14 Jun 2012, at 19:00, "Murray S. Kucherawy" <[email-masked]> wrote:

> The draft does not mention anything about how "deprecated" or "historic" are to be handed.  If the WG decides for FCFS, for example, how will the "Use" be handled?
>  
> 
> Well now that's an interesting question.  Can we say something like "FCFS, except IANA should probably check with ADs when they receive requests for status changes"?  Has that been done before?

I think ADs would prefer for an Expert to deal with this. Really, they don't have to be experts in SMTP and they already busy as it is.

You can restrict the Expert to only be able to do a very small set of tasks (or be limited in why he/she can reject a registration)

---

From: Ned Freed <[email-masked]>
Date: Thu, 14 Jun 2012 17:00:27 -0700 (PDT)

> status changes"?  Has that been done before?

AFAIK the answer is no, but OTOH IANA has been asked to implement policies
of some complexity up to and including the original media types registration
process without involving a Designated Expert.

That said, it's been my observation that the more you tell IANA to do, the
slower the process becomes, especially when what you're telling them to make
some sort of assessment. Additionally, and speaking from experience, ADs
are very busy people, so don't expect them to handle such queries in a very
timely way.

I can't help but think you're stirring up quite a pother in order to avoid
having a Designated Expert.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Thu, 14 Jun 2012 18:15:15 -0700

> interact with the IESG if they have any doubts at all about the request.

This issue goes beyond this specification.

In effect, it is a 'security' issue concerning authorization to make 
changes to an existing IANA entry.

I believe we should not be expected to resolve that issue for this 
specification.

On the other hand, I agree it does need resolving.

d/

---

From: Barry Leiba <[email-masked]>
Date: Fri, 15 Jun 2012 11:10:51 -0400

> status changes"?  Has that been done before?

That, in effect, is "Expert Review, and the current App ADs are the
designated experts."

So: No, let's not do that.

If we're worried about who's allowed to modify existing registrations,
you can say that in the registry definition:
FCFS for new registrations, and existing registrations can be updated
by the original requestor or by IESG Approval.

Barry

---

From: Ned Freed <[email-masked]>
Date: Fri, 15 Jun 2012 23:13:32 -0700 (PDT)

> by the original requestor or by IESG Approval.

That's much better.

				Ned