Subject: [Gen-art] GenART LC review of draft-ietf-appsawg-rfc3462bis-01

From: "Roni Even" <[email-masked]>
Date: Sat, 1 Oct 2011 16:30:55 +0300

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you
may receive.

Document: draft-ietf-appsawg-rfc3462bis-01

Reviewer: Roni Even

Review Date: 2011-10-1

IETF LC End Date: 2011-10-10

IESG Telechat date: 

Summary: This draft is almost ready for publication as an informational RFC.

Major issues:

Minor issues:

I noticed that the major change from RFC 3462 in the current version is to
remove requirement that multipart/report not be contained in anything. The
changes appear in appendix B which is to be removed in the published
document.  I think that it will be better to have the change from RFC 3462
be part of the main text and also discuss what are the backward
interoperability issues if any.

Nits/editorial comments:

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 2 Oct 2011 22:29:05 -0700

Hi Roni, thanks for your comments.
Two things in reply:
First, this is not an Informational document, it's Standards Track.  I don't know if that changes anything in your review, however.
Second, Section 1 does describe the change being made between RFC3462 and this document, and the rationale for doing so.  Was there some detail missing from there that was in the Appendix that you feel should be added?
Thanks,
-MSK
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
Sent: Saturday, October 01, 2011 6:31 AM
To: [email-masked]
Cc: [email-masked]; 'IETF-Discussion list'
Subject: GenART LC review of draft-ietf-appsawg-rfc3462bis-01

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments you may receive.

Reviewer: Roni Even

Review Date: 2011-10-1

IESG Telechat date:

Major issues:

Minor issues:

I noticed that the major change from RFC 3462 in the current version is to remove requirement that multipart/report not be contained in anything. The changes appear in appendix B which is to be removed in the published document.  I think that it will be better to have the change from RFC 3462 be part of the main text and also discuss what are the backward interoperability issues if any.

Nits/editorial comments:

---

From: "Roni Even" <[email-masked]>
Date: Mon, 3 Oct 2011 07:50:54 +0200

Hi,

My mistake about the document type (cut and paste problem)

As for me comment about multipart/report as part of  another multipart MIME
message, what will happen when an implementation based on RFC3462 will
receive the report according this document. Will it be processed, ignored or
take other behavior. Can the sender of the report know if it can send the
report in another multipart MIME message.

Thanks

Roni Even 

From: Murray S. Kucherawy [mailto:[email-masked]] 
Sent: Monday, October 03, 2011 7:29 AM
To: Roni Even; [email-masked]
Cc: [email-masked]; 'IETF-Discussion list'
Subject: RE: GenART LC review of draft-ietf-appsawg-rfc3462bis-01

Two things in reply:

First, this is not an Informational document, it's Standards Track.  I don't
know if that changes anything in your review, however.

Second, Section 1 does describe the change being made between RFC3462 and
this document, and the rationale for doing so.  Was there some detail
missing from there that was in the Appendix that you feel should be added?

Thanks,

-MSK

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni
Even

Reviewer: Roni Even

Review Date: 2011-10-1

IESG Telechat date: 

 

Major issues:

Minor issues:

 

Nits/editorial comments:

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 2 Oct 2011 23:24:32 -0700

The main implementations of multipart/report that I know of so far are ARF (RFC5965), DSN (RFC3464) and MDN (RFC3798).  In the latter two cases, they repeat the requirement that, at time of generation, a DSN/MDN has to have multipart/report as the outermost MIME type, which is why it's safe to remove the restriction here.  ARF specifically doesn't want the restriction, which was the impetus for this change; ARF wants to be able to send a message that is multipart/mixed containing many multipart/reports.
According to discussion within the working group, experience suggests most implementations of RFC3462 have disregarded the restriction anyway, specifically to allow DSNs and MDNs to be forwarded around (inside message/* MIME parts).  There has not been any report of interoperability problems as a result.  This factored into the working group's consensus.
-MSK
From: Roni Even [mailto:[email-masked]]
Sent: Sunday, October 02, 2011 10:51 PM
To: Murray S. Kucherawy; [email-masked]
Cc: [email-masked]; 'IETF-Discussion list'
Subject: RE: GenART LC review of draft-ietf-appsawg-rfc3462bis-01

Hi,
My mistake about the document type (cut and paste problem)
As for me comment about multipart/report as part of  another multipart MIME message, what will happen when an implementation based on RFC3462 will receive the report according this document. Will it be processed, ignored or take other behavior. Can the sender of the report know if it can send the report in another multipart MIME message.

Thanks
Roni Even

Reviewer: Roni Even

Review Date: 2011-10-1

IESG Telechat date:

Major issues:

Minor issues:

Nits/editorial comments:

---

From: "Roni Even" <[email-masked]>
Date: Mon, 3 Oct 2011 14:50:46 +0200

Thanks, for the information. I will leave it up to you to decide if the
information you provided me here should be in the document as backward
interoperability information.

Regards

Roni

Sent: Monday, October 03, 2011 8:25 AM

The main implementations of multipart/report that I know of so far are ARF
(RFC5965), DSN (RFC3464) and MDN (RFC3798).  In the latter two cases, they
repeat the requirement that, at time of generation, a DSN/MDN has to have
multipart/report as the outermost MIME type, which is why it's safe to
remove the restriction here.  ARF specifically doesn't want the restriction,
which was the impetus for this change; ARF wants to be able to send a
message that is multipart/mixed containing many multipart/reports.

According to discussion within the working group, experience suggests most
implementations of RFC3462 have disregarded the restriction anyway,
specifically to allow DSNs and MDNs to be forwarded around (inside message/*
MIME parts).  There has not been any report of interoperability problems as
a result.  This factored into the working group's consensus.

-MSK

Hi,

Thanks

Roni Even 

Two things in reply:

Thanks,

-MSK

Reviewer: Roni Even

Review Date: 2011-10-1

IESG Telechat date: 

 

Major issues:

Minor issues:

 

Nits/editorial comments: