Source Ports in Abuse Reporting Format (ARF) Reports
RFC 6692

Received changes through RFC Editor sync (changed abstract to 'This document defines an additional header field for use in Abuse Reporting Format (ARF) reports to permit the identification of the source port of the connection involved in an abuse incident.

This document updates RFC 6591. [STANDARDS-TRACK]')

[Ballot comment]
(Summarizing an IM conversation with Murray)
This appears to extend 5965 rather than update it. It would also help to more clearly point to exactly what in  RFC6591 is being updated.

[Ballot comment]
- Not really a DISCUSS but please consider the following comment (or please justify your choice)

I looked at http://www.iana.org/assignments/marf-parameters/marf-parameters.xml for the Source-IP definition, and see:
          Source-IP: IPv4 or IPv6 address from which the original message was received

Now at look at Source-Port definition in the draft, and see:
  TCP source port from which the reported connection originated

Don't you think those two definitions should be aligned, as they are related?
What I have in mind is: TCP source port from which the original message was received

- Also, the following sentence doesn't seem quite right
  When present in a report, it MUST contain the TCP source port matching the
  "Source-IP" field in the same report, thereby describing completely
  the origin of the abuse incident.

Looking at http://tools.ietf.org/html/rfc5965#section-3.2 as a guideline:

      o  "Source-IP" contains an IPv4 or IPv6 address of the MTA from which
          the original message was received.  Addresses MUST be formatted as
          per section 4.1.3 of [SMTP].

I'm wondering, don't you want to write something such as:
  When present in a report, it MUST contain the TCP source port of the MTA
  from which the reported connection originated (characterized by the
  "Source-IP" field in the same report), thereby describing completely
  the origin of the abuse incident.

[Ballot comment]
If you wanted to tighten up the syntax, you could do:

  source-port = "Source-Port:" [CFWS] 1*5DIGIT [CFWS] CRLF

since a port number can't be more than 5 digits. But entirely up to you.

IESG:

IANA has reviewed draft-kucherawy-marf-source-ports-03 and has
the following comments:

IANA understands that, upon approval of this document, there is
a single IANA action which must be completed.

In the Feedback Report Header Fields subregistry of the Messaging
Abuse Reporting Format (MARF) Parameters registry located at:

http://www.iana.org/assignments/marf-parameters/marf-parameters.xml

a new Header Field will be added as follows:

Field Name: Source-Port
Description: TCP source port from which the reported connection originated
Multiple Appearances: No
Related Feedback-Type: any
Reference: [ RFC-to-be ]
Status: current

IANA understands that this is the only action required to be
completed upon approval of this document.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Source Ports in ARF Reports) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'Source Ports in ARF Reports'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-06-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines an additional header field for use in Abuse
  Reporting Format reports to permit the identification of the source
  port of the connection involved in an abuse incident.

  This document updates RFC5965 and RFC6591.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-kucherawy-marf-source-ports/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-kucherawy-marf-source-ports/ballot/


No IPR declarations have been submitted directly on this I-D.

Doc shepherd writeup:

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

This draft requests Proposed Standard status.  The title page so indicates.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:


Technical Summary

The information included in an ARF report has not included the source
port number on which a message was received.  As RFC 6032 notes, the
increasing use of NAT on IPv4 networks means that the port number for a
connection is often needed to determine the actual host.  This draft adds
a new report field for the port number.

Working Group Summary

This individual submission was briefly disucssed at the MARF meeting
at IETF 83 and has had some discussion on the MARF mailing list.  Because
it is simple and uncontroversial, and MARF is scheduled to close once its
existing documents are done, it wasn't worth the hassle of keeping MARF
open to handle it.

Document Quality

The quality is good.  It's a tiny tweak to ARF which I added to my
reporting scripts in about 15 minutes.  No formal reviews are required.

Personnel

John Levine is the Document Shepherd.
Barry Leiba is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The Document Shepherd read the draft and quickly implemented it.  It is
ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

The MARF WG discussed the draft in a thread with a dozen messages.
One person wondered whether IDENT might be a better way for a NAT to
identify hosts behind a NAT, but upon being reminded the RFC 6302
already recommends logging ports, agreed that this draft describes a
reasonable way to do it, although he remains dubious that there will
be real mail servers behind NATs that are busy enough to need the port
to tell which host it was, and keep detailed enough logs for the port
number to be useful.  Another person was concerned about adding
additional complexity to ARF if there isn't a significant benefit.
The Apps Area reviewer agreed that it was almost ready to publish as
a Proposed Standard, with some minor editorial changes, now made in
the current version of the draft.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No special reviews needed.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No special concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Authors confirm no IPR disclosures.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

This is an individual submission.  It was discussed briefly in MARF
(see above).  Nobody seriously objected to the draft.  The consensus was
that we have our doubts about the utility of this feature, but it's
worth adding it.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No appeals.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Nits are OK.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal reviews needed.

(13) Have all references within this document been identified as
either normative or informative?

References are categorized.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative refs are to published RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

No downrefs.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

The document updates RFC5965 and RFC6591.  The title page and abstract
indicate such.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The IANA Considerations section updates the Feedback Report Header Fields
registry, and correctly specifies the new entry to add.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

The document has one line of ABNF.  It's very simple, I reviewed it manually,
it's OK.