Subject: [ietf-smtp] [IANA #823478] Protocol Action: 'SMTP 521 and 556 Reply Codes' to Proposed Standard (draft-klensin-smtp-521code-07.txt)

From: "Amanda Baber via RT" <[email-masked]>
Date: Fri, 15 May 2015 01:04:37 +0000

Dear Author:

ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED 

We've completed the IANA Actions for the following RFC-to-be:

draft-klensin-smtp-521code-07

ACTION 1:

IANA has updated the "Associated basic status code" and "Reference" fields for the following Enumerated Status Code:

Code: X.3.2
Sample Text: System not accepting network messages	
Associated basic status code: 453, 521	
Description: The host on which the mailbox is resident is not accepting messages. Examples of such conditions include an immanent shutdown, excessive load, or system maintenance. This is useful for both permanent and persistent transient errors.	
Reference: [RFC3463] (Standards Track); [RFC-klensin-smtp-521code-07] (Standards Track)	
Submitter: G. Vaudreuil	
Change Controller: IESG

Please see
http://www.iana.org/assignments/smtp-enhanced-status-codes

ACTION 2:

IANA has updated the "Reference" columns for the following Enumerated Status Code:

Code: X.1.10	
Sample Text: Recipient address has null MX	
Associated basic status code: 556	
Description: This status code is returned when the associated address is marked as invalid using a null MX.	
Reference: [RFC-ietf-appsawg-nullmx-10] (Standards Track); [RFC-klensin-smtp-521code-07] (Standards Track) 	
Submitter: J. Levine, M. Delany
Change Controller: IESG

Please see
http://www.iana.org/assignments/smtp-enhanced-status-codes

Please let us know whether the work described above was completed correctly. As soon as we receive your confirmation, we'll notify the RFC Editor that the document's IANA Actions are complete.

We'll update the references when the RFC Editor notifies us that they've assigned a number.

Thanks,

Amanda Baber
IANA Request Specialist
ICANN

---

From: "Alex van den Bogaerdt" <[email-masked]>
Date: Fri, 15 May 2015 08:17:43 +0200

> Description: The host on which the mailbox is resident is not accepting 
> messages. Examples of such conditions include an immanent shutdown, 
> excessive load, or system maintenance. This is useful for both permanent 
> and persistent transient errors.

Immanent?  Shouldn't that read imminent ?

---

From: John C Klensin <[email-masked]>
Date: Fri, 15 May 2015 14:36:04 -0400

> ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED 

Amanda and IANA colleagues,

I don't know who sees "draft-klensin-smtp-521code.all" so am
taking the liberty of copying Tony Hansen and John Levine on
this because some of the comments below may be relevant to them.
I am also copying Alex van den Bogaerdt to prevent a loop and to
note that this IANA action may not be an appropriate place to
ask for a registry change that is not associated with the
approved I-D in question.

Comments inline below.

> IANA has updated the "Associated basic status code" and
> "Reference" fields for the following Enumerated Status Code:
> 
> Code: X.3.2
> Description: The host on which the mailbox is resident is not
> accepting messages. Examples of such conditions include an
> immanent shutdown, excessive load, or system maintenance. This
> is useful for both permanent and persistent transient errors.	
> Reference: [RFC3463] (Standards Track);
> [RFC-klensin-smtp-521code-07] (Standards Track)	 Submitter: G.
> Vaudreuil	
> Change Controller: IESG

I don't know where "immanent" came from, but it wasn't from
either draft-klensin-smtp-521code-07.txt or RFC 5321.  It is
clearly an error, because none of the definitions I can find for
"immanent" make any sense at all in this sentence.  It does
appear in RFC 3463, so is an error there that was copied into
the registry.  I suspect that "imminent" was intended, but the
question of what procedure you need to fix that error is outside
my authority.  If you are going to continue to list Greg as the
responsible party for these codes even after you make changes to
them, you might ask him, but I don't think that would be very
productive.

In any event, because, as your description above indicates,
draft-klensin-smtp-521code-07 does not change that "Description"
field and you have not done so, I suggest that you mark this
change correctly completed as far as
draft-klensin-smtp-521code-07 is concerned and then sort the
spelling error out with the IESG at your mutual convenience
(Alex, please see note at end).

I hope we do not need to file an erratum on RFC 3463 and push it
through the system to get that fixed.

>From the perspective of draft-klensin-smtp-521code-07, the only
registry change associated with that entry is in adding "521" to
the "Associated Basic Status Code" column; that changes was
implemented correctly.

> Description: This status code is returned when the associated
> address is marked as invalid using a null MX.	 Reference:
> [RFC-ietf-appsawg-nullmx-10] (Standards Track);
> [RFC-klensin-smtp-521code-07] (Standards Track) 	 Submitter:
> J. Levine, M. Delany
> Change Controller: IESG
> 
> Please see

The "reference" change is correct and is correctly implemented.
I am agnostic as to which names you list in your "Submitter"
column, i.e., listing Levine and Delany is fine with me although
I can argue it either way.

> Please let us know whether the work described above was
> completed correctly. As soon as we receive your confirmation,
> we'll notify the RFC Editor that the document's IANA Actions
> are complete.

The work has been completed correctly, see above.   
 
> that they've assigned a number.

thanks,
    john

Alex: draft-klensin-smtp-521code was written ("thrown together"
might be more accurate) for the convenience of the community to
eliminate a procedural problem and avoid wasting time.  You are
sort of an innocent victim, but I'm going to be quite resistant
to the introduction of extraneous issues that cause further
delays.  Again, there is no question that "immanent" was an
error, but it is not one that is associated with this IANA
action and, while it is probably good that the error be caught
and fixed, I actually wonder why Amanda included fields in her
note that IANA did not change in any way.

---

From: "Amanda Baber via RT" <[email-masked]>
Date: Mon, 18 May 2015 18:44:07 +0000

Hi John, 

Per Chris, we've added your name to the "Submitter" field for X.1.10 and X.3.2:

Thanks for your help and your patience. I'll send this along to the RFC Editor.

Amanda

On Sat May 16 06:29:10 2015, [email-masked] wrote:
> This sounds most reasonable to me.  Thanks, Chris.
> 
> b
> 
> On Saturday, May 16, 2015, Chris Newman <[email-masked]> wrote:
> 
> > The standards track information we have on the "Submitter" field is what's
> > in
> > RFC 5248:
> >
> > "The identity of the submitter, usually the document author."
> >
> > When a registration is revised, that does not change the fact there was a
> > previous submitter. So I believe adding the new submitter is the correct
> > interpretation because it provides both the most information and is most
> > likely
> > to include at least one useful name.
> >
> >                 - Chris
> >
> > --On May 15, 2015 18:25:23 -0400 John C Klensin <[email-masked]
> > <javascript:;>> wrote:
> >
> > > Amanda,
> > >
> > > I'm adding Heather to the distribution for this because while
> > > the RFC Editor situations and the IANA ones are different (part
> > > of my point below), it interacts with another recent discussion
> > > or two.
> > >
> > > I might be the wrong person to ask because I tend to reason
> > > about these things forward from the IANA policies of 20 or 30
> > > years ago rather than backward from more recent decisions.
> > > With that caveat, I believe that most of your "submitter" fields
> > > are really "best contact if more information is needed or other
> > > issues arise".  On that basis and using the RFC 5248 registries
> > > and the discovery of "immanent" in the last 48 hours as an
> > > example, continuing to list Greg for any of those codes may be
> > > correct (because he was the lead author/editor of the document
> > > that defined them) but it is silly (because he has, AFAICT,
> > > dropped out and lost interest).
> > >
> > > In that regard, RFC authorship is used, much as some of us wish
> > > otherwise, to give credit.  We also use it as contact
> > > information if, for example, proposed errata appear and that
> > > purpose is often contradictory to the "credit" one after a few
> > > years have passed. For standards track materials, we also insist
> > > that the IESG be in the errata loop because it would not be
> > > sensible to allow the interpretations of an author/editor to
> > > formally change the interpretation of a standard.  I think you
> > > should be thinking about "submitter" in much the same way: make
> > > up whatever theories you like about what to put there as long as
> > > it is consistent (I can make a good case for "first to touch",
> > > "last to touch", or "first or last to touch whom we still know
> > > how to find and get to respond") but it seems to me that, if you
> > > have a designated expert who have been delegated by the IESG and
> > > the community to review changes, that is really the important
> > > contact information to list and that "submitter" is largely
> > > information for him or her.
> > >
> > > best,
> > >     john
> > >
> > >
> > > --On Friday, May 15, 2015 22:01 +0000 Amanda Baber via RT
> > > <[email-masked] <javascript:;>> wrote:
> > >
> > >> John, Tony, Chris, and Barry,
> > >>
> > >> John and Tony, this is a question for you as authors of RFC
> > >> 5248, and also for Chris, as the IESG-designated expert for
> > >> the RFC 5248 registries. (I overlooked earlier this week this
> > >> when I was initially making the edits requested by
> > >> draft-klensin-smtp-521code-07.)
> > >>
> > >> When we're modifying a Class Sub-Code, Status Sub-Code, or
> > >> Enumerated Status Code entry, should we add the
> > >> author's/authors' name(s) to the "Submitter" field? See
> > >> http://www.iana.org/assignments/smtp-enhanced-status-codes for
> > >> the current registry.
> > >>
> > >> Chris, can you send us the decision? IANA can't determine
> > >> consensus.
> > >>
> > >> John, I apologize for missing this.
> > >>
> > >> thanks,
> > >>
> > >> Amanda Baber
> > >> IANA Senior Specialist
> > >> ICANN
> > >>
> > >>
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >