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

Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.

Alvaro Retana No Record

Benjamin Kaduk No Record

Erik Kline No Record

Francesca Palombini No Record

John Scudder No Record

Lars Eggert No Record

Martin Duke No Record

Martin Vigoureux No Record

Murray Kucherawy No Record

Robert Wilton No Record

Roman Danyliw No Record

Warren Kumari No Record

Zaheduzzaman Sarker No Record

Éric Vyncke No Record

(Adrian Farrel; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2009-09-29 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Cullen Jennings; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2009-10-21 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  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.

(Lisa Dusseault; former steering group member) (was No Objection) Discuss

Discuss [Treat as non-blocking comment] (2009-10-05 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Magnus Westerlund; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2009-10-22 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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?

(Ralph Droms; former steering group member) (was No Objection) Discuss

Discuss [Treat as non-blocking comment] (2009-10-20 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
   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.

(Ron Bonica; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2009-10-06 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Russ Housley; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2009-10-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  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.

(Tim Polk; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2009-10-07 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I also want to discuss the implications of moving a document with known security limitations
to full standard.

(Alexey Melnikov; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Pasi Eronen; former steering group member) No Objection

No Objection (2009-10-05 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Robert Sparks; former steering group member) No Objection

No Objection (2009-10-07 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Dan Romascanu; former steering group member) No Record

No Record (2009-10-21 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.