Preliminary Evaluation of RFC 1652 for Advancement to Full Standard
draft-ietf-yam-rfc1652bis-pre-evaluation-02

IESG felt that having this document as Standard is wrong, because the document itself is not being proposed for Full Standard. I think the "Dead" state is wrong, because this document is still being tracked, at least until rfc1652bis is published.

[Ballot discuss]
I still think this should be handled another way. A management item would have been more suitable.

I also note that any views of the current IESG will become mote in 6 months time when many of the current ADs has been changed.

Also, I wouldn't commit to a position now. There is a clear difference between this investigating question and the formal decision that balloting on the actual document is.

On the questions my answer is:
1. Yes
2. Maybe, I would note that the security consideration for example is bloody useless. Are there issues with describing correctly what the existing issues are even if not fixed?
3. If you anyway are moving the other documents to full standard, are there issues with bringing the documents together so that there would be no downward references at all?

[Ballot discuss]
o  Does the IESG believe the proposed changes are suitable during a
      move from Draft to Full Standard?
Yes at this point in time but that does not guarantee what opinion will be in future

  o  Does the IESG believe any other proposed changes are necessary to
      satisfy IESG requirements to advance to Full Standard?
Yes

  o  Does the IESG consider the downward references acceptable for a
      Full Standard?
No.

[Ballot comment]
My answers to the three questions asked in the document are Yes/No/Yes. In other words I do believe that the document with the proposed changes is fit for advancement from Draft to Full Standard, pending on the advice of the security area concerning the security aspects raised by Tim Polk. The proper way of advancing this document seems to me to be an IETF Last Call for 1652bis (1652 with the proposed changes) advancement.

[Ballot discuss]
o  Does the IESG believe the proposed changes are suitable during a
      move from Draft to Full Standard?

I do.

  o  Does the IESG believe any other proposed changes are necessary to
      satisfy IESG requirements to advance to Full Standard?

I don't know of any other changes.

However, we should be clear in our response that other changes may be found to be required during the usual document processing including IETF last call and IESG voting.

  o  Does the IESG consider the downward references acceptable for a
      Full Standard?

I do.

[Ballot discuss]
I think we are beating a dead horse on a draft like this is not the best way to get input from IESG - lets find a better way in the future. So ignoring that, I'd like to get on with what advice the IESG might be able to offer to the WG.

The charter says the WG is going to form a list of proposed changes to

RFC 1652 8BITMIME
RFC 1864 Content-MD5
RFC 2045, 2046, 2047, 2049 MIME base specs
RFC 3282 Content-language
RFC 3461 DSNs
RFC 3462 Multipart/Report
RFC 3463 Enhanced Status Codes
RFC 3464 Message Format for DSNs
RFC 3798 Message Disposition Notification
RFC 4409 Message Submission
RFC 5321 SMTP
RFC 5322 Internet Message Format

then consult with IESG. Are the changes proposed in this draft the complete set of changes the WG wants to make to the above RFCs?

[Ballot comment]
I find using a draft to drive discussions like this a very useful technique. However, using the balloting/evaluation process this way is a poor fit to the tool and I strongly discourage taking this path again.

I currently think the changes proposed are suitable.
I don't have a problem with the downward references.

[Ballot comment]
My personal responses wrt to the questions in section 3:
(1) I have no issues with the changes proposed.
(2) I have not made my mind up whether other changes are needed.
(3) I have no issues with the downrefs.

Any of those answers could be changed during IETF Last Call for 1652bis.

[Ballot discuss]
Agree with Adrian. This seems more like a communication with the IESG than something that needs to be store in the RFC series for perpetuity.

[Ballot comment]
One additional item for our discussion of this doc - procedurally, how will we prepare an IESG response?  Do we need to respond to the yam WG uncontionally or only if we think RFC 1652 will not be advanced according to the criteria set out in this doc or otherwise; e.g., Lisa's concern about security?

[Ballot discuss]
One of the big questions discussed about whether older email standards could go to Full Standard was whether the security provisions were sufficient -- whether authentication and privacy met our modern requirements, or if not, whether Full Standard was acceptable anyway because of historical considerations. 

If that is in fact going to be an issue, then this pre-eval document doesn't address that or or make the IESG think about that.  Future pre-eval documents, if we stick with this WG model, could reasonably compare the standard's security to modern requirements.  This DISCUSS position is so that we can talk about these issues on the call.

[Ballot comment]
My "No Objection" vote means the following answers to the questions in
Section 3: Yes, I think the proposed changes are suitable. No, I don't
think any other changes are necessary. Yes, I consider the downward
references acceptable.

However, the eventual advancement of RFC 1652 to Full Standard will
naturally go through IETF Last Call (this draft did not go through
IETF Last Call), where the community has an opportunity to provide
more input. My "No Objection" vote here is not a guarantee that
I can't change my mind after considering the community input.

[Ballot discuss]
This document is not a candidate for standard, which is what one would
  expect from the this agenda item entry.  The document is a reasonable
  way to capture the questions at hand, but an agenda entry that indicates
  the document is moving to standard is misleading and confusing.

  This document should be moved to the 'Dead' state in the tracker.

[Ballot discuss]
This seems like a really weird way to communicate with the IESG, and
I assume we are not supposed to evaluate the draft for publication
as an RFC as I see...


Abstract
  THIS INTERNET DRAFT IS WRITTEN TO FACILITATE PROCESSING WITHIN THE
  IESG.  IT IS NOT MEANT TO BE PUBLISHED AS AN RFC.



1.1.  Note to RFC Editor

  This Internet-Draft is not meant to be published as an RFC.  It is
  written to facilitate processing within the IESG.

I think it a shame that community resource has been burnt (e.g. SecDir
review) evaluating this document as a potential RFC.

---

In answer to the questions in Section 3

  o  Does the IESG believe the proposed changes are suitable during a
      move from Draft to Full Standard?

Yes

  o  Does the IESG believe any other proposed changes are necessary to
      satisfy IESG requirements to advance to Full Standard?

I believe that the it is necessary to satisfy any requirements that
arise from community evaluation of the protocol and from the
implementation reports.

  o  Does the IESG consider the downward references acceptable for a
      Full Standard?

I would prefer that we moved the entire collection forward together,
but would tolerate the downrefs if the community approves them.

----

What about draft-dusseault-impl-reports? Not an RFC yet, but good guidance.

[Note]: 'This draft contains the list of changes planned by the YAM WG to move RFC 1652 to Full Standard. There is no intention to publish this document as an RFC, so IESG should vote on this document as if RFC 1652 is advancing to Full Standard.
S Moonesamy <sm+ietf@elandsys.com> has agreed to serve as the document shepherd, but note that there is no shepherding write-up for this document.' added by Alexey Melnikov

[Note]: 'This draft contains the list of changes planned by the YAM WG to move RFC 1652 to Full Standard. There is no intention to publish this document as an RFC, so IESG should vote on this document as if RFC 1652 is advancing to Full Standard.' added by Alexey Melnikov