1 / 16

Yet Another Mail

Working Group IETF 76 November 11, 2009. Yet Another Mail. Note Well.

adanne
Download Presentation

Yet Another Mail

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Working Group IETF 76 November 11, 2009 Yet Another Mail

  2. Note Well Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: the IETF plenary session, any IETF working group or portion thereof, the IESG or any member thereof on behalf of the IESG, the IAB or any member thereof on behalf of the IAB, any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 5378 and RFC 3979 (updated by RFC 4879). Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 5378 and RFC 3979 for details. A participant in any IETF activity is deemed to accept all IETF rules of process, as documented in Best Current Practices RFCs and IESG Statements. A participant in any IETF activity acknowledges that written, audio and video records of meetings may be made and may be available to the public.

  3. Pass the blue sheets around Need a note taker Need a jabber-er

  4. Finding Yammerers • Mailing List: • yam@ietf.org • Jabber: • xmpp:yam@jabber.ietf.org • Audio Stream: • http://videolab.uoregon.edu/events/ietf/ietf765.m3u • Meeting Materials: • https://datatracker.ietf.org/meeting/76/materials.html#wg-yam • WG Wiki • http://trac.tools.ietf.org/wg/yam/trac/wiki

  5. Agenda 75 minutes – 9:00 – 10:15 Note well - 1 minute Agenda bashing - 4 minutes Discuss how our process is working - 40 minutes Alexey Melnikov Dave Crocker Next steps - 20 minutes Whither the working group? Template changes? Any Other Business - 10 minutes

  6. “Nothing will ever be attempted if all possible objections must first be overcome.” – Samuel Johnson

  7. How is Our Process Working?

  8. How is Our Process Working? Alexey Melnikov Dave Crocker Reactions?

  9. Next Steps

  10. Next Steps Wither the working group? Template changes? Next documents?

  11. IESG Template

  12. IESG Template change #1? • Change this text: • Does the IESG believe any other proposed changes are necessary to satisfy IESG requirements to advance to Full Standard? • Excluding the previous proposed changes and expected IESG support for technically substantive IETF last call feedback, does the IESG believe any additional changes are critical to advance this document from draft to full standard?  If so, please provide sufficient information so the WG can address these issues prior to IETF last call or determine the document is inappropriate for the YAM WG to process at this time.

  13. IESG Template change #2? • Change this text: • Does the IESG consider the downward references acceptable for a Full Standard? • Does the IESG consider the downward references acceptable for a full standard?  If not, please cite which specific downward reference or references are problematic and why so the WG can address these issues prior to IETF last call or determine the document is inappropriate for the YAM WG to process at this time.

  14. IESG Template change #3? • (SM) As a meta comment, the WG is asking the IESG for answers but the pre-evaluation I-D does not provide ample information for them to understand the YAM WG's perspective.  The WG could consider whether “Working Group Summary” information similar to what is done for Document Shepherding would be helpful to the IESG.

  15. Next Documents? • RFC 5321 – SMTP • RFC 5322 – Mail Format • RFC 4409 – Submit

  16. Any Other Business?

More Related