[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Draft Package for March 6, 2003 IESG Telechat
Please note that our office has closed early due to inclement weather;
and with the forecast calling for more snow, I'm sending the telechat
agenda and package out early. An updated agenda will be sent by Monday.
Thanks,
Jacqueline
******************************
* DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT *
INTERNET ENGINEERING STEERING GROUP (IESG)
Agenda for the March 6, 2003 IESG Teleconference
1. Administrivia
o Roll Call
o Bash the Agenda
o Approval of the Minutes
- February 20, 2003
o Review of Action Items
OUTSTANDING TASKS
Last updated: February 27, 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 Scott and Allison to confer on draft-foster-mgcp-basic-packages
and return March 6, 2003 with discussion points.
o Allison to send Secretariat message that draft-malis-sonet-ces-mpls
is resolved once she receives a reply.
IP o Steve Bellovin to use channel to firewall vendors wrt
draft-ietf-tsvwg-tcp-nonce-04.txt
DONE o Bert Wijnen will send suggested wording to iesg-secretary about
"Does an IANA maintained MIB require an RFC?"
o Bert will follow up to make sure we have agreement from JORGE
wrt IANA MIB Copyright.
o Thomas will ask the WG whether they want to publish
draft-ietf-ipngwg-addr-arch-v3-11.txt as a Proposed Standard.
o Scott will write draft on how to inform the community about ID
Nits.
2. Protocol Action
o Advice for Internet Subnetwork Designers (BCP)
<draft-ietf-pilc-link-design-13.txt>
Token: Mankin, Allison
Note: A compendium of suggestions if someone is building a new
link layer or considering interactions of link layers and Transport.
Much effort was made to get WG consensus on everything while not
making it a committee draft.
3. Working Group Submissions
o A Flexible Method for Managing the Assignment of Bites of an IPv6
Address Block (Informational)
<draft-ietf-ipv6-ipaddressassign-06.txt>
Token: Narten, Thomas
Note: WG LC issued 2003-01-16
o Service requirements for Provider Provisioned Virtual Private
Networks (Informational)
<draft-ietf-ppvpn-requirements-05.txt>
Token: Bradner, Scott
o A Framework for Layer 3 Provider Provisioned Virtual Private
Networks (Informational)
<draft-ietf-ppvpn-framework-07.txt>
Token: Bradner, Scott
4. Individual via RFC Editor
o Terminology Used in Internationalization in the IETF (Informational)
<draft-hoffman-i18n-terms-11.txt>
Token: Faltstrom, Patrik
o Basic MGCP Packages (Informational)
<draft-foster-mgcp-basic-packages-09.txt>
Token: Bradner, Scott
5. Proposed Working Groups
o Network File System Version 4
Token: Scott
Note: Additional text and milestones
o IPSEC KEYing information resource record
Token: Steve Belllovin
o Enhancements to Internet email to support diverse service
environments
Token: Ned
Note: New title: Enhancements to Internet email to support
diverse service environments (lemonade) and updated charter
o Problem Statement
Token: Harald
6. Working Group News we can use
7. IAB News we can use
8. Management Issues
o draft-foster-mgcp-basic-packages
DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT *
INTERNET ENGINEERING STEERING GROUP (IESG)
February 20, 2003
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
Coya, Steve / IETF
Daigle, Leslie / Verisign (IAB)
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
-------
Faltstrom, Patrik / Cisco
Minutes
-------
1. The minutes of the February 6, 2003 teleconference were approved.
Secretariat to place in public archives.
2. The following action items were reported as DONE:
DONE o Harald to compose note for draft-ietf-isis-traffic-04.txt.
DONE o Ned to email Secretariat about draft-new-apex-server;
Secretariat to forward to RFC Editor.
DONE o Harald to draft note regarding Zorn Formal Appeal Against IESG
decision. Secretariat to announce.
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.
DONE o Steve Bellovin to ask Matt Blaze to talk at San Francisco
plenary about privacy considerations.
DONE o Bert to evaluate ownership statements in printer MIB.
DONE o Harald to send note to Bob Braden about not adding names of
STD.
DONE 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.
3. Protocol Actions TENTATIVELY APPROVED:
The IESG tentatively approved publication of 'Wrapping an HMAC key with
a Triple-DES Key or an AES Key' <draft-ietf-smime-hmac-key-wrap-01.txt>
as a Proposed Standard. Once Jeff and/or Steve resolve Thomas's
"discuss" with an RFC Editor Note, the Secretariat can announce.
4. Document Action APPROVED:
The IESG has approved the Internet-Draft 'The Eifel Detection Algorithm
for TCP' <draft-ietf-tsvwg-tcp-eifel-alg-07.txt> as an Experimental RFC.
Secretariat to send announcement.
5. The following documents are still under DISCUSSION:
o The UDP-Lite Protocol (Proposed Standard)
<draft-ietf-tsvwg-udp-lite-01.txt>
o Text string notation for Dial Sequences and GSTN / E.164
addresses (Proposed Standard)
<draft-allocchio-gstn-04.txt>
o RTP Payload Format for ETSI ES 201 108 Distributed Speech
Recognition Encoding (Proposed Standard)
<draft-ietf-avt-dsr-05.txt>
o NOPEER community for BGP route scope control (BCP)
<draft-ietf-ptomaine-nopeer-00.txt>
o Private Session Initiation Protocol(SIP) Proxy-to-Proxy
Extensions for Supporting DCS (Informational)
<draft-dcsgroup-sipping-proxy-proxy-02.txt>
6. Working Group Actions:
o Network File System Version 4
Note: Secretariat to send formal WG Charter Review message to
IESG, IAB, new-work, cc: WG Chairs.
o IPSEC KEYing information resource record (ipseckey)
Note: Tentatively approved pending word tweak from Rob Austein,
Steve Bellovin.
o Enhancements to Internet email to support diverse service
environments (lemonade)
Note: Secretariat to post current version of charter on the web.
o PROBLEM (problem)
Note: Secretariat to send WG Review message to ietf-announce and
new-work.
o Dynamic Host Configuration (dhc)
Note: Approved. Secretariat to announce.
o MANET
Note: Secretariat to update charter. Once Allison and Steve
Bellovin's concerns are addressed with a note, Alex will notify
the Secretariat that it's approved. Secretariat to then send WG
Action announcement.
7. The IESG discussed if new IANA-maintained MIB modules should be
published as (part of) an RFC. The consensus is that the initial
version indeed is to be in an RFC. The version in that RFC MUST make
sure that some a statement is made that the authoritative version of
the IANA-maintained MIB module is at the IANA web pages.
8. No action was taken on the following document:
o 'Basic MGCP Packages' (Informational)
<draft-foster-mgcp-basic-packages-09.txt>
Note: Discussion on this document was deferred until the
March 6, 2003 telechat.
9. NEW Action Items:
o Bert Wijnen will send suggested wording to iesg-secretary about
"Does an IANA maintained MIB require an RFC?"
o Bert will follow up to make sure we have agreement from JORGE
wrt IANA MIB Copyright.
o Thomas will ask the WG whether they want to publish
draft-ietf-ipngwg-addr-arch-v3-11.txt as a Proposed Standard.
o Scott will write draft on how to inform the community about ID
Nits.
10. 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 Scott and Allison to confer on draft-foster-mgcp-basic-packages
and return March 6, 2003 with discussion points.
o Allison to send Secretariat message that draft-malis-sonet-ces-
mpls is resolved once she receives a reply.
IP o Steve Bellovin to use channel to firewall vendors wrt
draft-ietf-tsvwg-tcp-nonce-04.txt
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-25
Current Status: Active Working Group
Chair(s):
Sam Weiler <weiler+ietf@watson.org>
Rob Austein <sra@hactrn.net>
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, and to design such a record in
co-operation with the dnsext working group. The contents of the resource
record are not limited to only the information that is in the DNS
KEY record but may also contain other useful IPSEC 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. It is anticipated that such analysis
will be documented in some future standards-track RFCs.
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