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

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.

  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.

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.

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?

   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.

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.

  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.

I also want to discuss the implications of moving a document with known security limitations
to full standard.