[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Draft IESG Telechat Agenda and Package for April 30, 2003
* DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT *
INTERNET ENGINEERING STEERING GROUP (IESG)
Agenda for the April 30, 2003 IESG Teleconference
1. Administrivia
o Roll Call
o Bash the Agenda
o Approval of the Minutes
- April 17, 2003
o Review of Action Items
OUTSTANDING TASKS
IP o Allison to review draft-agrawal-sip-h323-interworking-reqs
and send decision to IESG.
IP o Erik to document process of how the IESG goes about asking
architectural questions of the IAB
IP o Thomas to write (or cause to be written) a draft on "how to
get to Draft".
IP o Thomas to contact Cablelabs to discuss formal relationship
with IAB
IP o Allison and Thomas will email Secretariat note to send to RFC
Editor about 3GPP RFC Editor documents.
o Secretariat to modify auto-response for Internet-Drafts
submissions so that when someone submits an I-D, a note is
automatically generated which recommends that they consider
the issues listed in ID-Nits before submitting the I-D to the
IESG. Auto-response to include the URL pointing to the
I-D Nits page. IESG will review the auto-response text.
o Secretariat to email Working Group Chairs a reminder after each
conference with pointer to I-D Nits. Secretariat to draft
reminder text and pass by IESG first.
IP o Ned to write an IESG note for draft-tegen-smqp (Informational)
IP o Steve to write RFC re: TCP MD5 option
IP o Randy and Ned to finish ID on Clarifying when Standards Track
Documents may Refer Normatively to Documents at a Lower Level
DONE o Bert to send instructions/text to Secretariat to install URL
for IANA MIB Copyright
DONE o Ted to send RFC Editor Note to Secretariat for draft-walsh-urn-web3d-00.txt
DONE o Erik to write, send formal statement to Secretariat to be sent to IAB
confirming IETF appointment to ISOC BoT
IP o Ted Hardie to send message to Secretariat for apex wg to be sent to RFC
Editor re: changing status of draft from proposed to experimental. Secretariat
to change draft-ietf-apex-presence-06.txt from and individual to an
experimental document.
DONE o Secretariat to send formal WG Review message for netconf to ietf-announce,
new-work, et al. and return item to next telechat agenda.
DONE o IESG approved minor re-charter for rmt wg. Secretariat to update rmt wg
charter page.
DONE o Secretariat to update ballot for draft-zeilenga-ldap-user-schema for it to be
reconsidered as a new ballot on the next telechat
2. Protocol Actions
o LDAPv3: A Collection of User Schema (Proposed Standard)
<draft-zeilenga-ldap-user-schema-06.txt>
Token: Hardie, Ted
Note: It is proposed that this be approved for Proposed Standard
with the following IESG note: This document contains useful and
timely updates to RFC 2798. The IESG expects that this document
will be replaced or updated again once the LDAP community has
finished its work related to stringprep, and that those updates
will cause this document or its successors to recycle at the
Proposed Standard level.
o Message Disposition Notification (Draft Standard)
<draft-vaudreuil-mdnbis-03.txt>
Token: Freed, Ned
Note: Responsible: freed
o The IETF XML Registry (BCP)
<draft-mealling-iana-xmlns-registry-04.txt>
Token: Hardie, Ted
Note: Patrik to speak with Michael about this being a BCP.
Steve to remove from list of IESG items. When ready, paf to
request last call for BCP.
Responsible: paf
o Generalized Multi-Protocol Label Switching Architecture
(Proposed Standard)
<draft-ietf-ccamp-gmpls-architecture-05.txt>
Token: Wijnen, Bert
Note: IETF Last Call requested.
Responsible: Bert
o Session Initiation Protocol Basic Call Flow Examples (BCP)
<draft-ietf-sipping-basic-call-flows-02.txt>
Token: Mankin, Allison
Note: Discuss comments regarding the normative status as a BCP -
revision was done and it returns to IESG agenda.
o Session Initiation Protocol PSTN Call Flows (BCP)
<draft-ietf-sipping-pstn-call-flows-02.txt>
o UTF-8, a transformation format of ISO 10646 (Standard)
<draft-yergeau-rfc2279bis-04.txt>
Token: Hardie, Ted
o Link Management Protocol (LMP) (Proposed Standard)
<draft-ietf-ccamp-lmp-08.txt>
Token: Wijnen, Bert
Note: IETF Last Call requested
Responsible: secretariat
o Internet X.509 Public Key Infrastructure Certificate Management
Protocols (Proposed Standard)
<draft-ietf-pkix-rfc2510bis-08.txt>
Token: Housley, Russ
o Internet X.509 Public Key Infrastructure Certificate Request
Message Format (CRMF)(Proposed Standard)
<draft-ietf-pkix-rfc2511bis-06.txt>
Token: Housley, Russ
3. Working Group Submissions
o IP over Optical Networks: A Framework (Informational)
<draft-ietf-ipo-framework-04.txt>
Token: Zinin, Alex
o Content Internetworking (CDI) Scenarios (Informational)
<draft-ietf-cdi-scenarios-01.txt>
Token: Hardie, Ted
Note: Responsible: Ted
o Exclusive XML Canonicalization, Version 1.0 (Informational)
<draft-ietf-xmldsig-xc14n-00.txt>
Token: Housley, Russ
Note: Responsible: Russ Housley
o Policy Requirements for Time-Stamping Authorities (Informational)
<draft-ietf-pkix-pr-tsa-04.txt>
Token: Housley, Russ
o SDPng Transition (Informational)
<draft-ietf-mmusic-sdpng-trans-03.txt>
Token: Peterson, Jon
Note: Roadmap document explaining relation of various extensions
of SDP such as offer-answer and fid to the SDPng work.
4. Individual
o A Description of the Camellia Encryption Algorithm
(Informational)
<draft-nakajima-camellia-02.txt>
Token: Bellovin, Steve
o OSPF-xTE: An experimental extension to OSPF for Traffic
Engineering (Experimental)
<draft-srisuresh-ospf-te-05.txt>
Token: Zinin, Alex
5. Individual via RFC Editor
o A URN Namespace for SWIFT's Financial Messaging (Informational)
<draft-gustin-goyens-urn-id-02.txt>
Token: Hardie, Ted
Note: Responsible: paf
o A URN Namespace for MPEG (Informational)
<draft-smith-urn-mpeg-01.txt>
Token: Hardie, Ted
o Extreme Networks' Ethernet Automatic Protection Switching
(EAPS), Version 1 (Informational)
<draft-shah-extreme-eaps-02.txt>
Token: Nordmark, Erik
Note: Ready for the IESG agenda.
o A URN Namespace for FIPA (Informational)
<draft-bellifemine-urn-fipa-00.txt>
Token: Hardie, Ted
o A Framework for Purpose Built Keys (PBK) (Informational)
<draft-bradner-pbk-frame-04.txt>
Token: Bellovin, Steve
6. Proposed Working Group
o Multiparty Multimedia Session Control (mmusic)
Token: Jon
o Network Configuration (netconf)
Token: Bert
7. Working Group News we can use
8. IAB News we can use
9. Management Issues
o Proposed resolution of the AD-shepherded info/experimental
*DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT *
INTERNET ENGINEERING STEERING GROUP (IESG)
April 17, 2003
Reported by: Jacqueline Hargest, IETF Assistant Director
ATTENDEES
---------
Austein, Rob / IAB Liaison
Bellovin, Steve / AT&T Labs
Bush, Randy / IIJ
Cotton, Michelle / ICANN
Daigle, Leslie / Verisign (IAB)
Freed, Ned / Innosoft
Fuller, Barbara / IETF
Hardie, Ted / Qualcomm, Inc.
Hargest, Jacqueline / IETF
Mankin, Allison / Bell Labs, Lucent
Narten, Thomas / IBM
Nordmark, Erik / Sun
Peterson, Jon / NeuStar, Inc.
Reynolds, Joyce K. / ISI (RFC Editor)
Suleymanova, Dinara / IETF
Wijnen, Bert / Lucent
Zinin, Alex / Alcatel
REGRETS
-------
Alvestrand, Harald / Cisco
Fenner, Bill / AT&T
Housley, Russ / Vigil Security, LLC
Minutes
-------
1. The minutes of the April 3, 2003 teleconference were approved
pending minor wording change. Secretariat to place in public archives
and update minutes web page.
2. The following action items were reported as DONE:
o Steve Bellovin will write RFC for Automated Key Management
o Secretariat to send lemonade WG Action Announcement
o Randy to send GROW new charter review message to Secretariat.
Secretariat to send to IAB, IESG and WG Chairs.
o Thomas will check with 3GPP2 about expediting RFC processing
for draft-koren-pppext-rfc2509bis-03.txt and
draft-ietf-avt-crtp-enhance. If ok, the IESG has already
approved that request.
3. Protocol Action Tentatively Approved:
The IESG tentatively approved the Internet-Draft 'Use of the RSAES-OAEP
Transport Algorithm in CMS' <draft-ietf-smime-cms-rsaes-oaep-07.txt>
as a Proposed Standard, pending RFC Editor Note from Steve Bellovin.
Once received, Secretariat will announce.
4. Protocol Actions Deferred:
o LDAPv3 A Collection of User Schema (Proposed Standard)
<draft-zeilenga-ldap-user-schema-06.txt>
o Generalized Multi-Protocol Label Switching Architecture
(Proposed Standard)
<draft-ietf-ccamp-gmpls-architecture-05.txt>
5. Document Actions Approved:
The IESG has approved the Internet-Draft 'Framework Policy Information
Base for Usage Feedback' <draft-ietf-rap-feedback-fr-pib-06.txt> as an
Informational RFC. Secretariat to send announcement.
The IESG has approved the Internet-Draft 'IEEE 802.1X RADIUS Usage
Guidelines' <draft-congdon-radius-8021x-26.txt> as an Informational
RFC. Secretariat to send announcement.
6. Document Action Tentatively Approved:
o A URN Namespace for the Web3D Consortium (Web3D) (Informational)
<draft-walsh-urn-web3d-00.txt>
Note: Ted Hardie will discuss with author and send RFC Editor
Note.
7. Document Actions Deferred:
o Exclusive XML Canonicalization, Version 1.0 (Informational)
<draft-ietf-xmldsig-xc14n-00.txt>
o A URN Namespace for FIPA (Informational)
<draft-bellifemine-urn-fipa-00.txt>
8. Working Group Actions Approved:
o Application Exchange (apex) to close
Note: Ted Hardie to send message to Secretariat to be sent to
RFC Editor re: changing status of draft from proposed to
experimental. Secretariat to change draft-ietf-apex-presence-06.txt
from an individual to an experimental document.
o Network Configuration (netconf)
Note: Secretariat to send formal WG Review message to
ietf-announce, new-work, et al. and return item to next
telechat agenda.
o Reliable Multicast Transport (rmt)
Note: IESG approved minor re-charter. Secretariat to update
charter page.
9. Documents Remaining Under Discussion:
o Internet X.509 Public Key Infrastructure Permanent Identifier
(Proposed Standard)
<draft-ietf-pkix-pi-06.txt>
o Security Considerations for SIGTRAN Protocols (Proposed Standard)
<draft-ietf-sigtran-security-02.txt>
o The AES Cipher Algorithms and Their Use With IPsec (Proposed
Standard)
<draft-ietf-ipsec-ciph-aes-cbc-04.txt>
o Use of the AES Encryption Algorithm in CMS (Proposed Standard)
<draft-ietf-smime-aes-alg-06.txt>
o Using IPsec to Protect Mobile IPv6 Signaling between Mobile
Nodes and Home Agents (Proposed Standard)
<draft-ietf-mobileip-mipv6-ha-ipsec-04.txt>
o IANA Considerations for RADIUS (Proposed Standard)
<draft-aboba-radius-iana-05.txt>
o IPv6 Global Unicast Address Format (Informational)
<draft-ietf-ipv6-unicast-aggr-v2-02.txt>
o Policy Requirements for Time-Stamping Authorities (Informational)
<draft-ietf-pkix-pr-tsa-04.txt>
o Dynamic Authorization Extensions to Remote Authentication Dial-In
User Service (RADIUS) (Informational)
<draft-chiba-radius-dynamic-authorization-12.txt>
o Multicast Source Discovery Protocol (MSDP) (Experimental)
<draft-ietf-msdp-spec-15.txt>
o Handle System Overview (Informational)
<draft-sun-handle-system-10.txt>
o Handle System Protocol (ver 2.1) Specification (Informational)
<draft-sun-handle-system-protocol-04.txt>
o Handle System Namespace and Service Definition (Informational)
<draft-sun-handle-system-def-07.txt>
o Tracing Requirements for Generic Tunnels (None)
<draft-ietf-ccamp-tracereq-01.txt>
10. The IESG confirmed the IAB's selection for the IETF
appointment to the ISOC BoT. The decision was unanimous
among the 10 IESG members present on the telechat with 3 members
absent.
11. New Action Items:
o Ted to send RFC Editor Note to Secretariat for
draft-walsh-urn-web3d-00.txt.
o Erik to write, send formal statement to Secretariat to be sent to
IAB confirming IETF appointment to ISOC BoT.
o Ted Hardie to send message to Secretariat for apex wg to be sent
to RFC Editor re changing status of draft from proposed to
experimental. Secretariat to change.
draft-ietf-apex-presence-06.txt from and individual to an
experimental document.
o Secretariat to send formal WG Review message for netconf to
ietf-announce, new-work, et al. and return item to next telechat
agenda.
o IESG approved minor re-charter for rmt wg. Secretariat to update
rmt wg charter page.
o Secretariat to update ballot for draft-zeilenga-ldap-user-schema
for it to be reconsidered as a new ballot on the next telechat.
12. Outstanding Action Items:
IP o Allison to review draft-agrawal-sip-h323-interworking-reqs
and send decision to IESG.
IP o Erik to document process of how the IESG goes about asking
architectural questions of the IAB.
IP o Thomas to write (or cause to be written) a draft on "how to
get to Draft".
IP o Thomas to contact Cablelabs to discuss formal relationship
with IAB.
IP o Allison and Thomas will email Secretariat note to send to RFC
Editor about 3GPP RFC Editor documents.
o Secretariat to modify auto-response for Internet-Drafts
submissions so that when someone submits an I-D, a note is
automatically generated which recommends that they consider
the issues listed in ID-Nits before submitting the I-D to the
IESG. Auto-response to include the URL pointing to the
I-D Nits page.
o Secretariat to email Working Group Chairs a reminder after
each conference with pointer to I-D Nits. Secretariat to
draft reminder text and pass by IESG first.
IP o Ned to write an IESG note for draft-tegen-smqp (Informational).
IP o Steve to write RFC re TCP MD5 option.
IP o Randy and Ned to finish ID on Clarifying when Standards Track
Documents may Refer Normatively to Documents at a Lower Level.
IP o Bert to send instructions/text to Secretariat to install URL
for IANA MIB Copyright.
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-user-schema - LDAPv3: A
Collection of User Schema to Proposed Standard
--------
It is proposed that this be approved for Proposed Standard with the
following IESG note:
This document contains useful and timely updates to RFC 2798. The IESG
expects that this document will be replaced or updated again once the
LDAP community has finished its work related to stringprep, and that
those updates will cause this document or its successors to recycle at
the Proposed Standard level.
Last Call to expire on: January 28, 2002
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ XX] [ X ] [ ]
Randy Bush [ ] [ X ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ D ]
Ted Hardie [ X ] [ ] [ ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ X ] [ ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
Jon Peterson [ ] [ X ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
2/3 (10) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
========
Steve: Does this depend on stringprep for comparisons? Should it?
COMMENTS:
=========
Ted:
Steve,
Kurt has suggested a tweak to this; here is his note:
> Ted, regarding this recently added note to the tracker:
> It is proposed that this be approved for Proposed Standard with
> the following IESG note: This document contains useful and timely
> updates to RFC 2798. The IESG expects that this document will be
> replaced or updated again once the LDAP community has finished its
> work related to stringprep, and that those updates will cause this
> document or its successors to recycle at the Proposed Standard level.
>
> The primary focus of the I-D is to update RFC 1274 (Proposed Standard)
> and to adapt additional X.520(93) schema for use in LDAP (such as
> the matching rules needed by Policy WG draft). Superceding portions
> of RFC 2798 (Informational) became necessary as it tried to fill some
> of the gaps.
>
> I would suggest the IESG note focus more on "useful and timely
> updates" to RFC 1274 (and filling gaps between X.520(93) and LDAP).
>
> Kurt
Based on that, I think we might want to change the text to say
"This document contains useful and timely updates of RFC
1274 and RFC 2798, as well as harmonizing certain aspects
of X.520(93) and LDAP. The IESG expects that this document
will be replaced or updated again once the LDAP community has
finished its work related to stringprep, and that those updates will
cause this document or its successors to recycle at the Proposed
Standard level"
Would this text still be okay with you?
Russ:
Section 3.25. Should we change "secretary" to "secretary or
administrative assistant" in the description of the attribute? I am
not proposing to change the name of the attribute.
^L
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: LDAPv3: A Collection of User Schema to
Proposed Standard
-------------
The IESG has approved the Internet-Draft 'LDAPv3: A Collection of User
Schema' <draft-zeilenga-ldap-user-schema-06.txt> as a Proposed
Standard. 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 Patrik Faltstrom
Technical Summary
This document provides a collection of user schema elements for use
with LDAP (Lightweight Directory Access Protocol) from both ITU-T
Recommendations for the X.500 Directory and COSINE and Internet X.500
pilot projects.
Working Group Summary
This document is not a product of a working group. It has been
discussed on the LDAPBIS working group mailing list. There was
consensus for publication of a document specifying this schema.
Protocol Quality
The specification was 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-vaudreuil-mdnbis - Message Disposition
Notification to Draft Standard
--------
Last Call to expire on: 2002-12-23
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ X ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>,
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Message Disposition Notification to Draft
Standard
-------------
The IESG has approved the Internet-Draft 'Message Disposition
Notification' <draft-vaudreuil-mdnbis-03.txt> as a Draft Standard,
obsoleting RFC2298.
This document 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 memo defines a MIME content-type that may be used by a mail user
agent (MUA) or electronic mail gateway to report the disposition of a
message after it has been successfully delivered to a recipient. This
content-type is intended to be machine-processable. Additional
message headers are also defined to permit Message Disposition
Notifications (MDNs) to be requested by the sender of a message. The
purpose is to extend Internet Mail to support functionality often
found in other messaging systems, such as X.400 and the proprietary
"LAN-based" systems, and often referred to as "read receipts,"
"acknowledgements", or "receipt notifications." The intention is to
do this while respecting the privacy concerns that have often been
expressed when such functions have been discussed in the past.
Working Group Summary
This document was originally the product of the RECEIPT working group.
Review of the revised version was conducted largely in the context
of the VPIM working group.
Protocol Quality
Ned Freed reviewed the document for the IESG.
RFC Editor Note
The IPR boilerplate is missing from the draft and needs to be added
before publication.
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 [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ X ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>,
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-ietf-ccamp-gmpls-architecture - Generalized
Multi-Protocol Label Switching Architecture to Proposed Standard
--------
Last Call to expire on: 2003-4-10
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ X ] [ ]
Randy Bush [ ] [XX ] [ X ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ X ]
Russ Housley [ ] [ ] [ X ] [ ]
Allison Mankin [ ] [ X ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ D ]
Erik Nordmark [ ] [ X ] [ ] [ ]
Jon Peterson [ ] [ X ] [ ] [ ]
Bert Wijnen [ X ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ X ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
========
Russ:
Two minor comments:
1. Section 4.3, 4th paragraph says: "Forwarding Adjacencies (FA) are
further described in a separate section." It would be nice to say
which one.
2. Section 15, please change "IPSEC" to "IPsec."
Steve:
Nit: section 4 says
Re-using existing IP routing protocols allows for non-PSC layers
to take advantages of all the valuable developments that took
place since years for IP routing,
which isn't grammatically correct.
The Security Considerations section hints at, but doesn't follow
through with, the difference between authentication and authorization.
The requirement for cryptographic authentication or encryption
depends on the risk of attackers being able to inject and/or snoop
on traffic. This may or may not be correlated with intra-domain vs.
inter-domain GMPLS. The physical characteristics and exposure of the
link matter more; there may be additional exposure since it appears
that the control plane link may be more than one hop long.
The authorization question is what resources a given node may request
of another. This may indeed be differ for inter-domain and
intra-domain GMPLS. On the other hand, imposing such limits even
internally helps guard against spreading break-ins, and has useful
effects with regard to configuration errors.
The more important question raised by this latter point is whether or
not a security architecture is needed that specifies what sorts of
restrictions can be applied. I don't know the answer to that one;
clearly, though, implementors are going to have to decide.
COMMENTS:
=========
Ted:
This abstain falls under the category:
> I oppose this document for some philosophical reason but
> understand that others differ and am not going to stand
> in the way of the others
The philosophical reason here is that the document
has addressing fundamentally wrong. This almost
certainly isn't fixable now, so I will not stand in the way.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, ccamp@ops.ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Generalized Multi-Protocol Label Switching
Architecture to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Generalized Multi-Protocol
Label Switching Architecture'
<draft-ietf-ccamp-gmpls-architecture-05.txt> as a Proposed Standard.
This document is the product of the Common Control and Measurement
Plane Working Group. The IESG contact persons are Bert Wijnen and
Alex Zinin.
Technical Summary
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.
This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.
Working Group Summary
The CCAMP Working Group has consensus on this document to be
published as a standards track document.
Protocol Quality
This document has been reviewed for the IESG by Bert Wijnen and
Alex Zinin.
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-sipping-basic-call-flows - Session
Initiation Protocol Basic Call Flow Examples to BCP
--------
Last Call to expire on: 2002-12-8
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ X ] [ ] [ ]
Steve Bellovin [ ] [ ] [ X ] [ ]
Scott Bradner [ X ] [ ] [ ] [ ]
Randy Bush [ ] [ X ] [ ] [ ]
Patrik Faltstrom [ ] [ ] [ X ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Allison Mankin [ X ] [ ] [ ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jeff Schiller [ ] [ X ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
========
Patrik:
Discuss a: Domain names used in examples should be changed.
Discuss b: Should not use of ENUM be mentioned, so people understand
where to use it? I.e. when making call from PSTN to SIP, or from SIP to
SIP (where destination is E.164 number) an ENUM lookup should be done
(according to discussions in ENUM wg).
Steve:
Why is this BCP instead of Informational? (This is the grounds for my
DISCUSS, and it's a real "discuss", i.e., let's talk about it. Assume
that it will be lifted after the call.)
I think I'd prefer to omit the endorsement of IPsec in the Security
Considerations section. Yes, it's sort-of mentioned in 3261, but very
barely. But I can live with it being there.
COMMENTS:
=========
Scott:
references need to be split in draft-ietf-sipping-basic-call-flows-01.txt
Allison:
> Why is this BCP instead of Informational? (This is the grounds for my
> DISCUSS, and it's a real "discuss", i.e., let's talk about it. Assume
> that it will be lifted after the call.)
>
Steve,
It's a BCP for two reasons:
1. To be usable by ITU as they cannot use our documents unless they
are standards track. It is very desirable for these flow docs to
be cited by ITU docs. 2. More idealistiically it actually does
represent "best common practices" - the flows are those that are
the selections among all possible that work the best and are
viewed as most sensible...
> I think I'd prefer to omit the endorsement of IPsec in the Security
> Considerations section. Yes, it's sort-of mentioned in 3261, but very
> barely. But I can live with it being there.
I could see excising it with an RFC Editor note - it's pretty feeble.
I had missed it. There's a thread of IPsec story in SIP due to a Cisco
product theme, I think.
We're going to have an RFC Editor note for some other things anyway.
Thomas:
Allison Mankin <mankin@psg.com> writes:
> It's a BCP for two reasons:
Note that the document itself also says it is informational (per the
abstract)...
Also:
This document is informational only and is NOT NORMATIVE in any
sense, in that it does not prescribe the flows that are shown, indeed
they MUST NOT be copied due to the reasons described in the next
paragraph. On the other hand, the basic call flows represent well-
reviewed examples of SIP usage that are best common practice
according to community consensus.
It seems odd for a BCP to say it is NOT NORMATIVE...
> It's a BCP for two reasons:
> 1. To be usable by ITU as they cannot use our documents unless they
> are standards track. It is very desirable for these flow docs to
> be cited by ITU docs. 2. More idealistiically it actually does
> represent "best common practices" - the flows are those that are
> the selections among all possible that work the best and are viewed
> as most sensible...
I hear you, but on the surface, this just doesn't strike me as a BCP
document, at least not as the document currently reads.
If there was a better way to say the examples *are* the recommended
ways of doing certain (even common) things, that would have a better
justification for BCP. I.e., a bit more in the way of an applicability
section?
Also, split references?
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, sipping@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Session Initiation Protocol Basic Call Flow
Examples to BCP
-------------
The IESG has approved the following Internet-Drafts as BCPs:
o 'Session Initiation Protocol Basic Call Flow Examples'
<draft-ietf-sipping-basic-call-flows-01.txt>
o 'Session Initiation Protocol PSTN Call Flows'
<draft-ietf-sipping-pstn-call-flows-01.txt>
These documents are the product of the Session Initiation Proposal
Investigation Working Group. The IESG contact persons are Allison
Mankin and Scott Bradner.
Technical Summary
These documents have been developed to provide information on the
use of call flows in Session Initiation Protocol (SIP) networks.
The documents are designed to be used by SIP implementers,
designers, and protocol researchers to help further the goal of a
standard implementation of SIP.
These flows represent carefully checked and working group reviewed
scenarios of the most basic examples as a companion to the
specifications.
The "Basic Call Flow Examples" document gives examples of basic SIP
call flows. Elements in these call flows include SIP User Agents and
Clients, SIP Proxy and Redirect Servers. Scenarios include SIP
Registration and SIP session establishment.
The "PSTN Call Flows" document provides examples of SIP interworking
with the PSTN through gateways. Elements in these call flows include
SIP User Agents, SIP Proxy Servers, and PSTN Gateways. Scenarios
include SIP to PSTN, PSTN to SIP, and PSTN to PSTN via SIP. PSTN
telephony protocols are illustrated using ISDN (Integrated Services
Digital Network), ISUP (ISDN User Part), and FGB (Feature Group B)
circuit associated signaling. PSTN calls are illustrated using global
telephone numbers from the PSTN and private extensions served on by
a PBX (Private Branch Exchange).
Call flow diagrams and message details are shown in both documents.
Working Group Summary
The working group supported the publication of these documents as BCPs.
Protocol Quality
These documents were reviewed for the IESG by Allison Mankin.
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 [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ X ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>, Internet Architecture Board <iab@iab.org>,
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-04.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-ccamp-lmp - Link Management Protocol
(LMP) to Proposed Standard
--------
Last Call to expire on: 2003-4-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 [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ X ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, ccamp@ops.ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Link Management Protocol (LMP) to Proposed
Standard
-------------
The IESG has approved the Internet-Draft 'Link Management Protocol
(LMP)' <draft-ietf-ccamp-lmp-08.txt> as a Proposed Standard. This
document is the product of the Common Control and Measurement Plane
Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin.
Technical Summary
(What does this protocol do and why does the community need it?)
Working Group Summary
(Was there any significant dissent? Was the choice obvious?)
Protocol Quality
(Who has reviewed the spec for the IESG? Are there implementations?)
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-rfc2510bis - Internet X.509 Public
Key Infrastructure Certificate Management Protocols to
Proposed Standard
--------
Last Call to expire on: 2003-2-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 [ X ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, ietf-pkix@imc.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Internet X.509 Public Key Infrastructure
Certificate Management Protocols to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Internet X.509 Public
Key Infrastructure - Certificate Management Protocol'
<draft-ietf-pkix-rfc2510bis-08.txt> as a Proposed Standard.
This document is the product of the PKIX Working Group.
Technical Summary
This document obsoletes RFC 2510.
This document describes the Internet X.509 Public Key Infrastructure
(PKI) Certificate Management Protocol (CMP). Protocol messages are
defined for X.509v3 certificate creation and management. CMP provides
on-line interactions PKI components, including an exchange between a
Certification Authority (CA) and a client system.
Working Group Summary
The Working Group came to consensus on this document.
Protocol Quality
This document was reviewed by Jeffrey I. Schiller 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-pkix-rfc2511bis - Internet X.509 Public
Key Infrastructure Certificate Request Message Format (CRMF)
to Proposed Standard
--------
Last Call to expire on: 2003-2-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 [ X ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, ietf-pkix@imc.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF) to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Internet X.509 Public
Key Infrastructure - Certificate Request Message Format (CRMF)'
<draft-ietf-pkix-rfc2511bis-06.txt> as a Proposed Standard.
This document is the product of the PKIX Working Group.
Technical Summary
This document obsoletes RFC 2511.
This document describes the Certificate Request Message Format (CRMF).
This syntax is used to convey a request for a certificate to a
Certification Authority (CA), possibly via a Registration Authority
(RA), for the purposes of X.509 certificate production. The request
will typically include a public key and associated registration
information.
Working Group Summary
The Working Group came to consensus on this document.
Protocol Quality
This document was reviewed by Jeffrey I. Schiller for the IESG.
Multiparty Multimedia Session Control (mmusic)
-------------------------------------
Last Modified: 2003-04-14
Chair(s):
Joerg Ott <jo@ipdialog.com>
Colin Perkins <csp@csperkins.org>
Transport Area Director(s):
Jon Peterson <jon.peterson@neustar.biz>
Allison Mankin <mankin@psg.com>
Transport Area Advisor:
Jon Peterson <jon.peterson@neustar.biz>
Mailing Lists:
General Discussion: mmusic@ietf.org
To Subscribe: mmusic-request@ietf.org
In Body: subscribe your_email_address
Archive: http://www.ietf.org/mailman/listinfo/mmusic
Description of Working Group:
The Multiparty MUltimedia SessIon Control (MMUSIC) Working Group (WG) was
chartered to develop protocols to support Internet teleconferencing and
multimedia communications. These protocols are now reasonably mature, and
many have received widespread deployment. The group is now focussed on the
revisions of these protocols in the light of implementation experience and
additional demands that have arisen from other WGs (such as AVT, SIP,
SIPPING, and MEGACO).
Multimedia communications protocols use a common platform for expressing
media and session descriptions. This is the Session Description Protocol,
SDP. The many uses of SDP have led to (requests for) numerous extensions
and have led to recognition of several flaws in the protocol design. In
spite of these, it is widely deployed.
- To support this current deployment, MMUSIC will revise SDP suitable for
publication as a Draft Standard RFC. This will involve correcting minor
bugs and clarifying the current specification.
- Various extensions to SDP will be pursued to remedy the most urgent of
SDP's shortcomings. These will be limited to use of SDP in conjunction
with connection-oriented media such as TCP and SCTP, offering support
to work with NATs and firewalls, exchange of media session security
keys.
Apart from these, which are explicitly agreed to by the Area Directors and
shown in the milestones, only extensions within the existing framework of
SDP will be done (e.g. registering new codecs and defining parameters for
them extending SDP to include new address families).
To address the more fundamental issues with SDP, a next generation of SDP,
referred to as SDPng, has been in progress and will be continued towards a
Proposed Standard RFC. A requirements document will be devised that gathers
the requirements from the areas in which SDP is currently deployed.
MMUSIC will continue to maintain and revise the specification of the Real
Time Streaming Protocol (RTSP) based on implementation experience. The RTSP
specification will be revised to include various fixes and clarifications.
Depending on the changes, the revised RTSP specification will be re-issued
as either a Proposed or Draft Standard RFC. A MIB will be considered.
An Internet Media Guide (IMG) is a collection of multimedia session
descriptions expressed using SDP, SDPng or some similar session description
format. It is used to describe a collection of multimedia sessions (e.g.
television programme schedules). The IMG must be delivered to a
potentially large audience, who use it to join a subset of the sessions
described, and who may need to be notified of changes to the IMG.
MMUSIC will investigate work on delivery mechanisms for IMGs, generalizing
its work on session announcement and discovery protocols (SAP, RTSP, SIP).
We will investigate and document requirements for IMG delivery mechanisms,
and identify the requirements that these delivery mechanisms impose on the
session description formats used by the IMG. We will then work to produce
a framework document outlining the use of (existing) protocols to create an
IMG delivery infrastructure. After successful completion of these initial
milestones for IMG delivery, the MMUSIC working group will decide whether
or not MMUSIC is the proper place to pursue any needed mechanisms for IMGs,
and if so, recharter accordingly
The MMUSIC work items will be pursued in close coordination with other IETF
WGs related to multimedia conferencing and IP telephony (AVT, SIP, SIPPING,
IPTEL, MEGACO). Where appropriate, new separate working groups may be split
off (as has happened with the SIP WG).
The Working Group is also charged with addressing security issues related
to the protocols it develops.
Goals and Milestones:
APR 03 Submit SDP source filter extensions for Proposed Standard
MAY 03 Submit draft on SDPng motivations, comparisons with current SDP
capabilities. Request charter review on SDPng work from IAB and
IESG.
JUL 03 Submit revised SDP spec for Proposed Standard
JUL 03 Submit IMG requirements and framework for Informational
JUL 03 Review work on IMGs and update charter accordingly
AUG 03 Submit SDPng base spec profile for Proposed Standard
OCT 03 Submit revised RTSP spec for Proposed or Draft Standard
(as appropriate)
OCT 03 Submit SDP Offer/Answer examples for Informational
NOV 03 Submit SDP security extension for Proposed Standard
NOV 03 Submit SDPng RTP profile spec for Proposed Standard
NOV 03 Submit SDPng audio profile spec for Proposed Standard
NOV 03 Submit SDPng video profile spec for Proposed Standard
DEC 03 Submit RTSP MIB for Proposed Standard
Network Configuration WG (netconf)
-----------------------------------------------------
Status: Proposed new WG
Chair(s):
???
???
Operations and Management Area Directors:
Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>
Operation and Management Area Advisor:
Bert Wijnen <bwijnen@lucent.com>
Mailing Lists: [ed. these will change to netconf*]
General Discussion: xmlconf@ops.ietf.org
To Subscribe: xmlconf-request@ops.ietf.org
in msg body: subscribe
Archive: http://ops.ietf.org/lists/xmlconf
Description of Working Group:
Configuration of networks of devices has become a critical requirement for
operators in today's highly interoperable networks. Operators from large
to small have developed or used vendor specific mechanisms to transfer
configuration data to and from a device, and for examining device state
information which may impact the configuration. Each of these mechanisms
may be different in various aspects, such as session establishment,
user authentication, configuration data exchange, and error responses.
The Netconf Working Group is chartered to produce a protocol
suitable for network configuration, with the following
characteristics:
- Provides retrieval mechanisms which can differentiate between
configuration data and non-configuration data
- Is extensible enough that vendors will provide access
to all configuration data on the device using a single protocol
- Has a programmatic interface (avoids screen scraping
and formatting-related changes between releases)
- Uses a textual data representation, that can be easily
manipulated using non-specialized text manipulation tools.
- Supports integration with existing user authentication methods
- Supports integration with existing configuration database systems
- Supports network wide configuration transactions (with features
such as locking and rollback capability)
- Is as transport-independent as possible
- Provides support for asynchronous notifications
The Netconf protocol will use XML for data encoding purposes,
because XML is a widely deployed standard which is supported
by a large number of applications. XML also supports
hierarchical data structures and multiple character sets.
The Netconf protocol should be independent of the data definition
language and data models used to describe configuration and
state data. However, the authorization model used in the protocol
is dependent on the data model. Although these issues must be
fully addressed to develop standard data models, only a small part
of this work will be initially addressed. This group will specify
requirements for standard data models in order to fully support the
Netconf protocol, such as:
- identification of principals, such as user names or
distinguished names
- mechanism to distinguish configuration from
non-configuration data
- XML namespace conventions
- XML usage guidelines
It should be possible to transport the Netconf protocol using
several different protocols. The group will select at least
one suitable transport mechanism, and define a mapping for
the selected protocol(s).
The initial work will be restricted to the following items:
- Netconf Protocol Specification, which defines the
operational model, protocol operations, transaction model,
data model requirements, security requirements, and transport
layer requirements.
- Netconf over <TBD> Specification, which defines how the
Netconf protocol is used with the transport protocol
selected by the group. There will be a document of
this type for each selected transport protocol.
The working group will base its work on the XMLCONF Configuration
Protocol <draft-enns-xmlconf-spec-00.txt>.
Goals and Milestones:
MAY 03 Working Group formed
JUL 03 Submit initial Netconf Protocol draft
AUG 03 Submit initial Netconf over <TBD> draft
DEC 03 Begin Working Group Last Call for the Netconf Protocol
draft
JAN 04 Begin Working Group Last Call for the Netconf over
<TBD> draft
MAR 04 Submit final version of the Netconf Protocol draft
to the IESG
APR 04 Submit final version of the Netconf over <TBD> draft
to the IESG
Internet Drafts
Request for Comments
Management Issues:
Item name: AD-shepherded non-WG Info/Experimental documents
Writeup to be included in package:
RFC 2026 suggests that Info/Experimental non-WG documents "should"
come to the IESG via the RFC Editor. We've had some exceptions to
this; we need to describe what we do in such a way that the community
knows what to expect.
Suggested texts for a policy:
1)
When an AD decides that an Informational or
Experimental document is of particular importance to the
community, the AD may also choose to put it directly
before the IESG. This document will then be processed in
the same fashion as an Informational or Experimental
document from a working group.
2)
In some cases, an individual will ask an AD directly if they are
willing to shepherd a document through the IESG. This can happen,
for example, when an individual has already been discussing a
particular document with an AD because the topic of the document
naturally falls into a particular area. In such cases, the
document is processed in the same fashion as an Informational or
Experimental document from a working group.