[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FINAL: IESG Telechat Agenda and Package for April 30, 2003
INTERNET ENGINEERING STEERING GROUP (IESG)
Agenda for the April 30, 2003 IESG Teleconference
1. Administrivia
o Roll Call
o Bash the Agenda
o Approval of the Minutes
- April 17, 2003
o Review of Action Items
OUTSTANDING TASKS
IP o Allison to review draft-agrawal-sip-h323-interworking-reqs
and send decision to IESG.
IP o Erik to document process of how the IESG goes about asking
architectural questions of the IAB
IP o Thomas to write (or cause to be written) a draft on "how to
get to Draft".
IP o Thomas to contact Cablelabs to discuss formal relationship
with IAB
IP o Allison and Thomas will email Secretariat note to send to RFC
Editor about 3GPP RFC Editor documents.
IP o Secretariat to modify auto-response for Internet-Drafts
submissions so that when someone submits an I-D, a note is
automatically generated which recommends that they consider
the issues listed in ID-Nits before submitting the I-D to the
IESG. Auto-response to include the URL pointing to the
I-D Nits page. IESG will review the auto-response text.
IP o Secretariat to email Working Group Chairs a reminder after each
conference with pointer to I-D Nits. Secretariat to draft
reminder text and pass by IESG first.
IP o Ned to write an IESG note for draft-tegen-smqp (Informational)
IP o Steve to write RFC re: TCP MD5 option
IP o Randy and Ned to finish ID on Clarifying when Standards Track
Documents may Refer Normatively to Documents at a Lower Level
DONE o Bert to send instructions/text to Secretariat to install URL
for IANA MIB Copyright
DONE o Ted to send RFC Editor Note to Secretariat for draft-walsh-urn-
web3d-00.txt
DONE o Erik to write, send formal statement to Secretariat to be sent to
IAB confirming IETF appointment to ISOC BoT
DONE o Ted Hardie to send message to Secretariat for apex wg to be sent to
RFC Editor re: changing status of draft from proposed to experimental.
Secretariat to change draft-ietf-apex-presence-06.txt from and individual to
an experimental document.
DONE o Secretariat to send formal WG Review message for netconf to
ietf-announce, new-work, et al. and return item to next telechat agenda.
DONE o IESG approved minor re-charter for rmt wg. Secretariat to update rmt
wg charter page.
DONE o Secretariat to update ballot for draft-zeilenga-ldap-user-schema for
it to be reconsidered as a new ballot on the next telechat.
2. Protocol Actions
o LDAPv3: A Collection of User Schema (Proposed Standard)
<draft-zeilenga-ldap-user-schema-06.txt>
Token: Hardie, Ted
Note: It is proposed that this be approved for Proposed Standard
with the following IESG note: This document contains useful and
timely updates to RFC 2798. The IESG expects that this document
will be replaced or updated again once the LDAP community has
finished its work related to stringprep, and that those updates
will cause this document or its successors to recycle at the
Proposed Standard level.
o Message Disposition Notification (Draft Standard)
<draft-vaudreuil-mdnbis-03.txt>
Token: Freed, Ned
Note: Responsible: freed
o The IETF XML Registry (BCP)
<draft-mealling-iana-xmlns-registry-04.txt>
Token: Hardie, Ted
Note: Patrik to speak with Michael about this being a BCP.
Steve to remove from list of IESG items. When ready, paf to
request last call for BCP.
Responsible: paf
o Generalized Multi-Protocol Label Switching Architecture
(Proposed Standard)
<draft-ietf-ccamp-gmpls-architecture-05.txt>
Token: Wijnen, Bert
Note: IETF Last Call requested.
Responsible: Bert
o Session Initiation Protocol Basic Call Flow Examples (BCP)
<draft-ietf-sipping-basic-call-flows-02.txt>
Token: Mankin, Allison
Note: Discuss comments regarding the normative status as a BCP -
revision was done and it returns to IESG agenda.
o Session Initiation Protocol PSTN Call Flows (BCP)
<draft-ietf-sipping-pstn-call-flows-02.txt>
o UTF-8, a transformation format of ISO 10646 (Standard)
<draft-yergeau-rfc2279bis-04.txt>
Token: Hardie, Ted
o Link Management Protocol (LMP) (Proposed Standard)
<draft-ietf-ccamp-lmp-08.txt>
Token: Wijnen, Bert
Note: IETF Last Call requested
Responsible: secretariat
o Internet X.509 Public Key Infrastructure Certificate Management
Protocols (Proposed Standard)
<draft-ietf-pkix-rfc2510bis-08.txt>
Token: Housley, Russ
o Internet X.509 Public Key Infrastructure Certificate Request
Message Format (CRMF)(Proposed Standard)
<draft-ietf-pkix-rfc2511bis-06.txt>
Token: Housley, Russ
3. Working Group Submissions
o IP over Optical Networks: A Framework (Informational)
<draft-ietf-ipo-framework-04.txt>
Token: Zinin, Alex
o Content Internetworking (CDI) Scenarios (Informational)
<draft-ietf-cdi-scenarios-01.txt>
Token: Hardie, Ted
Note: Responsible: Ted
o Exclusive XML Canonicalization, Version 1.0 (Informational)
<draft-ietf-xmldsig-xc14n-00.txt>
Token: Housley, Russ
Note: Responsible: Russ Housley
o Policy Requirements for Time-Stamping Authorities (Informational)
<draft-ietf-pkix-pr-tsa-04.txt>
Token: Housley, Russ
o SDPng Transition (Informational)
<draft-ietf-mmusic-sdpng-trans-03.txt>
Token: Peterson, Jon
Note: Roadmap document explaining relation of various extensions
of SDP such as offer-answer and fid to the SDPng work.
4. Individual
o A Description of the Camellia Encryption Algorithm
(Informational)
<draft-nakajima-camellia-02.txt>
Token: Bellovin, Steve
5. Individual via RFC Editor
o A URN Namespace for SWIFT's Financial Messaging (Informational)
<draft-gustin-goyens-urn-id-02.txt>
Token: Hardie, Ted
Note: Responsible: paf
o A URN Namespace for MPEG (Informational)
<draft-smith-urn-mpeg-01.txt>
Token: Hardie, Ted
o Extreme Networks' Ethernet Automatic Protection Switching
(EAPS), Version 1 (Informational)
<draft-shah-extreme-eaps-02.txt>
Token: Nordmark, Erik
Note: Ready for the IESG agenda.
o A URN Namespace for FIPA (Informational)
<draft-bellifemine-urn-fipa-00.txt>
Token: Hardie, Ted
o A Framework for Purpose Built Keys (PBK) (Informational)
<draft-bradner-pbk-frame-04.txt>
Token: Bellovin, Steve
6. Proposed Working Group
o Multiparty Multimedia Session Control (mmusic)
Token: Jon
o Network Configuration (netconf)
Token: Bert
o LDAP Duplication/Replication/Update Protocols
Token: Ned
7. Working Group News we can use
8. IAB News we can use
9. Management Issues
o Proposed resolution of the AD-shepherded info/experimental
*DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT *
INTERNET ENGINEERING STEERING GROUP (IESG)
April 17, 2003
Reported by: Jacqueline Hargest, IETF Assistant Director
ATTENDEES
---------
Austein, Rob / IAB Liaison
Bellovin, Steve / AT&T Labs
Bush, Randy / IIJ
Cotton, Michelle / ICANN
Daigle, Leslie / Verisign (IAB)
Freed, Ned / Innosoft
Fuller, Barbara / IETF
Hardie, Ted / Qualcomm, Inc.
Hargest, Jacqueline / IETF
Mankin, Allison / Bell Labs, Lucent
Narten, Thomas / IBM
Nordmark, Erik / Sun
Peterson, Jon / NeuStar, Inc.
Reynolds, Joyce K. / ISI (RFC Editor)
Suleymanova, Dinara / IETF
Wijnen, Bert / Lucent
Zinin, Alex / Alcatel
REGRETS
-------
Alvestrand, Harald / Cisco
Fenner, Bill / AT&T
Housley, Russ / Vigil Security, LLC
Minutes
-------
1. The minutes of the April 3, 2003 teleconference were approved
pending minor wording change. Secretariat to place in public archives
and update minutes web page.
2. The following action items were reported as DONE:
o Steve Bellovin will write RFC for Automated Key Management
o Secretariat to send lemonade WG Action Announcement
o Randy to send GROW new charter review message to Secretariat.
Secretariat to send to IAB, IESG and WG Chairs.
o Thomas will check with 3GPP2 about expediting RFC processing
for draft-koren-pppext-rfc2509bis-03.txt and
draft-ietf-avt-crtp-enhance. If ok, the IESG has already
approved that request.
3. Protocol Action Tentatively Approved:
The IESG tentatively approved the Internet-Draft 'Use of the RSAES-OAEP
Transport Algorithm in CMS' <draft-ietf-smime-cms-rsaes-oaep-07.txt>
as a Proposed Standard, pending RFC Editor Note from Steve Bellovin.
Once received, Secretariat will announce.
4. Protocol Actions Deferred:
o LDAPv3 A Collection of User Schema (Proposed Standard)
<draft-zeilenga-ldap-user-schema-06.txt>
o Generalized Multi-Protocol Label Switching Architecture
(Proposed Standard)
<draft-ietf-ccamp-gmpls-architecture-05.txt>
5. Document Actions Approved:
The IESG has approved the Internet-Draft 'Framework Policy Information
Base for Usage Feedback' <draft-ietf-rap-feedback-fr-pib-06.txt> as an
Informational RFC. Secretariat to send announcement.
The IESG has approved the Internet-Draft 'IEEE 802.1X RADIUS Usage
Guidelines' <draft-congdon-radius-8021x-26.txt> as an Informational
RFC. Secretariat to send announcement.
6. Document Action Tentatively Approved:
o A URN Namespace for the Web3D Consortium (Web3D) (Informational)
<draft-walsh-urn-web3d-00.txt>
Note: Ted Hardie will discuss with author and send RFC Editor
Note.
7. Document Actions Deferred:
o Exclusive XML Canonicalization, Version 1.0 (Informational)
<draft-ietf-xmldsig-xc14n-00.txt>
o A URN Namespace for FIPA (Informational)
<draft-bellifemine-urn-fipa-00.txt>
8. Working Group Actions Approved:
o Application Exchange (apex) to close
Note: Ted Hardie to send message to Secretariat to be sent to
RFC Editor re: changing status of draft from proposed to
experimental. Secretariat to change draft-ietf-apex-presence-
06.txt from an individual to an experimental document.
o Network Configuration (netconf)
Note: Secretariat to send formal WG Review message to
ietf-announce, new-work, et al. and return item to next
telechat agenda.
o Reliable Multicast Transport (rmt)
Note: IESG approved minor re-charter. Secretariat to update
charter page.
9. Documents Remaining Under Discussion:
o Internet X.509 Public Key Infrastructure Permanent Identifier
(Proposed Standard)
<draft-ietf-pkix-pi-06.txt>
o Security Considerations for SIGTRAN Protocols (Proposed Standard)
<draft-ietf-sigtran-security-02.txt>
o The AES Cipher Algorithms and Their Use With IPsec (Proposed
Standard)
<draft-ietf-ipsec-ciph-aes-cbc-04.txt>
o Use of the AES Encryption Algorithm in CMS (Proposed Standard)
<draft-ietf-smime-aes-alg-06.txt>
o Using IPsec to Protect Mobile IPv6 Signaling between Mobile
Nodes and Home Agents (Proposed Standard)
<draft-ietf-mobileip-mipv6-ha-ipsec-04.txt>
o IANA Considerations for RADIUS (Proposed Standard)
<draft-aboba-radius-iana-05.txt>
o IPv6 Global Unicast Address Format (Informational)
<draft-ietf-ipv6-unicast-aggr-v2-02.txt>
o Policy Requirements for Time-Stamping Authorities (Informational)
<draft-ietf-pkix-pr-tsa-04.txt>
o Dynamic Authorization Extensions to Remote Authentication Dial-In
User Service (RADIUS) (Informational)
<draft-chiba-radius-dynamic-authorization-12.txt>
o Multicast Source Discovery Protocol (MSDP) (Experimental)
<draft-ietf-msdp-spec-15.txt>
o Handle System Overview (Informational)
<draft-sun-handle-system-10.txt>
o Handle System Protocol (ver 2.1) Specification (Informational)
<draft-sun-handle-system-protocol-04.txt>
o Handle System Namespace and Service Definition (Informational)
<draft-sun-handle-system-def-07.txt>
o Tracing Requirements for Generic Tunnels (None)
<draft-ietf-ccamp-tracereq-01.txt>
10. The IESG confirmed the IAB's selection for the IETF
appointment to the ISOC BoT. The decision was unanimous
among the 10 IESG members present on the telechat with 3 members
absent.
11. New Action Items:
o Ted to send RFC Editor Note to Secretariat for
draft-walsh-urn-web3d-00.txt.
o Erik to write, send formal statement to Secretariat to be sent to
IAB confirming IETF appointment to ISOC BoT.
o Ted Hardie to send message to Secretariat for apex wg to be sent
to RFC Editor re changing status of draft from proposed to
experimental. Secretariat to change.
draft-ietf-apex-presence-06.txt from and individual to an
experimental document.
o Secretariat to send formal WG Review message for netconf to
ietf-announce, new-work, et al. and return item to next telechat agenda.
o IESG approved minor re-charter for rmt wg. Secretariat to update
rmt wg charter page.
o Secretariat to update ballot for draft-zeilenga-ldap-user-schema
for it to be reconsidered as a new ballot on the next telechat.
12. Outstanding Action Items:
IP o Allison to review draft-agrawal-sip-h323-interworking-reqs
and send decision to IESG.
IP o Erik to document process of how the IESG goes about asking
architectural questions of the IAB.
IP o Thomas to write (or cause to be written) a draft on "how to
get to Draft".
IP o Thomas to contact Cablelabs to discuss formal relationship
with IAB.
IP o Allison and Thomas will email Secretariat note to send to RFC
Editor about 3GPP RFC Editor documents.
o Secretariat to modify auto-response for Internet-Drafts
submissions so that when someone submits an I-D, a note is
automatically generated which recommends that they consider
the issues listed in ID-Nits before submitting the I-D to the
IESG. Auto-response to include the URL pointing to the
I-D Nits page.
o Secretariat to email Working Group Chairs a reminder after
each conference with pointer to I-D Nits. Secretariat to
draft reminder text and pass by IESG first.
IP o Ned to write an IESG note for draft-tegen-smqp
(Informational).
IP o Steve to write RFC re TCP MD5 option.
IP o Randy and Ned to finish ID on Clarifying when Standards Track
Documents may Refer Normatively to Documents at a Lower Level.
IP o Bert to send instructions/text to Secretariat to install URL
for IANA MIB Copyright.
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-zeilenga-ldap-user-schema - LDAPv3: A
Collection of User Schema to Proposed Standard
--------
It is proposed that this be approved for Proposed Standard with the
following IESG note:
This document contains useful and timely updates to RFC 2798. The IESG
expects that this document will be replaced or updated again once the
LDAP community has finished its work related to stringprep, and that
those updates will cause this document or its successors to recycle at
the Proposed Standard level.
Last Call to expire on: January 28, 2002
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ XX] [ X ] [ ]
Randy Bush [ ] [ X ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ D ]
Ted Hardie [ X ] [ ] [ ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ X ] [ ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
Jon Peterson [ ] [ X ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
2/3 (10) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
========
Steve: Does this depend on stringprep for comparisons? Should it?
COMMENTS:
=========
Ted:
Steve,
Kurt has suggested a tweak to this; here is his note:
> Ted, regarding this recently added note to the tracker:
> It is proposed that this be approved for Proposed Standard with
> the following IESG note: This document contains useful and timely
> updates to RFC 2798. The IESG expects that this document will be
> replaced or updated again once the LDAP community has finished its
> work related to stringprep, and that those updates will cause this
> document or its successors to recycle at the Proposed Standard level.
>
> The primary focus of the I-D is to update RFC 1274 (Proposed Standard)
> and to adapt additional X.520(93) schema for use in LDAP (such as
> the matching rules needed by Policy WG draft). Superceding portions
> of RFC 2798 (Informational) became necessary as it tried to fill some
> of the gaps.
>
> I would suggest the IESG note focus more on "useful and timely
> updates" to RFC 1274 (and filling gaps between X.520(93) and LDAP).
>
> Kurt
Based on that, I think we might want to change the text to say
"This document contains useful and timely updates of RFC
1274 and RFC 2798, as well as harmonizing certain aspects
of X.520(93) and LDAP. The IESG expects that this document
will be replaced or updated again once the LDAP community has
finished its work related to stringprep, and that those updates will
cause this document or its successors to recycle at the Proposed
Standard level"
Would this text still be okay with you?
Russ:
Section 3.25. Should we change "secretary" to "secretary or
administrative assistant" in the description of the attribute? I am
not proposing to change the name of the attribute.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: LDAPv3: A Collection of User Schema to
Proposed Standard
-------------
The IESG has approved the Internet-Draft 'LDAPv3: A Collection of User
Schema' <draft-zeilenga-ldap-user-schema-06.txt> as a Proposed
Standard. This has been reviewed in the IETF but is not the product of
an IETF Working Group.
The IESG contact persons are Ned Freed and Patrik Faltstrom
Technical Summary
This document provides a collection of user schema elements for use
with LDAP (Lightweight Directory Access Protocol) from both ITU-T
Recommendations for the X.500 Directory and COSINE and Internet X.500
pilot projects.
Working Group Summary
This document is not a product of a working group. It has been
discussed on the LDAPBIS working group mailing list. There was
consensus for publication of a document specifying this schema.
Protocol Quality
The specification was reviewed for the IESG by Patrik Faltstrom.
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-vaudreuil-mdnbis - Message Disposition
Notification to Draft Standard
--------
Last Call to expire on: 2002-12-23
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ X ] [ ]
Ned Freed [ X ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
========
Bill:
The "parameter" ABNF in the document body is missing a '"," value'
sequence (which is present in the collected grammar, but not in
the first definition.)
- parameter = attribute "=" importance *("," value)
+ parameter = attribute "=" importance "," value *("," value)
The "-" disease bit the mdn-gateway-field definition:
- mdn-gateway field = "MDN-Gateway" ":" mta-name-type ";" mta-name
+ mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name
AFAIK, single-quotes are not quotes in ABNF. (This needs to get
fixed in both the document body and the collected ABNF).
disposition-field =
"Disposition" ":" disposition-mode ";"
disposition-type
- [ '/' disposition-modifier
+ [ "/" disposition-modifier
*( "," disposition-modifier ) ]
More "-" disease:
- should follow the "X-", (e.g. "X Foomail
+ should follow the "X-", (e.g. "X-Foomail-Log-ID" or "X-EDI-info").
The mdn-request-header definition in the collected ABNF says that the
mailbox list is seperated by periods; the definition in the document
body says commas. I selected commas because that is consistent with
the # notation from the original spec.
mdn-request-header =
"Disposition-Notification-To" ":"
- mailbox *("." mailbox)
+ mailbox *("," mailbox)
The disposition-type and disposition-modifier in the collected ABNF
disagree with the versions in the body of the document. I made them
the same as the definitions in the body, but this needs to be double-checked
by someone who knows the intent of the changes.
disposition-type = "displayed"
+ / "deleted"
/ "dispatched"
/ "processed"
- / "deleted"
- / "denied"
- / "failed"
- disposition-modifier = disposition-modifier-extension
+ disposition-modifier = "error" / disposition-modifier-extension
original-message-id-field got hit by "-" disease:
- original-message id
+ original-message-id-field = "Original-Message-ID" ":" msg-id
I may have missed some of the places where the editing damaged the original
RFC text. http://irg.attlabs.net/~fenner/2298bis.html might be useful in
trying to find other problems.
COMMENTS:
=========
Bert:
Oh well ... this ID-NITs byte us again:
- Many lines are beyond column 72, many pages are too long.
Summary:
-: 430 lines longer than 72 characters, max 76
-: 32 pages longer than 58 lines, max 61 lines
- Example on page 13:
Reporting-UA: rogers-mac.dcrt.nih.gov; Foomail 97.1
Should be something at example.com, no?
- Same for the example on page 27
- References not split in normative and informative
Other nits:
- bottom page 18. Is it just a closing ) that is missing, or more text?
It says: should follow the "X-", (e.g. "X Foomail
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>,
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Message Disposition Notification to Draft
Standard
-------------
The IESG has approved the Internet-Draft 'Message Disposition
Notification' <draft-vaudreuil-mdnbis-03.txt> as a Draft Standard,
obsoleting RFC2298.
This document has been reviewed in the IETF but is not the product of an
IETF Working Group. The IESG contact persons are Ned Freed and
Ted Hardie.
Technical Summary
This memo defines a MIME content-type that may be used by a mail user
agent (MUA) or electronic mail gateway to report the disposition of a
message after it has been successfully delivered to a recipient. This
content-type is intended to be machine-processable. Additional
message headers are also defined to permit Message Disposition
Notifications (MDNs) to be requested by the sender of a message. The
purpose is to extend Internet Mail to support functionality often
found in other messaging systems, such as X.400 and the proprietary
"LAN-based" systems, and often referred to as "read receipts,"
"acknowledgements", or "receipt notifications." The intention is to
do this while respecting the privacy concerns that have often been
expressed when such functions have been discussed in the past.
Working Group Summary
This document was originally the product of the RECEIPT working group.
Review of the revised version was conducted largely in the context
of the VPIM working group.
Implementation Report
The implementation report for this specification may be found at:
http://www.ietf.org/IESG/Implementations/Mail-DISP-Implementation.txt
Protocol Quality
Ned Freed reviewed the document for the IESG.
RFC Editor Note
The IPR boilerplate is missing from the draft and needs to be added
before publication.
The title of section 11 should be changed from "references" to
"normative references".
The following references in the bibliography should be updated to
read:
[RFC-REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages", RFC 3462,
January 2003.
[RFC-DSN-SMTP] Moore, K., "SMTP Service Extension for Delivery Status
Notifications", RFC 3461, January 2003.
[RFC-DSN-FORMAT] Moore, K., and G. Vaudreuil, "An Extensible Format
for Delivery Status Notifications, RFC 3464, January 2003.
The example Reporting-UA line in section 3.2.1 should be changed to read:
Reporting-UA: pc.example.com; Foomail 97.1
The last paragraph of section 3.3 should be changed to read:
If an application developer does not wish to register the meanings of
such extension fields, "X-" fields may be used for this purpose. To
avoid name collisions, the name of the application implementation
should follow the "X-" (e.g. "X-Foomail-fratzed").
The example in section 8.3 should be changed to read:
Date: Wed, 20 Sep 1995 00:19:00 (EDT) -0400
From: Joe Recipient <Joe_Recipient@example.com>
Message-Id: <199509200019.12345@example.com>
Subject: Disposition notification
To: Jane Sender <Jane_Sender@example.org>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=disposition-notification;
boundary="RAA14128.773615765/example.com"
--RAA14128.773615765/example.com
The message sent on 1995 Sep 19 at 13:30:00 (EDT) -0400 to Joe
Recipient <Joe_Recipient@example.com> with subject "First draft of
report" has been displayed. This is no guarantee that the message has
been read or understood.
--RAA14128.773615765/example.com
Content-type: message/disposition-notification
Reporting-UA: joes-pc.cs.example.com; Foomail 97.1
Original-Recipient: rfc822;Joe_Recipient@example.com
Final-Recipient: rfc822;Joe_Recipient@example.com
Original-Message-ID: <199509192301.23456@example.org>
Disposition: manual-action/MDN-sent-manually; displayed
--RAA14128.773615765/example.com
content-type: message/rfc822
[original message optionally goes here]
--RAA14128.773615765/example.com--
Implementation Report for Message Disposition Notifications (MDNs)
moving to Draft Standard
MDN implementation breaks down into three separate areas:
[1] Client support for sending MDN requests.
[2] Client support for acting on MDN requests and sending MDNs.
[3] Client support for rendering of MDNs.
These numbers will be used as labels throughout this report.
MDNs are a client to client protocol; apart from transporting MDN request
headers and MDN messages, message submission, transfer, and delivery agents
are not directly involved in the implementation of MDN. MDN request headers
and MDN messages are designed so that any message submission, transfer, or
delivery implementation that complies with the associated messaging
standards (RFC 822, SMTP, ESMTP, and MIME) can be used.
MDNs are constructed as MIME multipart objects. This means that any agent
that conforms to the MIME specification is capable of displaying an MDN in a
reasonable fashion.
Several desktop clients send MDN requests [1] and generate MDNs [2]. Fewer
interpret the MDNs in a mechanical fashion [3]. VPIM systems and desktop
messaging clients do interpret MDNs, although the extent to which they do so
varies.
However, several specific MDN options defined in RFC 2298 have not seen
implementation or deployment and have been removed from the current draft:
The dispositions "denied", and "failed" were removed from the document
reflecting the lack of implementation or usage at this time.
The disposition modifiers "warning", "superseded", "expired", and
"mailbox-terminated" have not seen actual implementation and have been
deleted from the draft. The extension modifier, while not currently
used, has been retained for future extensibility.
The MDN specification has been implemented by a number of VPIM vendors,
including Comverse, Lucent, and Nortel. These implementations request MDNs
[1], generate MDNs [2], and machine interpret and render MDNs for the user
[3] in the form of a spoken notification. General VPIM implementation
results including MDN testing are posted on http://www.vpim.org/vpim.
The specification is also implemented by several simple mode fax vendors
including Cisco, Ricoh, and Sharp. These implementations generate MDN
requests [1] and generate MDNs in response to MDN requests [2], but
generally display MDNs as uninterpreted text.
Various desktop clients have implemented MDNs, including Netscape Messenger,
Qualcomm Eudora, Microsoft Outlook, and Exmh. These clients are all capable
of generating MDN requests [1] and generate MDNs in response to such
requests [2]. These clients all rely on their ability to render MIME
messages in order to display MDNs; they do not implement MDN-specific
handling [3].
Finally, the message format validator operated by the applications area
available at:
http://www.apps.ietf.org/msglint.html
validates both MDN request headers [1] and MDNs themselves [3].
Detailed implementation results were provided for the revised version of the
MDN specification by Ned Freed for the SunOne Messaging Server, Simon
Josefsson for the Gnus MUA, and Greg Vaudreuil for the MessagingLink
gateway. These reports are summarized below.
Reports on the original specification were collected from MUA vendors
immediately following the London IETF (July/August 2001), from several iFAX
and VPIM vendors, and from third party testing of popular MUAs. These
results were used to prune the list of options in the current internet-draft
version of the MDN protocol and to create an earlier implementation report
for MDN. Regretfully, these original implementation reports were lost and
replacement implementation reports were not received from these vendors in
response to a second call for implementation reports on the IETF mailing
list.
--- Implementation result summary ---
(1) Date Implemented and released:
SunOne: Feature implemented over several releases, report for current
release 5.2.
Gnus, v0.05, January 2002
MessagingLink 2.1, 2000
(2) MDN Requesting Behavior
(a) Client sends disposition-notification-to header: (Y/N)
The Messenger Express client component of SunOne message server has the
ability to do this. Guns requests the header. MessagingLink converts a
request for MDN in the OctelNet protocol to this header when acting as a
gateway.
(b) Client sends disposition-notifications-options header (Y/N)
(b1) Client sends request for proprietary options (describe)
No implementations reported requesting proprietary
options extension headers.
(c) Message disposition header is placed in inner message when used
with message/partial. (Y/N/NA) Please indicate NA if the UA or gateway does
not generate message partial constructs
SunOne message server does this when messages are fragmented. The
opposite is also true: These fields are copied from the inner message to
the new message while defragmenting. Gnus and MessagingLink do not
fragment nor reassemble messages.
(3) Final MTA behavior
Final MTA (Delivery process) copies ORCPT parameter from RCPT-TO command
into Original-Recipient header of message upon deposit.
SunOne does this as long as the number and nature of the recipients
permit it. This behavior is not applicable to Gnus or MessagingLink.
Neither is responsible for final delivery.
(4) MDN Generating UA
(a) MDN report is generated upon request (Y/N). If yes, which fields
are populated:
Reporting-UA
mdn-gateway
original-recipient
final-recipient
original-message-id
disposition
failure
error
warning
extension fields
SunOne provides facilities for generating MDNs with all of these fields
are built in to the product. However, at present the two primary uses
are: (1) Displayed MDNs are generated by Messenger Express, which only
produces final-recipient, original-message-id, and disposition. (2)
Deleted MDNs are generated by the reject sieve action, which only
produces original-recipient, final-recipient, original-message-id,
and disposition.
Gnus does not generate MDN's.
MessagingLink provides the following fields when converting from
OctelNet: mdn-gateway, final-recipient, and disposition.
(b) Which disposition modes are supported / generated:
Manual action
automatic action
MDN-sent-manually
MDN-sent-automatically
SunOne generated all these modes in practice. Gnus does not generate
MDNs. MessagingLink generates only manual action and
MDN-sent-automatically, corresponding to the semantics of an OctelNet
MDN.
(c) Which disposition types are generated
displayed
deleted
SunOne generates both displayed and deleted types. Gnus does not
generate MDN's. MessagingLink generates both displayed and deleted
disposition types.
(d) Are any extension fields generated?
No implementations reported generating extension fields.
(5) MDN receiving user agent behavior
Which of the following fields are presented to the user or converted
into a foreign format via gateway
Reporting-UA
mdn-gateway
original-recipient
final-recipient
original-message-id
disposition
failure
error
warning
extension fields
In SunOne all of these fields can be displayed in the text of the MDN.
Facilities are also provided to do locale-specific conversion of
field labels. Gnus displays all fields as text. MessagingLink converts
the final recipient and disposition fields into the relevant OctelNet
protocol elements.
(6) Interoperability Experience
No interoperability problems were reported.
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-mealling-iana-xmlns-registry - The IETF XML
Registry to BCP
--------
Last Call to expire on: 2003-5-2
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ X ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ X ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
========
Bert:
- Section 2.1 states:
NOTE: in order for a URN of this type to be
assigned, the item being registered MUST have been through the IETF
concensus process. Practically this means it must be documented in
an RFC.
Given the confusion we have seen over what "IETF consensus" means, do
we want to keep the above or maybe define it better?
- Under publicid on page 2 it says:
In the case
where a PUBLIC Identifier is also a URI it is possible for the
SYSTEM Identifier to contain the same URI but this behavior is not
recommended unless its side effects are well known.
I think the intention is: "unless its side effect are well known and
understood to not cause any unacceptable harm" or some such, no?
Question:
- Sect 3, Registration Process explains how an XML file is being
stored. It does not talk at all about if or if so how such an XML
file will be validated to have correct syntax.
Given the experiens with MIB modules, I would hope that IANA gets
a tool to verify that such XML syntax is correct before a file
gets accepted. Should the document say something about that?
NITS:
- Page 3 under schema:
'urn:ietf:params:xml:schema:<id>'.
probably should be:
'urn:ietf:params:xml:schema:<id>'.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>,
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: The IETF XML Registry to BCP
-------------
The IESG has approved the Internet-Draft 'The IETF XML Registry'
<draft-mealling-iana-xmlns-registry-04.txt> as a BCP. This has been
reviewed in the IETF but is not the product of an IETF Working
Group. The IESG contact persons are Ned Freed and Ted Hardie.
Technical Summary
This document creates an IANA maintained registry of XML element
identifiers so that document authors and implementors have a well
maintained and authoritative location for their XML elements. As part
of this standard, the IANA will maintain
o the public representation of the document,
o the URI for the elements if one is provided at the time of
registration,
o a registry of Public Identifiers as URIs.
Working Group Summary
This document is not the product of an IETF Working group, but it
has been reviewed within the IETF.
Protocol Quality
This document was reviewed for the IESG by
the XML directorate.
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-ccamp-gmpls-architecture - Generalized
Multi-Protocol Label Switching Architecture to Proposed Standard
--------
Last Call to expire on: 2003-4-10
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ X ] [ ] [ ]
Steve Bellovin [ ] [ ] [ X ] [ ]
Randy Bush [ ] [XX ] [ X ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ X ]
Russ Housley [ ] [ ] [ X ] [ ]
Allison Mankin [ ] [ X ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ D ]
Erik Nordmark [ ] [ X ] [ ] [ ]
Jon Peterson [ ] [ X ] [ ] [ ]
Bert Wijnen [ X ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ X ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
========
Russ:
Two minor comments:
1. Section 4.3, 4th paragraph says: "Forwarding Adjacencies (FA) are
further described in a separate section." It would be nice to say
which one.
2. Section 15, please change "IPSEC" to "IPsec."
Steve:
Nit: section 4 says
Re-using existing IP routing protocols allows for non-PSC layers
to take advantages of all the valuable developments that took
place since years for IP routing,
which isn't grammatically correct.
The Security Considerations section hints at, but doesn't follow
through with, the difference between authentication and authorization.
The requirement for cryptographic authentication or encryption
depends on the risk of attackers being able to inject and/or snoop
on traffic. This may or may not be correlated with intra-domain vs.
inter-domain GMPLS. The physical characteristics and exposure of the
link matter more; there may be additional exposure since it appears
that the control plane link may be more than one hop long.
The authorization question is what resources a given node may request
of another. This may indeed be differ for inter-domain and
intra-domain GMPLS. On the other hand, imposing such limits even
internally helps guard against spreading break-ins, and has useful
effects with regard to configuration errors.
The more important question raised by this latter point is whether or
not a security architecture is needed that specifies what sorts of
restrictions can be applied. I don't know the answer to that one;
clearly, though, implementors are going to have to decide.
COMMENTS:
=========
Ted:
This abstain falls under the category:
> I oppose this document for some philosophical reason but
> understand that others differ and am not going to stand
> in the way of the others
The philosophical reason here is that the document
has addressing fundamentally wrong. This almost
certainly isn't fixable now, so I will not stand in the way.
Bert:
Revision 06 (on agenda for coming Wednesday) has:
-: 56 pages longer than 58 lines, max 59 lines
RFC-Editor, can we assume that you can deal with that?
Harald:
note: this does not mean that I like it.....
In particular, I don't like the fact that the document can't decide
whether it's an architecture, an introduction or a specification. It
goes into lots of details that are ALMOST specified, but then just says
that these are "finished elsewhere" - sometimes giving, sometimes not
giving, the forward pointers.
It's just about right (although overly detailed, and lacking some
pointers to where the "real spec" is) for an introduction.
It also *contains* an architecture description - the idea of a control
plane that is a fully connected IP network (with, apparently, manual
link configuration), a set of links that are not necessarily the
control links, and in many cases not even IP-capable links, and
groupings of these that can be manipulated and controlled in various
ways, and a set of protocols and ways to use those protocols that are
defined in other documents.
But the lenght and the level of detail means that it's very hard for
me to be sure I have grasped that architecture correctly and fully.
And - note - I have said nothing about whether or not I *like* that
architecture.
Note: It will be a while before this is published as an RFC. There are
no less than thirteen "works in progress" in its normative references.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, ccamp@ops.ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching
Architecture to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Generalized Multi-Protocol
Label Switching Architecture'
<draft-ietf-ccamp-gmpls-architecture-05.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement
Plane Working Group. The IESG contact persons are Bert Wijnen and
Alex Zinin.
Technical Summary
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.
This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
Working Group Summary
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
Protocol Quality
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-sipping-basic-call-flows - Session
Initiation Protocol Basic Call Flow Examples to BCP
--------
Last Call to expire on: 2002-12-8
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ X ] [ ] [ ]
Steve Bellovin [ ] [ ] [ X ] [ ]
Scott Bradner [ X ] [ ] [ ] [ ]
Randy Bush [ ] [ X ] [ ] [ ]
Patrik Faltstrom [ ] [ ] [ X ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Allison Mankin [ X ] [ ] [ ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jeff Schiller [ ] [ X ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
========
Patrik:
Discuss a: Domain names used in examples should be changed.
Discuss b: Should not use of ENUM be mentioned, so people understand
where to use it? I.e. when making call from PSTN to SIP, or from SIP to
SIP (where destination is E.164 number) an ENUM lookup should be done
(according to discussions in ENUM wg).
Steve:
Why is this BCP instead of Informational? (This is the grounds for my
DISCUSS, and it's a real "discuss", i.e., let's talk about it. Assume
that it will be lifted after the call.)
I think I'd prefer to omit the endorsement of IPsec in the Security
Considerations section. Yes, it's sort-of mentioned in 3261, but very
barely. But I can live with it being there.
COMMENTS:
=========
Scott:
references need to be split in draft-ietf-sipping-basic-call-flows-01.txt
Allison:
Why is this BCP instead of Informational? (This is the grounds for my
DISCUSS, and it's a real "discuss", i.e., let's talk about it. Assume that
it will be lifted after the call.)
Steve,
It's a BCP for two reasons:
1. To be usable by ITU as they cannot use our documents unless they
are standards track. It is very desirable for these flow docs to
be cited by ITU docs. 2. More idealistiically it actually does
represent "best common practices" - the flows are those that are
the selections among all possible that work the best and are
viewed as most sensible...
I think I'd prefer to omit the endorsement of IPsec in the Security
Considerations section. Yes, it's sort-of mentioned in 3261, but very
barely. But I can live with it being there.
I could see excising it with an RFC Editor note - it's pretty feeble.
I had missed it. There's a thread of IPsec story in SIP due to a Cisco
product theme, I think.
We're going to have an RFC Editor note for some other things anyway.
Thomas:
Allison Mankin <mankin@psg.com> writes:
> It's a BCP for two reasons:
Note that the document itself also says it is informational (per the
abstract)...
Also:
This document is informational only and is NOT NORMATIVE in any
sense, in that it does not prescribe the flows that are shown, indeed
they MUST NOT be copied due to the reasons described in the next
paragraph. On the other hand, the basic call flows represent well-
reviewed examples of SIP usage that are best common practice
according to community consensus.
It seems odd for a BCP to say it is NOT NORMATIVE...
> It's a BCP for two reasons:
> 1. To be usable by ITU as they cannot use our documents unless they
> are standards track. It is very desirable for these flow docs to
> be cited by ITU docs. 2. More idealistiically it actually does
> represent "best common practices" - the flows are those that are
> the selections among all possible that work the best and are viewed
> as most sensible...
I hear you, but on the surface, this just doesn't strike me as a BCP
document, at least not as the document currently reads.
If there was a better way to say the examples *are* the recommended
ways of doing certain (even common) things, that would have a better
justification for BCP. I.e., a bit more in the way of an applicability
section?
Also, split references?
Bert:
These ID-NITs are biting us again:
- draft-ietf-sipping-basic-call-flows-02.txt
-: 97 lines containing non-US-ASCII characters
possibly that is only in the footers
-: 85 lines longer than 72 characters, max 74
but those are only extraneous spaces
- There is no normative reference to RFC2119, while it is used.
Simple RFC-Editor note will fix.
- draft-ietf-sipping-pstn-call-flows-02.txt
-: 52 lines longer than 72 characters, max 74
but those are only extraneous spaces
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, sipping@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Session Initiation Protocol Basic Call Flow
Examples to BCP
-------------
The IESG has approved the following Internet-Drafts as BCPs:
o 'Session Initiation Protocol Basic Call Flow Examples'
<draft-ietf-sipping-basic-call-flows-01.txt>
o 'Session Initiation Protocol PSTN Call Flows'
<draft-ietf-sipping-pstn-call-flows-01.txt>
These documents are the product of the Session Initiation Proposal
Investigation Working Group. The IESG contact persons are Allison
Mankin and Scott Bradner.
Technical Summary
These documents have been developed to provide information on the
use of call flows in Session Initiation Protocol (SIP) networks.
The documents are designed to be used by SIP implementers,
designers, and protocol researchers to help further the goal of a
standard implementation of SIP.
These flows represent carefully checked and working group reviewed
scenarios of the most basic examples as a companion to the
specifications.
The "Basic Call Flow Examples" document gives examples of basic SIP
call flows. Elements in these call flows include SIP User Agents and
Clients, SIP Proxy and Redirect Servers. Scenarios include SIP
Registration and SIP session establishment.
The "PSTN Call Flows" document provides examples of SIP interworking
with the PSTN through gateways. Elements in these call flows include
SIP User Agents, SIP Proxy Servers, and PSTN Gateways. Scenarios
include SIP to PSTN, PSTN to SIP, and PSTN to PSTN via SIP. PSTN
telephony protocols are illustrated using ISDN (Integrated Services
Digital Network), ISUP (ISDN User Part), and FGB (Feature Group B)
circuit associated signaling. PSTN calls are illustrated using global
telephone numbers from the PSTN and private extensions served on by
a PBX (Private Branch Exchange).
Call flow diagrams and message details are shown in both documents.
Working Group Summary
The working group supported the publication of these documents as BCPs.
Protocol Quality
These documents were reviewed for the IESG by Allison Mankin.
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-yergeau-rfc2279bis - UTF-8, a
transformation format of ISO 10646 to Standard
--------
Last Call to expire on: 2003-3-21
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ X ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>, Internet Architecture Board
<iab@iab.org>,
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: UTF-8, a transformation format of ISO 10646
to Standard
-------------
The IESG has approved the Internet-Draft 'UTF-8, a transformation
format of ISO 10646' <draft-yergeau-rfc2279bis-04.txt> as a Standard.
This has been reviewed in the IETF but is not the product of an IETF
Working Group. The IESG contact person is Ted Hardie.
Technical Summary
This document updates the specification of UTF-8,
an encoding of the UCS which is designed to be
compatible with many current applications and protocols. UTF-8
has the characteristic of preserving the full US-ASCII range,
providing compatibility with file systems, parsers and other software
that rely on US-ASCII values but are transparent to other values.
This memo obsoletes and replaces RFC 2279.
Working Group Summary
This draft and the interoperability reports associated with it were
discussed
on the IETF-charsets@iana.org mailing list. Archives may be
found at http://lists.w3.org/Archives/Public/ietf-charsets/ among
other places.
Protocol Quality
This specification was reviewed for the IESG by Patrik Falstrom.
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-ccamp-lmp - Link Management Protocol
(LMP) to Proposed Standard
--------
Last Call to expire on: 2003-4-24
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ X ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
COMMENTS:
=========
Bert:
ID-NITS biting me too
Bad chars at 1870
-: 1 lines containing non-US-ASCII characters
RFC-Editor note:
Pls change on page 33, line 1870:
OLD:
(i.e., the link is not \xE6in service')
NEW:
(i.e., the link is not 'in service')
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, ccamp@ops.ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Link Management Protocol (LMP) to Proposed
Standard
-------------
The IESG has approved the Internet-Draft 'Link Management Protocol
(LMP)' <draft-ietf-ccamp-lmp-08.txt> as a Proposed Standard. This
document is the product of the Common Control and Measurement Plane
Working Group. The IESG contact persons are Bert Wijnen and Alex
Zinin.
Technical Summary
For scalability purposes, multiple data links can be combined to
form a single traffic engineering (TE) link. Furthermore, the
management of TE links is not restricted to in-band messaging, but
instead can be done using out-of-band techniques. This document
specifies a link management protocol (LMP) that runs between
neighboring nodes and is used to manage TE links. Specifically, LMP
will be used to maintain control channel connectivity, verify the
physical connectivity of the data links, correlate the link property
information, suppress downstream alarms, and localize link failures
for protection/restoration purposes in multiple kinds of networks.
Working Group Summary
The WG has consensus on this document. In the beginning there was too
much SONET/SDH specific material in this document, but that has now
been moved out into a separate document.
Protocol Quality
This memo has been reviewed for the IESG by Bert Wijnen.
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-pkix-rfc2510bis - Internet X.509 Public
Key Infrastructure Certificate Management Protocols to
Proposed Standard
--------
Last Call to expire on: 2003-2-24
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ X ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
COMMENTS:
=========
Bert:
ID-NITs biting again:
-: 346 lines longer than 72 characters, max 75
-: 1 pages longer than 58 lines, max 5337 lines
I suspect that my awk script does not recognize the
page separation here (guess they are not using the
normal pagination methods)
- Missing IPR statement
Other NITs:
- Possibly the reference to RFC2279 should be replaced with
a reference to draft-yergeau-rfc2279bis-04.txt, that is
assuming that we will approve it at this telechat
- Pls note that date on copyright statement on last page needs
to use 2003 instead of 2001 as the year.
I trust the security ADs to have properly checked the technical
content. Russ, did you actually check that ASN.1 material does
pass SYNTAX checker? I don;t have easy access to one at the
moment.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, ietf-pkix@imc.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Internet X.509 Public Key Infrastructure
Certificate Management Protocols to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Internet X.509 Public
Key Infrastructure - Certificate Management Protocol'
<draft-ietf-pkix-rfc2510bis-08.txt> as a Proposed Standard.
This document is the product of the PKIX Working Group.
Technical Summary
This document obsoletes RFC 2510.
This document describes the Internet X.509 Public Key Infrastructure
(PKI) Certificate Management Protocol (CMP). Protocol messages are
defined for X.509v3 certificate creation and management. CMP provides
on-line interactions PKI components, including an exchange between a
Certification Authority (CA) and a client system.
Working Group Summary
The Working Group came to consensus on this document.
Protocol Quality
This document was reviewed by Jeffrey I. Schiller for the IESG.
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-pkix-rfc2511bis - Internet X.509 Public
Key Infrastructure Certificate Request Message Format (CRMF)
to Proposed Standard
--------
Last Call to expire on: 2003-2-24
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ X ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, ietf-pkix@imc.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF) to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Internet X.509 Public
Key Infrastructure - Certificate Request Message Format (CRMF)'
<draft-ietf-pkix-rfc2511bis-06.txt> as a Proposed Standard.
This document is the product of the PKIX Working Group.
Technical Summary
This document obsoletes RFC 2511.
This document describes the Certificate Request Message Format (CRMF).
This syntax is used to convey a request for a certificate to a
Certification Authority (CA), possibly via a Registration Authority
(RA), for the purposes of X.509 certificate production. The request
will typically include a public key and associated registration
information.
Working Group Summary
The Working Group came to consensus on this document.
Protocol Quality
This document was reviewed by Jeffrey I. Schiller for the IESG.
Multiparty Multimedia Session Control (mmusic)
-------------------------------------
Last Modified: 2003-04-14
Chair(s):
Joerg Ott <jo@ipdialog.com>
Colin Perkins <csp@csperkins.org>
Transport Area Director(s):
Jon Peterson <jon.peterson@neustar.biz>
Allison Mankin <mankin@psg.com>
Transport Area Advisor:
Jon Peterson <jon.peterson@neustar.biz>
Mailing Lists:
General Discussion: mmusic@ietf.org
To Subscribe: mmusic-request@ietf.org
In Body: subscribe your_email_address
Archive: http://www.ietf.org/mailman/listinfo/mmusic
Description of Working Group:
The Multiparty MUltimedia SessIon Control (MMUSIC) Working Group (WG) was
chartered to develop protocols to support Internet teleconferencing and
multimedia communications. These protocols are now reasonably mature, and
many have received widespread deployment. The group is now focussed on the
revisions of these protocols in the light of implementation experience and
additional demands that have arisen from other WGs (such as AVT, SIP,
SIPPING, and MEGACO).
Multimedia communications protocols use a common platform for expressing
media and session descriptions. This is the Session Description Protocol,
SDP. The many uses of SDP have led to (requests for) numerous extensions and
have led to recognition of several flaws in the protocol design. In spite of
these, it is widely deployed.
- To support this current deployment, MMUSIC will revise SDP suitable
for publication as a Draft Standard RFC. This will involve correcting minor
bugs and clarifying the current specification.
- Various extensions to SDP will be pursued to remedy the most urgent
of SDP's shortcomings. These will be limited to use of SDP in conjunction
with connection-oriented media such as TCP and SCTP, offering support to
work with NATs and firewalls, exchange of media session security keys.
Apart from these, which are explicitly agreed to by the Area Directors and
shown in the milestones, only extensions within the existing framework of
SDP will be done (e.g. registering new codecs and defining parameters for
them extending SDP to include new address families).
To address the more fundamental issues with SDP, a next generation of SDP,
referred to as SDPng, has been in progress and will be continued towards a
Proposed Standard RFC. A requirements document will be devised that gathers
the requirements from the areas in which SDP is currently deployed.
MMUSIC will continue to maintain and revise the specification of the Real
Time Streaming Protocol (RTSP) based on implementation experience. The RTSP
specification will be revised to include various fixes and clarifications.
Depending on the changes, the revised RTSP specification will be re-issued
as either a Proposed or Draft Standard RFC. A MIB will be considered.
An Internet Media Guide (IMG) is a collection of multimedia session
descriptions expressed using SDP, SDPng or some similar session description
format. It is used to describe a collection of multimedia sessions (e.g.
television programme schedules). The IMG must be delivered to a potentially
large audience, who use it to join a subset of the sessions described, and
who may need to be notified of changes to the IMG.
MMUSIC will investigate work on delivery mechanisms for IMGs, generalizing
its work on session announcement and discovery protocols (SAP, RTSP, SIP).
We will investigate and document requirements for IMG delivery mechanisms,
and identify the requirements that these delivery mechanisms impose on the
session description formats used by the IMG. We will then work to produce a
framework document outlining the use of (existing) protocols to create an
IMG delivery infrastructure. After successful completion of these initial
milestones for IMG delivery, the MMUSIC working group will decide whether or
not MMUSIC is the proper place to pursue any needed mechanisms for IMGs, and
if so, recharter accordingly.
The MMUSIC work items will be pursued in close coordination with other IETF
WGs related to multimedia conferencing and IP telephony (AVT, SIP, SIPPING,
IPTEL, MEGACO). Where appropriate, new separate working groups may be split
off (as has happened with the SIP WG).
The Working Group is also charged with addressing security issues related to
the protocols it develops.
Goals and Milestones:
APR 03 Submit SDP source filter extensions for Proposed Standard
MAY 03 Submit draft on SDPng motivations, comparisons with current SDP
capabilities. Request charter review on SDPng work from IAB and
IESG.
JUL 03 Submit revised SDP spec for Proposed Standard
JUL 03 Submit IMG requirements and framework for Informational
JUL 03 Review work on IMGs and update charter accordingly
AUG 03 Submit SDPng base spec profile for Proposed Standard
OCT 03 Submit revised RTSP spec for Proposed or Draft Standard
(as appropriate)
OCT 03 Submit SDP Offer/Answer examples for Informational
NOV 03 Submit SDP security extension for Proposed Standard
NOV 03 Submit SDPng RTP profile spec for Proposed Standard
NOV 03 Submit SDPng audio profile spec for Proposed Standard
NOV 03 Submit SDPng video profile spec for Proposed Standard
DEC 03 Submit RTSP MIB for Proposed Standard
Network Configuration WG (netconf)
-----------------------------------------------------
Status: Proposed new WG
Chair(s):
???
???
Operations and Management Area Directors:
Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>
Operation and Management Area Advisor:
Bert Wijnen <bwijnen@lucent.com>
Mailing Lists: [ed. these will change to netconf*]
General Discussion: xmlconf@ops.ietf.org
To Subscribe: xmlconf-request@ops.ietf.org
in msg body: subscribe
Archive: http://ops.ietf.org/lists/xmlconf
Description of Working Group:
Configuration of networks of devices has become a critical requirement for
operators in today's highly interoperable networks. Operators from large to
small have developed or used vendor specific mechanisms to transfer
configuration data to and from a device, and for examining device state
information which may impact the configuration. Each of these mechanisms may
be different in various aspects, such as session establishment, user
authentication, configuration data exchange, and error responses.
The Netconf Working Group is chartered to produce a protocol
suitable for network configuration, with the following
characteristics:
- Provides retrieval mechanisms which can differentiate between
configuration data and non-configuration data
- Is extensible enough that vendors will provide access
to all configuration data on the device using a single protocol
- Has a programmatic interface (avoids screen scraping
and formatting-related changes between releases)
- Uses a textual data representation, that can be easily
manipulated using non-specialized text manipulation tools.
- Supports integration with existing user authentication methods
- Supports integration with existing configuration database systems
- Supports network wide configuration transactions (with features
such as locking and rollback capability)
- Is as transport-independent as possible
- Provides support for asynchronous notifications
The Netconf protocol will use XML for data encoding purposes,
because XML is a widely deployed standard which is supported
by a large number of applications. XML also supports
hierarchical data structures and multiple character sets.
The Netconf protocol should be independent of the data definition
language and data models used to describe configuration and
state data. However, the authorization model used in the protocol
is dependent on the data model. Although these issues must be
fully addressed to develop standard data models, only a small part
of this work will be initially addressed. This group will specify
requirements for standard data models in order to fully support the
Netconf protocol, such as:
- identification of principals, such as user names or
distinguished names
- mechanism to distinguish configuration from
non-configuration data
- XML namespace conventions
- XML usage guidelines
It should be possible to transport the Netconf protocol using
several different protocols. The group will select at least
one suitable transport mechanism, and define a mapping for
the selected protocol(s).
The initial work will be restricted to the following items:
- Netconf Protocol Specification, which defines the
operational model, protocol operations, transaction model,
data model requirements, security requirements, and transport
layer requirements.
- Netconf over <TBD> Specification, which defines how the
Netconf protocol is used with the transport protocol
selected by the group. There will be a document of
this type for each selected transport protocol.
The working group will base its work on the XMLCONF Configuration
Protocol <draft-enns-xmlconf-spec-00.txt>.
Goals and Milestones:
MAY 03 Working Group formed
JUL 03 Submit initial Netconf Protocol draft
AUG 03 Submit initial Netconf over <TBD> draft
DEC 03 Begin Working Group Last Call for the Netconf Protocol
draft
JAN 04 Begin Working Group Last Call for the Netconf over
<TBD> draft
MAR 04 Submit final version of the Netconf Protocol draft
to the IESG
APR 04 Submit final version of the Netconf over <TBD> draft
to the IESG
Internet Drafts
Request for Comments
LDAP Duplication/Replication/Update Protocols (ldup)
---------------------------------------------------
Chair(s):
Chris Apple <capple@dsi-consulting.net>
John Strassner <john.strassner@intelliden.com>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.com>
Ted Hardie <hardie@qualcomm.com>
Applications Area Advisor:
Ted Hardie <hardie@qualcomm.com>
Mailing Lists:
General Discussion: ietf-ldup@imc.org
To Subscribe: ietf-ldup-request@imc.org
In Body: subscribe
Archive: http://www.imc.org/ietf-ldup/
Description of Working Group:
As LDAPv3 becomes more widely deployed, replication of data
across servers running different implementations becomes an
important part of providing a distributed directory service.
However, the LDAPv3 community, to date, has focused on
standardizing the client-server access protocol. This group
was originally chartered to standardize master-slave and
multi-master LDAPv3 replication as defined below:
o Multi-Master Replication - A replication model where
entries can be written and updated on any of several
replica copies, without requiring communication with
other masters before the write or update is performed.
o Master-Slave, or Single-Master Replication - A replication
model that assumes only one server, the master, allows
write access to the replicated data. Note that
Master-Slave replication can be considered a proper
subset of multi-master replication.
Recently, the WG established consensus on a change of
direction to pursue publication of a standards track
protocol for LDAPv3 client synchronization, an experimental
LDAPv3 replication protocol, and supporting informational
documents. Thus the new work program is largely the same
as the original work program with one notable exception,
the LDAPv3 replication protocol is intended to be an
experimental rather than a standards track protocol.
The WG's approach was to first develop a set of requirements
for LDAPv3 directory replication and write an applicability
statement defining scenarios on which replication requirements
are based. An engineering team was formed consisting of different
vendors and the co-chairs in order to harmonize the existing
approaches into a single standard approach. All of these have
been accomplished during the pre-working group stage. It should
be noted, however, that replication using heterogeneous servers
is dependent on resolving access control issues, which were
the domain of other working groups. Because the responsible
WG failed to achieve consensus on a standard access control
model for LDAPv3, the LDUP WG formed a design team to explore
the issue of how to address the lack of such a model
in the context of LDAPv3 replication. This design team made
recommendations to the working group. The working group
considered these recommendations and consensus was
established on addressing these recommendations in
the context of revising other working group deliverables
rather than adding new deliverables specific to access
control for replication. Largely because of the lack of
a standard access control model for LDAPv3, the working
group also established consensus on pursuing an experimental
or informational publication path for a majority of working
group documents formerly intended to become proposed standards.
The new replication architecture supports all forms of
replication mentioned above. Seven areas of working group
focus have been identified through LDUP Engineering Team
discussions, each leading to one or more documents to be
published:
o LDAPv3 Replication Architecture
This documents a general-purpose LDAPv3 replication
architecture, defines key components of this architecture,
describes how these key components functionally behave,
and describes how these components interact with each
other when in various modes of operation
o LDAPv3 Replication Information Model
Defines the schema and semantics of information used to
operate, administer, maintain, and provision replication
between LDAPv3 servers. Specifically, this document will
contain common schema specifications intended to
facilitate interoperable implementations with respect to:
+ replication agreements
+ consistency models
+ replication topologies
+ managing deleted objects and their states
+ administration and management
o LDAPv3 Replication Information Transport Protocol
LDAPv3 extended operation and control specifications
required to allow LDAPv3 to be used as the transport
protocol for information being replicated
o LDAPv3 Replica Management
Specifications designed to support administration,
maintenance, and provisioning of replicas and
replication agreements. These specifications may
take the form of definitions for LDAPv3 extended
operations, controls, and/or new schema elements.
o LDAPv3 Update Reconciliation Procedures
Procedures for detection and resolution of conflicts
between the state of multiple replicas that contain
information from the same unit of replication.
o A General Usage Profile of the LDAPv3 Replication Architecture,
Information Model, Protocol Extensions, and Update Reconciliation
Procedures.
o LDAPv3 Client Update
A protocol that enables an LDAP client to
synchronize with the content of a directory
information tree (DIT) stored by an LDAP server
and to be notified about the changes to that
content.
The work being done in the LDUP WG should be coordinated
to the closest extent possible with similar work being done
in the ITU. This is necessary both because LDAP depends
on X.500 and because it makes sense from an operational
perspective.
Goals and Milestones:
Done Submit I-D on LDAPv3 Directory Replication Requirements.
Done Submit I-D on LDAPv3 Replication Information Model.
Done Submit I-D on LDAPv3 Update Reconciliation Procedures.
Done Revise I-D on LDAPv3 Directory Replication Requirements.
Done Revise I-D on LDAPv3 Replication Architecture.
Done Revise I-D on LDAPv3 Replication Information Model.
Done Submit I-D on LDAPv3 Replication Information Transport Protocol.
Done Revise I-D on LDAPv3 Replication Architecture.
Done LDAPv3 Directory Replication Requirements I-D goes to WG Last
Call as Informational.
Done Submit I-D on LDAPv3 Mandatory Replica Management.
Done Submit I-D on LDAPv3 Replication General Usage Profile.
Done LDAPv3 Client Update Protocol I-D goes to WG Last Call
as Proposed Standard.
Done Revise LDAPv3 Client Update Protocol I-D.
APR 03 Revise LDAPv3 Replication Information Model I-D.
APR 03 Revise LDAPv3 Client Update Protocol I-D.
MAY 03 Revise LDAPv3 Update Reconciliation Procedures I-D.
MAY 03 Revise LDAPv3 Replication Architecture I-D.
MAY 03 Revise LDAPv3 Replication Information Transport Protocol I-D.
MAY 03 Revise LDAPv3 Replica Management I-D.
MAY 03 LDAPv3 Client Update Protocol I-D goes to WG Last Call
as Proposed Standard.
JUN 03 Revise LDAPv3 Replication General Usage Profile I-D.
JUN 03 LDAPv3 Replication Information Model I-D goes to WG Last Call
as Informational.
JUN 03 LDAPv3 Replication Architecture I-D goes to WG Last Call
as Informational.
JUL 03 Revise LDAPv3 Update Reconciliation Procedures I-D.
JUL 03 Revise LDAPv3 Replication Information Transport Protocol I-D.
JUL 03 Revise LDAPv3 Replica Management I-D.
JUL 03 Evaluate Deliverables Status.
AUG 03 LDAPv3 Update Reconciliation Procedures I-D goes to WG Last Call
as Experimental.
AUG 03 LDAPv3 Replication Information Transport Protocol I-D goes to
WG Last Call as Experimental.
AUG 03 LDAPv3 Replica Management I-D goes to WG Last Call as
Experimental.
SEP 03 LDAPv3 Replication General Usage Profile I-D goes to WG Last
Call as Informational.
Management Issues:
Item name: AD-shepherded non-WG Info/Experimental documents
Writeup to be included in package:
RFC 2026 suggests that Info/Experimental non-WG documents "should"
come to the IESG via the RFC Editor. We've had some exceptions to
this; we need to describe what we do in such a way that the community
knows what to expect.
Suggested texts for a policy:
1)
When an AD decides that an Informational or
Experimental document is of particular importance to the
community, the AD may also choose to put it directly
before the IESG. This document will then be processed in
the same fashion as an Informational or Experimental
document from a working group.
2)
In some cases, an individual will ask an AD directly if they are
willing to shepherd a document through the IESG. This can happen,
for example, when an individual has already been discussing a
particular document with an AD because the topic of the document
naturally falls into a particular area. In such cases, the
document is processed in the same fashion as an Informational or
Experimental document from a working group.
_________________________________________________________________