Subject: [marf] Proposed base-04 changes based on AD feedback

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 26 Apr 2010 10:55:53 -0700

We got a review back from our Area Director about base-03 prior to him sending it out for IETF-wide last call.  Nearly all of the changes are ABNF housekeeping and the like, but a few issues of some substance did come up.  I made a preliminary guess at what would fly with the working group, so here are the major points and my proposed responses.

"Incidents" as defined has no upper bound.  Should it?  I suspect Sections 7.2 and 7.4 make enough of a point that implementers should be wary of silly or garbage input, but we can be more explicit about it if needed, or even impose a limit on the size of the number in this field.

"Version" had no ABNF (actually we just had "token" there, which is mighty generic).  I've gone with the "x.y" version format.  DKIM went with a single integer.  I'm not partial to either; I just picked one.

Our "Reporting-MTA" differs noticeably from the one defined in RFC3464 (DSN) in that the "mta-name-type;" prefix is missing.  Do we want to conform (reducing possible confusion) or do we want to push to leave it as-is (documenting current practice), perhaps amending the draft to acknowledge the discrepancy?

The "Designated Experts" requirement for the IANA registrations conflicts with the registry fields we name since we also require a specification document be stated in the registry.   It seems simpler to just change to "Specification Required" so that's what I've done.  I've also added a "Status" field to both registries allowing each item to be "current", "deprecated" or "historic", which was recommended.

I can generate a full copy of what I have for base-04 if anyone wants to see it.

Please reply with a +1 or other suggestions in each case.  I'd like to get this turned around without any apathy-induced delay.  :)

-MSK

---

From: SM <[email-masked]>
Date: Mon, 26 Apr 2010 11:38:09 -0700

Hi Murray,
At 10:55 26-04-10, Murray S. Kucherawy wrote:
>"Incidents" as defined has no upper bound.  Should it?  I suspect 
>Sections 7.2 and 7.4 make enough of a point that implementers should 
>be wary of silly or garbage input, but we can be more explicit about 
>it if needed, or even impose a limit on the size of the number in this field.

In Section 3.2, you could have:

   "Incidents" contains an unsigned 32-bit integer.

>Our "Reporting-MTA" differs noticeably from the one defined in 
>RFC3464 (DSN) in that the "mta-name-type;" prefix is missing.  Do we 
>want to conform (reducing possible confusion) or do we want to push 
>to leave it as-is (documenting current practice), perhaps amending 
>the draft to acknowledge the discrepancy?

I suggest following RFC 3464 on that.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 26 Apr 2010 12:30:03 -0700

> -----Original Message-----
> From: SM [mailto:[email-masked]]
> Sent: Monday, April 26, 2010 11:38 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Re: [marf] Proposed base-04 changes based on AD feedback
> 
> Hi Murray,

Alexey suggested that as well, so I'll include that text.

> I suggest following RFC 3464 on that.

I think that would be my personal preference just because I would expect some resistance to having two different formats for something called "Reporting-MTA", but I'm not an implementer so I'd like to hear from those folks.

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 26 Apr 2010 14:30:49 -0600

> I think that would be my personal preference just because I would expect some resistance to having two different formats for something called "Reporting-MTA", but I'm not an implementer so I'd like…

As an implementer: we don't include that field, so no strong opinion either way.

As a WG participant: I'm wary of depreciating current practice without a really strong rationale.  But, maybe it's okay, since we're also updating the version number: ARF metadata parsers could reliably assume that version 1 has the new format, and version 0.1 has the old.

--
J.D. Falk <[email-masked]>
Return Path Inc

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 26 Apr 2010 16:05:39 -0700

After further off-list chatter, I've changed the version to a single-digit form instead of "x.y", and "Incidents" is bound to be an unsigned 32-bit integer.

Feedback from implementers about "Reporting-MTA" is probably the most important one.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Monday, April 26, 2010 10:56 AM
To: [email-masked]
Subject: [marf] Proposed base-04 changes based on AD feedback

-MSK

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 26 Apr 2010 21:43:23 -0400

