[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Agenda and Package for September 4, 2003 Telechat
[dropped iesg-secretary to help on ticket]
I think we have the following bug that needs fixing.
The current Web agenda has a clickable link for "Management Issues",
with the management issues only viewable after clicking the link. This
(presumably) causes them to not be listed on the agenda summary at the
top of the package as Bert reports.
Because a number of us use the summary agenda to figure out what is
on the agenda, each item needs to be listed there. This is also
consistent with the old agenda we were using a few weeks ago, which
listed the each management item in the agenda summary.
I think its fine to have each management item be a one line summary,
with a clickable link to the details. Sometimes, this is overkill
(because the link would point to 2 sentences), but it is also fairly
common for the info that goes with an item to be long (e.g, a mail
message of several screenfulls). The latter can make it hard to
actually see what the individual items are, if all of the details are
included here. Thus, a one-line name/summary on the agenda makes sense
to me.
If this makes sense to others, Bert can file a bug report.
Thomas
> Mmm... I though we agreed at the last telechat that the
> Tod Glassey appeal would be put on the agenda again.
> It should be as last item under Management Issues.
> I now see it is listed at the very bottom of the package.
> But I suspect that some may not see that cause we used
> to have at least the topics listed at the beginning in
> the agenda.
> So having the details at the bottom is fine, but it would
> be good to have the topics listed under te short agenda,
> so people are ware that which Management Issue are scheduled.
> For the Tod Glassey appeal, pls add these details.
> 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.
> Bert
> > -----Original Message-----
> > From: IESG Secretary [mailto:iesg-secretary@ietf.org]
> > Sent: zaterdag 30 augustus 2003 0:05
> > To: iesg@ietf.org
> > Cc: bfuller@foretec.com; amyk@foretec.com
> > Subject: Agenda and Package for September 4, 2003 Telechat
> >
> >
> > Dear IESG Members,
> >
> > Due to the Labor Day holiday weekend, the updated agenda package for
> > the September 4, 2003 IESG teleconference will be sent on the
> > afternoon of
> > Tuesday, September 2, 2003 instead of Monday, September 1, 2003. The
> > final package will be sent on Wednesday, September 3, 2003 as
> > scheduled.
> >
> > Thank you,
> >
> > The IESG Secretary
> >
> > --------------
> >
> > INTERNET ENGINEERING STEERING GROUP (IESG)
> > Summarized Agenda for the September 4, 2003 IESG Teleconference
> >
> > This summary was generated at 17:28:2 EDT, August 29, 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 1
> > - 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
> >
> >
> > 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
> >
> > --------------------------------------------------------------
> > ----------------
> >
> >
> > INTERNET ENGINEERING STEERING GROUP (IESG)
> > Agenda for the September 4, 2003 IESG Teleconference
> >
> > This package was generated at 17:28:2 EDT, August 29, 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--- Will call in
> > 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 1
> >
> > 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.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/workinggroupact
> ions.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 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)