[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Draft Package for Febuary 20, 2003 IESG Telechat
Please let us know if you notice any items listed on the agenda that
do not belong, or if any items are missing, and we will revise and
resend. Thanks.
-----------------------------------------------------------------
* DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT *
INTERNET ENGINEERING STEERING GROUP (IESG)
Agenda for the February 20, 2003 IESG Teleconference
1. Administrivia
o Roll Call
o Bash the Agenda
o Approval of the Minutes
- February 6, 2003
o Review of Action Items
OUTSTANDING TASKS
Last updated: February 12, 2002
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 Patrik to take action on elevating RFC2279 to Standard.
IP o Thomas to contact Cablelabs to discuss formal relationship
with IAB
IP o Allison to re-evaluate state of draft-malis-sonet-ces-mpls (Request).
Allison to send message to Andy.
IP o Ned to re-evaluate state of draft-tegen-smqp (Informational)
IP o Harald to compose note for draft-ietf-isis-traffic-04.txt.
IP o Scott and Allison to confer on draft-foster-mgcp-basic-packages
and return February 20, 2003 with discussion points.
IP o Ned to email Secretariat about draft-new-apex-server; Secretariat to
forward to RFC Editor.
IP o Harald to draft note regarding Zorn Formal Appeal Against IESG
decision. Secretariat to announce.
o Allison to send Secretariat message that draft-malis-sonet-ces-mpls
is resolved once she receives a reply.
o Steve Bellovin to find channel to firewall vendors wrt
draft-ietf-tsvwg-tcp-nonce-04.txt
o Allison to send Secretariat message that draft-malis-sonet-ces-mpls
is resolved once she receives a reply.
o Steve Bellovin to find channel to firewall vendors wrt
draft-ietf-tsvwg-tcp-nonce-04.txt.
DONE o Patrik to send IESG Statement about International Domain Names to
Secretariat. Secretariat to send to ietf-anounce and place on
iesg/statements page.
o Steve Bellovin to ask Matt Blaze to talk at San Francisco plenary
about privacy considerations.
o Bert to evaluate ownership statements in printer MIB.
o Harald to send note to Bob Braden about not adding names of STD.
o Secretariat to find and send response to Zorn appeal, add to website.
DONE o Ned to send OPES note and ICAP IESG notes to mailing list and WG, and
to send ticket to iesg-secretary.
2. Protocol Actions
o The UDP-Lite Protocol (Proposed Standard)
<draft-ietf-tsvwg-udp-lite-01.txt>
Token: Mankin, Allison
o NOPEER community for BGP route scope control (BCP)
<draft-ietf-ptomaine-nopeer-00.txt>
Token: Bush, Randy
Note: Responsible: Working Group
o Text string notation for Dial Sequences and GSTN / E.164 addresses
(Proposed Standard)
<draft-allocchio-gstn-04.txt>
Token: Faltstrom, Patrik
o RTP Payload Format for ETSI ES 201 108 Distributed Speech
Recognition Encoding (Proposed Standard)
<draft-ietf-avt-dsr-05.txt>
Token: Mankin, Allison
Note: A well-constructed payload with just the need of a few grammar
edits.
3. Working Group Submissions
o Wrapping an HMAC key with a Triple-DES Key or an AES Key (Proposed
Standard)
<draft-ietf-smime-hmac-key-wrap-01.txt>
Token: Schiller, Jeff
Note: Responsible: Jeff
o The Eifel Detection Algorithm for TCP (Experimental)
<draft-ietf-tsvwg-tcp-eifel-alg-07.txt>
Token: Bradner, Scott
4. Individual Submissions
o Private Session Initiation Protocol(SIP) Proxy-to-Proxy Extensions
for Supporting DCS (Informational)
<draft-dcsgroup-sipping-proxy-proxy-02.txt>
Token: Mankin, Allison
Note: For 2003-Feb-06 agenda - ballot not needed, it is an
Informational document that has had Expert Review by the SIPPING
working group.
5. Individual via RFC Editor
o Basic MGCP Packages (Informational)
<draft-foster-mgcp-basic-packages-09.txt>
Token: Bradner, Scott
6. Proposed Working Groups
o Network File System Version 4
Token: Scott
Note: Additional text and milestones
o IPSEC KEYing information resource record (ipseckey)
Token:Steve Belllovin
o Enhancements to Internet email to support diverse service
environments (lemonade)
Token: Ned
Note: New title: Enhancements to Internet email to support
diverse service environments (lemonade) and updated charter
o PROBLEM (problem)
Token: Harald
7. Working Group News We Can Use
8. IAB News we can use
9. Management Issues
o draft-iab-research-funding
DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT *
INTERNET ENGINEERING STEERING GROUP (IESG)
February 6, 2002
Reported by: Jacqueline Hargest, IETF Assistant Director
ATTENDEES
---------
Alvestrand, Harald / Cisco
Austein, Rob / IAB Liaison
Bellovin, Steve / AT&T Labs
Bradner, Scott / Harvard
Bush, Randy / IIJ
Cotton, Michelle / ICANN
Daigle, Leslie / Verisign (IAB)
Faltstrom, Patrik / Cisco
Fenner, Bill / AT&T
Freed, Ned / Innosoft
Hargest, Jacqueline / IETF
Mankin, Allison / Bell Labs, Lucent
Narten, Thomas / IBM
Nordmark, Erik / Sun
Reynolds, Joyce K. / ISI (RFC Editor)
Schiller, Jeff / MIT
Wijnen, Bert / Lucent
Zinin, Alex / Alcatel
REGRETS
-------
Coya, Steve / IETF
Minutes
-------
1. The minutes of the January 23, 2003 teleconference were approved.
Secretariat to place in public archives.
2. The following action items were reported as DONE:
o <draft-dfncis-netnews-admin-sys-04.txt> in Expert Review; Ned to
evaluate.
o Ned to write MIME and MEDIA TYPES Roadmap document
o Patrik to re-evaluate state of draft-irtf-idrm-handle-system (Informational)
o Erik to re-evaluate state of draft-jl-pcdp (Informational)
o Ned to re-evaluate state of draft-tiwari-appl-wxxx-forms (Informational)
o Thomas to get IESG's sign off for draft-stoica-diffserv-dps.
Secretariat to announce.
o Secretariat to have aliases for statements to ietf.org that goes
to ticket system.
o Secretariat to place 'lemonade' on new-work.
o Secretariat to note in minutes of January 9, 2003 that the IDR
Working Group was discussed and approved.
o Secretariat to send all liaison statements to ticketing system for
tracking.
o Secretariat to list all known meetings that overlap/conflict with
IETF on existing calendar.
o Secretariat to publish all liaison statements immediately.
o Secretariat to include all IETF Secretariat action items on this
list going forward.
3. Protocol Actions APPROVED:
The IESG approved publication of 'A Conservative SACK-based Loss Recovery
Algorithm for TCP' <draft-allman-tcp-sack-13.txt> as a Proposed Standard.
Secretariat to announce.
The IESG approved publication of 'Internet Printing Protocol/1.1: IPP URL
Scheme' <draft-ietf-ipp-url-scheme-05.txt> as a Proposed Standard.
Secretariat to announce.
The IESG approved publication of 'Link Selection sub-option for the Relay
Agent Information Option for DHCPv4' <draft-ietf-dhc-agent-subnet-selection-04.txt>
as a Proposed Standard. Secretariat to announce.
4. Document Actions APPROVED:
The IESG has approved the Internet-Draft 'Alternative OSPF ABR
Implementations' <draft-ietf-ospf-abr-alt-05.txt>' as an Informational
RFC. Secretariat to send announcement.
The IESG has approved the Internet-Draft 'Benchmarking Methodology for
Firewall Performance' <draft-ietf-bmwg-firewall-08.txt> as an
Informational RFC. Secretariat to send announcement.
The IESG has approved the Internet-Draft 'Mesh-enhanced Service
Location Protocol' <draft-zhao-slp-da-interaction-16.txt> as an
Experimental RFC. Secretariat to send announcement.
5. Document Action TENTATIVELY APPROVED:
o Robust ECN Signaling with Nonces (Experimental)
<draft-ietf-tsvwg-tcp-nonce-04.txt>
Note: Allison to send RFC Editor Note to Secretariat. Secretariat
to announce.
6. The following document is still under DISCUSSION:
o Guidelines for Writing RFC Text on Security Considerations (BCP)
<draft-iab-sec-cons-02.txt>
Note: Ned will send his discuss comments for the Secretariat to record.
7. The following document was deferred to the next telechat:
o Private Session Initiation Protocol(SIP) Proxy-to-Proxy Extensions
for Supporting DCS (Informational)
<draft-dcsgroup-sipping-proxy-proxy-02.txt>
8. Working Group Actions:
o IPSEC KEYing information resource record (ipseckey)
Note: Steve Bellovin will send revised text. Secretariat to send
WG Review message and send to new-work.
o PROBLEM (problem)
Token: Harald
Note: Secretariat to send WG Review message to ietf-announce and new-work.
9. No action was taken on the following document:
o IP over Optical Networks: A Framework (Informational)
<draft-ietf-ipo-framework-03.txt>
Note: This item was taken off the agenda.
10. NEW Action Items:
o Allison to send Secretariat message that draft-malis-sonet-ces-mpls
is resolved once she receives a reply.
o Steve Bellovin to find channel to firewall vendors wrt
draft-ietf-tsvwg-tcp-nonce-04.txt.
o Patrik to send IESG Statement about International Domain Names to
Secretariat. Secretariat to send to ietf-announce and place on
iesg/statements page.
o Steve Bellovin to ask Matt Blaze to talk at San Francisco plenary
about privacy considerations.
o Bert to evaluate ownership statements in printer MIB.
o Harald to send note to Bob Braden about not adding names of STD.
o Secretariat to find and send response to Zorn appeal, add to website.
o Ned to send OPES note and ICAP IESG notes to mailing list and WG, and
send ticket to iesg-secretary.
11. 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 Patrik to take action on elevating RFC2279 to Standard.
IP o Thomas to contact Cablelabs to discuss formal relationship
with IAB
IP o Allison to re-evaluate state of draft-malis-sonet-ces-mpls (Request).
Allison to send message to Andy.
IP o Ned to re-evaluate state of draft-tegen-smqp (Informational)
IP o Harald to compose note for draft-ietf-isis-traffic-04.txt.
IP o Scott and Allison to confer on draft-foster-mgcp-basic-packages
and return February 20, 2003 with discussion points.
IP o Ned to email Secretariat about draft-new-apex-server; Secretariat to
forward to RFC Editor.
IP o Harald to draft note regarding Zorn Formal Appeal Against IESG
decision. Secretariat to announce.
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-tsvwg-udp-lite - The UDP Lite Protocol
to Proposed Standard
--------
Last Call to expire on: May 15, 2002
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Scott Bradner [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Patrik Faltstrom [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Allison Mankin [ X ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jeff Schiller [ ] [ ] [ ] [ ]
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>, tsvwg@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: The UDP Lite Protocol to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'The UDP Lite Protocol'
<draft-ietf-tsvwg-udp-lite-01.txt> as a Proposed Standard. This
document is the product of the Transport Area Working Group Working
Group. The IESG contact persons are Allison Mankin and Scott Bradner.
Technical Summary
This document describes the UDP-Lite protocol, which is similar to
UDP (RFC 768), but can also serve applications that in error-prone
network environments prefer to have partially damaged payloads
delivered rather than discarded. If this feature is not used, UDP-
Lite is semantically identical to UDP. UDP-Lite provides a checksum
with optional partial coverage. When using this option, a packet is
divided into a sensitive part (covered by the checksum) and an
insensitive part (not covered by the checksum). Errors in the
insensitive part will not cause the packet to be discarded by the
transport layer.
Working Group Summary
The Transport Working Group supported advancement of this
specification. There was Last Call dissent about two aspects: first,
its original plan of being a variant of UDP itself. The response was
to develop the protocol as a separate transport protocol, which has
better properties in general. Second, there were questions about the
applicability. For this, the debate was referred to the authors' more
detailed conference paper on audio use of errored data. The flexibility
of UDP-Lite is not for broad classes of applications, but the conclusion
was that it has utility for a significant class of cellular uses now and
should be advanced.
Protocol Quality
The protocol was reviewed for the IESG by Allison Mankin. There have
been implementations for a number of years and many experimental trials.
RFC Editor Notes:
RFC Editor, please replace "[RFC-768]" with "(RFC 768)" in the
Abstract.
RFC Editor, please add before the Copyright Notice a section headed
"IPR Notices", containing RFC 2026, Sections 10.4 (A) and 10.4(B)
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-ptomaine-nopeer - NOPEER community for
BGP route scope control to BCP
--------
Last Call to expire on: 2002-11-17
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
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 [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS
=======
Steve: This is a real DISCUSS -- i.e., I want to talk about it.
The Security Considerations section is a bit scary. It says, in
effect, "this makes an existing attack worse". Do we really want that?
Absent something like sbgp, one defense is monitoring AS paths to
important destinations -- this can, to some extent, prevent such
monitoring.
In a separate vein, routing games are useful adjuncts to eavesdropping
and MITM attacks (if no crypto us used), not just DoS attacks. That
should be clarified.
Scott: note - this ID talks about a "proposal" but when its published as a BCP
its more than a proposal
my issue can be cleared with the following (conceptual) RFC Ed note
dear RFC Ed please
s/2. Proposal/2. NOPEER attribute/
s/The proposal/This memo/
s/The approach proposed here/The approach descibed here/
(I may have missed a few)
change Security considerations to
"The IANA should register NOPEER as a new BGP well-known transitive
community field"
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, ptomaine@shrubbery.net
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: NOPEER community for BGP route scope control
to BCP
-------------
The IESG has approved the Internet-Draft 'NOPEER community for BGP
route scope control' <draft-ietf-ptomaine-nopeer-00.txt> as a BCP.
This document is the product of the Prefix Taxonomy Ongoing Measurement
& Inter Network Experiment Working Group. The IESG contact persons are
Randy Bush and Bert Wijnen.
Technical Summary
This document proposes the use of a BGP community to advise BGP
peers and others on the scope of propagation the originating AS
intended for a prefix. This proposed well-known advisory
transitive community is intended to allow an origin AS to specify
the extent to which it suggests that a specific prefix should be
externally propagated. In particular this community, termed here
as NOPEER, allows an origin AS to suggest that a route with this
attribute need not be advertised across bilateral peer
connections.
Working Group Summary
There were no technical issues raised in working group discussion
or working group last call.
Protocol Quality
This document was reviewed for the IESG by Randy Bush.
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-allocchio-gstn - Text string notation for
Dial Sequences and GSTN / E.164 addresses to Proposed Standard
--------
Last Call to expire on: August 6, 2002
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Scott Bradner [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Patrik Faltstrom [ X ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jeff Schiller [ ] [ ] [ ] [ ]
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: Text string notation for Dial Sequences and
GSTN / E.164 addresses to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Text string notation for Dial
Sequences and GSTN / E.164 addresses' <draft-allocchio-gstn-04.txt> as
a Proposed Standard.
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
Patrik Faltstrom.
Technical Summary
The document describes the full set of notations needed to represent in
a text string a Dial Sequence. A Dial Sequence is normally composed by
Dual Tone Multi Frequency (DTMF) elements plus separators and the
additional "actions" (such as "wait for dialtone", "pause for N secs",
etc.) which could be needed to successfully establish the connection
with the target service: this includes the cases where subaddresses or
DTMF menu navigation apply. Global Switched Telephone Numbers (GSTN) /
E.164 addresses (commonly called "telephone numbers") are a subset of a
Dial Sequence, and thus use the same set of notations.
Working Group Summary
This is not the product of any working group in the IETF, but it has
been reviewed in the working groups which deal with E.164 numbers of
any kind. In version 03 (which was last called), there were some
misunderstandings what this document specified, and this is cleared up
in version 04.
This document is a compilation of syntaxes used in email, fax and URL
definitions, and is not supposed to replace any of those
specifications, but instead be a clear definition using ABNF on the
syntax used.
Protocol Quality
The spec 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-ietf-avt-dsr - RTP Payload Format for ETSI
ES 201 108 Distributed Speech Recognition Encoding to Proposed
Standard
--------
Last Call to expire on: 2003-2-14
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Scott Bradner [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Patrik Faltstrom [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Allison Mankin [ X ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jeff Schiller [ ] [ ] [ ] [ ]
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>, avt@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: RTP Payload Format for ETSI ES 201 108
Distributed Speech Recognition Encoding to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'RTP Payload Format for
ETSI ES 201 108 Distributed Speech Recognition Encoding'
<draft-ietf-avt-dsr-05.txt> as a Proposed Standard. This document is
the product of the Audio/Video Transport Working Group. The IESG
contact persons are Allison Mankin and Scott Bradner.
Technical Summary
This document specifies an RTP payload format for encapsulating ETSI
Standard ES 201 108 front-end signal processing feature streams for
distributed speech recognition (DSR) systems. The use of RTP enables
the distributed systems scenarios to be broader. The payload consists
of concatenated Frame Pairs (FP) of the ETSI-defined inputs, and
guidance is provided on the size and timing issues of placing the voice
recognition signals in the RTP payloads.
Besides defining the payload, the document specifies and registers the
MIME subtype audio/dsr-es201108.
Working Group Summary
The Transport Working Group supported advancement of this
specification.
Protocol Quality
The protocol was reviewed for the IESG by Allison Mankin.
RFC Editor Note:
RFC Editor, please add after the References a section titled
"Copyright Notice," containing RFC 2026, Section 10.4 (C), followed
by a section titled "IPR Notices", containing RFC 2026, Sections
10.4 (A) and 10.4(B)
Network File System Version 4 (nfsv4)
-------------------------------------
Charter
Last Modified: 2003-02-09
Current Status: Active Working Group
Chair(s):
Brian Pawlowski <beepy@netapp.com>
Robert Thurlow <robert.thurlow@sun.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@psg.com>
Transport Area Advisor:
Scott Bradner <sob@harvard.edu>
Mailing Lists:
General Discussion:nfsv4-wg@sunroof.eng.sun.com
To Subscribe: majordomo@sunroof.eng.sun.com
Archive: http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive
Description of Working Group:
The objective of this working group is to advance the state of NFS
technology by producing specifications to extend the original NFS
Version 4 work (RFC 3010) to provide additional capabilities, as
described below.
o NFS version 4
Advance the protocol along the standards track, coordinating the
development of test suites to provide a high level of implementation
quality. The ONC RPC standards that NFSv4 references must also be
advanced. This includes work to make NFSv4 and the underlying ONC RPC
protocol compatible with IPv6. Specifically, we will advance RFC
3010, RFC 1831, RFC 1833 and RFC 2203 to Draft Standard. The working
group will help advance related security RFCs, specifically through
the definition of a method to advance APIs.
o Replication and Migration
The original working group defined a mechanism for NFS clients and
servers to support replication and migration of data transparently
to an application. Left undefined in the initial work was the
server back end migration and replication mechanism. The working
group will produce a draft submission of a replication/migration
protocol that supports NFS Version 4 clients - needed to create and
maintain replicated filesystems as well as migrating filesystems
from one location to another - and servers for consideration as
Proposed Standard.
o Management
The working group will produce a draft submission for consideration
as Proposed Standard of a management MIBs to provide better
management and administration capabilities for NFS and ONC RPC.
o Minor Versions
NFS Version 4 contains within it the capability for minor versioning.
Some discussions within the working group suggest addressing
additional requirements over the original charter. The WG will work
to identify additional requirements for NFSv4 and determine if they
are appropriate and worthwhile for a minor version. This work may
lead to proposals for additional work items. If it does a specific
proposal to add these work items to the charter will be forwarded to
the IESG and IAB.
=================================================
NEW CHARTER WORDING ADDITION:
o RDMA/RDDP enabling
The performance benefit of RDMA/RDDP transports in NFS-related
applications, by reducing the overhead of data and metadata
exchange, has been demonstrated sufficiently such that the
working group will pursue in parallel enabling NFS and RPC over
the transport defined by the RDDP working group. The WG will
restrict its initial activities to defining the problem
statement and specifying the requirements for possible
extensions to RPC and NFS (in the context of a minor
revision).
=================================================
Goals and Milestones:
Done Issue strawman Internet-Draft for v4
Done Submit Initial Internet-Draft of requirements document
Done Submit Final Internet-Draft of requirements document
Done AD reassesses WG charter
Done Submit v4 Internet-Draft sufficient to begin prototype implementations
Done Begin Interoperability testing of prototype implementations
Done Submit NFS version 4 to IESG for consideration as a
Proposed Standard.
Done Conduct final Interoperability tests
Done Conduct full Interoperability tests for all NFSv4 features
Done Update API advancement draft
Done Form core design team to work on NFS V4
migration/replication requirements and protocol
Done Submit revised NFS Version 4 specification (revision to RFC
3010) to IESG for consideration as a Proposed Standard
OCT 02 ADs to submit API advancement internet draft as
informational RFC (needed to advance GSSAPI to Draft
Standard to allow advancement of NFS Version 4)
OCT 02 Strawman NFS V4 replication/migration protocol proposal
submitted as an ID
NOV 02 Internet draft on NFS V4 migration/replication requirements
NOV 02 AD review of NFS V4 migration/replication requirements
draft
DEC 02 Creation of internet draft on ONC RPC MIB
DEC 02 Revision of internet draft on NFS MIB
DEC 02 Depending on results of AD review of NFS Version 4
migration/replication requirements document, review scope
of task
FEB 03 Submit related Proposed Standards required by NFS Version 4
for consideration as Draft Standards to IESG - RFCs 1831,
1833, 2203, 2078, 2744, RFC 1964, & 2847
MAR 03 Continued interoperability testing of NFS Version 4
MAY 03 Document full Interoperability tests for all NFSv4 features
MAY 03 Interoperability tests of NFS V4 migration/replication
MAY 03 Submit an NFS V4 migration/replication protocol to IESG for
consideration as a Proposed Standard
MAY 03 Submit ONC RPC and NFS MIBs to IESG for consideration as
Proposed Standards
JUN 03 Submit report on results of interoperability testing
AUG 03 Submit revised NFS Version 4 Proposed Standard for
consideration as Draft Standard to IESG
=================================================
NEW MILESTONES
FEB 03 ADs to submit API advancement internet draft as
nformational RFC (needed to advance GSSAPI to Draft
Standard to allow advancement of NFS Version 4)
DONE Strawman NFS V4 replication/migration protocol
proposal submitted as an ID
FEB 03 Internet draft on NFS V4 migration/replication requirements
FEB 03 AD review of NFS V4 migration/replication requirements draft
FEB 03 Creation of internet draft on ONC RPC MIB
JAN 03 Revision of internet draft on NFS MIB
JUN 03 Depending on results of AD review of NFS Version 4
migration/replication requirements document, review
scope of task
FEB 03 Draft problem statement I-D for NFS/RPC/RDDP submitted
JUN 03 Submit related Proposed Standards required by NFS
Version 4 for consideration as Draft Standards to
IESG - RFCs 1831, 1833, 2203, 2078, 2744, RFC 1964, & 2847
MAR 03 Continued interoperability testing of NFS Version 4
MAR 03 Draft requirements document I-D for NFS/RPC/RDDP submitted
APR 03 AD review of NFS/RPC/RDDP progress and charter
MAY 03 Document full Interoperability tests for all NFSv4 features
JUL 03 Interoperability tests of NFS V4 migration/replication
JUN 03 Submit an NFS V4 migration/replication protocol to
IESG for consideration as a Proposed Standard
JUN 03 Submit ONC RPC and NFS MIBs to IESG for consideration as
Proposed Standards
JUN 03 Submit report on results of *NFS VERSION 4 RFC*
interoperability testing
AUG 03 Submit revised NFS Version 4 Proposed Standard for
consideration as Draft Standard to IESG
IPSEC KEYing information resource record (ipseckey)
---------------------------------------------------
Charter
Last Modified: 2003-02-10
Current Status: Active Proposed Working Group
Chair(s): TBA
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Steven Bellovin <smb@research.att.com>
Security Area Advisor:
Steven Bellovin <smb@research.att.com>
Mailing Lists:
General Discussion:ipseckey@sandelman.ca
To Subscribe: ipseckey-request@sandelman.ca
Archive: http://www.sandelman.ca/lists/html/ipseckey/
Description of Working Group:
This effort has the goal of designing a IPSEC-specific resource
record for the domain name system (DNS) to replace the functionality
of the IPSEC sub-type of the KEY resource record.
The original DNSSEC specification explicitly specified flags on
the KEY resource records for use by IPSEC. Experience has shown that
this has operational problems. The DNSEXT working group is restricting
the use of the KEY record to DNS uses only. Thus, IPSEC keying via
DNS needs a new resource record.
The scope of work is to identify what information is needed in an
IPSEC-specific keying resource record. The content of the resource
record are not limited to only the information that is in the DNS
KEY record but may also contain useful IPSEC information information,
such as that which is required for Opportunistic Encryption. Other
possible uses are out of scope for this working group, since any
reuse will require a careful analysis of the trust model and possible
security interactions with IPsec.
The WG will define the semantics of the record only in terms of
how the data in the record can be used for initializing an IPSEC
session. Questions of when it is appropriate to do so are regarded
as policy issues that are out of scope for this WG.
This effort is specific to providing IPSEC information in DNS.
All other distribution channels are out of scope.
Goals and Milestones:
MAR 03 Solicit various proposals on what information is needed in
IPSEC specific KEYing record
APR 03 Publish first Internet-Draft of consensus DNS Resource
Record
MAY 03 Complete WG Last Call on consensus DNS RR proposal document
and pass document to IESG for consideration as a Proposed
Standard
Enhancements to Internet email to support diverse service environments (lemonade)
---------------------------------------------------------------------------------
Charter
Last Modified: 2003-01-31
Current Status: Active Proposed Working Group
Chair(s):
Glenn Parsons <gparsons@nortelnetworks.com>
Eric Burger <eburger@snowshore.com>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.com>
Patrik Faltstrom <paf@cisco.com>
Applications Area Advisor:
Ned Freed <ned.freed@mrochek.com>
Mailing Lists:
General Discussion:um@snowshore.com
To Subscribe: majordomo@snowshore.com
In Body: subscribe um
Archive: http://flyingfox.snowshore.com/um_archive/maillist.html
Description of Working Group:
Lemonade is tasked to provide a set of enhancements and profiles of
Internet email submission, transport, and retrieval protocols to
facilitate operation in environments which use Internet-based
technologies but which have link characteristics, device
characteristics, or service environments that are significantly
different from those common on the Internet. A primary goal of this work
is to ensure that those profiles and enhancements continue to
interoperate with the existing Internet email protocols in use on the
Internet, so that these environments and more traditional Internet
users have access to a seamless service.
Lemonade's work is at the crossroads of a body of work related to
Internet messaging, in particular work done by the VPIM, FAX, IMAPEXT
and other IETF working groups. Given the potentially broad scope of
activities this group could engage in, the group will focus
specifically on the following work items:
0. An informational RFC will be produced on LEMONADE requirements.
1. Enhance the existing IMAP4 message retrieval protocol to satisfy
the requirements for streaming playback of multimedia content.
2. Enhance the exsiting IMAP4 message retrieval protocol to facilitate
its use with devices that have limited capabilities such as mobile
endpoints. The existing standards-track CONNEG framework will be
used if content negotiation capabilities are needed.
3. Create a message notification protocol for the specific purpose of
servers reporting message status information to other servers.
4. Create a specification describing the use of Internet message
services in environments where message delivery may take place using
either Internet protocols or through an MMS server using
WAP to communicate with the receiving user agent.
Any protocols defined by this working group will include appopriate
security mechanisms, including authentication, privacy, and access
control. Mandatory-to-implement security mechanisms will be specified
as needed in order to guarantee secure protocol interoperability.
The transport area will be consulted to deal with any transport-related
issues that arise, especially in regards to items 1-4 above.
The working group is aware of several related activities in other groups:
- 3GPP TSG T WG2 SWG3 Messaging (http://www.3gpp.org/TB/T/T2/T2.htm)
- W3C Mulitmodal interaction Activity (http://www.w3.org/2002/mmi/)
- Open Mobile Alliance (http://www.openmobilealliance.org/)
- 3GPP2 TSG-P (http://3gpp2.org/Public_html/P/index.cfm)
- 3GPP2 TSG-N (http://3gpp2.org/Public_html/N/index.cfm)
The goal is to coordinate efforts with at least these groups as required.
While there is obvious synergy, given the end-of-life of the VPIM and
FAX work groups and the similar membership, the working group does not
expect to coordinate with these other groups.
Drafts to be used as input for working group deliverables (grouped per
milestone):
LEMONADE requirements
- draft-vaudreuil-um-issues-00.txt
- draft-burger-um-reqts-00.txt
- draft-wong-umcli-00.txt
Server to server notification protocol
- draft-shapira-snap-04.txt
IMAP4 extensions for VM playback
- draft-burger-imap-chanuse-00.txt
- draft-nerenberg-imap-channel-01.txt
IMAP4 extensions for mobile devices
- draft-neystadt-imap-status-counters-00.txt
- draft-shveidel-mediasize-00.txt
Translation to and from other messaging systems
- draft-vaudreuil-futuredelivery-00.txt
Goals and Milestones:
FEB 03 LEMONADE Requirements
MAY 03 Server to server notification protocol
JUL 03 IMAP extensions for VM playback
SEP 03 IMAP extensions for mobile devices
JAN 04 Translation to and from other messaging systems
Problem Statement (problem)
---------------------------
Charter
Last Modified: 2003-01-31
Current Status: Active Proposed Working Group
Chair(s):
Avri Doria <avri@acm.org>
Melinda Shore <mshore@cisco.com>
General Area Director(s):
Harald Alvestrand <harald@alvestrand.no>
General Area Advisor:
Harald Alvestrand <harald@alvestrand.no>
Mailing Lists:
General Discussion:problem-statement@alvestrand.no
To Subscribe: problem-statement-request@alvestrand.no
Archive: http://www.alvestrand.no/pipermail/problem-statement/
Description of Working Group:
Discussions during 2002 have revealed a significant number of thoughts
about problems that exist with the way the IETF operates. In advance of
trying to change the IETF procedures and rules to deal with these
problems, the IETF should have a clear, agreed description of what
problems we are trying to solve.
This group is charged with producing the document describing these
problems. The analysis of the problem should seek out the root causes
of the problems as well as the perceived derivative problems.
The intent is that the group will discuss issues on its mailing list,
and that there will be an editing team to produce a clear concise
problem statement on which the group has come to consensus and present
to the IETF as a basis for an IETF consensus.
As a second work item, the group will also produce a proposal for a
process to develop solutions to the problems identified by this working
group.
It is not a part of this group's charter to propose solutions to the
problems.
The work items will be reviewed in IESG plenary at the IETF.
Goals and Milestones:
JAN 03 Group formed
FEB 03 First I-D of problem statement issued
MAR 03 Problem statement reviewed at the IESG Plenary
MAR 03 First I-D of process proposal issued
MAY 03 Problem statement submitted for IESG review
JUL 03 Process proposal reviewed at the IESG Plenary
AUG 03 Process proposal submitted for IESG review
OCT 03 Re-charter or close working group
Management Issue: IESG comments solicited: draft-iab-research-funding
Just to increase the probability that folks read this I'd like to
add it to the next telechat agenda under management issues.
(Or under "IAB documents" if we had such an agenda heading.)
Erik
>----------------Begin Forwarded Message----------------<
Date: Fri, 07 Feb 2003 00:37:50 -0500
From: "Rob Austein" <sra@hactrn.net>
Subject: IESG comments solicited: draft-iab-research-funding
To: iesg@ietf.org
A group of IAB folks (which, somewhat to my surprise, appears to
include me, not that I've done a lick of work on this or even had time
to read what the others have done yet) has been tasked with writing a
pair of documents talking about (a) research topics that we think need
to be addressed and (b) how the IETF, ISOC, etc, should and should not
play in this space with the folks from various governments who have
their checkbooks ready. Complex topic, please suspend disbelief
rather than assuming that we're idiots just on the basis of my
incompetent attempt to summarize the subject in one sentence :).
At any rate, one of the proto drafts is far enough along that its
authors would like to offer IESG folks the chance to read and comment.
The URL is:
http://www.icir.org/floyd/research/draft-iab-research-funding-00f.txt
I have been asked to ask the IESG not to leak that URL beyond IAB+IESG
for now.