[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Agenda and Package for August 7, 2003 Telechat, 2nd Draft
INTERNET ENGINEERING STEERING GROUP (IESG)
Agenda for the August 7, 2003 IESG Teleconference
1. Administrivia
o Roll Call
Dear IESG Members:
The next IESG teleconference will take place on Thursday, August 7, 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
Marcia Beaulieu---Regrets
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---Will call in
Barbara Fuller---Will call in
Ted Hardie---Will call in
Jacqueline Hargest---Regrets
Russ Housley---Regrets
Allison Mankin---Will call in
Thomas Narten---Will call in
Jon Peterson---Will call in
Joyce K. Reynolds---Will call in
Dinara Suleymanova---Regrets
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.
o Bash the Agenda
o Approval of the Minutes
- July 10, 2003
o Review of Action Items
OUTSTANDING TASKS
Last updated: July 31, 2003
IP o Allison Mankin to review draft-agrawal-sip-h323-interworking-reqs
and send decision to IESG.
IP o Bert Wijnen to document process of how the IESG goes about asking architectural
questions of the IAB
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 Hardie 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.
IP o Ted Hardie to send the Secretariat a message to forward to the RFC Editor
indicating that the Do Not Publish note that was originally created for
draft-paskin-doi-uri-03.txt also applies to draft-paskin-doi-uri-04.txt.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item
o draft-ietf-pkix-wlan-extns-04.txt
Certificate Extensions and Attributes Supporting Authentication in PPP
and Wireless LAN (Proposed Standard)
Token: Steve Bellovin
o draft-ietf-impp-im-03.txt
Common Profile for Instant Messaging (CPIM) (Proposed Standard)
Token: Hardie, Ted
- draft-ietf-impp-cpim-msgfmt-08.txt
Common Presence and Instant Messaging: Message Format (Proposed
Standard)
- draft-ietf-impp-cpim-pidf-08.txt
Presence Information Data Format (PIDF) (Proposed Standard)
- draft-ietf-impp-pres-03.txt
Common Profile for Presence (CPP) (Proposed Standard)
- draft-ietf-impp-srv-03.txt
Address Resolution for Instant Messaging and Presence (Proposed
Standard)
o draft-ietf-dhc-isnsoption-08.txt
The IPv4 DHCP Options for the Internet Storage Name Service (Proposed
Standard)
Token: Thomas Narten
Note: Title says "options" rather than "option" but otherwise ready.
o draft-ietf-dhc-dhcpv6-opt-prefix-delegation-04.txt
IPv6 Prefix Options for DHCPv6 (Proposed Standard)
Token: Thomas Narten
o draft-ietf-secsh-dns-04.txt
Using DNS to securely publish SSH key fingerprints (Proposed Standard)
Token: Housley, Russ
o draft-ietf-ipsec-ciph-aes-ctr-05.txt
Using AES Counter Mode With IPsec ESP (Proposed Standard)
Token: Steve Bellovin
o draft-ietf-smime-camellia-04.txt
Use of the Camellia Encryption Algorithm in CMS (Proposed Standard)
Token: Housley, Russ
o draft-ietf-ipv6-flow-label-07.txt
IPv6 Flow Label Specification (Proposed Standard)
Token: Thomas Narten
o draft-schryver-pppext-iana-01.txt
IANA Considerations for the Point-to-Point Protocol (PPP) (BCP)
Token: Thomas Narten
Note: I have some nits that will need cleaning up before IESG approval,
but document seems fine overall.
2.1.2 Returning Item
o draft-ietf-policy-qos-device-info-model-10.txt
Information Model for Describing Network Device QoS Datapath Mechanisms
(Proposed Standard)
Token: Bert Wijnen
Note: Returning document to IESG agenda. Allison still has a DISCUSS to
be documented. Responsible: Bert
o draft-ietf-policy-qos-info-model-05.txt
Policy QoS Information Model (Proposed Standard)
Token: Bert Wijnen
Note: Returning this to IESG telechat This to force resolution of a
DEFER and a DISCUSS. Responsible: Bert Wijnen
o draft-ietf-kink-kink-05.txt
Kerberized Internet Negotiation of Keys (KINK) (Proposed Standard)
Token: Bellovin, Steve
2.2 Individual Submissions
2.2.1 New Item
NONE
2.2.2 Returning Item
o draft-mealling-iana-xmlns-registry-05.txt
The IETF XML Registry (BCP)
Token: Ted Hardie
o draft-zeilenga-ldap-collective-08.txt
Collective Attributes in LDAP (Proposed Standard)
Token: Ted Hardie
Note: New versions exists which is verified with IESG Responsible:
Patrik
- draft-zeilenga-ldap-subentry-07.txt
Subentries in LDAP (Proposed Standard)
- draft-legg-ldap-gser-abnf-07.txt
Common Elements of GSER Encodings (Informational)
- draft-legg-ldap-gser-04.txt
Generic String Encoding Rules for ASN.1 Types (Proposed Standard)
o draft-yergeau-rfc2279bis-05.txt
UTF-8, a transformation format of ISO 10646 (Standard)
Token: Ted Hardie
3. Document Actions
3.1 WG Submissions
3.1.1 New Item
o draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt
An analysis of IPv6 anycast (Informational)
Token: Nordmark, Erik
Note: Ready for IESG agenda
o draft-ietf-ieprep-ets-general-03.txt
General Requirements for Emergency Telecommunication Service
(Informational)
Token: Jon Peterson
o draft-ietf-xmldsig-xpf2-00.txt
XML-Signature XPath Filter 2.0 (Informational)
Token: Housley, Russ
o draft-ietf-dhc-unused-optioncodes-05.txt
Unused DHCP Option Codes (Informational)
Token: Thomas Narten
Note: 2003-06-24: sent comments to list (mainly nits).
3.1.2 Returning Item
o draft-ietf-xmldsig-xc14n-01.txt
Exclusive XML Canonicalization, Version 1.0 (Informational)
Token: Housley, Russ
o draft-ietf-pkix-pr-tsa-04.txt
Policy Requirements for Time-Stamping Authorities (Informational)
Token: Housley, Russ
3.2 Indiviual Submissions Via AD
3.2.1 New Item
o draft-fink-6bone-phaseout-04.txt
6bone (IPv6 Testing Address Allocation) Phaseout (Informational)
Token: Bush, Randy
3.2.2 Returning Item
NONE
3.3 Indiviual Submissions Via RFC Editor
3.3.1 New Item
NONE
3.3.2 Returning Item
o draft-shah-extreme-eaps-03.txt
Extreme Networks'Ethernet Automatic Protection Switching (EAPS),
Version 1 (Informational)
Token: Thomas Narten
Note: Note to IESG: Checked with IEEE and they don't have a problem
with this document.
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
o Mobility for IPv4
Token: Thomas
o Centralized Conferencing
Token: Allison
4.1.2 Proposed for Approval
NONE
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
o Multicast Security
o IP over Cable Data Network
Token: Bert
o AToM MIB
Token: Bert
4.2.2 Proposed for Approval
NONE
5. Working Group News We Can Use
6. IAB News We Can Use
* Review of boxes and arrows
IESG,
I had posted the below a while ago, but it was just
before the IETF meeting in Vienna, so maybe it got
lost. By putting this on the Telechat Agenda, I am
trying to gently force everyone to read it and to
comment so we can feed back to Eric and IAB. In fact,
feel free to post to Eric and or IAB list directly.
The document in question is: http://www.rtfm.com/model.txt
Thanks,
Bert
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: woensdag 9 juli 2003 16:19
> To: Iesg (E-mail)
> Subject: From IAB: Protocol models document
>
>
> Eric Rescorla has a rought draft for an I-D that he
> would appreciate feedback on. I took a quick look at
> it, and it seems to me if people follow this advice,
> then reviewing documents would become much easier for
> people like ourselves but also for others.
>
> The ptr is: http://www.rtfm.com/model.txt
>
> Feedback to Eric or to the iab mailing list please.
>
> Thanks,
> Bert
>
> > -----Original Message-----
> > From: Eric Rescorla [mailto:ekr@rtfm.com]
> > Sent: dinsdag 8 juli 2003 22:32
> > To: iab@ietf.org
> > Subject: Protocol models document
> >
> >
> > I know that I've talked to a few of you about what I call "protocol
> > models" or more informally "boxes and arrows". The basic idea
> > is that it would be very nice if protocol authors wrote up
> high-level
> > summaries of how the protocol worked so that reviewers could grasp
> > the important elements before they read the entire document. I've
> > written up a document that describes what I consider a useful method
> > for presenting this kind of model, which can be found at:
> >
> > http://www.rtfm.com/model.txt
> >
> >
> > I'd like to get IAB comments before submitting it as an
> I-D. It's not
> > clear that this is appropriate as an IAB document--quite probably
> > not--though I have no objection to making it one. However,
> I think the
> > IAB would be a good group to get opinions from.
> >
> > In particular, one of my examples is DCCP, so I'd like to
> get comments
> > from Mark and Sally as to whether i've totally bungled things.
> >
> > -Ekr
> >
>
7. Management Issues
* IESG architectural questions to IAB
This is a direct result of my ACTION ITEM:
IP o Erik to document process of how the IESG goes about asking architectural
questions of the IAB
Yep, it still seems listed under Erik (on the online draft agenda),
but I inherited that work/action item at the last telechat.
For the IESG, below is the proposed procedure.
-- draft procedure for: how IESG sends architectural questions to IAB--
When we (IESG) want architectural help/review from/by the IAB,
then we should properly formulate what we expect.
What we should make clear is:
1. What is the exact architural question we have. Would be best
if IESG has consensus on the question as well.
2. What type of response we want to get, e.g. one or more of
- a document;
- a (few) paragraph(s),
- an e-mail to IESG or some specific mailing list
- discussion with IESG or some specific WG
3. By what time we expect the above to happen
4. If we believe we know who on the IAB would have the appropriate
background to tackle the problem, we should be prepared to
inform IAB, IAB-chair or specific person(s) about that.
Steps:
- Once IESG agrees on the above, we (IESG chair) send(s) an
email to the iab mailing list.
- The first round of discussions is then to make sure that IAB and
IESG have a common understanding of the question and expected
delivery and time-frame.
- If IAB however has clarifying questions then we need to discuss
and explain, which may result in a re-statement of the question.
This discussion is expected to happen on both iab and iesg mailing
lists. Sometimes things may be easy and do not need this step.
- Once IAB and IESG agree on the question, the deliverable,
and the respective IAB & IESG members who are designated as
responsible for seeing this activity to completion, the
IAB starts the work and delivers as requested. The designated
stuckees may continue to discuss (liaise) refinements as needed.
- When IAB thinks they have delivered, they (IAB chair) send(s) an
email to IESG saying so and pointing to the deliverable.
- IESG checks and IESG chair lets IAB know if they are happy and
if not explain why not.
Bert
DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT
INTERNET ENGINEERING STEERING GROUP (IESG)
Minutes of the July 10, 2003 IESG Teleconference
Reported by: Amy Vezza, IETF Secretariat
ATTENDEES
------------------
Harald Alvestrand / Cisco
Rob Austein / IAB Liaison
Steve Bellovin / AT&T
Randy Bush / IIJ
Leslie Daigle / Verisign (IAB)
Bill Fenner / AT&T
Ned Freed / Sun Microsystems
Barbara Fuller / IETF Secretariat
Ted Hardie / Qualcomm, Inc.
Russ Housley / Vigil Security, LLC
Allison Mankin / Bell Labs, Lucent
Thomas Narten / IBM
Erik Nordmark / Sun
Jon Peterson / NeuStar, Inc.
Dinara Suleymanova / IETF Secretariat
Amy Vezza / IETF Secretariat
Bert Wijnen / Lucent
Alex Zinin / Alcatel
REGRETS
------------
Marcia Beaulieu / IETF Secretariat
Michelle Cotton / ICANN
Jacqueline Hargest / IETF Secretariat
Joyce K. Reynolds / ISI (RFC Editor)
MINUTES
---------------
1. Administrivia
1.1 Approval of the Minutes
The minutes of the June 26, 2003 Teleconference were approved
pending removal of the "Web notes." The Secretariat will place
the minutes in the public archives.
1.2 Review of Action Items
DONE:
o Harald Alvestrand to talk to RFC Editor about independent
submissions.
o Thomas Narten to coordinate and send comments on minutes
to the Secretariat. IESG to review the format of the minutes
and propose changes to improve readability and communication
to the outside world.
o Steve Bellovin to make proposal to discuss "problem" at the
Sunday IESG meeting in Vienna.
o Thomas Narten to write up issue with references in
draft-dasilva-l2tp-relaysvc-06.txt and start discussion in
IESG list.
DELETED:
NONE
IN PROGRESS:
o Allison Mankin to review draft-agrawal-sip-h323-interworking-reqs and send
decision to IESG.
o Bert Wijnen to document process of how the IESG goes about asking architectural
questions of the IAB.
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 Directorates 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:
o Ted Hardie to send the Secretariat a message to forward to the RFC Editor
indicating that the Do Not Publish note that was originally created for
draft-paskin-doi-uri-03.txt also applies to draft-paskin-doi-uri-04.txt.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item
o draft-ietf-atommib-atm2-19.txt - 1 of 10
Definitions of Supplemental Managed Objects for ATM Interface (Proposed
Standard)
Token: Nordmark, Erik
The document was approved by the IESG pending an RFC Editor Note to be
prepared by Erik Nordmark. The Secretariat will send a working group
submission Protocol Action Announcement that includes the RFC Editor Note.
o draft-ietf-policy-qos-device-info-model-10.txt - 2 of 10
Information Model for Describing Network Device QoS Datapath Mechanisms
(Proposed Standard)
Token: Wijnen, Bert
The document remains under discussion by the IESG in order to resolve
points raised by Allison Mankin.*
o draft-ietf-policy-qos-info-model-05.txt - 3 of 10
Policy QoS Information Model (Proposed Standard)
Token: Wijnen, Bert
The document was deferred to the next teleconference by Steve Bellovin.
The document remains under discussion by the IESG in order to resolve
points raised by Russ Housley.*
o draft-ietf-sip-sctp-03.txt - 4 of 10
The Stream Control Transmission Protocol as a Transport for for the
Session Initiation Protocol (Proposed Standard)
Token: Mankin, Allison
The document remains under discussion by the IESG in order to resolve
points raised by Steve Bellovin, Ned Freed, and Ted Hardie.*
o Set of two documents - 5 of 10
- draft-ietf-ips-fcip-slp-07.txt
Finding FCIP Entities Using SLPv2 (Proposed Standard)
- draft-ietf-ips-isci-slp-06.txt
Finding iSCSI Targets and Name Servers Using SLP (Proposed Standard)
Token: Mankin, Allison
The documents were deferred to the next teleconference by Thomas Narten.
The documents remain under discussion by the IESG in order to resolve
points raised by Steve Bellovin and Ted Hardie.*
o draft-ietf-sipping-3pcc-04.txt - 6 of 10
Best Current Practices for Third Party Call Control in the Session
Initiation Protocol (BCP)
Token: Mankin, Allison
The document was deferred to the next teleconference by Steve Bellovin.
The document remains under discussion by the IESG in order to resolve
points raised by Russ Housley and Erik Nordmark.*
o draft-ietf-dnsext-rfc1886bis-03.txt - 7 of 10
DNS Extensions to support IP version 6 (Draft Standard)
Token: Nordmark, Erik
The document was approved by the IESG pending an RFC Editor Note to be
prepared by Erik Nordmark. The Secretariat will send a working group
submission Protocol Action Announcement that includes the RFC Editor
Note.
o draft-ietf-ospf-hitless-restart-07.txt - 8 of 10
Graceful OSPF Restart (Proposed Standard)
Token: Zinin, Alex
The document remains under discussion by the IESG in order to resolve
points raised by Ted Hardie.*
o draft-ietf-webdav-ordering-protocol-09.txt - 9 of 10
WebDAV Ordered Collections Protocol (Proposed Standard)
Token: Hardie, Ted
The document remains under discussion by the IESG in order to resolve
points raised by Allison Mankin.*
o draft-ietf-avt-rtcp-report-extns-06.txt - 10 of 10
RTP Control Protocol Extended Reports (RTCP XR) (Proposed Standard)
Token: Mankin, Allison
The document was approved by the IESG pending an RFC Editor Note to be
prepared by Jon Peterson and Allison Mankin. The Secretariat will send a
working group submission Protocol Action Announcement that includes
the RFC Editor Note.
2.1.2 Returning Item
o draft-ietf-dnsext-gss-tsig-06.txt - 1 of 7
GSS Algorithm for TSIG (GSS-TSIG) (Proposed Standard)
Token: Nordmark, Erik
The document was approved by the IESG. The Secretariat will send a
working group submission Protocol Action Announcement.
o draft-katz-yeung-ospf-traffic-10.txt - 2 of 7
Traffic Engineering Extensions to OSPF Version 2 (Proposed Standard)
Token: Fenner, Bill
The document remains under discussion by the IESG in order to resolve
points raised by Thomas Narten, and by Thomas Narten on behalf of IANA.*
o draft-ietf-dnsext-ad-is-secure-06.txt - 3 of 7
Redefinition of DNS AD bit (Proposed Standard)
Token: Nordmark, Erik
The document was approved by the IESG pending an RFC Editor Note to be
prepared by Erik Nordmark. The Secretariat will send a working group
submission Protocol Action Announcement that includes the RFC Editor Note.
o draft-ietf-enum-rfc2916bis-06.txt - 4 of 7
The E.164 to URI DDDS Application (ENUM) (Proposed Standard)
Token: Mankin, Allison
The document remains under discussion by the IESG in order to resolve
points raised by Ted Hardie.*
o draft-ietf-sip-scvrtdisco-04.txt - 5 of 7
Session Initiation Protocol Extension Header Field for Service Route
Discovery During Registration (Proposed Standard)
Token: Mankin, Allison
The document remains under discussion by the IESG in order to resolve
points raised by Allison Mankin on behalf of IANA.*
o draft-ietf-magma-mld-source-07.txt - 6 of 7
Source Address Selection for Multicast Listener Discovery Protocol (RFC
2710) (Proposed Standard)
Token: Nordmark, Erik
The document was approved by the IESG. The Secretariat will send a
working group submission Protocol Action Announcement.
o draft-ietf-mobileip-mipv6-ha-ipsec-06.txt - 7 of 7
Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and
Home Agents (Proposed Standard)
Token: Narten, Thomas
The document remains under discussion by the IESG in order to resolve
points raised by Steve Bellovin and Randy Bush.*
2.2 Individual Submissions
2.2.1 New Item
NONE
2.2.2 Returning Item
o draft-legg-ldapext-component-matching-11.txt - 1 of 1
LDAP & X.500 Component Matching Rules (Proposed Standard)
Token: Hardie, Ted
The document was approved by the IESG pending an RFC Editor Note to be
prepared by Ted Hardie. The Secretariat will send an individual
submission Protocol Action Announcement that includes the RFC Editor Note.
3. Document Actions
3.1 WG Submissions
3.1.1 New Item
o draft-ietf-gsmp-reqs-06.txt - 1 of 3
Requirements For Adding Optical Support To GSMPv3 (Informational)
Token: Wijnen, Bert
The document was approved by the IESG pending an RFC Editor Note to be
prepared by Allison Mankin and Bert Wijnen. The Secretariat will send
a working group submission Document Action Announcement that includes the
RFC Editor Note.
o draft-ietf-sipping-3gpp-r5-requirements-00.txt - 2 of 3
3rd-Generation Partnership Project (3GPP) Release 5 requirements on the
Session Initiation Protocol (SIP) (Informational)
Token: Mankin, Allison
The document remains under discussion by the IESG.* Allison Mankin will
prepare a revised IESG Note.
o draft-ietf-manet-tbrpf-09.txt - 3 of 3
Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)
(Experimental)
Token: Zinin, Alex
The document remains under discussion by the IESG to address
points raised by IANA.*
3.1.2 Returning Item
o draft-ietf-pkix-ipki-new-rfc2527-02.txt - 1 of 4
Internet X.509 Public Key Infrastructure Certificate Policy and
Certification Practices Framework (Informational)
Token: Housley, Russ
The document was approved by the IESG. The Secretariat will send
a working group submission Document Action Announcement.
o draft-ietf-ippm-owdp-reqs-06.txt - 2 of 4
A One-way Active Measurement Protocol Requirements (Informational)
Token: Mankin, Allison
The document remains under discussion by the IESG.*
o draft-ietf-manet-olsr-11.txt - 3 of 4
Optimized Link State Routing Protocol (Experimental)
Token: Zinin, Alex
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-crisp-requirements-05.txt - 4 of 4
Cross Registry Internet Service Protocol (CRISP) Requirements
(Informational)
Token: Freed, Ned
The Document remains under discussion by the IESG.*
3.2 Individual Submissions Via AD
3.2.1 New Item
o draft-savola-ipv6-127-prefixlen-04.txt - 1 of 2
Use of /127 Prefix Length Between Routers Considered Harmful
(Informational)
Token: Bush, Randy
The document was approved by the IESG. The Secretariat will send a
n individual submission Document Action Announcement.
o draft-siemborski-mupdate-04.txt - 2 of 2
The MUPDATE Distributed Mailbox Database Protocol (Experimental)
Token: Freed, Ned
The document was deferred to the next teleconference by Ted Hardie.
3.2.2 Returning Item
NONE
3.3 Individual Submissions Via RFC Editor
3.3.1 New Item
o draft-song-pppext-sip-support-02.txt - 1 of 1
SIP server IPCP configuration option for PPP (Informational)
Token: Narten, Thomas
The IESG recommends that the RFC Editor does not publish this
document. The Secretariat will send a "do not publish" message
prepared by Thomas Narten to the RFC Editor.
3.3.2 Returning Item
o Set of three documents - 1 of 3
- draft-sun-handle-system-11.txt
Handle System Overview (Informational)
- draft-sun-handle-system-def-08.txt
Handle System Namespace and Service Definition (Informational)
- draft-sun-handle-system-protocol-05.txt
Handle System Protocol (ver 2.1) Specification (Informational)
Token: Hardie, Ted
The IESG has no problem with the RFC Editor publishing these documents.
Ted Hardie will prepare a "no problem" message, and forward it to the
Secretariat to send to the RFC Editor.
o draft-bradner-pbk-frame-06.txt - 2 of 3
A Framework for Purpose-Built Keys (PBK) (Informational)
Token: Bellovin, Steve
The document remains under discussion by the IESG.*
o draft-leech-chinese-lottery-04.txt - 3 of 3
Chinese Lottery Cryptanalysis Revisited: The Internet as Codebreaking
Tool (Informational)
Token: Bellovin, Steve
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 RFC Editor Note to be prepared by Steve
Bellovin.
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
NONE
4.1.2 Proposed for Approval
NONE
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 Sunday's agenda (added by Harald Alvestrand)
- Is 1000-1400 enough time?
- Are the topics listed the most important ones?
(discussed)
o Routing Protocol overload (added by Alex Zinin)
(discussed)
----------------------------------------
* Please see the ID Tracker
(https://datatracker.ietf.org/public/pidtracker.cgi) for details
on documents that are under discussion by the IESG.
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-pkix-wlan-extns -
Certificate Extensions and Attributes Supporting
Authentication in PPP and Wireless LAN
--------
Last Call to expire on: 2002-12-16
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ X ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ X ] [ ]
Russ Housley [ ] [ ] [ ] [ R ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Ted Hardie:
Discuss:
Since there is no guarantee of uniqueness for SSIDs,
it seems like there may be a separate step needed
when you have the "every SSID is called CORP" problem.
This text, in particular:
The Wireless LAN (WLAN) System Service identifiers (SSIDs) public key
certificate extension is always non-critical. It contains a list of
SSIDs. When more than one certificate includes an extended key usage
extension indicating that the certified public key is appropriate for
use with the EAP in the LAN environment, the list of SSIDs MAY be
used to select the correct certificate for authentication in a
particular WLAN.
may need to contain text on what to do if more than one certificate
contains the same octet string as an SSID. Given that the whole
thing is a "MAY" the answer may well be "try them in turn" or
something very basic, but a note of the problem and what to do
would be useful.
thanks,
Ted
^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>, <ietf-pkix@imc.org>
Subject: Protocol Action: 'Certificate Extensions and Attributes
Supporting Authentication in PPP and Wireless LAN' to Proposed
Standard
The IESG has approved the Internet-Draft 'Certificate Extensions and
Attributes Supporting Authentication in PPP and Wireless LAN'
<draft-ietf-pkix-wlan-extns-04.txt> as a Proposed Standard. This document
is the product of the Public-Key Infrastructure (X.509) Working Group. The
IESG contact persons are Steve Bellovin and Russ Housley.
Technical Summary
Certificates have to be flagged for particular uses. Thus, an email certificate
can't be used for code-signing. This document describes how to mark a certificate
for PPP and Wireless LAN authentication.
Working Group Summary
There was working group consensus to advance this document.
Protocol Quality
The 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 Scretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-impp-im -
Common Profile for Instant Messaging (CPIM)
--------
This Evaluation reflects positions for a set of five documents:
<draft-ietf-impp-im-03.txt> Common Profile for Instant Messaging (CPIM)
<draft-ietf-impp-srv-03.txt> Address Resolution for Instant Messaging and Presence
<draft-ietf-impp-cpim-msgfmt-08.txt> Common Presence and Instant Messaging: Message Format
<draft-ietf-impp-pres-03.txt> Common Profile for Presence (CPP)
<draft-ietf-impp-cpim-pidf-08.txt> Presence Information Data Format (PIDF)
Last Call to expire on: 2003-06-27
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ X ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ R ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
^L
---- following is a DRAFT of message to be sent AFTER approval ---
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce:;
Cc: "RFC Editor" <rfc-editor@isi.edu>,
"Internet Architecture Board" <iab@iab.org>, <impp@iastate.edu>
Subject: Protocol Action: 'Common Profile for Instant Messaging
(CPIM)' to a Proposed Standard
------------------------
The IESG has approved the Internet-Drafts 'Common Profile for Instant
Messaging (CPIM)' <draft-ietf-impp-im-03.txt>, 'Address Resolution for
Instant Messaging and Presence' <draft-ietf-impp-srv-03.txt>, 'Common
Presence and Instant Messaging: Message Format'
<draft-ietf-impp-cpim-msgfmt-08.txt>, 'Common Profile for Presence
(CPP)' <draft-ietf-impp-pres-03.txt>, and 'Presence Information Data
Format (PIDF)' <draft-ietf-impp-cpim-pidf-08.txt>, each as
Proposed Standard.
These documents are the product of the Instant Messaging and Presence
Protocol Working Group.
The IESG contact persons are Ned Freed and Ted Hardie
Technical Summary
These documents form the basis for a mechanism by which multiple
distinct Instant Messaging applications may pass messages among
the different systems while retaining the ability to use end-to-end
encryption, integrity protection, and a shared framework for presence
information.
The work on PIDF (Presence Information Data Format) is already in
widespread usage by the SIP-based instant messaging community,
as is the message format described.
Working Group Summary
The IMPP working group was originally chartered to develop requirements
and then protocols which would provide an "Internet-scale end-user
presence awareness, notification and instant messaging system". The group
delivered RFCs 2778 and 2779 defining a model and requirements for
instant messaging, but it was unable to select among the candidate
protocols for this task even after setting up a nine-member design
and review team. After this impasse was reached, the work of
development was split to allow for multiple, interoperable transport protocols.
While the tasks assigned to those groups chartered after the split
are relatively clear in their charters, the work to be done by IMPP
was, regrettably, not defined in a new charter. As a result, the
task taken on by these documents represents the rough consensus
of the group as determined by the chairs; there remains, however,
a view that the group was chartered to define minimal gateway
semantics for the multiple IM systems, thus rendering end-to-end
encryption and data integrity out of scope, rather than the formats
and framework defined by these documents.
In evaluating these documents, the IESG has thus both needed to assess
whether the documents meet the needs of the work plan as the chairs
have understood it and whether the work plan itself was on target. The
IESG greatly regrets the necessity of this second task and its failure in
not updating the charter of IMPP. It does not, however, believe that refusing
to advance the documents on the basis of this failure is appropriate,
as it is contrary to the promotion of interoperability in this arena. Instead,
the IESG has been guided by the charters granted to the successor groups,
by the place end-to-end security normally holds in IETF protocol
analyses, and by a careful review of the mailing list and minutes of the
meetings subsequent to the split. The IESG has, through this review,
concluded that the work plan described by the chairs was on target
and has conducted their technical review of the documents solely on
the question of whether the documents meet the need outlined by that plan.
In its technical evaluation, the IESG noted that many of the formats and
discovery mechanisms described are already in use or replicate well-known
existing mechanism. They reflect that maturity in their description
and completeness.
The core document on CPIM, in contrast, represents a fairly abstract
description
of the service. The IESG believes that the documents are of sufficient quality
to be the basis of an interoperable service, but notes that it
expects the development of documents mapping CPIM to specific
protocols to show how to make the
abstract terms in CPIM concrete. Further, it expects that
interoperability reports
presented for the transition to draft standard would include multiple
protocols,
as well as the usual requirement that the implementations be independent.
Protocol Quality
The documents were reviewed for the IESG by Ted Hardie.
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-isnsoption -
The IPv4 DHCP Options for the Internet Storage Name Service
--------
Last Call to expire on: 2003-07-22
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ X ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
^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@isi.edu>, <dhcwg@ietf.org>
Subject: Protocol Action: 'The IPv4 DHCP Options for the Internet
Storage Name Service' to Proposed Standard
The IESG has approved the Internet-Draft 'The IPv4 DHCP Options for the
Internet Storage Name Service' <draft-ietf-dhc-isnsoption-08.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 the DHCP option to allow Internet Storage Name
Service (iSNS) clients to automatically discover the location of the
iSNS server through the use of DHCP for IPv4.
Working Group Summary
There was support in both the DHC and IPS WGs for this option.
Protocol Quality
This document has been reviewed for the IESG by 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-prefix-delegation -
IPv6 Prefix Options for DHCPv6
--------
Last Call to expire on: 2003-06-24
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ X ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
^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@isi.edu>, <dhcwg@ietf.org>
Subject: Protocol Action: 'IPv6 Prefix Options for DHCPv6' to
Proposed Standard
The IESG has approved the Internet-Draft 'IPv6 Prefix Options for DHCPv6'
<draft-ietf-dhc-dhcpv6-opt-prefix-delegation-04.txt> as 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
The Prefix Delegation options provide a mechanism for automated
delegation of IPv6 prefixes using DHCP. This mechanism is intended
for delegating a long-lived prefix from a delegating router (e.g., at
an ISP) to a requesting router (e.g., at a customer site), across an
administrative boundary, where the delegating router does not require
knowledge about the topology of the links in the network to which the
prefixes will be assigned.
The Prefix Delegation option makes it possible for an ISP to
dynamically assign a prefix of arbitraty size (e.g., a /64 or /48) to
an end site, with the end site taking responsibility for further
sub-dividing the prefix and assigning subnet numbers to its internal
links.
Working Group Summary
There was WG consensus for this document in both the DHC and IPv6 WGs.
Protocol Quality
This protocol has been reviewed for the IESG by Thomas Narten. The
option has been implemented (e.g., it is being tested at
interoperability events) and some ISPs in Japan have started using it.
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Scretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-secsh-dns -
Using DNS to securely publish SSH key fingerprints
--------
Last Call to expire on: 2003-05-19
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 [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ X ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Randy Bush:
Discuss:
1. Introduction
The SSH [5] protocol provides secure remote login and other secure
network services over an insecure network. The security of the
connection relies on the server authenticating itself to the client.
it also relies on the user on the client host authenticating
themself to the server. though this is not germane to this
document, the above statement could be dangerous out of context.
---
Server authentication is normally done by presenting the fingerprint
of an unknown public key to the user for verification.
the public key is not unknown, in fact the opposite. if it was
unknown, then all ssh would offer is being able to talk to the same
liar all the time. :-)
perhaps "unique" is what was meant?
---
2.4 Authentication
A public key verified using this method MUST only be trusted if the
SSHFP resource record (RR) used for verification was authenticated by
a trusted SIG RR.
may want to say that the trust must either come from a validated
trust descent from the root or from a validated descent from a zone
trusted because of a locally known association.
---
The overall security of using SSHFP for SSH host key verification is
dependent on detailed aspects of how verification is done in SSH
implementations.
and of the practices of securing the data inserted in the SSHFP RR
in the dns and in the client host's diligence in accessing those
data securely. c.f. the discussion on
draft-ietf-dnsext-ad-is-secure-06.txt
---
nits:
fingerprint out-of-band before accepting the key, many users blindly
accepts the presented key.
^
-
algorithm and fingerprint of the key received from the SSH server
matches the algorithm and fingerprint of one of the SSHFP resource
^^
-
A message digest of the public key, using the message digest
algorithm specified in the SSHFP fingerprint type, MUST match the
SSH FP fingerprint.
^
-
3.2 Presentation Format of the SSHFP RR
The presentation format of the SSHFP resource record consists of two
numbers (algorithm and fingerprint type) followed by the fingerprint
itself presented in hex, e.g:
host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890
well bad wording, actually, as the example shows, the presentation
format consists of the label, the RR type, SSHFP, and ...
randy
^L
---- following is a DRAFT of message to be sent AFTER approval ---
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce:;
Cc: "RFC Editor" <rfc-editor@isi.edu>,
"Internet Architecture Board" <iab@iab.org>, <ietf-ssh@netbsd.org>
Subject: Protocol Action: 'Using DNS to securely publish SSH key
fingerprints' to a Proposed Standard
------------------------
The IESG has approved the Internet-Draft 'Using DNS to securely
publish Secure Shell key fingerprints' <draft-ietf-secsh-dns-04.txt>
as a Proposed Standard. This document is the product of the Secure
Shell Working Group. The IESG contact persons are Russell Housley
and Steven Bellovin.
Technical Summary
This document describes a method to verify Secure Shell (SSH) host
keys using DNS security (DNSSEC). The document defines a new DNS
resource record that contains a standard SSH key fingerprint.
Working Group Summary
The Secure Shell Working Group came to consensus on this document.
Protocol Quality
This document was reviewed by Russell Housley for the IESG.
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-ctr -
Using AES Counter Mode With IPsec ESP
--------
Last Call to expire on: 2003-04-24
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ X ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ R ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
^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>, <ipsec@lists.tislabs.com>
Subject: Protocol Action: 'Using AES Counter Mode With IPsec ESP'
to Proposed Standard
The IESG has approved the Internet-Draft 'Using AES Counter Mode With IPsec
ESP' <draft-ietf-ipsec-ciph-aes-ctr-05.txt> as a Proposed Standard. This
document is the product of the IP Security Protocol Working Group. The IESG
contact persons are Steve Bellovin and Russ Housley
Technical Summary
This is a new cipher description for IPsec. In particular, it describes how to
use AES in counter mode within the ESP framework. Counter mode is especially
useful for very high speed implementations, since it can be parallelized very
easily. Counter mode is easily misused; however, this draft contains adequate
warnings, cautions, and requirements to prevent such misue.
Working Group Summary
There was strong working group consensus to advance this document and it has a
significant pull from the community, including groups that need high-speed IPsec.
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-smime-camellia - Use of the Camellia
Encryption Algorithm in CMS to Proposed Standard
--------
Last Call to expire on: 2003-5-19
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 [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ X ] [ ] [ ]
Russ Housley [ X ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
COMMENTS:
=========
Steve:
I think that IPR section needs to be made conformant to 2026, via an
RFC editor's note.
Ted:
Notes:
In section 2.2
Implements MUST support the CEK and the KEK having the same length.
should be "Implementations MUST support"
^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-smime@imc.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Use of the Camellia Encryption Algorithm in
CMS to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Use of the Camellia
Encryption Algorithm in CMS' <draft-ietf-smime-camellia-04.txt> as a
Proposed Standard. This document is the product of the S/MIME Mail
Security Working Group.
The IESG contact persons are Russell Housley and Steven Bellovin.
Technical Summary
This document specifies the conventions for using the Camellia
encryption algorithm for encryption with the Cryptographic Message
Syntax (CMS).
Working Group Summary
The Working Group came to consensus on this document.
Protocol Quality
This document was reviewed by Russell Housley for the IESG.
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-ipv6-flow-label -
IPv6 Flow Label Specification
--------
Last Call to expire on: 2003-07-08
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ X ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
^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@isi.edu>, <ipng@sunroof.eng.sun.com>
Subject: Protocol Action: 'IPv6 Flow Label Specification' to
Proposed Standard
The IESG has approved the Internet-Draft 'IPv6 Flow Label Specification'
<draft-ietf-ipv6-flow-label-07.txt> as a Proposed Standard. This document is
the product of the IP Version 6 Working Group Working Group. The IESG
contact persons are Thomas Narten and Margaret Wasserman.
Technical Summary
The details of the IPv6 Flow Label are not defined in detail in the
base IPv6 documents (i.e., RFC 2460). Although an appendix in 2460
provides some background and a possible usage, they are not considered
part of the specification itself. This document specifies the IPv6
Flow Label field, the requirements for IPv6 source nodes labeling
flows, the requirements for IPv6 nodes forwarding labeled packets, and
the requirements for flow state establishment methods.
Working Group Summary
There was consensus in the WG for the current definitions. Indeed,
there has been a desire for sometime to define the Flow Label, as its
considered a part of IPv6, and its lack of a clear definition
contributed to an appearance of lack of completeness.
Protocol Quality
This document has been reviewed for the IESG by 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-schryver-pppext-iana -
IANA Considerations for the Point-to-Point Protocol (PPP)
--------
Last Call to expire on: 2003-07-14
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ X ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
^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@isi.edu>, <ietf-ppp@merit.edu>
Subject: Protocol Action: 'IANA Considerations for the
Point-to-Point Protocol (PPP)' to BCP
The IESG has approved the Internet-Draft 'IANA Considerations for the
Point-to-Point Protocol (PPP)' <draft-schryver-pppext-iana-01.txt> as a
BCP. This document is the product of the Point-to-Point Protocol Extensions
Working Group. The IESG contact persons are Thomas Narten and Margaret
Wasserman.
Technical Summary
This document tightens up the IANA considerations for the PPP number
spaces. Specifically, it changes many First-Come-First-Served spaces
to require RFC publication, in order to get WG and IESG review prior
to number assignment.
Working Group Summary
There was support in the PPPEXT WG for these changes to the IANA
Considerations for PPP numbers. Indeed, the document resulted from a
thread discussing an individual Internet-Draft that proposed a new PPP
LCP option that the WG PPP was opposed to. Discussion of that
document pointed out that many PPP code points could be obtained from
IANA without any review, prompting this document.
Protocol Quality
This document has been reviewed for the IESG by Thomas Narten.
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Scretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-policy-qos-device-info-model -
Information Model for Describing Network Device QoS Datapath Mechanisms
--------
Last Call to expire on: 2003-06-17
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ X ] [ ] [ ]
Steve Bellovin [ ] [ X ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Ted Hardie [ ] [ X ] [ ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ ] [ X ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Jon Peterson [ ] [ X ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ X ] [ ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
In the Abstract:
s/This documenthis document/This document/
s/Together, these two drafts/Together, these two documents/
In the Introduction:
s/A separate draft could be written/A separate document could be written/
s/Similarly, a draft could be written/Similarly, a document could be
written/
s/Together, these four drafts/Together, these four documents/
s/Model Extensions draft [PCIME]./Model Extensions [PCIME]./
In section 7:
^L
---- following is a DRAFT of message to be sent AFTER approval ---
To: IETF-Announce:;
Cc: "RFC Editor" <rfc-editor@isi.edu>,"Internet Architecture Board"
<iab@iab.org>, <policy@ietf.org>
Subject: Protocol Action: Information Model for Describing Network Device QoS
Datapath Mechanisms to a Proposed Standard
------------------------
The IESG has approved the Internet-Draft 'Information Model for Describing
Network Device QoS Datapath Mechanisms'
<draft-ietf-policy-qos-device-info-model-10.txt> as a Proposed Standard.
This document is the product of the Policy Framework Working Group.
The IESG contact persons are Randy Bush and Bert Wijnen
Technical Summary
The purpose of this document is to define an information model to
describe the quality of service (QoS) mechanisms inherent in
different network devices, including hosts. Broadly speaking,
these mechanisms describe the properties common to selecting and
conditioning traffic through the forwarding path (datapath) of a
network device. This selection and conditioning of traffic in
the datapath spans both major QoS architectures: Differentiated
Services and Integrated Services.
This documen should be used with the QoS Policy Information Model
(QPIM) to model how policies can be defined to manage and configure
the QoS mechanisms (i.e., the classification, marking, metering,
dropping, queuing, and scheduling functionality) of devices.
Together, these two drafts describe how to write QoS policy rules
to configure and manage the QoS mechanisms present in the datapaths
of devices.
This document, as well as QPIM, are information models. That is,
they represent information independent of a binding to a specific
type of repository.
Working Group Summary
The Working Group has consensus on this document to be published as
Proposed Standard.
Protocol Quality
This document has been reviewed for the IESG by Bert Wijnen
RFC-Editor notes:
- 2nd para of abstract
OLD:
This documenthis document
NEW:
This document
- Co-Author Walter Weiss is now at: walterweiss@attbi.com
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Scretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-policy-qos-info-model -
Policy QoS Information Model
--------
Last Call to expire on: 2003-06-17
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ X ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ D ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Ted Hardie [ ] [ X ] [ ] [ ]
Russ Housley [ ] [ ] [ X ] [ ]
Allison Mankin [ ] [ X ] [ ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Jon Peterson [ ] [ X ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ X ] [ ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Russ:
Discuss:
The first paragraph of the Introduction indicates that the QPIM includes
a standard framework for controlling access to network QoS resources. Yet,
I do not find any discussion of authentication, authorization, or access
control. The discussion of admission control actions is not sufficient to
meet fulfill the expectation of the Introduction. At a minimum, acc
^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>, policy@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action
-------------
To: IETF-Announce:;
Cc: "RFC Editor" <rfc-editor@isi.edu>,"Internet Architecture Board"
<iab@iab.org>, <policy@ietf.org>
Subject: Protocol Action: Policy QoS Information Model to a Proposed Standard
------------------------
The IESG has approved the Internet-Draft 'Policy QoS Information Model'
<draft-ietf-policy-qos-info-model-05.txt> as a Proposed Standard. This
document is the product of the Policy Framework Working Group.
The IESG contact persons are Randy Bush and Bert Wijnen
Technical Summary
This document presents an object-oriented information model for
representing policies that administer, manage, and control access to
network QoS resources. This document is based on the IETF Policy Core
Information Model and its extensions.
This defines an information model for QoS enforcement for
differentiated and integrated services using policy.
It is important to note that this document defines an information
model, which by definition is independent of any particular data
storage mechanism and access protocol.
Working Group Summary
The Working Group has consensus to publish this document as Proposed
Standard.
Protocol Quality
This document has been reviewed for the IESG by Bert Wijnen
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-kink-kink - Kerberized Internet
Negotiation of Keys (KINK) to Proposed Standard
--------
Last Call to expire on: 2002-12-11
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ X ] [ ] [ ]
Steve Bellovin [ X ] [ ] [ ] [ ]
Randy Bush [ ] [ X ] [ XX] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ X ] [ ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
Scott Bradner [ ] [ ] [ X ] [ ]
Patrik Faltstrom [ ] [ XX] [ X ] [ ]
Jeff Schiller [ X ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
========
Scott:
notes:
at 36 pages this doc should have a table of contents
this can be done with an RFC Ed note if there are no
other reasons to spin the ID
Patrik:
There is no wording about how to compare for example realms. Is this a
resolved issue with the kerberos protocol? I.e. normally the realm in
kerberos is case _sensitive_ but when using DNS together with realms
(SRV-records) one say the realm name is the same as the domain name,
which is case _insensitive_.
Does this not create a need for an explicit note in this document about
how to compare the attributes which are compared?
I can not find any, but might have the wrong regexp in my grep.
Randy:
if there is to be kerberos sales literature
The central key management provided by Kerberos is efficient because
it limits computational cost and limits complexity versus IKE's
necessity of using public key cryptography. Initial authentication
to the KDC may be performed using either symmetric keys or asymmetric
keys using [PKINIT]; however, subsequent requests for tickets, as
well as authenticated exchanges between client and server always
utilize symmetric cryptography. Therefore, public key operations (if
any) are limited and are amortized over the lifetime of the initial
authentication operation to the Kerberos KDC. For example, a client
may use a single public key exchange with the KDC to efficiently
establish multiple security associations with many other servers in
the extended realm of the KDC. Kerberos also scales better than
direct peer to peer keying when symmetric keys are used. The reason
is that since the keys are stored in the KDC, the number of principal
keys is O(n) rather than O(n*m), where "n" is the number of clients
and "m" is the number of servers.
it might also mention the vulnerabilities of centralized key
service, and kerberos's other issues. [ note that i did love and
use the dawg for many years, but in the multi-organization
internet, it just did not scale to meet my needs ]
---
i am confused by the first clause in
Note: if B adds a nonce, or does not choose the first proposal, it
MUST request an ACK so that it can install the final outbound secu-
rity association. The initiator MUST always generate an ACK if the
ACKREQ bit is set in the KINK header, even if it believes that the
respondent was in error.
because, if B does not choose the first proposal, B MUST add a
nonce.
---
delete the incoming SA. For simplicity, KINK does not allow half open
security associations; thus upon receiving a DELETE, the responder
MUST delete its security associations, and MUST reply with ISAKMP
delete notification messages if the SPI is found.
or ISAKMP INVALID_SPI if it is not
---
Normally a KINK implementation which rekeys existing security associ-
ations will try to rekey the security association ahead of a hard SA
expiration. We call this time the rekey time Trekey. In order to
avoid synchronization with similar implementations, KINK initiators
MUST randomly pick a rekeying time between Trekey and the SA expira-
tion time minus the amount of time it would take to go through a full
retransmission time cycle, Tretrans. Trk SHOULD be set at least twice
as high as Tretrans. ^^^
what is Trk? (hint: it is nowhere else in the document). likely
TReKey is ment (and yes, i wish they had used smalltalkish caps)
---
i gota ask. why the heck is the payload type of payload N encoded
as data in payload N-1 (or the header when N=1)? this is just too
kinky for me. if there is an actual reason, at least explain it.
i mean what the heck, why not have the length of payload N be in
payload N-1 so at least things are consistent? </sarcasm>
yes, i realize that making N tell its own type would mean that
KINK_DONE would have to become something like KINK_LAST. so what?
---
KINK proudly uses UDP. will it's data always fit in MTU?
---
maybe a sec cons ref to some kerberos sec cons reviews would be
useful.
---
no iana considerations for registering future
Payload Types
NOTIFY ERROR TYPES
KINK_ERROR Payload
are appropriate?
---
nits:
draft uses end of line hypenation
draft occasionally uses right margin juustification
i know i am not supposed to whine about these, but they make it
hard to read, darn it.
-
redefinition of all the canine terms such as ticket, kdc, etc. may
leave one open to definitional differences. i guess it's a hard
call on how much to bring over.
-
KINK uses Kerberos mechanisms to provide mutual authentication,
replay protection.
gramur. prolly want to s/,/and/
-
The initiator MUST checks to see if the optimistic payload was
^
-
The DELETE command deletes an existing security association. The DOI
specific payloads describe the actual security association to be
deleted. For the IPSEC DOI, those payloads will include an ISAKMP
payload contains the SPI to be deleted in each direction.
s/contains/containing/
or
s/contains/which contains/
-
In order to determine that a KINK peer has lost its security database
information, KINK peers MUST record the current epoch for which they
have valid SADB information
no definition of SADB in document, though it is occasionally
hinted.
-
lack of consistency in field explanations, e.g. in
5.1.5. KINK_TGT_REQ Payload, RESERVED is defined, while in
5.1.6. KINK_TGT_REP Payload, it is not
and field explanations are often not in the same order as the
fields in the payload. and the explanations often do not use
consistent typography, e.g. in 5.1.7. KINK_ISAKMP Payload.
-
The Nonce payload contains random data that MUST be used in key
generation by the initiating KINK peer, and MAY be used by the
responding KINK peer. See section 8 for the discussion of their use
in key generation.
s/thier/its/
-
randy
COMMENTS:
=========
Allison:
Please convey this to the working group for later consideration:
Yes, the MUST for truncated exponential backoff of retransmission
in the Transport Considerations is critically needed - thanks!
It seems like there might be a lot of retransmission in some
circumstances - fragments due to long packets...
Could the group consider another transport (future PR-SCTP or a
reliability shim over DCCP, both of which are much more DoS resistant
than TCP) when they think about a later rev with more experience or
when they get ready for Draft Standard?
^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-kink@vpnc.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Kerberized Internet Negotiation of Keys
(KINK) to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Kerberized Internet
Negotiation of Keys (KINK)' <draft-ietf-kink-kink-04.txt> as a Proposed
Standard. This document is the product of the Kerberized Internet
Negotiation of Keys Working Group. The IESG contact persons are Jeffrey
Schiller and Steve Bellovin.
Technical Summary
This document provides for a Kerberos-based IPsec keying mechanism,
as opposed to IKE. It's of most use to places that already have
a Kerberos infrastructure, and do not want to use IKE for some reason.
The most common reason expressed is the load on a large gateway from
many public-key operations simultaneously, i.e., after a power failure.
Working Group Summary
The major issue is whether or not this protocol is too closely tied
to IKE. The coupling appears to be clean, and there should not be
any major problem using it with IKEv2.
Protocol Quality
This specification 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-mealling-iana-xmlns-registry - The IETF XML
Registry to BCP
--------
Last Call to expire on: 2003-5-2
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 [ ] [ X ] [ ] [ ]
Ted Hardie [ X ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ X ] [ ]
Allison Mankin [ ] [ X ] [ ] [ ]
Thomas Narten [ ] [ ] [ X ] [ ]
Jon Peterson [ ] [ X ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [XX ] [ X ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
========
Bert:
- Section 2.1 states:
NOTE: in order for a URN of this type to be
assigned, the item being registered MUST have been through the IETF
concensus process. Practically this means it must be documented in
an RFC.
Given the confusion we have seen over what "IETF consensus" means, do
we want to keep the above or maybe define it better?
- Under publicid on page 2 it says:
In the case
where a PUBLIC Identifier is also a URI it is possible for the
SYSTEM Identifier to contain the same URI but this behavior is not
recommended unless its side effects are well known.
I think the intention is: "unless its side effect are well known and
understood to not cause any unacceptable harm" or some such, no?
Question:
- Sect 3, Registration Process explains how an XML file is being
stored. It does not talk at all about if or if so how such an XML
file will be validated to have correct syntax.
Given the experiens with MIB modules, I would hope that IANA gets
a tool to verify that such XML syntax is correct before a file
gets accepted. Should the document say something about that?
NITS:
- Page 3 under schema:
'urn:ietf:params:xml:schema:<id>'.
probably should be:
'urn:ietf:params:xml:schema:<id>'.
Steve:
No "Security Considerations" section.
Russ:
The document does not have a Security Considerations section.
^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>,
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: The IETF XML Registry to BCP
-------------
The IESG has approved the Internet-Draft 'The IETF XML Registry'
<draft-mealling-iana-xmlns-registry-04.txt> as a BCP. This has been
reviewed in the IETF but is not the product of an IETF Working
Group. The IESG contact persons are Ned Freed and Ted Hardie.
Technical Summary
This document creates an IANA maintained registry of XML element
identifiers so that document authors and implementors have a well
maintained and authoritative location for their XML elements. As part
of this standard, the IANA will maintain
o the public representation of the document,
o the URI for the elements if one is provided at the time of
registration,
o a registry of Public Identifiers as URIs.
Working Group Summary
This document is not the product of an IETF Working group, but it
has been reviewed within the IETF.
Protocol Quality
This document was reviewed for the IESG by
the XML directorate.
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-zeilenga-ldap-collective - Collective
Attributes in LDAP to Proposed Standard
--------
Last Call to expire on: July 11, 2002
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ X ] [ ] [ ]
Steve Bellovin [ ] [ ] [ X ] [ ]
Randy Bush [ ] [ X ] [ ] [ ]
Bill Fenner [ ] [ XX] [ X ] [ ]
Ned Freed [ X ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ X ] [ ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
Scott Bradner [ ] [ XX] [ X ] [ ]
Patrik Faltstrom [ X ] [ ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
Jeff Schiller [ ] [ XX] [ X ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
-------
Scott:
note: shesh - we tell people that they should not refer to IDs
draft-legg-ldap-gser-abnf-03.txt does so in its abstract
draft-legg-ldap-gser-00.txt
draft-legg-ldap-gser-abnf-03.txt
the reference in the IPR section to BCP 11 is wrong
(it's wrong in RFC 2026 but I did not notice that before)
the reference should be to RFC 2026 BCP 9
we have not been putting this text into RFCs - even though
RFC 2026 says we should - maybe that is why this problem
has not been noticed before
the above issues could be delt with by an RFC Editor note
the rest of the docs look OK to me
Steve: If I understand this correctly -- and I'm not at all sure that
I do -- the security considerations should specify that the same security
checks must be made on retrieval or update of the collective attribute
as for the actual entry. This is a minor point and can, I think, be
handled with an RFC editor note.
Alternatively, I have no idea what I'm talking about and this DISCUSS
should be ignored...
Bert: Has anybody (or is anyone) checked(ing) the ABNF syntax
in those documents?
In here I see a request to IANA to assign a set of OIDs, for example:
c-FacsimileTelephoneNumber A 2.5.4.23.1
c-InternationalISDNNumber A 2.5.4.25.1
c-PhysicalDeliveryOffice A 2.5.4.19.1
When I go to
http://www.alvestrand.no/objectid/2.5.4.23.1.html
then it seems they are already assigned.
but certainly, the OID starts with a 2 and that is ISO/ITU-T
jointly assigned OIDs. So I wonder (did I so earlier on too
and did I forget the answer) why IANA has anything to do
with it. Does not IANA (in principle) only make
assignments in Internet owned Name spaces. So for OIDs that
is underneath 1.3.6.1 (which is the Internet OID) ??
I assume that PAF or someone makes sure that assignments are
not overlapping with anything else?
I guess that it is historical, but these attribute names
c-l A 2.5.4.7.1
c-o A 2.5.4.10.1
c-ou A 2.5.4.11.1
c-st A 2.5.4.8.1
are kind of short and cryptic, are they not?
To follow up on my own questions below, at the bottom of
IANA Considerations section it says:
This document uses in this document were assigned by the ISO/IEC
Joint Technical Committee 1 - Subcommitte 6 to identify elements of
X.500 schema. This document make no OID assignments, it only
associates LDAP schema descriptions with existing elements of X.500
schema.
Which I cannot parse. But potentially it means to say:
The OIDs used in this document were assigned by the ISO/IEC Joint
Technical Committee 1 - Subcommitte 6 to identify elements of X.500
schema. This document make no OID assignments, it only associates
LDAP schema descriptions with existing elements of X.500 schema.
So if this document makes no OID assignments, is it then the idea
that IANA still registers them? I guess it needs to be added then
that authoritative "registration" or "OID assignment" is done
in that other place, possibly witha ptr to it (if any).
Bill: draft-zeilenga-ldap-subentry-06.txt has an ABNF error in Appendix
A. ABNF rule names are case-insensitive, however it has one rule
specificExclusions and one SpecificExclusions. One of them should
be renamed. This would be easily done with an RFC-Editor note.
draft-legg-ldap-gser-abnf-03.txt and draft-legg-ldap-gser-00.txt
have syntactically correct ABNF.
Jeff: ]7. Security Considerations
]
] The Generic String Encoding Rules do not necessarily enable the exact
] octet encoding of values of the TeletexString, VideotexString,
] GraphicString or GeneralString types to be reconstructed, so a
] transformation from DER to GSER and back to DER may not reproduce the
] original DER encoding. This has consequences for the verification of
] digital signatures.
I am not sure this is an acceptable restriction. I would recommend
that the author come up with a way that permits transformation from
DER to GSER to DER in a way that doesn't break signatures.
^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>,
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Collective Attributes in LDAP to Proposed
Standard
-------------
The IESG has approved publication of the following Internet-Drafts as
Proposed Standards:
o Collective Attributes in LDAP
<draft-zeilenga-ldap-collective-07.txt>
o Subentries in LDAP
<draft-zeilenga-ldap-subentry-07.txt>
o Generic String Encoding Rules for ASN.1 Types
<draft-legg-ldap-gser-00.txt>
The IESG also approved publication of Common Elements of GSER Encodings
<draft-legg-ldap-gser-abnf-03.txt> as an Informational RFC.
These documents have been reviewed in the IETF but are not the product
of an IETF Working Group. The IESG contact persons are Ned Freed and
Patrik Faltstrom.
Technical Summary
X.500 collective attributes allow common characteristics to be shared
between collections of entries. This document summarizes the X.500
information model for collective attributes and describes use of
collective attributes in LDAP (Lightweight Directory Access Protocol).
The information needed are stored as subentries (special entries used
to hold information associated with a subtree or subtree refinement).
"Collective Attributes in LDAP" provides schema definitions for collective
attributes for use in LDAP.
"Subentries in LDAP" adapts X.500 subentries mechanisms for use with LDAP.
"Generic String Encoding Rules for ASN.1 Types" defines a set of ASN.1
encoding rules that produce a human readable text encoding for values of
any given ASN.1 data type.
Working Group Summary
The documents have been discussed on the mailing lists for the LDAP
working groups in the IETF, and in the LDAP Directorate. There is
consensus for publication of these documents.
Protocol Quality
The specification has been reviewed for the IESG by Patrik Faltstrom.
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-yergeau-rfc2279bis - UTF-8, a
transformation format of ISO 10646 to Standard
--------
Last Call to expire on: 2003-3-21
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ X ] [ XX] [ ]
Steve Bellovin [ ] [ X ] [ ] [ ]
Randy Bush [ ] [ X ] [ ] [ ]
Bill Fenner [ X ] [ ] [ ] [ ]
Ned Freed [ X ] [ ] [ ] [ ]
Ted Hardie [ X ] [ ] [ ] [ ]
Russ Housley [ ] [ XX] [ X ] [ ]
Allison Mankin [ X ] [ ] [ ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Jon Peterson [ ] [ X ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ X ] [ ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
========
Russ:
Section 10 should include an additional paragraph. When UTF-8
is used in identifiers, comparison of two strings is needed. For
example, an identifier appears in a credential and in access control
list entries. It seem that the exact match of UTF-8 is not simply a
buffer comparison. I think that a warning is needed. Tell people that
rules for comparison need to be specified in cases where
octet-by-octet comparison is not sufficient.
Harald:
OK, here's the ABNF issue.
ISSUE: ABNF, RFC 2234, is at Proposed.
The text with the ABNF grammar is added between Draft and Full, and
thus has had no known implementation or interoperability testing.
Thus, we can't be certain of its quality.
SUGGESTION:
1) add to the beginning of section 4:
For the convenience of implementors using ABNF, a definition of UTF-8
characters in ABNF syntax is given here.
2) Add to the end of section 4 a NOTE:
NOTE: The authoritative definition of UTF-8 is in [UNICODE] and
[ISO.10646]. This grammar is believed to describe the same thing as
what those references describe, but does not claim to be
authoritative.
3) Move the RFC 2234 reference from NORMATIVE to INFORMATIVE.
OK, it's working around the edge. But understanding the ABNF is *not*
required to implement UTF-8, which is the point of the document.
COMMENTS:
=========
Steve:
Maybe strengthen that a bit, by adding this:
Implementors are strongly urged to rely on the authoritative
documents, rather than on this ABNF.
^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>,
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: UTF-8, a transformation format of ISO 10646
to Standard
-------------
The IESG has approved the Internet-Draft 'UTF-8, a transformation
format of ISO 10646' <draft-yergeau-rfc2279bis-05.txt> as a Standard.
This has been reviewed in the IETF but is not the product of an IETF
Working Group. The IESG contact person is Ted Hardie.
Technical Summary
This document updates the specification of UTF-8,
an encoding of the UCS which is designed to be
compatible with many current applications and protocols. UTF-8
has the characteristic of preserving the full US-ASCII range,
providing compatibility with file systems, parsers and other software
that rely on US-ASCII values but are transparent to other values.
This memo obsoletes and replaces RFC 2279.
Working Group Summary
This draft and the interoperability reports associated with it were
discussed
on the IETF-charsets@iana.org mailing list. Archives may be
found at http://lists.w3.org/Archives/Public/ietf-charsets/ among
other places.
Protocol Quality
This specification was reviewed for the IESG by Patrik Falstrom.
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-pkix-pr-tsa -
Policy Requirements for Time-Stamping Authorities
--------
Last Call to expire on: 0000-00-00
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ X ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Randy:
as was pointed out on 2003.04.14, this UNCHANGED document says
This document is an Internet-Draft and is NOT offered in accordance
with Section 10 of RFC 2026, and the authors do not provide the IETF
with any rights other than to publish as an Internet-Draft.
until it says otherwise, i assume it would be a waste of time to
read it further.
^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@isi.edu>, <ietf-pkix@imc.org>
Subject: Document Action: 'Policy Requirements for Time-Stamping
Authorities' to Informational RFC
The IESG has approved the Internet-Draft 'Policy Requirements for
Time-Stamping Authorities' <draft-ietf-pkix-pr-tsa-04.txt> as an
Informational RFC. This document is the product of the Public-Key
Infrastructure (X.509) Working Group. The IESG contact persons are Russ
Housley and Steve Bellovin.
Multicast Security (msec)
-------------------------
Last Modified: 2003-07-24
Current Status: Active Working Group
Chair(s):
Ran Canetti <canetti@watson.ibm.com>
Thomas Hardjono <thardjono@verisign.com>
Security Area Director(s):
Russell Housley <housley@vigilsec.com>
Steven Bellovin <smb@research.att.com>
Security Area Advisor:
Russell Housley <housley@vigilsec.com>
Mailing Lists:
General Discussion: msec@securemulticast.org
To Subscribe: msec-request@securemulticast.org
In Body: subscribe
Archive: http://www.pairlist.net/mailman/listinfo/msec
Description of Working Group:
The purpose of the MSEC WG is to standardize protocols for securing group
communication over internets, and in particular over the global Internet.
Initial efforts will focus on scalable solutions for groups with a single
source and a very large number of recipients. Additional emphasis will be
put on groups where the data is transmitted via IP-layer multicast routing
protocols (with or without guaranteed reliability). The developed standard
will assume that each group has a single trusted entity (the Group
Controller) that sets the security policy and controls the group
membership. The standard will strive to provide at least the following
basic security guarantees:
+ Only legitimate group members will have access to current group
communication. This includes groups with highly dynamic membership.
+ Legitimate group members will be able to authenticate the source and
contents of the group communication. This includes cases where group
members do not trust each other.
An additional goal of the standard will be to protect against
denial-of-service attacks, whenever possible.
Due to the large number of one-to-many multicast applications and the
sometimes conflicting requirements these applications exhibit, it is
believed that a single protocol will be unable to meet the requirements of
all applications. Therefore, the WG will first specify a general Reference
Framework that includes a number of functional building blocks. Each such
building block will be instantiated by one or more protocols that will be
interchangable. The Reference Framework will not only describe one-to-many
multicast, but also many-to-many multicast.
In addition, as a secondary goal the MSEC WG will also focus on distributed
architectures for group key management and group policy management, where
for scalability purposes multiple trusted entities (such as Key
Distributors) are deployed in a distributed fashion. For this purpose, the
Reference Framework will not only describe one-to-many multicast, but also
many-to-many multicast.
MSEC will generate at least the following documents, which could be
considered as base documents:
1. An RFC describing the security requirements of multicast security and an
RFC describing the MSEC Architecture.
2. An RFC describing the Group Key Management Architecture and an RFC
describing Group Policy Management Architecture in MSEC.
3. Several RFCs describing specifications for protocols that implement
source authentication, group key management and group policy management.
As multicast security covers a broad range of issues, and therefore touches
other Working Groups in the IETF, the MSEC WG will work closely with other
security-related Working Groups (e.g. IPsec, IPSP), as well as other
Working Groups which maybe considered a "consumer" of the technologies
produced in the MSEC WG (e.g. AVT, MMUSIC) or which may have a multicast
focus (e.g. PIM, RMT, IDRM, MAGMA).
With this in mind, the MSEC WG is open to receiving new work items,
whenever it is considered appropriate to be homed in the MSEC WG. Such
drafts will be matured in conjunction with the MSEC base documents.
GOALS AND MILESTONES
DONE Working Group Last Call on GDOI Protocol.
DONE Working Group Last Call on MIKEY Protocol.
Sep 03 WG Last Call on Group Key Management Architecture draft.
Sep 03 WG Last Call on MSEC Architecture draft.
Sep 03 WG Last Call on DHHMAC for MIKEY.
Sep 03 WG Last Call on Data Security Architecture draft
Dec 03 WG Last Call on Security Requirements draft.
Mar 04 WG Last Call on Group Security Policy Architecture draft
Mar 04 WG Last Call on MESP (Multicast ESP) draft.
Mar 04 WG Last call on MESP-TESLA draft.
Mar 04 WG Last Call on GSAKMP-Light protocol.
Jul 04 WG re-charter for other work items (or disband).
Mobility for IPv4 (mip4)
-------------------------
Charter
Last Modified: 2003-07-30
Current Status: Proposed Working Group
Chair(s):
Henrik Levkowetz <henrik@levkowetz.com>
Pete McCann <mccap@lucent.com>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <mrw@windriver.com>
DESCRIPTION:
Mailing list: mip4@ietf.org
To Subscribe: mip4-request@ietf.org
In Body or Subject: subscribe
Archive: www.ietf.org/mail-archive/working-groups/mip4/current/maillist.html
IP mobility support for IPv4 nodes (hosts and routers) is specified in
RFC3344. RFC 3344 mobility allows a node to continue using its
"permanent" home address as it moves around the internet. The Mobile IP
protocols support transparency above the IP layer, including maintenance
of active TCP connections and UDP port bindings. Besides the basic
Mobile IPv4 (MIPv4) protocols, several other drafts deal with concerns
such as optimization, security, extensions, AAA support, and deployment
issues.
Mobile IPv4 is currently being deployed on a wide basis (e.g., in
cdma2000 networks). The scope of the deployment is on a fairly large
scale and accordingly, the MIP4 WG will focus on deployment issues and
on addressing known deficiencies and shortcomings in the protocol that
have come up as a result of deployment experience. Specifically, the
working group will complete the work items to facilitate interactions
with AAA environments, interactions with enterprise environments when
Mobile IPv4 is used therein, and updating existing protocol
specifications in accordance with deployment needs and advancing those
protocols that are on the standards track.
Work expected to be done by the MIP4 WG as proposed by this charter is
as follows:
1. MIPv4 has been a proposed standard for several years. It has been
adopted by other standard development organizations and has been
deployed commercially. One of the next steps for the WG is to advance
the protocol to draft standard status. As part of advancing base
Mobile IP specs to DS, the Mobile IPv4 NAI RFC (2794) will also be
progressed towards DS.
2. Key exchange using AAA infrastructures for setting up security
associations defined in RFC3344 will be completed.
3. The AAA WG, which is currently dealing with the Diameter Mobile IP
application, requires the AAA NAI for Mobile IPv4. This work will
be completed by the WG. The MIP4 WG will also work with the AAA WG
to ensure that the Diameter Mobile IP application is aligned with
WG requirements.
4. Home agent assignment at the time of mobile-ip registration, rather
than preconfigured for the mobile node, has been proposed in
draft-kulkarni-mobileip-dynamic-assignment-01.txt. The WG will
take on the task of completing this. The ability to switch the home
agent assigned to a mobile node while registered will also be
considered as part of this task.
5. Work items that are pending from the previous Mobile IP WG, which will be
completed by the MIP4 WG, are RFC3012bis (Challenge-response mechanism),
low-latency handover draft to experimental status and the completion
of the MIB for the revised base Mobile IP specification (2006bis).
6. The MIP4 WG will also complete the work on Mobile IPv4 interactions
in VPN scenarios. This work will involve identifying the requirements
and a solution development for Mobile IPv4 operation in the presence
of IPsec VPN's.
Other potential work items may be identified in the future but will
require an appropriate recharter.
Milestones:
Aug 03 AAA Keys for MIPv4 to IESG
Sep 03 MIPv4 VPN interaction problem statement to IESG
Sep 03 Low latency handover to experimental
Oct 03 Revised MIPv4 Challenge/Response (3012bis) to IESG
Oct 03 Advance RFC 2794 (NAI Extension specification) to IESG for Draft Standard
Nov 03 Revised MIB for MIPv4 to IESG
Dec 03 Revised MIPv4 specification to IESG for Draft Standard
Jan 04 Dynamic Home Agent assignment protocol solution to IESG
Feb 04 MIPv4 VPN Solution to IESG
IP over Cable Data Network (ipcdn)
----------------------------------
Charter
Last Modified: 2003-08-01
Current Status: Active Working Group
Chair(s):
Richard Woundy <Richard_Woundy@cable.comcast.com>
Jean-Francois Mule <jf.mule@cablelabs.com>
Operations and Management Area Director(s):
Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>
Operations and Management Area Advisor:
Bert Wijnen <bwijnen@lucent.com>
Mailing Lists:
General Discussion: ipcdn@ietf.org
To Subscribe: http://www.ietf.org/mailman/listinfo/ipcdn
Archive: ftp://ftp.ietf.org/ietf-mail-archive/ipcdn
Description of Working Group:
The IETF IPCDN Working Group develops and standardizes MIBs
for IP-capable data-over-cable systems, for example cable
modems, multimedia terminal adapters and associated
cable-data equipment in a cable headend.
These MIBs cover not only cable data interfaces, but also
management of cable-data equipment and systems.
The WG mailing list may be used discussion of Internet-related
issues in data-over-cable equipment and systems. In the event
of a particular new Internet technology issue arising in the
cable-data context, the WG will identify whether that is best
handled within the IETF or is best handled by another standards
body. In the event that new IETF MIB work, the WG chairs can
discuss additional WG work items with the AD. Such additions
will have to go through normal re-charter process.
If non-MIB work gets identified, such items are not normal
work items for this IPCDN-MIB WG and must go through normal
IETF new WG chartering process.
Standardization of MIBs for DOCSIS, PacketCable and CableHome
systems are explicitly within the scope of the IPCDN Working
Group.
The IPCDN WG will also keep informed on what other groups in
the industry are doing as it relates to the efforts of this
working group.
The WG will align its specifications with IPv6 and SNMP STD.
Related groups:
CableLabs (http://www.cablelabs.com/) is structured into projects.
In its Cable Modem/DOCSIS project, CableLabs has produced three
generations of data over cable specifications: DOCSIS 1.0,
DOCSIS 1.1, and DOCSIS 2.0.
In its PacketCable project, CableLabs has produced one generation
of interface specifications for delivering real-time multimedia
services over DOCSIS (http://www.packetcable.com/specifications/).
Internationally, IPCablecom is the global name associated
with the extensions & global standardization of PacketCable
in ETSI & ITU-T SG9.
In its CableHome project, CableLabs has produced one generation
of interface specifications for extending manageability for
customer care to the residential gateway or home router device
connected to the Internet through a DOCSIS-compliant cable modem
(http://www.cablelabs.com/projects/cablehome/).
DOCSIS 1.0 includes specifications for a bidirectional
data-over-cable interface (RFI, or Radio Frequency Interface)
and a data privacy service (BPI, or Baseline Privacy Interface).
The key devices in a DOCSIS network are the Cable Modem (CM, the
device at the subscriber premise) and the Cable Modem Termination
System (CMTS, the device at the cable headend). For DOCSIS 1.0
systems, the IPCDN WG has published the Cable Device MIB
(RFC 2669), the RF Interface MIB (RFC 2670), and the Baseline
Privacy MIB (RFC 3083).
DOCSIS 1.1 extends the DOCSIS 1.0 specifications to support
better quality of service parameters (RFIv1.1), to enable
operation in European cable networks (EuroDOCSIS), and to
authenticate modems and firmware images (BPI+). The IPCDN WG
will update the Cable Device and Radio Frequency MIBs for
DOCSIS 1.1, and repair flaws discovered in operational use.
Other IPCDN WG documents will address the operational and
management issues for new DOCSIS 1.1 functional components
(e.g. BPI+), for subscriber device management, and for
uniform event notification.
DOCSIS 2.0 enhances the DOCSIS 1.1 specifications at the
physical layer, in particular to support two new physical
layer encodings: S-CDMA and A-TDMA. The IPCDN WG will update
the Radio Frequency MIB for DOCSIS 2.0.
PacketCable 1.0 is built on top of the DOCSIS 1.1 cable modem
infrastructure and it includes a suite of interface
specifications covering multimedia terminal adapter (MTA)
device provisioning, voice over IP session signaling, QoS
signaling based on IETF standards. The key systems in a
PacketCable network are the multimedia terminal adapter (MTA),
a Call Management Server (CMS), a PacketCable-compliant
DOCSIS 1.1 CMTS, Media Gateway Controllers, Media Gateways
along with back-office systems. In ITU-T SG-9 and ETSI AT,
IPCableCom has standardized PacketCable to create a set of
international standards.
CableHome 1.0 is a set of specifications for residential
gateway or home router functionality standardizing methods
for implementing address acquisition, device configuration
and management, network address translation, event reporting,
remote connectivity diagnostics, secure software download,
firewall policy file download, firewall monitoring,
management parameter access control and other residential
gateway functionality. By standardizing these features,
CableHome 1.0 specifications enable cable operators to
deliver high-value, managed broadband services to their
high-speed data service subscribers, through a DOCSIS cable
modem.
Work items:
The IPCDN WG will address issues related to network management,
especially as they concern HFC access networks. It is expected
that other services (i.e. RSVP, IPSEC, etc.) will operate
mostly unmodified.
The specific work items include
-- DOCSIS,
- publish MIB documents for:
- subscriber device management on a DOCSIS 1.1 CMTS,
- managing the quality of service parameters for a
DOCSIS 1.1 device,
- managing the Baseline Privacy Plus system for a
DOCSIS 1.1 device,
- uniform event notification on a DOCSIS 1.1 device,
- revise MIB documents for:
- DOCSIS 1.0 RF Interface MIB to support EuroDOCSIS
parameters and DOCSIS 2.0 physical layer management,
- the DOCSIS 1.0 Cable Device MIBs to address SNMPv3
and IPv6 compliance and interoperability issues,
-- IPCablecom & PacketCable
- publish MIB documents for:
- managing the device parameters of
PacketCable/IPCableCom MTA devices,
- managing the signaling parameters of
PacketCable/IPCableCom MTA devices,
- managing events for PacketCable/IPCablecom systems,
-- CableHome
- publish MIB documents for:
- managing attributes of a residential gateway or
home router device,
- managing private address-to-public address mappings
for a residential gateway or home router device,
- managing the address lease acquistion client and the
address lease server functionality of a residential
gateway or home router device,
- managing diagnostic utilities used to remotely test
the connectivity between a residential gateway and
privately-addressed LAN hosts,
- managing firewall attributes, monitoring firewall
attacks, and managing security certificates in a
residential gateway or home router device,
- managing QoS configuration in a residential
gateway or home router device.
Goals and Milestones:
Done Post final I-D on Baseline Privacy MIB; Last call
Done Post I-Ds revising RF and CM MIBs to support DOCSIS1.1
and for compliance with SNMPv3 and IPv6
Done Submit Baseline Privacy MIB to IESG for publication as
a Standards Track RFC
Aug 03 Submit DOCSIS Subscriber Management MIB to IESG for
consideration as a Standards Track RFC
Sep 03 Submit DOCSIS 1.1 QoS MIB to IESG for consideration as a
Standards Track RFC
Sep 03 Submit DOCSIS BPI+ MIB to IESG for consideration as a
Standards Track RFC
Sep 03 Submit updated DOCSIS RF MIB to IESG for consideration
as a Standards Track RFC (Proposed Standard)
Sep 03 Submit updated DOCSIS Cable Device MIB to IESG for
consideration as a Standards Track RFC
Sep 03 Submit DOCSIS Event Notification MIB to IESG for
consideration as a Standards Track RFC
Sep 03 Submit PacketCable/IPCableCom MTA device MIB to IESG
for consideration as a Standards Track RFC
Sep 03 Submit PacketCable/IPCableCom MTA signaling MIB to IESG
for consideration as a Standards Track RFC
Nov 03 Submit PacketCable/IPCableCom MTA event MIB to IESG for
consideration as a Standards Track RFC
Nov 03 Submit Cablehome MIB for managing residential gateway or
home router device to IESG for consideration as
Standards Track RFC,
Nov 03 Submit Cablehome MIB for MIB for managing private
address-to-public address mappings for a residential
gateway or home router device to IESG for consideration
as Standards Track RFC,
Nov 03 Submit Cablehome MIB for managing the address lease
acquistion client and the address lease server
functionality of a residential gateway or home router
device to IESG for consideration as Standards Track RFC,
Nov 03 Submit Cablehome MIB for managing diagnostic utilities
used to remotely test the connectivity between a residential
gateway and privately-addressed LAN hosts to IESG for
consideration as Standards Track RFC,
Nov 03 Submit Cablehome MIB for managing firewall attributes,
monitoring firewall attacks, and managing security
certificates in a residential gateway or home router device
to IESG for consideration as Standards Track RFC,
Feb 04 Revaluate charter and milestones or conclude wg.
AToM MIB (atommib)
------------------
Charter
Last Modified: 2003-08-01
Current Status: Active Working Group
Chair(s):
Faye Ly <faye@pedestalnetworks.com>
Kam Lam <hklam@lucent.com>
Operations and Management Area Director(s):
Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>
Operations and Management Area Advisor:
Bert Wijnen <bwijnen@lucent.com>
Technical Advisor(s):
Keith McCloghrie <kzm@cisco.com> ?? still to be discussed ??
Mailing Lists:
General Discussion: atommib@research.telcordia.com
To Subscribe: atommib-request@research.telcordia.com
Archive: ftp://ftp.research.telcordia.com/pub/Group.archive/atommib
Description of Working Group:
The AToM MIB Working Group is currently chartered to:
1. Maintain and advance on the standards track the existing
specifications for ATM management (RFC2512-2515).
2. Maintain and advance on the standards track other trunk-mib
specifications (i.e., for DS0 - DS3-E3, RFC2493-2496).
The objects defined by the working group will be consistent with the
Internet-standard Management framework.
Goals and Milestones:
Done Revised OpticalMIB Internet-Draft and make available for
discussion
Done Submit the SONET APS MIB to the IESG for consideration as
a Proposed Standard
Done Report on implementation experience on RFC 2558
Done Submit OpticalMIB Internet-Draft to IESG for standards
track elevation
Done Submit the ATM Supplemental to the IESG for consideration
as a Proposed Standard
Done Report on implementation experience on RFC 2493
Done Submit any needed revisions of RFC2493 to the IESG for
standards track advancement as appropriate
Done Submit any needed revisions of RFC2558 to the IESG for
standards track advancement as appropriate
Oct 03 Report on implementation experience on RFC 2494
Oct 03 Report on implementation experience on RFC 2495-2496
Oct 03 Report on implementation experience on RFC 2512-2513
Oct 03 Report on implementation experience on RFC 2514-2515
Oct 03 Submit any needed revisions of RFC2495-2496 to the IESG
for standards track advancement as appropriate
Oct 03 Submit any needed revisions of RFC2514-2515 to the IESG
for consideration of standards track advancement as
appropriate
Jan 04 Submit any needed revisions of RFC2494 to the IESG for
standards track advancement as appropriate
Jan 04 Submit any needed revisions of RFC2512-2513 to the IESG
for consideration of standards track advancement
as appropriate
Jan 04 Re-evaluate charter or close the WG
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