On Mon, Apr 26, 2010 at 7:05 PM, Murray S. Kucherawy <[email-masked]> wrote:
> After further off-list chatter, I’ve changed the version to a single-digit
> form instead of “x.y”, and “Incidents” is bound to be an unsigned 32-bit
> integer.
>
...

Will switching from x.y to a single digit cause problems with current
implementations?

Yakov

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 26 Apr 2010 22:00:52 -0400

On Mon, Apr 26, 2010 at 1:55 PM, Murray S. Kucherawy <[email-masked]> wrote:
> We got a review back from our Area Director about base-03 prior to him
> sending it out for IETF-wide last call.  Nearly all of the changes are ABNF
> housekeeping and the like, but a few issues of some substance did come up.
> I made a preliminary guess at what would fly with the working group, so here
> are the major points and my proposed responses.
>
...
>
>
> Our “Reporting-MTA” differs noticeably from the one defined in RFC3464 (DSN)
> in that the “mta-name-type;” prefix is missing.  Do we want to conform
> (reducing possible confusion) or do we want to push to leave it as-is
> (documenting current practice), perhaps amending the draft to acknowledge
> the discrepancy?
>
>

Since we are referencing the RFC 3464, it needs to match that
document. Any existing implementations should have been following RFC
3464 format anyway, since that is how it was always defined in the ARF
drafts even though the ABNF did not match.

It is also interesting to note that this field was only present since
version "-04" / March 2008:

http://www.shaftek.org/publications/drafts/abuse-report/draft-shafranovich-feedback-report-04.txt

It was prompted by this email:

http://mipassoc.org/pipermail/abuse-feedback-report/2007q4/000209.html

There may be a larger question of whether it is wise to tie this draft
to RFC 3464's IANA registries, but that may be a discussion for a
different time.

>
> The “Designated Experts” requirement for the IANA registrations conflicts
> with the registry fields we name since we also require a specification
> document be stated in the registry.   It seems simpler to just change to
> “Specification Required” so that’s what I’ve done.  I’ve also added a
> “Status” field to both registries allowing each item to be “current”,
> “deprecated” or “historic”, which was recommended.
>

I am a bit vary of allowing only Specification Required without a
designated expert, Why can't we have a procedure similar to MIME types
where a specification and an expert review is needed?

On the other hand, if "specification required" means that the RFC
Editor will ask the IESG for their opinion, that may be sufficient.

Also, what is the difference between deprecated and historic? Should
we just have one of them ("deprecated")?

Yakov

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 26 Apr 2010 21:36:21 -0700

> From: Yakov Shafranovich [mailto:[email-masked]]
> Sent: Monday, April 26, 2010 6:43 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> > After further off-list chatter, I've changed the version to a single-
> digit
> > form instead of "x.y", and "Incidents" is bound to be an unsigned 32-
> bit
> > integer.
> >
> ...
> 

I suspect not, since there's only been one version so far.  But the implementers are being awfully quiet...

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 26 Apr 2010 21:39:57 -0700

> Sent: Monday, April 26, 2010 7:01 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]

The ABNF should probably be changed to match RFC3464's then, if that's been the intent all along.  I'll dig that up and make the change.

I was the one that added the ABNF to the spec, but I seem to recall was doing so based on an example and not on the basis RFCs.  So there's at least one broken implementation out there.  :-)

> > The "Designated Experts" requirement for the IANA registrations
> conflicts
> > "Specification Required" so that's what I've done.  I've also added a
> > "Status" field to both registries allowing each item to be "current",
> > "deprecated" or "historic", which was recommended.
> 

According to RFC5226, Specification Required includes a Designated Expert, selected by the IESG.  Where the publication is an RFC, I believe the IESG has the discretion to declare that the working group (if there was one) counts as the Expert.
 
> we just have one of them ("deprecated")?

I would say "deprecated" is "still supported, but use discouraged [in favour of something else that's newer]," while "historic" is "no longer supported, but still documented for informational purposes."

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 30 Apr 2010 12:20:09 -0600

> I suspect not, since there's only been one version so far.  But the implementers are being awfully quiet...

I believe our ARF parsing code ignores the version number, because (as you say) there's been only one so far.  And so long as the differences between 0.1 and 1 are minimal, we'll probably continue ignoring the version number.