[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Agenda and Package for September 4, 2003 Telechat
INTERNET ENGINEERING STEERING GROUP (IESG)
Summarized Agenda for the September 4, 2003 IESG Teleconference
This summary was generated at 12:19:40 EDT, September 2, 2003
1. Administrivia
1.1 Roll Call
1.2 Bash the Agenda
1.3 Approval of the Minutes
1.4 Review of Action Items
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item
NONE
2.1.2 Returning Item
o Five-document ballot: - 1 of 2
- draft-ietf-secsh-architecture-14.txt
SSH Protocol Architecture (Proposed Standard)
- draft-ietf-secsh-connect-17.txt
SSH Connection Protocol (Proposed Standard)
- draft-ietf-secsh-transport-16.txt
SSH Transport Layer Protocol (Proposed Standard)
- draft-ietf-secsh-userauth-17.txt
SSH Authentication Protocol (Proposed Standard)
- draft-ietf-secsh-assignednumbers-04.txt
SSH Protocol Assigned Numbers (Proposed Standard)
Token: Russ Housley
o draft-ietf-dhc-dhcpv6-opt-dnsconfig-04.txt
DNS Configuration Options for DHCPv6 (Proposed Standard) - 2 of 2
Note: Nte to IESG: Only need to verify that IANA considerations in -04
addresse's Michelle's comment, then approve.
Token: Thomas Narten
2.2 Individual Submissions
2.2.1 New Item
NONE
2.2.2 Returning Item
NONE
3. Document Actions
3.1 WG Submissions
3.1.1 New Item
o draft-ietf-magma-snoop-09.txt
Considerations for IGMP and MLD Snooping Switches (Informational) - 1
of 2
Token: Margaret Wasserman
o draft-ietf-ipv6-prefix-delegation-requirement-03.txt
Requirements for IPv6 prefix delegation (Informational) - 2 of 2
Token: Thomas Narten
3.1.2 Returning Item
o draft-ietf-manet-tbrpf-10.txt
Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)
(Experimental) - 1 of 1
Token: Alex Zinin
3.2 Individual Submissions Via AD
3.2.1 New Item
NONE
3.2.2 Returning Item
NONE
3.3 Individual Submissions Via RFC Editor
3.3.1 New Item
o draft-hollenbeck-rfc2832bis-03.txt
VeriSign Registry Registrar Protocol (RRP) Version 2.0.0
(Informational) - 1 of 1
Token: Ted Hardie
3.3.2 Returning Item
NONE
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
NONE
4.1.2 Proposed for Approval
o Centralized Conferencing - 1 of 2
Token: Allison
o Mobility for IPv6 - 2 of 2
Token: Thomas
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
NONE
4.2.2 Proposed for Approval
NONE
5. Working Group News We Can Use
6. IAB News We Can Use
7. Management Issues
o Procedures for Creating, Rechartering and Closing a Working Group
(Harald Alvestrand)
o Recording Retention Policy (Ted Hardie)
o draft-baker-liaisons-00.txt (Bert Wijnen)
o Tony Hain appeal (Harald Alvestrand)
o Todd Glassey appeal (Bert Wijnen)
------------------------------------------------------------------------------
INTERNET ENGINEERING STEERING GROUP (IESG)
Agenda for the September 4, 2003 IESG Teleconference
This package was generated at 12:19:41 EDT, September 2, 2003.
1. Administrivia
1.1 Roll Call
Dear IESG Members:
The next IESG teleconference will take place on Thursday, September 4,
2003 from 11:30-14:00 US-ET. If you are *unable* to participate in the
teleconference, or if you wish to change your usual procedures for
connecting to the call (as indicated in the list below), then please reply
to this message as follows:
o If you are unable to participate, then please write "Regrets" after your
name.
o If you normally call in, but will require operator assistance for this
teleconference, then please provide the telephone number where you can be
reached.
o If you are normally connected to the teleconference by an operator, but
will call in for this teleconference, then please write "Will call in"
next to your name in place of the telephone number.
Harald Alvestrand---Will call in
Rob Austein---Will call in
Steve Bellovin---Will call in
Randy Bush--- Will call in
Michelle Cotton---Will call in
Leslie Daigle---Regrets
Bill Fenner---Will call in
Ned Freed---Regrets
Barbara Fuller---Will call in
Ted Hardie---Will call in
Russ Housley---Will call in
Allison Mankin---Will call in
Thomas Narten--- Will call in
Jon Peterson---Will call in
Joyce K. Reynolds---Will call in
Dinara Suleymanova--- Will call in
Amy Vezza---Will call in
Margaret Wasserman---Will call in
Bert Wijnen---Will call in
Alex Zinin---Will call in
To join the teleconference, please call the appropriate dial-in number
(see below) at 11:30 AM ET. If you have requested operator assistance,
then an operator will call you and connect you to the call. Participants
inside the U.S. should use the toll-free number 888-315-1685.
Participants outside the U.S. should use either one of the toll-free
numbers listed at the end of this message, or the direct-dial number
703-788-0617. Participants using the direct-dial number will pay their own
long distance charges through their own carriers. Participants dialing the
toll-free number will not pay any charges for the conference, as all
charges, including long distance, will be included on the invoice sent to
the company hosting the call. In some cases, participants from certain
international countries may only use a direct-dial number.
All participants should enter the passcode 235467 when prompted to do so.
The first person on the call will not hear anything until joined by other
participants. A tone will sound as others join the conference.
****************************************
TOLL-FREE NUMBERS
ARGENTINA---0800-666-0375
AUSTRALIA---1800-001-906
BRAZIL---000-817-200-5360
CHINA---10800-1300398
FINLAND---08001-10966
FRANCE---0800-91-1452
GERMANY---0800-181-7632
HONG KONG---800-96-3907
HUNGARY---06-800-15083
ISRAEL---18009300182
JAPAN---00531-13-0415
MEXICO---001-866-857-1855
NORWAY---800-10-074
SWEDEN---020-791386
UNITED KINGDOM---0800-904-7969
SOUTH KOREA---00308-131103
NETHERLANDS---0800-023-2726
PARTICIPANTS FROM ALL OTHER COUNTRIES MUST USE THE DIRECT DIAL NUMBER AND
THUS INCUR CHARGES FROM THEIR OWN CARRIER.
1.2 Bash the Agenda
1.3 Approval of the Minutes
DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT
INTERNET ENGINEERING STEERING GROUP (IESG)
Minutes of the August 21, 2003 IESG Teleconference
Reported by: Amy Vezza, IETF Secretariat
ATTENDEES
------------------
Harald Alvestrand / Cisco
Rob Austein / IAB Liaison
Steve Bellovin / AT&T
Michelle Cotton / ICANN
Bill Fenner / AT&T
Barbara Fuller / IETF Secretariat
Ted Hardie / Qualcomm, Inc.
Russ Housley / Vigil Security, LLC
Jon Peterson / NeuStar, Inc.
Joyce K. Reynolds / ISI (RFC Editor)
Natalia Syracuse / IETF Secretariat
Amy Vezza / IETF Secretariat
Margaret Wasserman / Wind River
Bert Wijnen / Lucent
Alex Zinin / Alcatel
REGRETS
------------
Randy Bush / IIJ
Leslie Daigle / Verisign (IAB)
Ned Freed / Sun Microsystems
Allison Mankin / Bell Labs, Lucent
Thomas Narten / IBM
Dinara Suleymanova / IETF Secretariat
MINUTES
---------------
1. Administrivia
1.1 Approval of the Minutes
The minutes of the August 7, 2003 Teleconference were approved.
The Secretariat will place the minutes in the public archives.
1.2 Review of Action Items
DONE:
o Harald Alvestrand to send text of Tony Hain appeal to the IETF
Secretariat. The Secretariat will post the appeal on the "Appeals
submitted to the IESG" Web page.
o Bert Wijnen will send the document on how the IESG goes about
asking architectural questions of the IAB to the Secretariat.
The Secretariat will post the document on the internal IESG Web
page.
DELETED:
NONE
IN PROGRESS:
o Jon Peterson to review draft-agrawal-sip-h323-interworking-reqs
and send decision to IESG.
o Thomas Narten to write (or cause to be written) a draft on "how
to get to Draft".
o Thomas Narten to contact Cablelabs to discuss formal relationship
with IAB.
o Steve Bellovin to write RFC re: TCP MD5 option.
o Randy Bush and Ned Freed to finish ID on Clarifying when Standards
Track Documents may Refer Normatively to Documents at a Lower Level.
o Alex Zinin to send proposal and justification for interim document
review.
o Steve Bellovin to propose a different document classification than
the current info/proposed/etc.
o Alex Zinin to phrase a question to RTG and OPS Area Directoriats
and IAB on PPVPN issue. Alex to summarize the results as a proposed
IESG consensus regarding the PPVPN issue to be given to the PPVPN
working group.
NEW:
NONE
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item
o draft-ietf-dnsext-delegation-signer-15.txt - 1 of 5
Delegation Signer Resource Record (Proposed Standard)
Token: Thomas Narten
The document was approved by the IESG. The Secretariat will send
a working group submission Protocol Action Announcement.
o draft-ietf-dhc-dhcpv6-opt-dnsconfig-03.txt - 2 of 5
DNS Configuration Options for DHCPv6 (Proposed Standard)
Token: Thomas Narten
The document remains under discussion by the IESG in order to
resolve points raised by Margaret Wasserman on behalf of IANA.*
o draft-ietf-ospf-dc-06.txt - 3 of 5
Detecting Inactive Neighbors over OSPF Demand Circuits
(Proposed Standard)
Token: Bill Fenner
The document remains under discussion by the IESG in order to resolve
points raised by Bill Fenner.*
o draft-ietf-hubmib-power-ethernet-mib-08.txt - 4 of 5
Power Ethernet MIB (Proposed Standard)
Token: Bert Wijnen
The document was approved by the IESG pending an RFC Editor Note to
be prepared by Bert Wijnen. The Secretariat will send a working group
submission Protocol Action Announcement that includes the RFC Editor
Note.
o draft-ietf-dnsext-dnssec-2535typecode-change-04.txt - 5 of 5
Legacy Resolver Compatibility for Delegation Signer
(Proposed Standard)
Token: Thomas Narten
The document was approved by the IESG. The Secretariat will send a
working group submission Protocol Action Announcement.
2.1.2 Returning Item
o draft-ietf-sigtran-sctp-mib-10.txt - 1 of 2
Stream Control Transmission Protocol Management Information Base
(Proposed Standard)
Token: Jon Peterson
The document was approved by the IESG. The Secretariat will send a
working group submission Protocol Action Announcement.
o draft-ietf-sigtran-security-03.txt - 2 of 2
Security Considerations for SIGTRAN Protocols (Proposed Standard)
Token: Jon Peterson
The document remains under discussion by the IESG in order to resolve
points raised by Jon Peterson on behalf of IANA.*
2.2 Individual Submissions
2.2.1 New Item
o draft-rharrison-ldap-intermediate-resp-01.txt - 1 of 2
The Lightweight Directory Access Protocol (LDAP) Intermediate
Response Message (Proposed Standard)
Token: Ted Hardie
The document was approved by the IESG. The Secretariat will send
an individual submission Protocol Action Announcement.
o draft-zeilenga-ldap-authzid-08.txt - 2 of 2
LDAP 'Who am I?' Operation (Proposed Standard)
Token: Ted Hardie
The document remains under discussion by the IESG in order to resolve
points raised by Russ Housley and Bert Wijnen.*
2.2.2 Returning Item
o draft-vaudreuil-mdnbis-05.txt - 1 of 1
Message Disposition Notification (Draft Standard)
Token: Ned Freed
The document remains under discussion by the IESG in order to resolve
points raised by Randy Bush and Bill Fenner.*
3. Document Actions
3.1 WG Submissions
3.1.1 New Item
o draft-ietf-forces-framework-08.txt - 1 of 1
Forwarding and Control Element Separation (ForCES) Framework
(Informational)
Token: Alex Zinin
The document remains under discussion by the IESG.*
3.1.2 Returning Item
o draft-ietf-isis-traffic-05.txt - 1 of 2
IS-IS extensions for Traffic Engineering (Informational)
Token: Alex Zinin
The document was approved by the IESG pending an RFC Editor Note to
be prepared by Alex Zinin. The Secretariat will send a working group
submission Document Action Announcement that includes the RFC Editor
Note.
o draft-ietf-forces-requirements-10.txt - 2 of 2
Requirements for Separation of IP Control and Forwarding
(Informational)
Token: Alex Zinin
The document was approved by the IESG. The Secretariat will send
a working group submission Document Action Announcement.
3.2 Indiviual Submissions Via AD
3.2.1 New Item
o draft-weltman-ldapv3-auth-response-09.txt - 1 of 1
LDAP Authorization Identity Request and Response Controls
(Informational)
Token: Ted Hardie
The document was approved by the IESG pending revisions to the text
and an IESG note, both to be prepared by Ted Hardie. The Secretariat
will send an individual submission Document Action Announcement that
includes the IESG note.
3.2.2 Returning Item
NONE
3.3 Individual Submissions Via RFC Editor
3.3.1 New Item
o draft-foster-mgcp-returncodes-03.txt - 1 of 1
Media Gateway Control Protocol (MGCP) Return Code Usage
(Informational)
Token: Jon Peterson
The IESG has no problem with the RFC Editor publishing this document.
The Secretariat will send a standard "no problem" message to the RFC
Editor that includes an IESG Note to be prepared by Jon Peterson.
3.3.2 Returning Item
NONE
3.3.3 To be assigned
o draft-rmcgowan-unicode-procs-03.txt 1 of 1
A Summary of Unicode Consortium Procedures, Policies, Stability,
and Public Access (Informational)
The document was assigned to Ted Hardie.
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
o Mobility for Ipv6 - 1 of 1
Token: Thomas Narten
The IESG approved the draft WG charter for IETF review. The
Secretariat will send a WG Review announcement, with a copy to
new-work@ietf.org. The Secretariat will place the WG on the
agenda for the next IESG teleconference.
4.1.2 Proposed for Approval
o Mobility for IPv4 - 1 of 2
Token: Thomas Narten
The IESG has approved the creation of the working group. The
Secretariat will send a WG Action Announcement with copies to the
working group chairs.
o Centralized Conferencing - 2 of 2
Token: Allison Mankin
The working group remains under discussion by the IESG. The
Secretariat will place the WG on the agenda for the next IESG
teleconference.
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
o ADSL MIB - 1 of 1
Token: Bert Wijnen
The IESG has approved the modifications to the charter. Bert Wijnen
will send a revised charter to the Secretariat. The Secretariat will
send a WG Action: RECHARTER announcement with copies to the working
group chairs upon notification from Bert.
4.2.2 Proposed for Approval
o IP over Cable Data Network - 1 of 1
Token: Bert Wijnen
The IESG has approved the rechartering of the working group. The
Secretariat will send a WG Action: RECHARTER Announcement with copies
to the working group chairs.
5. Working Group News We Can Use
6. IAB News We Can Use
7. Management Issues
o Todd Glassey Appeal (Bert Wijnen)
(discussed) Harald Alvestrand, Steve Bellovin, and Rob Austein left the
teleconference prior to the discussion.
----------------------------------------
* Please see the ID Tracker
(https://datatracker.ietf.org/public/pidtracker.cgi) for details
on documents that are under discussion by the IESG.
1. Administrivia
1.4 Review of Action Items
OUTSTANDING TASKS
Last updated: August 25, 2003
IP o Jon Peterson to review draft-agrawal-sip-h323-interworking-reqs
and send decision to IESG.
IP o Thomas Narten to write (or cause to be written) a draft on "how to get to Draft".
IP o Thomas Narten to contact Cablelabs to discuss formal relationship with IAB
IP o Steve Bellovin to write RFC re: TCP MD5 option
IP o Randy Bush and Ned Freed to finish ID on Clarifying when Standards Track Documents may
Refer Normatively to Documents at a Lower Level
IP o Alex Zinin to send proposal and justification for interim document review.
IP o Steve Bellovin to propose a different document classification than the current
info/proposed/etc.
IP o Alex Zinin to phrase a question to RTG and OPS Area Directoriats and IAB
on PPVPN issue. Alex to summarize the results as a proposed IESG consensus
regarding the PPVPN issue to be given to the PPVPN working group.
2.1.1 New Item
NONE
2. Protocol Actions
2.1 WG Submissions
2.1.2 Returning Item - 1 of 2
o Five-document ballot:
- draft-ietf-secsh-architecture-14.txt
SSH Protocol Architecture (Proposed Standard)
- draft-ietf-secsh-connect-17.txt
SSH Connection Protocol (Proposed Standard)
- draft-ietf-secsh-transport-16.txt
SSH Transport Layer Protocol (Proposed Standard)
- draft-ietf-secsh-userauth-17.txt
SSH Authentication Protocol (Proposed Standard)
- draft-ietf-secsh-assignednumbers-04.txt
SSH Protocol Assigned Numbers (Proposed Standard)
Token: Russ Housley
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-secsh-architecture - SSH Protocol
Architecture to Proposed Standard
--------
This Evaluation reflects positions for a set of five documents:
o SSH Protocol Architecture <draft-ietf-secsh-architecture-14.txt>
o SSH Protocol Assigned Numbers <draft-ietf-secsh-assignednumbers-04.txt>
o SSH Connection Protocol <draft-ietf-secsh-connect-17.txt>
o SSH Transport Layer Protocol <draft-ietf-secsh-transport-16.txt>
o SSH Authentication Protocol <draft-ietf-secsh-userauth-17.txt>
Last Call to expire on: April 10, 2002
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ X ] [ ]
Randy Bush [ ] [ X ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ X ] [ ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
Scott Bradner [ ] [ XX] [ X ] [ ]
Patrik Faltstrom [ ] [ X ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
Jeff Schiller [ X ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS
=======
Scott:
these IDs have a note about the SSH trademark in a " Trademark Issues"
section
it has been the IETF policy to not include any specific IPR
claims in RFCs - if we are to follow that policy this
comment should be removed from the IDs and put in the on-line
IPR directory and this note replaced with rfc 2026 text
but this is something we should talk about and maybe get
specific legal advice on including this note and on the
use of "SSH" itself as in
"SSH is a protocol for secure remote login ..."
in the face of the trademark claim
yes, I know that we did have some general advice in the
past about ssh-the-trademark but it would seem to be a good
idea to ask the specific question of just what should we put into
these RFCs.
The set of documents should include a statement, probably in
the architecture document, that when there is a change
in the host key, implementations should give a
sufficiently strong message to the user that this
may mean that there has been a security problem if
the change was not an expected one. The specific message should not
be defined, but the recommendation that it explicitly warn of a
possible security situation should be made clear.
COMMENTS
========
Steve: Should the Security Considerations section be strengthened?
^L
---- following is a DRAFT of message to be sent AFTER approval ---
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, ietf-ssh@netbsd.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: SSH Protocol Architecture to Proposed
Standard
-------------
The IESG has approved publication of the following Internet-Drafts as
Proposed Standards:
o SSH Protocol Architecture <draft-ietf-secsh-architecture-14.txt>
o SSH Protocol Assigned Numbers <draft-ietf-secsh-assignednumbers-04.txt>
o SSH Connection Protocol <draft-ietf-secsh-connect-17.txt>
o SSH Transport Layer Protocol <draft-ietf-secsh-transport-16.txt>
o SSH Authentication Protocol <draft-ietf-secsh-userauth-17.txt>
These documents are the product of the Secure Shell Working Group.
The IESG contact persons are Jeffrey Schiller and Steve Bellovin.
Technical Summary
SSH is a protocol for providing an authenticated, integrity protected
and encrypted stream between two end-points. It can optionally
provide compression as well as multiplexing several virtual streams
within a single TCP connection. This multiplexing feature is
particularly useful for "tunneling" other protocols such as the X
Window System.
A Main focus of the SSH protocol is to provide a transport for remote
login from a client computer system to a server system.
Working Group Summary
There is working group consensus around this set of documents.
Protocol Quality
These documents were reviewed by Jeffrey I. Schiller for the IESG
2. Protocol Actions
2.1 WG Submissions
2.1.2 Returning Item - 2 of 2
o draft-ietf-dhc-dhcpv6-opt-dnsconfig-04.txt
DNS Configuration Options for DHCPv6 (Proposed Standard)
Note: Nte to IESG: Only need to verify that IANA considerations in -04
addresse's Michelle's comment, then approve.
Token: Thomas Narten
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-dhc-dhcpv6-opt-dnsconfig -
DNS Configuration Options for DHCPv6
--------
Last Call to expire on: 2003-05-28
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ X ] [ ] [ ]
Steve Bellovin [ ] [ X ] [ ] [ ]
Randy Bush [ ] [ X ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ X ] [ ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ X ] [ ] [ ] [ ]
Jon Peterson [ ] [ X ] [ ] [ ]
Margaret Wasserman [ ] [ X ] [ XX] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Russ Housley (Comments):
Two Comments:
1. There are two "Normative References" sections. I assume one should
be "Informative References"
2. Please delete section 9 prior to publication as an RFC.
Bill Fenner (Comment):
Comment on the writeup:
>There was consensus in the WG for this option. Note that this option
>is analogous to the DHCPv4 option in RFC 3397.
There are two options in the document; one is analogous to DHCPv4 option #6,
the other is analogous to the DHCPv4 option in RFC 3397.
Bert Wijnen (Comment):
Nit:
has no IPR section
^L
---- following is a DRAFT of message to be sent AFTER approval ---
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce:;
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@rfc-editor.org>, <dhcwg@ietf.org>
Subject: Protocol Action: 'DNS Configuration Options for DHCPv6'
to Proposed Standard
The IESG has approved the Internet-Draft 'DNS Configuration Options for
DHCPv6' <draft-ietf-dhc-dhcpv6-opt-dnsconfig-03.txt> as a Proposed
Standard. This document is the product of the Dynamic Host Configuration
Working Group.
The IESG contact persons are Thomas Narten and Margaret Wasserman.
Technical Summary
This document describes DHCPv6 options for passing a list of
available DNS resolvers and a domain search list to a client.
Working Group Summary
There was consensus in the WG for this option. Note that this option
is analogous to the DHCPv4 option in RFC 3397.
Protocol Quality
This document has been reviewed for the IESG by Thomas Narten.
2.2.1 New Item
NONE
2.2.2 Returning Item
NONE
3. Document Actions
3.1 WG Submissions
3.1.1 New Item - 1 of 2
o draft-ietf-magma-snoop-09.txt
Considerations for IGMP and MLD Snooping Switches (Informational)
Token: Margaret Wasserman
3. Document Actions
3.1 WG Submissions
3.1.1 New Item - 2 of 2
o draft-ietf-ipv6-prefix-delegation-requirement-03.txt
Requirements for IPv6 prefix delegation (Informational)
Token: Thomas Narten
3. Document Actions
3.1 WG Submissions
3.1.2 Returning Item - 1 of 1
o draft-ietf-manet-tbrpf-10.txt
Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)
(Experimental)
Token: Alex Zinin
3.2.1 New Item
NONE
3.2.2 Returning Item
NONE
3. Document Actions
3.3 Individual Submissions Via RFC Editor
3.3.1 New Item - 1 of 1
o draft-hollenbeck-rfc2832bis-03.txt
VeriSign Registry Registrar Protocol (RRP) Version 2.0.0
(Informational)
Token: Ted Hardie
3.3.2 Returning Item
NONE
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
NONE
4. Working Group Actions
4.1 WG Creation
4.1.2 Proposed for Approval
o Centralized Conferencing - 1 of 2
Token: Allison
Centralized Conferencing (xcon)
---------------------------------
Charter
Last Modified: 2003-08-04
Current Status: Proposed Working Group
CHAIRS: Alan Johnston (alan.johnston@mci.com)
Adam Roach (adam@dynamicsoft.com)
Mailing list: <http://www.softarmor.com/mailman/listinfo/xcon>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
Transport Area
Responsible Area Director: Allison Mankin
Description of Working Group
The focus of this working group is to develop a standardized suite of
protocols for tightly-coupled multimedia conferences, where strong security
and authorization requirements are integral to the solution.
Tightly-coupled conferences have a central point of control and
authorization so they can enforce specific media and membership
relationships, and provide an accurate roster of participants. The media
mixing or combining function of a tightly-coupled conference need not be
performed centrally, however.
The scope of this effort is intentionally more narrow than previous
attempts to standardize conferencing (e.g. centralized control), and is
intended to enable interoperability in a commercial environment which
already has a number of non-standard implementations using some of the
protocols.
Privacy, security, and authorization mechanisms are integral to the
solution generated by the working group. This includes allowing
participants to be completely invisible or to be visible but participate
anonymously with respect to some or all of the other participants.
Authorization rules allow for participants and non-participants to have
roles (ex: speaker, moderator, owner), and to be otherwise authorized to
perform membership and media manipulation for or on behalf of other
participants. In order to preserve these properties, the protocols used
will require implementation of channel security and authentication services.
Initially this combination of protocols will be specified with respect to
session setup with SIP. The solutions developed in XCON will not preclude
operation with other signaling protocols; however it is anticipated that
the use of other protocols would require modifications which are out of
scope for this working group.
None of the protocols defined by this group will be SIP, although the SIP
specific event notification framework will be used. The group will use the
high-level requirements and framework already described by documents
published by the SIPPING WG.
The deliverables for the group will be:
- - A mechanism for membership and authorization control
- - A mechanism to manipulate and describe media "mixing" or "topology" for
multiple media types (audio, video, text)
- - A mechanism for notification of conference related events/changes (for
example a floor change)
- - A basic floor control protocol
The initial set of protocols will be developed for use in unicast media
conferences. The working group will perform a second round of work to
enhance the set of protocols as necessary for use with multicast media
after their initial publication.
The following items are specifically out-of-scope:
- - Voting
- - Fully distributed conferences
- - Loosely-coupled conferences (no central point of control)
- - Far-end device control
- - Protocol used between the conference controller and the mixer(s)
- - Capabilities negotiation of the mixer(s)
- - Master-slave cascaded conferences
The working group will coordinate closely with the SIPPING and MMUSIC
working groups. In addition the working group will cooperate with other
groups as needed, including SIP, AVT, and the W3C SMIL working groups.
In addition, the working group will consider a number of existing drafts (a
non-exhaustive list is included below) as input to the working group.
Proposed Milestones
Oct 2003 Submit Requirements for Membership Manipulation for publication as
Informational
Oct 2003 Submit Requirements for Basic Floor Control for publication as
Informational
Nov 2003 Submit Conferencing Scenarios document for publication as
Informational
Nov 2003 Submit Use Cases for Media Topology Control for publication as
Informational
Dec 2003 Submit Requirements for Media Topology Control for publication as
Informational
Feb 2004 Submit Basic Floor Control Protocol for publication as PS
Mar 2004 Submit Notification Event package extension for conference related
events for publication as PS
May 2004 Submit Membership Manipulation Protocol for publication as PS
Jul 2004 Submit Protocol for Media Topology Control for publication as PS
4. Working Group Actions
4.1 WG Creation
4.1.2 Proposed for Approval
o Mobility for IPv6 - 2 of 2
Token: Thomas
Mobility for IPv6 (mip6)
--------------------
Charter
Last Modified: 2003-08-15
Current Status: Proposed Working Group
Chair(s):
Internet Area Director(s):
Thomas Narten (narten@us.ibm.com)
Margaret Wasserman (mrw@windriver.com)
Internet Area Advisor:
Thomas Narten (narten@us.ibm.com)
Mailing Lists:
General Discussion: mip6@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/mip6
In Body: put subscribe in subject
Archive:
www1.ietf.org/mail-archive/working-groups/mip6/current/
Description of Working Group:
Mobile IPv6 (MIPv6) specifies routing support to permit IPv6 hosts to
continue using its "permanent" home address as it moves around
the Internet. Mobile IPv6 supports transparency above the IP
layer, including maintenance of active TCP connections and UDP port
bindings. The specifications for these mechanisms consist of:
draft-ietf-mobileip-ipv6-24 and
draft-ietf-mobleip-mipv6-ha-ipsec-06
The protocol as specified in the above two documents can be considered as
the baseline or minimum protocol set for implementing IPv6
mobility. During the development phase of the base protocol, a few
additional features were identified as necessary to facilitate
deployment (described below).
The primary goal of the MIP6 working group is to improve the base
specification as a result of experience gained from implementation and
interop testing and to work on items that are deemed critical to getting
MIPv6 deployable on a large scale. Specifically, this includes:
1) Refining the base specifications based on experience of initial
implementations and interoperability testing.
2) Features such as renumbering of the home link, home agent discovery,
Route Optimization, which are currently a part of the base
specification can be specified more explicitly as separate
specifications. This will also enable modularizing the Mobile
IPv6 specification further into the minimal subset and add-on
features. Some of these specifications will be identified as
base mechanisims of Mobile IPv6.
3) A number of enhancements to basic IPv6 mobility were identified
during the development of the base specification. These
enhancements would be taken up in a phased manner depending on the
priority identified with each. Below are listed the work items to
be taken up by the WG:
- A bootstrap mechanism for setting up security associations
between the MN and HA that would enable easier deployment of
Mobile IPv6. This bootstrap mechanisim is intended to be used
when the device is turned on the very first time and activates
MIP. The WG should investigate and define the scope before
solving the problem.
- Improving home agent reliability: in the even of a home agent
crashing, this would allow another home agent to continue
providing service to a given mobile node.
- Support for the MN's changing addresses either because of
renumbering in its home network or because it periodically
changes addresses (perhaps via rfc3041)
- Route optimization will require security mechanisims for
trusting and updating the binding information. Return-routability
is the basic mechanism for route-optimization. Mechanisims using
a shared secret Key/Security Association will be considered.
Methods for establishing a security association between the mobile
node and the correspondent node are out of the scope of the WG.
- The working group will also document problem statements
associated with deploying Mobile IPv6 in the following areas:
a. Mobile IPv6 issues in the presence of firewalls
b. Mobile IPv6 deployment and transition issues in the presence
of IPv4/IPv6 networks
c. Multicast issues
It should be noted that there are potential optimizations that might
make mobile IP more attractive for use by certain applications (e.g.,
making handovers "faster"). The latter category of optimizations is
explicitly out-of-scope at this time; this WG will focus on issues
for which there is strong consensus that the work is needed to get
basic mobility deployable on a large scale.
Goals and Milestones:
Aug 03 Charter approval
Nov 03 Problem statement documents (to IESG)
- Issues with firewall
- Mobile IPv6 transition between v4/v6 networks
Nov 03 Bootstrapping problem statement to IESG
Feb 04 Submit MIPv6 MIB to IESG
Feb 04 Submit alternate security mechanisms for CN-MN to IESG
Mar 04 Submit alternate security mechanisms for HA-MN to IESG
Mar 04 Alternate Route Optimization scheme to IESG
May 04 Home agent reliability to IESG
Jul 04 Bootstrapping solution to IESG
Nov 04 Separate specs for HA Discovery, Route Optimization,
Renumbering to IESG
4. Working Group Actions
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
NONE
4. Working Group Actions
4.2 WG Rechartering
4.2.2 Proposed for Approval
NONE
5. Working Group News We Can Use
Harald Alvestrand
Steve Bellovin
Randy Bush
Bill Fenner
Ned Freed
Ted Hardie
Russ Housley
Allison Mankin
Thomas Narten
Jon Peterson
Margaret Wasserman
Bert Wijnen
Alex Zinin
6. IAB News We Can Use
7. Management Issues
o Procedures for Creating, Rechartering and Closing a Working Group (Harald Alvestrand)
https://www1.ietf.org/IESG/internal/Procedures/workinggroupactions.html
o Recording Retention Policy (Ted Hardie)
I propose that we establish a recording retention policy for telechats of
2 weeks, so that the records are deleted after the minutes of the past
telechat are approved.
o draft-baker-liaisons-00.txt (Bert Wijnen)
The IAB is looking at this document and they want to hear
if IESG has any concerns. Specifically if we have any
concerns with regard to the daily-management of such a
process.
The biggest potential issue I see is that it is not so
clear how we define a "consensus based" or an "authoritative"
answer back from a WG to another SDO.
It is a similar issue (in my view) as how we decide who can
be an official IETF liaison to some other SDO at one of their
meetings or such.
A lot of it has already been discussed in postings to both IAB and
IESG mailing lists, but I propose we all read/evaluate and see
if we have any issues. We can then feed that into the IAB.
Comments from Randy Bush regarding draft-baker-liaisons-00.txt:
that is (one reason) why we appoint liaisons
while, in general, the ietf is moving more from persons to
process, this movement itself is, and rightly should be,
slow. we do not need to have massive formal process to do
something unless we need it.
in this case i think we can trust our liaison to represent
the ietf on this particular channel, and to request more
formal process on a particular response (or stimulus) if it
is needed.
o Tony Hain appeal (Harald Alvestrand)
Background material: <http://www.ietf.org/IESG/Appeals.html>
Purpose of discussion:
- Evaluate what further information the IESG needs
- Assign a designated editor for an appeal response
o Todd Glassey appeal (Bert Wijnen)
Background material:
1. From the IPR WG chairs (Steve and Rob)
http://www.machshav.com/~smb/tg/
2. From the responsible AD (Harald)
http://www.alvestrand.no/ietf/ipr/suspension/glassey.html
3. The original appeal
http://www.ietf.org/IESG/APPEALS/todd-glassey-appeal.txt
4. Some postings to the iesg-only list.