[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FINAL IESG Telechat Agenda and Package for May 15, 2003
INTERNET ENGINEERING STEERING GROUP (IESG)
Agenda for the May 15, 2003 IESG Teleconference
1. Administrivia
o Roll Call
o Bash the Agenda
o Approval of the Minutes
- April 30, 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.
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
o Alex to send proposal and justification for interim document review.
DONE o Secretariat to send drafted auto-response text for I-D submissions
to IESG for review.
DONE o Secretariat to send drafted Working Group Chairs reminder text w/
pointer to I-D Nits to IESG for review.
o Allison will send RFC Editor Note to address Patrik's issues for Ted
for draft-ietf-sipping-basic-call-flows
o Allison to ask Steve Casner, AVT Chair, to review draft-smith-urn-mpeg
o Ted to write straw working group procedures for handling consensus-
blocked decisions
o Alex will notify Secretariat once ok to announce
draft-ietf-ipo-framework-04.txt
o Ted will notify Secretariat when ready to announce
draft-ietf-cdi-scenarios-01.txt
o Ted will send note as well as notify Secretariat when
draft-gustin-goyens-urn-id-02.txt is officially approved and ready
to announce.
IP o Secretariat to send change in mmusic charter (WG Re-charter) to IAB,
IESG and WG Chairs. After one week, if ok, Jon will tell the
Secretariat to send this charter to ietf-announce and new-work.
IP o Secretariat to send ldup WG Action/Re-charter announcement to IAB,
IESG, WG Chairs. If nothing happens, in one week Ted will ask
Secretariat to announce.
IP o Secretariat to send grow WG Action announcement to ietf-announce,
install charter.
o After netconf WG Chairs are approved, Bert will ask Secretariat to
send WG Action to ietf-announce, cc: WG Chairs.
IP o Alex to send DNP message for draft-srisuresh-ospf-te-05.txt to
Secretariat to send on behalf of IESG.
IP o Steve to generate a summary of IESG views of the "problem"
IP o Steve to propose a different document classification than the
current info/proposed/etc.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item
o Stream Control Transmission Protocol Management Information Base
(Proposed Standard)
<draft-ietf-sigtran-sctp-mib-09.txt>
Token: Peterson, Jon
o Handling of Unknown DNS Resource Record Types (Proposed Standard)
<draft-ietf-dnsext-unknown-rrs-05.txt>
Token: Nordmark, Erik
2.1.2 Returning Items
o Extensible Provisioning Protocol (Proposed Standard)
<draft-ietf-provreg-epp-09.txt>
Token: Hardie, Ted
o Extensible Provisioning Protocol Domain Name Mapping (Proposed
Standard)
<draft-ietf-provreg-epp-domain-07.txt>
o Extensible Provisioning Protocol Host Mapping (Proposed
Standard)
<draft-ietf-provreg-epp-host-07.txt>
o Extensible Provisioning Protocol Contact Mapping (Proposed
Standard)
<draft-ietf-provreg-epp-contact-07.txt>
o Extensible Provisioning Protocol Transport Over TCP (Proposed
Standard)
<draft-ietf-provreg-epp-tcp-06.txt>
o Source Address Selection for Multicast Listener Discovery Protocol
(RFC 2710) (Proposed Standard)
<draft-ietf-magma-mld-source-05.txt>
Token: Nordmark, Erik
Note: Waiting for Thomas to clear his discuss.
o Link Management Protocol (LMP) (Proposed Standard)
<draft-ietf-ccamp-lmp-08.txt>
Token: Wijnen, Bert
Note: New revision needed
Responsible: Authors and WG
2.2 Individual Submissions
2.2.1 New Item
o Sieve -- Subaddress Extension (Proposed Standard)
<draft-murchison-sieve-subaddrdraft-murchison-sieve-subaddressess-06.txt>
Token: Freed, Ned
Note: Revised version received during last call
2.2.2 Returning Item
NONE
3. Document Actions
3.1 WG Submissions
3.1.1 New Item
o Service requirements for Layer 3 Provider Provisioned Virtual Private
Networks: (Informational)
<draft-ietf-ppvpn-requirements-06.txt>
Token: Zinin, Alex
o A Framework for Layer 3 Provider Provisioned Virtual Private
Networks (Informational)
<draft-ietf-ppvpn-framework-08.txt>
Token: Zinin, Alex
3.1.2 Returning Item
NONE
3.2 Individual Submissions Via AD
3.2.1 New Items
o Dynamic Authorization Extensions to Remote Authentication Dial In
User Service (RADIUS) (Informational)
<draft-chiba-radius-dynamic-authorization-19.txt>
Token: Bush, Randy
o IP Version 6 over MAPOS (Informational)
<draft-ogura-ipv6-mapos-02.txt>
Token: Narten, Thomas
Note: IESG: This is a returning document. security considerations
revised per smb's request, document is ready to go. Needs the
following IESG note added: This memo documents a way of carrying IPv6
packets over MAPOS networks. This document is NOT the product of an
IETF working group nor is it a standards track document. It has not
necessarily benefited from the widespread and in-depth community
review that standards track documents receive.
3.2.2 Returning Item
o RADIUS Support For Extensible Authentication Protocol (EAP)
(Informational)
<draft-aboba-radius-rfc2869bis-21.txt>
Token: Bush, Randy
3.3 Individual Submissions Via RFC Editor
3.3.1 New Item
NONE
3.3.2 Returning Item
NONE
4. Working Group Actions
o IP Telephony
Token: Jon Peterson
o SIP for Instant Messaging and Presence Leveraging Extensions
Token: Ted Hardie
5. Working Group News We Can Use
6. IAB News We Can Use
7. Management Issues
o isakmp-registry
o Approval of RFC Editor Note for CDI scenarios draft
*DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT *
INTERNET ENGINEERING STEERING GROUP (IESG)
April 30, 2003
Reported by: Jacqueline Hargest, IETF Assistant Director
ATTENDEES
---------
Alvestrand, Harald / Cisco
Austein, Rob / IAB Liaison
Bellovin, Steve / AT&T Labs
Bush, Randy / IIJ
Daigle, Leslie / Verisign (IAB)
Falk, Aaron / ISI
Fenner, Bill / AT&T
Freed, Ned / Innosoft
Fuller, Barbara / IETF
Hardie, Ted / Qualcomm, Inc.
Hargest, Jacqueline / IETF
Housley, Russ / Vigil Security, LLC
Mankin, Allison / Bell Labs, Lucent
Narten, Thomas / IBM
Nordmark, Erik / Sun
Peterson, Jon / NeuStar, Inc.
Reynolds, Joyce K. / ISI (RFC Editor)
Wijnen, Bert / Lucent
Zinin, Alex / Alcatel
REGRETS
-------
Cotton, Michelle / ICANN
Minutes
-------
1. The minutes of the April 17, 2003 teleconference were approved.
Secretariat to place in public archives and update minutes web page.
2. The following action items were reported as DONE:
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.
3. Protocol Actions Deferred:
o Link Management Protocol (LMP) (Proposed Standard)
<draft-ietf-ccamp-lmp-08.txt
4. Document Actions Tentatively Approved:
o IP over Optical Networks: A Framework (Informational)
<draft-ietf-ipo-framework-04.txt>
Note: Tentatively approved, subject to addressing Allison's
concerns. Alex will notify Secretariat once ok to announce.
o Content Internetworking (CDI) Scenarios (Informational)
<draft-ietf-cdi-scenarios-01.txt>
Note: Tentatively approved pending references correction. Ted
will notify Secretariat when ready to announce.
o A Description of the Camellia Encryption Algorithm
(Informational)
<draft-nakajima-camellia-02.txt>
Note: Tentatively approved pending new revision to address
Thomas's boilerplate issue.
o A URN Namespace for SWIFT's Financial Messaging (Informational)
<draft-gustin-goyens-urn-id-02.txt>
Note: Tentatively approved pending note from Ted.
o A URN Namespace for MPEG (Informational)
<draft-smith-urn-mpeg-01.txt>
Note: Tentatively approved, subject to review by AVT Chair.
o A URN Namespace for FIPA (Informational)
<draft-bellifemine-urn-fipa-00.txt>
Note: Tentatively approved pending update to security
considerations and expansion of acronym in title.
5. Document Action Deferred:
o SDPng Transition (Informational)
<draft-ietf-mmusic-sdpng-trans-03.txt>
6. Working Group Actions Approved:
o Multiparty Multimedia Session Control (mmusic)
Note: Secretariat to send change in charter (WG Re-charter) to IAB,
IESG and WG Chairs. After one week, if ok, Jon can tell the
Secretariat to send this charter to ietf-announce and new-work.
o LDAP Duplication/Replication/Update Protocols
Note: Secretariat to send WG Action/Re-charter announcement to IAB,
IESG, WG Chairs. If nothing happens, in one week Ted will ask
Secretariat to announce.
o Global Routing Operations (grow)
Note: IESG gave final approval. Secretariat to send WG Action
announcement to ietf-announce, install charter.
7. Working Group Action Tentatively Approved:
o Network Configuration (netconf)
Note: Once WG Chairs are approved, Bert will ask Secretariat to
send WG Action to ietf-announce, cc: WG Chairs.
8. Documents Remaining Under Discussion:
o LDAPv3: A Collection of User Schema (Proposed Standard)
<draft-zeilenga-ldap-user-schema-06.txt>
o Message Disposition Notification (Draft Standard)
<draft-vaudreuil-mdnbis-03.txt>
o The IETF XML Registry (BCP)
<draft-mealling-iana-xmlns-registry-04.txt>
o Generalized Multi-Protocol Label Switching Architecture
(Proposed Standard)
<draft-ietf-ccamp-gmpls-architecture-05.txt>
o Session Initiation Protocol Basic Call Flow Examples (BCP)
<draft-ietf-sipping-basic-call-flows-02.txt>
o UTF-8, a transformation format of ISO 10646 (Standard)
<draft-yergeau-rfc2279bis-04.txt>
o Internet X.509 Public Key Infrastructure Certificate Management
Protocols (Proposed Standard)
<draft-ietf-pkix-rfc2510bis-08.txt>
o Internet X.509 Public Key Infrastructure Certificate Request
Message Format (CRMF)(Proposed Standard)
<draft-ietf-pkix-rfc2511bis-06.txt>
o Exclusive XML Canonicalization, Version 1.0 (Informational)
<draft-ietf-xmldsig-xc14n-00.txt>
o Policy Requirements for Time-Stamping Authorities (Informational)
<draft-ietf-pkix-pr-tsa-04.txt>
o Extreme Networks' Ethernet Automatic Protection Switching
(EAPS), Version 1 (Informational)
<draft-shah-extreme-eaps-02.txt>
o A Framework for Purpose Built Keys (PBK) (Informational)
<draft-bradner-pbk-frame-04.txt>
9. DNP (Do Not Publish):
o OSPF-xTE: An experimental extension to OSPF for Traffic
Engineering (Experimental)
<draft-srisuresh-ospf-te-05.txt>
Note: Alex to send DNP message to Secretariat to send on behalf
of IESG.
10. The IESG agreed that, since the IPR WG is currently discussing
boilerplate issues regarding informational and experimental
documents, until the working group reaches a conclusion it is
inappropriate for the IESG to make a permanent change to policy.
Where IPR might be relevant, standard boilerplate should be used.
In addition, if there are IPR, then IPR claims should be filed.
11. New Action Items:
o Alex to send proposal and justification for interim document
review.
o Secretariat to send drafted auto-response text for I-D
submissions to IESG for review.
o Secretariat to send drafted Working Group Chairs reminder text
w/ pointer to I-D Nits to IESG for review.
o Allison will send RFC Editor Note to address Patrik's issues
for Ted for draft-ietf-sipping-basic-call-flows
o Allison to ask Steve Casner, AVT Chair, to review
draft-smith-urn-mpeg
o Ted to write straw working group procedures for handling
consensus-blocked decisions
o Alex will notify Secretariat once ok to announce
draft-ietf-ipo-framework-04.txt
o Ted will notify Secretariat when ready to announce
draft-ietf-cdi-scenarios-01.txt
o Ted will send note as well as notify Secretariat when
draft-gustin-goyens-urn-id-02.txt is officially approved and
ready to announce.
o Secretariat to send change in mmusic charter (WG Re-charter) to
IAB, IESG and WG Chairs. After one week, if ok, Jon will tell
the Secretariat to send this charter to ietf-announce and
new-work.
o Secretariat to send ldup WG Action/Re-charter announcement to
IAB, IESG, WG Chairs. If nothing happens, in one week Ted will
ask Secretariat to announce.
o Secretariat to send grow WG Action announcement to
ietf-announce, install charter.
o After netconf WG Chairs are approved, Bert will ask Secretariat
to send WG Action to ietf-announce, cc: WG Chairs.
o Alex to send DNP message for draft-srisuresh-ospf-te-05.txt to
Secretariat to send on behalf of IESG.
o Steve to generate a summary of IESG views of the "problem"
o Steve to propose a different document classification than the
current info/proposed/etc.
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.
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
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-sigtran-sctp-mib - Stream Control
Transmission Protocol Management Information Base to Proposed
Standard
--------
Last Call to expire on: 2003-4-28
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 [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ X ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
COMMENTS:
=========
Ted:
Notes:
The Status of the memo cites it as an individual submission,
but the document name implies it is a sigtran working group
submission.
3.1.2
Would it make sense to eliminate "other" as a valid
entry for the SCTP RTO mechanism (leaving only vanj),
and note that later specifications may define other
values? Leaving "other" for future use doesn't seem
very likely to work well; it is meaningless now and under-
specified in the future.
4 (page 20)
So, whatever DNS name is received at initialization
time is stored in sctpAssocRemHostName. First,
that notation (0..115) indicates a 255 octet field?
The authors might also want to review the recent
thread on namedroppers:
http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg00964.html
and decide whether they need to describe more fully whether this
stored format is
the uncompressed wire format or some other format.
Russ:
Spell out first use of PSTN and SNMP.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, sigtran@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Stream Control Transmission Protocol
Management Information Base to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Stream Control Transmission
Protocol Management Information Base'
<draft-ietf-sigtran-sctp-mib-09.txt> as a Proposed Standard. This
document is the product of the Signaling Transport Working Group. The
IESG contact persons are Jon Peterson and Allison Mankin.
Technical Summary
The Stream Control Transmission Protocol (SCTP) is a reliable
transport protocol operating on top of a connectionless packet
network such as IP. It is designed to transport PSTN signaling
messages over the connectionless packet network, but is capable of
broader applications.
This memo defines the Management Information Base (MIB) module which
describes the minimum set of objects needed to manage the
implementation of the SCTP.
There is one existing nit that we need to fix in an RFC-editor note -
namely that the SIZE restriction of 115 octets on the
sctpAssocRemHostName needs to be removed (should be 255).
Working Group Summary
The SIGTRAN WG and the TSVWG WG supported this document.
Protocol Quality
This specification was reviewed for the IESG by Bert Wijnen and Jon
Peterson. Further MIB review was performed by the participants of
the mreview mailing list.
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-dnsext-unknown-rrs - Handling of
Unknown DNS Resource Record Types to Proposed Standard
--------
Last Call to expire on: 2003-4-16
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ X ] [ ] [ ] [ ]
Steve Bellovin [ ] [ X ] [ ] [ ]
Randy Bush [ ] [ X ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ X ] [ ] [ ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ X ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
COMMENTS:
=========
Steve:
It's clearly necessary to have something like that, but frankly,
the document scares me; it retroactively changes the behavior
required for older RFCs. I sure with Mockapetris had thought of
saying this.
Am I offbase? Is this much better -- or much worse -- than I fear?
Russ:
Please change "RFC TBD" to "this specification." I believe that it
will be easier for the reader.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, namedroppers@ops.ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Handling of Unknown DNS Resource Record
Types to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Handling of Unknown DNS
Resource Record Types' <draft-ietf-dnsext-unknown-rrs-05.txt> as a
Proposed Standard. This document is the product of the DNS Extensions
Working Group. The IESG contact persons are Thomas Narten and Erik
Nordmark.
Technical Summary
Extending the Domain Name System with new Resource Record (RR) types
currently requires changes to name server software. This document
specifies the changes necessary to allow future DNS implementations
to handle new RR types transparently.
Working Group Summary
There was WG consensus to advance the document.
Protocol Quality
The specification has been reviewed for the IESG by Erik Nordmark.
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-provreg-epp - Extensible Provisioning
Protocol to Proposed Standard
--------
Last Call to expire on: March 29, 2002
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ D ] [ ] [ ]
Steve Bellovin [ ] [ ] [XX ] [ D ]
Scott Bradner [ ] [ ] [ X ] [ ]
Randy Bush [ ] [ XX] [ X ] [ ]
Patrik Faltstrom [ X ] [ ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ ] [ X ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
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
-------
Steve:
> <draft-ietf-provreg-epp-07.txt>
Do we put mailing list names and URLs in RFCs?
I'd like a stronger Security Considerations section, though I think
it can be added by an RFC Editor note. In particular, I want it to
say that EPP "MUST NOT be used over a transport mechanism that does
not provide confidentiality", or "All transport mappings for EPP
MUST provide confidentiality and integrity". (I think that that's what
they intend, but it's not clear enough.)
> <draft-ietf-provreg-epp-domain-05.txt>
What is an "authorization token"? It's not defined, but it's mandated
by the security considerations. (I suspect it's what is discussed in
2.6, but it doesn't use the same words.)
> <draft-ietf-provreg-epp-contact-05.txt>
What is an "authorization token"? It's not defined, but it's mandated
by the security considerations. (I suspect it's what is discussed in
2.8, but it doesn't use the same words.)
> <draft-ietf-provreg-epp-tcp-05.txt>
The Security Considerations section seems to require TLS client
authentication, which in turn requires client certificates. Is this
intended? If so, great! But in that case, what is the fate, if any,
of the EPP login/password command? Is it still needed? Is it still
legal? What does it mean? Must the identities agree? (The requirement
for server authentication is excellent, but some more text mentioning
the need to validate the certificate chain is probably a good idea.)
Scott:
note:
draft-ietf-provreg-epp-07.txt sec 2.1
I think it would be good to be a bit more strict about
the use of congestion control protocols specifically require
the use of an IETF standards track congestion control
protocol such as TCP or SCTP
i.e. change the following line:
- The transport mapping MUST manage congestion.
to:
- The transport mapping MUST only be to an IETF standards
track congestion control protocol such as TCP or SCTP.
Bert: document: draft-ietf-provreg-epp-07.txt
page 12, example greeting has:
S: <svID>Example EPP server epp.example.tld</svID>
in an example greeting. Did we not decide at some point
that examples should be of the form: epp.example.org ??
Patrik answers:
> We should follow RFC 2606 which states that:
>
> 3. Reserved Example Second Level Domain Names
>
> The Internet Assigned Numbers Authority (IANA) also
> currently has the
> following second level domain names reserved which can be used as
> examples.
>
> example.com
> example.net
> example.org
>
>
> I.e. using "tld" as an example top level domain is wrong.
>
> Can you please have a discuss on this?
>
Sure... it seemed more like a small nit to me, in any event, such a
discuss I think can be cleared with a RFC-Editor note.
Allison:
ISSUES with draft-ietf-provreg-epp-07.txt
1.
The transport mapping MUST manage congestion.
This wording would be better replaced by the following (and
my comment takes into account both Scott's request and
the fact that the transport mapping may be over SMTP or
something other than a "transport" such as TCP or SCTP.
The transport mapping MUST be onto a transport such
as TCP or SCTP that provides congestion avoidance that
follows RFC 2914, or if it maps onto a protocol such
as SMTP or BEEP, then the performance issues need to
take into account issues of overload, server availability
and so forth.
2.
Within the optional dcp (data collection policy) element:
there is a non-technical spin in at least the
following label definition, what kind of marketing is meant?
<contact/>: Contact for marketing purposes.
Please add more to this definition so that is more neutral in
in its terminology.
About the recipient and data retention
elements - how would they provide a means to allow provisioning
a strick privacy policy in some use of EPP (they are not used
in one of the companion documents? The author is asked to
give a few sentences to encourage a view that they have teeth
(more so than their parent P3P) in EPP.
3.
This is a general question, but I would like the author, as
an expert on the topic, to send an written answer to the IESG,
not to make a change to this document set:
How does IESG and the community check the extensive XML in a
specification like this (analogous to the ABNF and MIB
checking described that is done regularly...)? How did you
check what's here? Why might it not matter?
******
ISSUES with draft-ietf-provreg-epp-tcp-05.txt
1.
An EPP client streams EPP commands to an EPP server on an established
TCP connection. A client MAY establish multiple TCP connections to
create multiple command exchange channels. A server MAY limit a
client to a maximum number of TCP connections based on server
capabilities and operational load.
It is not a good thing for the net for services to choose
this approach. A MAY like this is problematic for congestion
control reasons. I would like to change this language from
"MAY establish" to "MAY but SHOULD NOT" and from "A server MAY
limit" to "A server SHOULD limit"
2.
For references to TCP, besides RFC 793, you need:
RFC 2581, 2914.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, ietf-provreg@cafax.se
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Extensible Provisioning Protocol to Proposed
Standard
-------------
The IESG has approved the following Internet-Drafts as Proposed
Standards:
o Extensible Provisioning Protocol
<draft-ietf-provreg-epp-07.txt>
o Extensible Provisioning Protocol Domain Name Mapping
<draft-ietf-provreg-epp-domain-05.txt>
o Extensible Provisioning Protocol Host Mapping
<draft-ietf-provreg-epp-host-05.txt>
o Extensible Provisioning Protocol Contact Mapping
<draft-ietf-provreg-epp-contact-05.txt>
o Extensible Provisioning Protocol Transport Over TCP
<draft-ietf-provreg-epp-tcp-05.txt>
These documents are the product of the Provisioning Registry Protocol
Working Group. The IESG contact persons are Ned Freed and Patrik
Faltstrom.
Technical Summary
These documents describes an application layer client-server protocol
for the provisioning and management of objects stored in a shared
central repository. Specified in XML, the protocol defines generic
object management operations and an extensible framework that maps
protocol operations to objects. Further, object definitions of a few
objects needed for domain name registration and a binding to TCP as
transport protocl is provided.
Working Group Summary
There has been discussions in the wg whether the binding to TCP should
be the only binding, whether other bindings like SMTP and Beep is
"better" or "required" and during last call whether the protcol
itself should be asynchronous or not.
Result of these discussions ended up with TCP as one extension
mechanism of many possible ones (SMTP and Beep bindings in separate
documents), and that the protocol itself should be synchronous. This
last point make the protocol simpler, but will possibly make some
bindings more complicated.
The changes had concensus in the working group, and resulted in the
version of the documents which are now approved.
Protocol Quality
The specification has been reviewed by Patrik Faltstrom for the IESG.
To: Internet Engineering Steering Group <iesg@ietf.org>
Fcc: OUTBOX
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-magma-mld-source - Source Address
Selection for Multicast Listener Discovery Protocol (RFC 2710)
to Proposed Standard
--------
Last Call to expire on: 2002-10-25
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 [ ] [ ] [ ] [ R ]
Ned Freed [ ] [ X ] [ ] [ ]
Russ Housley [ ] [ ] [ X ] [ ]
Allison Mankin [ ] [ X ] [ ] [ ]
Thomas Narten [ ] [ ] [ X ] [ ]
Erik Nordmark [ X ] [ ] [ ] [ ]
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:
========
Thomas:
> MLD Report and Done messages MUST be sent with a valid link-local
> address as the IPv6 source address. If a valid link-local address is
> not available, the message MUST be sent with the unspecified address
> (::) as the IPv6 source address.
A bit of a nit, but the MUSTs are almost contradictory. It's a bit odd
to say: Do X. Well except if you can't, in which case you do Y. Better
to rewrite something like:
MLD Report and Done messages are sent with a link-local address as
the IPv6 source address, if the one has been assigned to the
interface. If a none exists (e.g., one hasn't been assigned to
the interface yet), the message is sent with the unspecified
address (::) as the IPv6 source address.
nit: RFC 2119 reference should be normative rather than informative.
Finally, the document really could include a bit more context about
why the document exists and what problem is being solved.
Based on some discussions with the author, the exact problem being
solved seems to be:
The rules and desired behavior with regards to receiving multicast
traffic prior to having an IP address need clarification. Before
assigning an LL address to an interface, a node needs to run DAD. But
DAD involves recieving multicast traffic sent to the solicited node
multicast address. But joining a multicast group involves running
MLD. The MLD spec says that MLD messages MUST be sourced from a LL
source address. This is needed even for LL multicast addresses due to
l2 bridge snooping. Thus, clarifications/guidelines regarding the
handling of joining multicast groups when one has no LL address are
needed.
It would be good to get words into the document that explain this
better.
Also, I think it would be good to add some explicit wording to the
document making it clear which rules in 2710 are being changed. I
particular, it would be good to indicate that receivers should not
drop packets with a source address of unspecified.
In general, you might want to say something about what problems have
been encountered in practice from the current wording, and whether
this change will result in different/better/worse behavior.
For example, should an implementation (once it has a valid ll address)
also run MLD again with its new address, to be sure that it
interoperates well with routers that drop packets with a source
address of unspecified?
Russ:
The security considerations say:
The ability to send MLD messages with the unspecified address can
lead to on-link abuse that is harder to trace.
Harder than what? Please clarify.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>, Internet Architecture Board <iab@iab.org>, magma@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Source Address Selection for Multicast
Listener Discovery Protocol (RFC 2710) to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Source Address Selection for
Multicast Listener Discovery Protocol (RFC 2710)'
<draft-ietf-magma-mld-source-02.txt> as a Proposed Standard. This
document is the product of the Multicast & Anycast Group Membership
Working Group. The IESG contact persons are Thomas Narten and Erik
Nordmark.
Technical Summary
The neighbor discovery specification allows using the unspecified
address as source for certain MLD messages but this is not captured
in the MLD specification. This document updates the MLD specification
with source address rules that are consistent with neighbor discovery.
Working Group Summary
There was WG consensus to advance this document.
Protocol Quality
The document has been reviewed for the IESG by Erik Nordmark.
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 [ ] [ X ] [ ] [ ]
Steve Bellovin [ ] [ ] [ X ] [ ]
Randy Bush [ ] [ X ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Ted Hardie [ ] [ ] [ X ] [ ]
Russ Housley [ ] [ ] [ X ] [ ]
Allison Mankin [ ] [ ] [ ] [ D ]
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:
Section 16.1 says:
o Security mechanism should provide for well defined key
management schemes. The key management schemes should be well
analyzed to be cryptographically secure. The key management
schemes should be scalable.
I think that automated key management SHOULD be provided.
Section 16.2 recommends the use of AH in tunnel mode. I would greatly
prefer ESP in tunnel mode, even if confidentiality is not turned on. In my
opinion, ESP with integrity-only security associations is better.
In section 16.2, the term "crypto channel" is not clear. Usually, it
means "IPsec security association." Yet, sometimes it refers to both the
IKE SA as well as the IPsec SA. I think that IKE SA and IPsec SA can be used.
In section 16.2, please change "man-in-the middle attacks" to
"man-in-the-middle attacks."
Section 16.2 says:
Digital signature based authentication is not prone to such
problems. It is recommended using digital signature based
authentication mechanism where possible. If pre-shared key based
authentication is required, then aggressive mode SHOULD be used.
IKE pre-shared authentication key values SHOULD be protected in a
manner similar to the user's account password.
Please change "recommended" to upper case.
Steve:
I'm not sure how much the ccamp and forces people talk, but isn't this
sentence:
the control channel MUST terminate on the same two nodes
that the TE link spans.
incorrect with remote control elements?
16.2:
The IPsec selectors are all SHOULDs -- what are the MUSTs?
Setting the port number to 0 means that all UDP traffic between
those nodes is protected -- is that right? I though the
document spoke of an LMP port.
The channel identifer is part of the payload, not the IP or UDP
headers, and thus can't be a selector.
IKE is listed as a SHOULD, not a MUST, but the requirements
mandate replay detection. You can't do that with manual keying.
(The requirements also mandate support for manual keying.)
If replay protection is needed, either IKE must be required,
or an application-specific replay protection mechanism must
be defined.
Ted:
In section 3.2.1, there is a recommendation for setting
the default values for the HelloInterval to 150ms and
the HelloDeadInterval to 500ms. The text seems to
indicate that the same default is used when you pass
the traffic over an IP network as when you are
directly connected. This seems low in the presence
of a multi-hop IP network, as you seem likely to end
up in Degraded state unnecessarily. Language indicating
how to judge a deviation from this default would
be very useful.
The draft does not seem to be clear on what happens
if a TestStatusSuccess or TestStatusFailure message
is lost in flight; the current language could be read
to indicate that the same TestStatusAck message
would be sent in both cases (5.0, just above 5.1)
In section 8, Graceful Restart, it is not clear whether
Multicast discovery is re-done on interfaces which
have had Interface_Ids discovered through
that method, or whether these are also assumed
to remain stable.
In section 12.1, how are bits which
are currently reserved later assigned?
Notes:
In the introduction, paragraph 2 the use of "neighboring" is
non-trivially different from the usual, so defining it would
be a good idea.
The first SHOULD occurs before the Terminology definition.
In LMP overview the statement "All LMP packest are run over
UDP with an LMP port number [except in some cases]" would
be better if "Except in for test messages, which may be limited
by the transport mechanism to in-band messaging, all LMP..."
In section 3. there is a requirement for a unique 32-bit
non-zero integer, but no specification for how to ensure uniqueness.
In Section 3.0, is a unicast source address used for the multicast
packet?
In section 3.1, the nodes MAY continue to retransmit Config messages
both when Node_Ids are equal and when a ConfigNack with unacceptable
alternate values is received. Some justification for *why*it would
seems
useful.
In Section 3.2.1, it notes that "if other methods are used to indicate
bi-directional control channel connectivity", but there are no pointers
to other methods; if none are currently specified, it might be
useful to change the language to indicate that.
Is the Verify_Id monotonically increasing, or random?
In 6.0, "procedure can be used to rapidly isolate link failures" seems
to mean data link failures, and it might be better to be more precise.
In Section 7, the statement "Note that the 32-bit Message_Id value MAY
wrap"
does not need an RFC 2119 MAY, since it is a statement of fact, not
an interoperability point.
In 11.3.1, there is a ligatured ae in the text for Down:
COMMENTS:
=========
Bert:
ID-NITS biting me too
Bad chars at 1870
-: 1 lines containing non-US-ASCII characters
RFC-Editor note:
Pls change on page 33, line 1870:
OLD:
(i.e., the link is not \xE6in service')
NEW:
(i.e., the link is not 'in service')
Erik:
I didn't see anything about autorization/access control in
the document. Presumably there is something an implementation needs
to do to associate authority for certain TE links with a particular
IPsec SA.
Nit:
In two places it explicitly talks about 224.0.0.1 even though the
document supports IPv6 for example:
the control channel. This is done by sending the Config message to
the Multicast address (224.0.0.1). The ConfigAck and ConfigNack
How about at least saying "224.0.0.1 or ff02::1" instead.
^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
For scalability purposes, multiple data links can be combined to
form a single traffic engineering (TE) link. Furthermore, the
management of TE links is not restricted to in-band messaging, but
instead can be done using out-of-band techniques. This document
specifies a link management protocol (LMP) that runs between
neighboring nodes and is used to manage TE links. Specifically, LMP
will be used to maintain control channel connectivity, verify the
physical connectivity of the data links, correlate the link property
information, suppress downstream alarms, and localize link failures
for protection/restoration purposes in multiple kinds of networks.
Working Group Summary
The WG has consensus on this document. In the beginning there was too
much SONET/SDH specific material in this document, but that has now
been moved out into a separate document.
Protocol Quality
This memo 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-murchison-sieve-subaddress - Sieve --
Subaddress Extension to Proposed Standard
--------
Last Call to expire on: 2003-4-25
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ X ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ X ] [ ] [ ] [ ]
Ted Hardie [ ] [ X ] [ ] [ ]
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'.
COMMENTS:
=========
Russ:
Line 318 contains a non-ASCII character.
^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: Sieve -- Subaddress Extension to Proposed
Standard
-------------
The IESG has approved the Internet-Draft 'Sieve -- Subaddress
Extension' <draft-murchison-sieve-subaddress-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 Ted
Hardie.
Technical Summary
On email systems that allow for "subaddressing" or "detailed
addressing" (eg, "ken+sieve@example.org"), it is sometimes desirable
to make comparisons against these sub-parts of addresses. This draft
defines an extension to the Sieve mail filtering language that
allows users to compare against the user and detail parts of an
address.
Working Group Summary
This document is an extension to the sieve mail filtering language
defined in RFC 3028. There are already several implementations of
this extension.
Protocol Quality
Ned Freed reviewed the specification for the IESG.
RFC Editor note:
Please change the title of this document to "Sieve Email
Filtering -- Subaddress Extension" to avoid confusion with other
uses of the term "subaddressing"
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-aboba-radius-rfc2869bis - RADIUS Support For
Extensible Authentication Protocol (EAP) to Informational
--------
Last Call to expire on: 2003-3-11
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Scott Bradner [ ] [ ] [ ] [ ]
Randy Bush [ X ] [ ] [ ] [ ]
Patrik Faltstrom [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jeff Schiller [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>,
From: The IESG <iesg-secretary@ietf.org>
Subject: Document Action: RADIUS Support For Extensible
Authentication Protocol (EAP) to Informational
-------------
The IESG has approved the Internet-Draft 'RADIUS Support For Extensible
Authentication Protocol (EAP)' <draft-aboba-radius-rfc2869bis-09.txt>
as an Informational RFC.
This has been reviewed in the IETF but is not the product of an IETF
Working Group. The IESG contact persons are Randy Bush and Bert Wijnen.
Technical Summary
This specification describes RADIUS attributes supporting the Extensible
Authentication Protocol (EAP): EAP-Message and Message-Authenticator.
These attributes now have extensive field experience, and so the purpose
of this document is to provide clarification and resolve interoperability
issues.
As noted in [RFC2865], a Network Access Server (NAS) that does not
implement a given service MUST NOT implement the RADIUS attributes for
that service. This implies that a NAS that is unable to offer EAP service
MUST NOT implement the RADIUS attributes for EAP. A NAS MUST treat a
RADIUS Access-Accept requesting an unavailable service as an Access-Reject
instead.
All attributes are comprised of variable length Type-Length-Value 3-
tuples. New attribute values can be added without disturbing existing
implementations of the protocol.
This document updates RFC 2869.
Working Group Summary
As this document was not the product of an IETF working group, there
was no discussion in the origin WG. But the document was brought
to the attention of all relevant WGs and a four-week IETF-wide last
call was conducted with no negative comments.
Protocol Quality
This document was reviewed for the IESG by Randy Bush.
IP Telephony (iptel)
--------------------
Charter
Last Modified: 2003-03-31
Current Status: Active Working Group
Chair(s):
Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cullen Jennings <fluffy@cisco.com>
Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Advisor:
Jon Peterson <jon.peterson@neustar.biz>
Mailing Lists:
General Discussion:iptel@ietf.org
To Subscribe: iptel-request@ietf.org
In Body: put subscribe in subject
Archive: www.ietf.org/mail-archive/working-groups/iptel/current/maillist.html
Description of Working Group:
The focus of the IP Telephony (iptel) group is on the problems related
to propagation of routing information for VoIP protocols. Specifically,
both SIP and H.323 have the notion of signaling intermediaries (proxies
in SIP and gatekeepers in H.323). When these devices receive call
establishment messages, they must make a routing decision on where to
forward the call setup messages.
The iptel group has already defined a protocol, Telephony Routing over
IP (TRIP), which solves one aspect of this problem. Specifically, it
handles the case where calls need to be routed between domains. It
allows for the exchange of routing information between these
providers, so that policies can be applied to the resulting data to
create a forwarding information base.
However, this protocol does not address all the scenarios of route
information exchange between servers. One important scenario is the
propagation of routing information between gateways and the signaling
servers in front of them. This is also known as "gateway registration".
It allows the signaling server to make a routing decision about which
gateway to use based on dynamic information about the gateway
resources. Vendors have deployed proprietary solutions for this
communications interface. A standard is needed. The group will
generate a standards track document that defines a protocol (possibly
based on TRIP) for this interface.
The group will also generate a MIB document for TRIP.
Note that the group is not working on elevating TRIP to Draft
Standard at this time.
Deliverables:
1. A proposed standard RFC for gateway to server route exchange.
2. A proposed standard TRIP MIB specification, based heavily on the
existing BGP-4 MIB documents.
Goals and Milestones:
Done Submit gateway location framework document to IESG for
consideration as an RFC.
Done Submit call processing syntax framework document to IESG
for consideration as an RFC.
Done Submit call processing syntax document to IESG for
consideration as a Proposed Standard.
Done Submit gateway location protocol document to IESG for
consideration as an RFC.
Done TRIP MIB Document submitted to IESG for consideration as
proposed standard
DEC 02 Gateway to Server Route Exchange document submitted to IESG
for consideration as proposed standard.
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- --------------------------------------------
MAR 99 JAN 02 <draft-ietf-iptel-cpl-06.txt>
CPL: A Language for User Control of Internet Telephony
Services
AUG 01 FEB 03 <draft-ietf-iptel-trip-mib-05.txt>
Management Information Base for Telephony Routing over IP
(TRIP)
OCT 02 MAR 03 <draft-ietf-iptel-tgrep-01.txt>
A Telephony Gateway REgistration Protocol (TGREP)
NOV 02 NOV 02 <draft-ietf-iptel-trunk-group-00.txt>
Representing trunk groups in sip/tel Uniform Resource
Identifiers (URIs)
Request For Comments:
RFC Stat Published Title
------- -- ----------- ------------------------------------
RFC2824 I JUN 00 Call Processing Language Framework and Requirements
RFC2871 I JUL 00 A Framework for a Gateway Location Protocol
RFC3219 PS JAN 02 Telephony Routing over IP (TRIP)
SIP for Instant Messaging and Presence Leveraging Extensions (simple)
---------------------------------------------------------------------
Charter
Last Modified: 2003-03-25
Current Status: Active Working Group
Chair(s):
Robert Sparks <rsparks@dynamicsoft.com>
Jon Peterson <jon.peterson@neustar.biz>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.com>
Ted Hardie <hardie@qualcomm.com>
Applications Area Advisor:
Ted Hardie <hardie@qualcomm.com>
Mailing Lists:
General Discussion:simple@ietf.org
To Subscribe: simple-request@ietf.org
In Body: subscribe
Archive: http://www.ietf.org/mail-archive/working-groups/simple/current/maillist.html
Description of Working Group:
This working group focuses on the application of the Session Initiation
Protocol (SIP, RFC 3261) to the suite of services collectively known as
instant messaging and presence (IMP). The IETF has committed to
producing an interoperable standard for these services compliant to the
requirements for IM outlined in RFC 2779 (including the security and
privacy requirements there) and in the Common Presence and Instant
Messaging (CPIM) specification, developed within the IMPP working
group.
As the most common services for which SIP is used share quite a bit in
common with IMP, the adaptation of SIP to IMP seems a natural choice
given the widespread support for (and relative maturity of) the SIP
standard.
The primary work of this group will be to generate:
1. A proposed standard SIP extension documenting the transport of
Instant Messages in SIP, compliant to the requirements for IM outlined
in RFC 2779, CPIM and in BCP 41 (so that the transport implications of
the extension with respect to network congestion are considered in the
design).
2. A proposed standard SIP event package and any related protocol
mechanisms used to support presence, compliant to the requirements for
presence outlined in RFC 2779 and CPIM.
3. An architecture for the implementation of a traditional buddylist-
based instant messaging and presence application with SIP, including
for
example new mechanisms for message confirmation delivery, indications
for when a party is in the process of typing a message, secure
buddylist
manipulation operations, and the extension of the CPIM presence format
to describe typical IM states.
All SIMPLE proposals fulfilling these goals must document the mappings
of their operation to CPIM. Any SIP extensions proposed in the course
of
this development will, after a last call process, be transferred to the
SIP WG for consideration as formal SIP extensions.
The working group will work within the framework for presence and IM
described in RFC 2778. The extensions it defines must also be compliant
with the SIP processes for extensions. The group cannot modify baseline
SIP behavior or define a new version of SIP for IM and presence. If the
group determines that any capabilities requiring an extension to SIP
are
needed, the group will seek to define such extensions within the SIP
working group, and then use them here.
The working group will operate in close cooperation with the IMPP
working group, which will be completing CPIM in parallel. The working
group will also cooperate with any other groups defined to standardize
other presence and IM systems, to ensure maximum sharing of information
and avoid reinvention of the wheel. The working group will cooperate
with the SIP working group, soliciting reviews to ensure its extensions
meet SIPs requirements. The working group will also collaborate with
the
SIP WG to ensure consistent operation of the SUBSCRIBE and NOTIFY
methods across the other applications being defined for its use.
Goals and Milestones:
JAN 03 Submission of instant messaging session drafts to IESG for
publication as Proposed Standards
JAN 03 Submission of presence list package set to IESG for
publication as Proposed Standards
JAN 03 Submission of presence list auth/modify requirements draft
to IESG for publication as Informational
FEB 03 Submission of requirements and proposed mechanism for event
publishing to the SIP working group
FEB 03 Submission of CPIM mapping draft to IESG for publication as
Informational
FEB 03 Submission of advanced messaging requirements draft to IESG
for publication as Informational
MAR 03 Submission of SIMPLE PIDF profile to IESG for publication
as Proposed Standard
APR 03 Submission of Presence/IM System Architecture draft to IESG
for publication as Informational
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- --------------------------------------------
APR 01 JAN 03 <draft-ietf-simple-presence-10.txt>
A Presence Event Package for the Session Initiation
Protocol (SIP)
JUL 01 JAN 03 <draft-ietf-simple-winfo-format-04.txt>
An Extensible Markup Language (XML) Based Format for
Watcher Information
JUL 01 JAN 03 <draft-ietf-simple-winfo-package-05.txt>
A Watcher Information Event Template-Package for the
Session Initiation Protocol (SIP)
OCT 02 APR 03 <draft-ietf-simple-data-req-02.txt>
Requirements for Manipulation of Data Elements in Session
Initiation Protocol (SIP) for Instant Messaging and
Presence Leveraging Extensions (SIMPLE) Systems
FEB 03 FEB 03 <draft-ietf-simple-publish-reqs-00.txt>
SIMPLE Presence Publication Requirements
FEB 03 MAY 03 <draft-ietf-simple-event-list-02.txt>
A Session Initiation Protocol (SIP) Event Notification
Extension for Resource Lists
FEB 03 FEB 03 <draft-ietf-simple-publish-00.txt>
SIMPLE Presence Publication Mechanism
MAY 03 MAY 03 <draft-ietf-simple-presinfo-deliv-reg-00.txt>
Requirements for Efficient Delivery of Presence Information
MAY 03 MAY 03 <draft-ietf-simple-winfo-filter-reqs-00.txt>
Requirements for Filtering of Watcher Information
Request For Comments:
None to date.