[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Agenda and Package for January 23, 2003 Telechat
- To: iesg@ietf.org
- Subject: Agenda and Package for January 23, 2003 Telechat
- From: Jacqueline Hargest <jhargest@ietf.org>
- Date: Wed, 22 Jan 2003 17:17:21 -0500
INTERNET ENGINEERING STEERING GROUP (IESG)
Agenda for the January 23, 2003 IESG Teleconference
1. Administrivia
o Roll Call
o Bash the Agenda
o Approval of the Minutes
- January 9, 2003
o Review of Action Items
OUTSTANDING TASKS
Last updated January 21, 2002
o <draft-dfncis-netnews-admin-sys-04.txt> in Expert Review; Ned
to evaluate.
IP o Allison to review draft-agrawal-sip-h323-interworking-reqs
and send decision to IESG. If OK, Steve/Secretariat to announce.
IP o Ned to write MIME and MEDIA TYPES Roadmap document
IP o Jeff to compare and contrast identity vs. identifier
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
o Patrik to re-evaluate state of draft-irtf-idrm-handle-system (Informational)
o Patrik to re-evaluate state of draft-jaffer-metric-interchange-format (None)
o Erik to re-evaluate state of draft-jl-pcdp (Informational)
IP o Allison to re-evaluate state of draft-malis-sonet-ces-mpls (Request)
o Patrik to re-evaluate state of draft-new-apex-server (Informational)
IP o Ned to re-evaluate state of draft-tegen-smqp (Informational)
IP 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.
IP o Secretariat to publish all liaison statements immediately.
o Secretariat to have aliases for statements to ietf.org that goes
to ticket system.
IP o Secretariat to include all IETF Secretariat action items on the
list.
o Harald to compose note for draft-ietf-isis-traffic-04.txt.
o Scott and Allison to confer on draft-foster-mgcp-basic-packages
and return next week with discussion points.
o Secretariat to place 'lemonade' on new-work.
2. Protocol Actions
o Intrusion Detection Message Exchange Format Data Model and Extensible
Markup Language (XML) Document Type Definition (Proposed Standard)
<draft-ietf-idwg-idmef-xml-09.txt>
Token Bellovin, Steve
o The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec (Proposed
Standard)
<draft-ietf-ipsec-ciph-aes-xcbc-mac-02.txt>
Token Schiller, Jeff
Note Responsible Jeff
3. Under discussion
o The application/ogg Media Type (Proposed Standard)
<draft-walleij-ogg-mediatype-08.txt>
Token Mankin, Allison
Note This MIME type registration needed documentation of the
medium - the Discuss was that the only type of resource was html
(and then I pointed out there was also source code) - anyway, now
there is an i-d, which is on this week's agenda. [Note from
Allison prior to 2002-Jan-23 IESG telechat]
4. Working Group Submissions
o IP over Optical Networks A Framework (Informational)
<draft-ietf-ipo-framework-03.txt>
Token Bradner, Scott
o Internet X.509 Public Key Infrastructure Certificate Policy and
Certification Practices Framework (Informational)
<draft-ietf-pkix-ipki-new-rfc2527-01.txt>
Token Schiller, Jeff
Note Responsible Responsible AD
o Policy Requirements for Time-Stamping Authorities (Informational)
<draft-ietf-pkix-pr-tsa-02.txt>
Token Schiller, Jeff
o Generic Requirements for Provider Provisioned VPN (Informational)
<draft-ietf-ppvpn-generic-reqts-02.txt>
Token Bradner, Scott
5. Individual Submissions
o CR-LDP Extensions for ASON (Informational)
<draft-aboulmagd-ccamp-crldp-ason-ext-02.txt>
Token Bradner, Scott
o The Ogg encapsulation format version 0 (Informational)
<draft-pfeiffer-ogg-fileformat-01.tx>
Token Allison Mankin
Note This is the documentation IESG felt needed to go with the ogg
mime type registration...with this in hand, the ogg mime type should
be able to go forward - but this needs to go on the IESG agenda next
time (that is 2002-Jan-23)
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
6. Individual via RFC Editor
o LDP and RSVP Extensions for Optical UNI Signaling (Informational)
<draft-bala-uni-ldp-rsvp-extension>
Token Bradner, Scott
o IP Version 6 over MAPOS (Informational)
<draft-ogura-ipv6-mapos-01.txt>
Token Narten, Thomas
Note minor questions/comments sent to authors
Recommend IESG note along lines of notes attached to other MAPOS
RFCs.
7. Proposed Working Groups
o License to Enhance Messaging Oriented Network Access for Diverse
Endpoints
Token Ned
Note New title Enhancements to Internet email to support
diverse service environments (lemonade) and updated charter
8. Working Group News We Can Use
9. IAB News we can use
10. Management Issues
o Basic MGCP Packages (Informational)
o IETF Meetings - avoiding overlaps
o Zorn Formal Appeal against IESG decision
o draft-ietf-idwg-idmef-xml
DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT *
INTERNET ENGINEERING STEERING GROUP (IESG)
January 9, 2003
Reported by Jacqueline Hargest, IETF Assistant Director
ATTENDEES
---------
Alvestrand, Harald / Cisco
Austein, Rob / IAB Liaison
Bradner, Scott / Harvard
Bush, Randy / IIJ
Cotton, Michelle / ICANN
Faltstrom, Patrik / Cisco
Fenner, Bill / AT&T
Hargest, Jacqueline / IETF
Mankin, Allison / Bell Labs, Lucent
Narten, Thomas / IBM
Reynolds, Joyce K. / ISI (RFC Editor)
Schiller, Jeff / MIT
Wijnen, Bert / Lucent
Zinin, Alex / Alcatel
REGRETS
-------
Bellovin, Steve / AT&T Labs
Coya, Steve / IETF
Daigle, Leslie / Verisign (IAB)
Freed, Ned / Innosoft
Nordmark, Erik / Sun
Minutes
-------
1. The minutes of the December 27, 2002 Teleconference were approved.
Secretariat to place in public archives.
2. Prior to the January 9, 2003 teleconference, the following
documents were APPROVED
o 'The Group Domain of Interpretation' (Proposed)
<draft-ietf-msec-gdoi-07.txt>
o 'LDAPv2 to Historical Status' (Informational)
<draft-zeilenga-ldapv2-04.txt>
3. Protocol Actions TENTATIVELY APPROVED
o 'RTP Payload Format for SMPTE 292M Video' (Proposed Standard)
<draft-ietf-avt-smpte292-video-08.txt>
Note Scott to send note. Secretariat to announce.
4. Document Actions APPROVED
The IESG has approved the Internet-Draft 'Requirements for Resource
Priority Mechanisms for the Session Initiation Protocol'
<draft-ietf-ieprep-sip-reqs-03.txt> as an Informational RFC.
Secretariat to send announcement.
5. Document Actions TENTATIVELY APPROVED
o 'LDP and RSVP Extensions for Optical UNI Signaling' (Informational)
<draft-bala-uni-ldp-rsvp-extensions-03.txt>
Note IANA to review assignments for this and two other documents.
Once Thomas gives ok, Secretariat to announce.
6. Working Group Action
o 'License to Enhance Messaging Oriented Network Access for Diverse
Endpoints' (lemonade)
Note Secretariat to place on new-work.
7. The following documents are still under DISCUSSION
o 'A Presence Event Package for the Session Initiation Protocol (SIP)'
(Proposed Standard)
<draft-ietf-simple-presence-09.txt>
Note Ned holds a "Defer".
o 'IS-IS extensions for Traffic Engineering' (Informational)
<draft-ietf-isis-traffic-04.txt>
Note Harald will compose a note.
o 'Basic MGCP Packages' (Informational)
<draft-foster-mgcp-basic-packages-09.txt>
Note Scott and Allison to confer and return next week with
discussion points.
8. NEW Action Items
o Scott to summarize discussion on the Osama document.
o Thomas to get IESG's sign off for draft-stoica-diffserv-dps.
Secretariat to announce.
o Secretariat to publish all liaison statements immediately.
o Secretariat to have aliases for statements to ietf.org that goes
to ticket system.
o Secretariat to include all IETF Secretariat action items on the
list.
o Harald to compose note for draft-ietf-isis-traffic-04.txt.
o Scott and Allison to confer on draft-foster-mgcp-basic-packages
and return next week with discussion points.
o Secretariat to place 'lemonade' on new-work.
9. Outstanding Action Items
o <draft-dfncis-netnews-admin-sys-04.txt> in Expert Review; Ned to
evaluate.
IP o Allison to review draft-agrawal-sip-h323-interworking-reqs
and send decision to IESG. If OK, Steve/Secretariat to announce.
IP o Ned to write MIME and MEDIA TYPES Roadmap document
IP o Jeff to compare and contrast identity vs. identifier
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
o Patrik to re-evaluate state of draft-irtf-idrm-handle-system (Informational)
o Patrik to re-evaluate state of draft-jaffer-metric-interchange-format (None)
o Erik to re-evaluate state of draft-jl-pcdp (Informational)
IP o Allison to re-evaluate state of draft-malis-sonet-ces-mpls (Request)
o Patrik to re-evaluate state of draft-new-apex-server (Informational)
IP o Ned to re-evaluate state of draft-tegen-smqp (Informational)
IP o Ned to re-evaluate state of draft-tiwari-appl-wxxx-forms (Informational)
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-idwg-idmef-xml - Intrusion Detection
Message Exchange Format Data Model and Extensible Markup
Language (XML) Document Type Definition to Proposed Standard
--------
Last Call to expire on July 3, 2002
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 [ ] [ XX] [ D ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ X ] [ ] [ ] [ ]
Allison Mankin [ X ] [ ] [ ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jeff Schiller [ ] [ X ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ XX] [ D ]
Alex Zinin [ ] [ X ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS
========
Scott note
I would have thought that there should eb an IANA considerations
section that at least points to sec 5 on how extensions
can get made but also, I would have thought that sec 5 would
have included what IETF proocesses (see RFC 2434) should
be used to extend teh protocol
I'm sensitive to this because we are getting a pile of
requests to extend IETF protools (MPLS, RSVP etc) of
late and we did not have any -must be extened within the
ietf only- IANA mesage so we are being asked to OK
some messy extensions - it woudl be good to cut this off at the
pass and include such restrictions in new docs
Patrik
Yes, I should have discovered this earlier, but this last week has been
too much. I just passed the document to the xml-directorate for review.
I will send in a new ballot as soon as I get a response.
This imply I hope this only have to wait until say monday, and not next
telechat before it can pass.
So, please, do the rest of the ballot!
Randy
needs to separate into at least two docs, the xml and transport model
and the particular application
xml-dir review comment
1) There is too much description and teaching about XML and UML. The
document should merely reference the XML and UML standards and explain
the restrictions and/or extensions to those specs in the definition of
IDMEF.
2) Section 3.3.4 mentions XML Schema and how they would one day use it.
Well, it has been out for awhile, so why aren't they? If they
switched from DTD's to XML Schema, they could probably get rid of half
of the data type sections (3.4.1 to 3.4.6) and their entire need for UML.
Bert
I think I had a Defer (after initially thought I would be noObj.
But I need to rais a Discuss.
Section 4.2.7.4.2 The SNMPService Class
The description of this Class shows only how to deal with SNMPv1/v2c
where authentication is done by (very weak) communitty String.
WWWWWe just made SNMPv1/v2c Historic. Of course they are still in
wide use, but SNMPv3 (which we just publsihed as STD 62) is already
deployed at many places and will get more and more deployment.
I think this document should recognize that and also address SNMPv3
where we no longer have a community String.
I also wonder if in the many examples on Pages 76 and folloing, if
it is OK to use domain names and IP addresses as they do. In other
words, do they violate one of our NITS
Addresses used in examples should prefer use of fully
qualified domain names to literal IP addresses, and prefer use
of example fqdn's such as foo.example.com to real-world fqdn's
See RFC 2606 for example domain names that can be used
There is also a range of IP addresses set aside for this
purpose. These are 192.0.2.0/24 (see RFC 3330). Private
addressess that would be used in the real world should be
avoided in examples.
Let me add that the IPR section is also missing for this doc
that is targeted for STDs track.
COMMMENTS
==========
Ned
>To Randy Bush <randy@psg.com>
> discuss
> ...
> 2) Section 3.3.4 mentions XML Schema and how they would one day use it.
> Well, it has been out for awhile, so why aren't they? If they
> switched from DTD's to XML Schema, they could probably get rid of half
> of the data type sections (3.4.1 to 3.4.6) and their entire need for UML.
This isssue is discussed in section 4.7 of
draft-hollenbeck-ietf-xml-guidelines-07.txt, recently approved as a BCP.
This section makes it clear that either a DTD or a Schema based approach
is permissible; neither one is inherently better than the other
The choice of tool depends on the needs for extensibility or for a
formal language and mechanism for constraining permissible values
and validating adherence to the constraints.
I read this as saying that unless a case can be made that these needs
aren't met by the chosen mechanism we should not be insisting they make a
different choice.
Ned
Randy
i think the point is
both water and air are allowed. one may be better for washing your
car.
^L
To IETF-Announce;
Dcc *******
Cc RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, idwg-public@zurich.ibm.com
>From The IESG <iesg-secretary@ietf.org>
Subject Protocol Action Intrusion Detection Message Exchange Format
Data Model and Extensible Markup Language (XML) Document Type
Definition to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Intrusion Detection Message
Exchange Format Data Model and Extensible Markup Language (XML) Document
Type Definition' <draft-ietf-idwg-idmef-xml-09.txt> as a Proposed
Standard. This document is the product of the Intrusion Detection
Exchange Format Working Group. The IESG contact persons are Jeffrey
Schiller and Steve Bellovin.
Technical Summary
Different elements of intrusion detection systems (IDS) need to
communicate with each other. This document defines a standard
data model, and implements it as an XML DTD.
Working Group Summary
There were no major issues with the document.
Protocol Quality
This document was reviewed for the IESG by Steve Bellovin.
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-ipsec-ciph-aes-xcbc-mac - The
AES-XCBC-MAC-96 Algorithm and Its Use With IPsec 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 [ ] [ ] [ ] [ ]
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>, ipsec@lists.tislabs.com
>From The IESG <iesg-secretary@ietf.org>
Subject Protocol Action The AES-XCBC-MAC-96 Algorithm and Its Use
With IPsec to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'The AES-XCBC-MAC-96 Algorithm
and Its Use With IPsec' <draft-ietf-ipsec-ciph-aes-xcbc-mac-02.txt> as
a Proposed Standard. This document is the product of the IP Security
Protocol Working Group. The IESG contact persons are Jeffrey Schiller
and Steve Bellovin.
Technical Summary
(What does this protocol do and why does the community need it?)
Working Group Summary
(Was there any significant dissent? Was the choice obvious?)
Protocol Quality
(Who has reviewed the spec for the IESG? Are there implementations?)
Enhancements to Internet email to support diverse service environments
(lemonade)
Proposed Charter
================
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.
Milestones (document completion)
==========
Feb 2003 - LEMONADE Requirements
May 2003 - Server to server notification protocol
Jul 2003 - IMAP4 extensions for VM playback
Sep 2003 - IMAP4 extensions for mobile devices
Jan 2004 - Translation to and from other messaging systems
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