[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Agenda and Package for May 29, 2003 Telechat
INTERNET ENGINEERING STEERING GROUP (IESG)
Agenda for the May 29, 2003 IESG Teleconference
1. Administrivia
o Roll Call
o Bash the Agenda
o Approval of the Minutes
- May 15, 2003
o Review of Action Items
OUTSTANDING TASKS
Last updated: May 15, 2003
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.
IP o Ted to write straw working group procedures for handling consensus-
blocked decisions
IP o Alex will notify Secretariat once ok to announce
draft-ietf-ipo-framework-04.txt
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 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.
o Secretariat to send mmusic charter (WG Re-charter) to
ietf-announce and new-work.
o Secretariat to send IESG a list of groups with whom we need to avoid
meeting conflicts when scheduling IETF conferences.
o Alex to send RFC Editor Note for draft-ietf-ppvpn-framework-08.txt
addressing Bert's and Ted's concerns.
o Secretariat to include IESG note in announcement for
draft-ogura-ipv6-mapos-02.txt
o Secretariat to include new RFC Editor Note in announcement for
draft-murchison-sieve-subaddress-06.txt
o Secretariat to send internal Working Group Review message for
simple WG.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item
o RTCP attribute in SDP (Proposed Standard)
<draft-ietf-mmusic-sdp4nat-04.txt>
Token: Peterson, Jon
Note: This document is connected to STUN and a related document
is SIP...should it be Last Called alone or wait for the SIP
one? It was rev'd to make sure it aligned with STUN and is
ready for Last Call so that question is the only remaining one.
o Textual Conventions for IPv6 Flow Label (Proposed Standard)
<draft-ietf-ops-ipv6-flowlabel-01.txt>
Token: Bush, Randy
Note: Bert recuses himself as he is co-author. so randy
takes AD role for the document.
2.1.2 Returning Item
NONE
2.2 Individual Submissions
2.2.1 New Item
o Printer MIB v2 (Proposed Standard)
<draft-ietf-printmib-mib-info-15.txt>
Token: Freed, Ned
Note: Four week last call requested
o Registration procedures for message header fields (BCP)
<draft-klyne-msghdr-registry-06.txt>
Token: Freed, Ned
Note: Writeup submitted; asked to have on IESG agenda
o Delegation of E.F.F.3.IP6.ARPA (BCP)
<draft-ymbk-6bone-arpa-delegation-01.txt>
Token: Narten, Thomas
2.2.2 Returning Item
o Collective Attributes in LDAP (Proposed Standard)
<draft-zeilenga-ldap-collective-08.txt>
Token: Hardie, Ted
Note: New versions exists which is verified with
IESG
Responsible: Patrik
o Subentries in LDAP (Proposed Standard)
<draft-zeilenga-ldap-subentry-07.txt>
o Generic String Encoding Rules for ASN.1 Types (Proposed
Standard)
<draft-legg-ldap-gser-03.txt>
3. Document Actions
3.1 WG Submissions
3.1.1 New Item
o IS-IS Cryptographic Authentication (Informational)
<draft-ietf-isis-hmac-04.txt>
Token: Zinin, Alex
Note: Responsible: Author
o Multicast Source Discovery Protocol (MSDP) (Experimental)
<draft-ietf-msdp-spec-19.txt>
Token: Zinin, Alex
3.1.2 Returning Item
NONE
3.2 Indiviual Submissions Via AD
3.2.1 New Item
o Printer Finishing MIB (Informational)
<draft-ietf-printmib-finishing-16.txt>
Token: Freed, Ned
Note: Four week last call requested
o IANA Charset MIB (Informational)
<draft-mcdonald-iana-charset-mib-02.txt>
Token: Freed, Ned
Note: Four week last call requested
3.2.2 Returning Item
o Common Elements of GSER Encodings (Informational)
<draft-legg-ldap-gser-abnf-06.txt>
o RADIUS Support For Extensible Authentication Protocol (EAP)
(Informational)
<draft-aboba-radius-rfc2869bis-22.txt>
Token: Bush, Randy
3.3 Indiviual Submissions Via RFC Editor
3.3.1 New Item
o Developing High Quality SNMP Agents (Informational)
<draft-aromanov-snmp-hiqa-04.txt>
Token: Wijnen, Bert
Note: On IESG agenda for 29 May
3.3.2 Returning Item
NONE
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
NONE
4.1.2 Proposed for Approval
NONE
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
o Next Steps in Signaling
Token: Allison
4.2.2 Proposed for Approval
o IP Telephony
Token: Jon
Note: under discussion
5. Working Group News We Can Use
6. IAB News We Can Use
7. Management Issues
o DNP
o Review criteria for independent submissions
The IESG review of independent submissions was designed to let the IESG see
and catch attempts to bypass the IETF standards process, and detect
documents that would be harmful to the IETF if published.
We have also used the review to stop documents that were actively inimical
to the Internet (draft-higgs being the classic example).
But this review is often very slow. Especially the review that occurs
before the document gets on the IESG agenda; possibly also the process of
writing down the note to go with it after the IESG has decided on a don't
publish or publish-with-IESG-note.
I would like to see us resolve that the output of the AD review should be
one of three standard notes:
- Harmless, publish
- Doubtful, needs an IESG note
- Harmful, should not be published
and that the AD performing initial review doesn't use more time on the
document than the minimum required to decide which of those is appropriate
to recommend to the IESG.
In the case of individual submissions, the IESG has no remit to make sure
the document is clear, understandable or follows the nits; that's the RFC
Editor's business to push back on.
*DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT *
INTERNET ENGINEERING STEERING GROUP (IESG)
May 15, 2003
Reported by: Jacqueline Hargest, IETF Assistant Director
ATTENDEES
---------
Alvestrand, Harald / Cisco
Austein, Rob / IAB Liaison
Bellovin, Steve / AT&T Labs
Bush, Randy / IIJ
Cotton, Michelle / ICANN
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
-------
Daigle, Leslie / Verisign (IAB)
Minutes
-------
1. The minutes of the April 30, 2003 teleconference were approved.
Secretariat to place in public archives.
2. The following action items were reported as DONE:
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 to ask Steve Casner, AVT Chair, to review draft-smith-urn-mpeg
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 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 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 know to send this charter to ietf-announce and new-work.
3. Protocol Actions Approved:
o Extensible Provisioning Protocol (Proposed Standard)
<draft-ietf-provreg-epp-09.txt>
o Sieve -- Subaddress Extension (Proposed Standard)
<draft-murchison-sieve-subaddress-06.txt>
4. Document Action Deferred:
o RADIUS Support For Extensible Authentication Protocol (EAP)
(Informational)
<draft-aboba-radius-rfc2869bis-21.txt>
5. Working Group Action Tentatively Approved:
o SIP for Instant Messaging and Presence Leveraging Extensions
Token: Ted Hardie
Note: Tentatively approved, subject to wordsmithing. Secretariat
to send internal Working Group Review message.
6. Documents Remaining Under Discussion:
o Stream Control Transmission Protocol Management Information Base
(Proposed Standard)
<draft-ietf-sigtran-sctp-mib-09.txt>
o Handling of Unknown DNS Resource Record Types (Proposed Standard)
<draft-ietf-dnsext-unknown-rrs-05.txt>
o Source Address Selection for Multicast Listener Discovery Protocol
(RFC 2710) (Proposed Standard)
<draft-ietf-magma-mld-source-05.txt>
o Link Management Protocol (LMP) (Proposed Standard)
<draft-ietf-ccamp-lmp-08.txt>
7. New Action Items:
o Secretariat to send mmusic charter (WG Re-charter) to
ietf-announce and new-work.
8. 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
IP o Alex to send proposal and justification for interim document review.
IP o Ted to write straw working group procedures for handling consensus-
blocked decisions
IP o Alex will notify Secretariat once ok to announce
draft-ietf-ipo-framework-04.txt
IP 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.
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-mmusic-sdp4nat - RTCP attribute in SDP
to Proposed Standard
--------
Last Call to expire on: 2003-4-14
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ X ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
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'.
DISCUSS:
========
Steve:
The discussion in point (4) (of the three-step process....) in Section
3.1 is, in fact, imposing a new requirement on NATs. This document is
a rather subtle place for such a requirment. I believe that a separate
"NAT Requirements to Support SIP" document needs to be written first.
Given that according to this document, only "a large fraction" of NATs
behave in the desired fashion today, there needs to be discussion of
how an application can discover that it is behind an older NAT. The
alternative is silent failures to connect, which aren't very
user-friendly. The abstract to this document should note that it
depends on STUN servers being available.
COMMENTS:
=========
Jon:
Thanks for your comments, Steven.
First of all, this document wasn't actually supposed to be on the
ballot for this next call - there were some last call comments, and
the author is actually spinning a new version of the draft to fix
those (basically, updates resulting from the transition from RFC1889
to rtp-new-12). I wrote to the secretariat already asking them to
remove the doc from this week's ballet, but it would be nice if the
author could take care of any further issues (such as those you raise
below) in the revision currently underway.
>
> The discussion in point (4) (of the three-step process....) in Section
> 3.1 is, in fact, imposing a new requirement on NATs. This document is
> a rather subtle place for such a requirment. I believe that a separate
> "NAT Requirements to Support SIP" document needs to be written first.
>
Well, I'm not sure this is really a new requirement on NATs - what
requirement on NATs do you read here? I didn't think 3.1 requires
anything of NATs themselves, merely that clients have a way of
ascertaining the port numbers on the remote side of NATs. STUN provides
one way that these port numbers can be discovered for some existing
NATs today. The intention of the sdp4nat draft is not to change the
behavior of NATs themselves in any way, as far as I know - in terms of
protocol mechanism, the only thing it changes is the information
provided in SDP.
There are some existing drafts in the SIP[PING] WGs, most recently the
ICE draft (draft-rosenberg-sipping-ice-00), that paint the big picture
for using SIP, STUN, and the extensions shown in the sdp4nat draft (see
5.4 in ICE on sdp4nat). I would hope that sdp4nat could progress
without a normative depency on ICE, since it doesn't promote STUN as
the only possible solution for discovering a port number for RTCP on
the remote side of the NAT.
> Given that according to this document, only "a large fraction" of NATs
> behave in the desired fashion today, there needs to be discussion of
> how an application can discover that it is behind an older NAT. The
> alternative is silent failures to connect, which aren't very
> user-friendly. The abstract to this document should note that it
> depends on STUN servers being available.
>
That discovery discussion does exist in RFC3489 (the STUN RFC, see
section 6). Agreed that the abstract of this document could mention
STUN, but I'm not sure that the extensions it describes are useless in
the absence of STUN. Presumably, any method other than STUN for
ascertaining the capabilities of NATs would need to have its own
discovery mechanism. Would it be all right to require in sdp4nat that
any NAT discovery mechanism (e.g. STUN) used by a client that plans
to employ sdp4nat must have a way of ascertaining the suitability of
NATs?
As a final note, it is perhaps unfortunate that the document takes NAT
as its exclusive focus, since the mechanism it describes (an SDP
attribute for RTCP port numbers) could be useful for reasons unrelated
to NAT, especially in light of rtp-new-12.
- J
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, mmusic@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: RTCP attribute in SDP to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'RTCP attribute in SDP'
<draft-ietf-mmusic-sdp4nat-04.txt> as a Proposed Standard. This
document is the product of the Multiparty Multimedia Session Control
Working Group. The IESG contact persons are Allison Mankin and Jon
Peterson.
Technical Summary
The new version of RTP (draft-ietf-avt-rtp-new-12) relaxes the requirement
in 1889 that the port number used for the Real Time Control Protocol (RTCP)
must be one port number higher than the port chosen for an RTP stream.
Because of this, protocols like the Session Description Protocol which use
RTP now need a way to explicitly specify the port that will be used for an
RTCP stream corresponding to an RTP stream; previously, SDP had no need for
this capability since implementations just assumed that RTP/RTCP used
consecutive numbers.
So, this document proposes a new SDP attribute (a=rtcp:<port>) that allows
implementations to specify the port over which RTCP will be sent. Prior to
this change in RTP, and the proposed change to SDP, RTCP had a great deal of
trouble traversing NATs in SDP-based applications (like SIP). The document
therefore considers NAT traversal as a motivating case for the addition of
this attribute. The use of this new attribute to facilitate NAT traversal is
intended to be used in concert with STUN (RFC 3489).
Working Group Summary
The MMUSIC WG supported the advancement of this document.
Protocol Quality
Jon Peterson reviewed this specification for the IESG.
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Scretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-ops-ipv6-flowlabel -
Textual Conventions for IPv6 Flow Label
--------
Last Call to expire on: 2003-05-04
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 [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Jeff Schiller [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ R ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, scoya@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Textual Conventions for IPv6 Flow Label to Proposed
Standard
-------------
The IESG has approved the Internet-Draft 'Textual Conventions for
IPv6 Flow Label' <draft-ietf-ops-ipv6-flowlabel-01.txt> as a
Proposed Standard. This document is not the product of an IETF
Working Group, but has been reviewed in the IETF. The IESG contact
persons are Randy Bush and Bert Wijnen.
Technical Summary
This document contains a MIB module that defines textual conventions
to represent the commonly used IPv6 Flow Label. The intent is that
these textual conventions (TCs) will be imported and used in MIB
modules that might otherwise define their own representations.
Working Group Summary
Several WGs have defined standards-track MIB modules that define
objects to represent an IPv6 Flow Label (sometimes refered to as
Flow ID) and IPv6 Flow Label filters. Unfortunately the result
has been a set of different definitions for the same piece of
management information. This may lead to confusion and unneeded
complexity. This document was produced within the Operations and
Management area to provide a few common TCs for future use.
Protocol Quality
This document is an individual submission from within the
Operations and Management area. It was reviewed and discussed on
various WG mailing lists (e.g. mibs@ops.ietf.org, diffserv, rap).
It also had a 4-week IETF Last Call. It has been further
reviewed for the IESG by Randy Bush.
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-printmib-mib-info - Printer MIB v2 to
Proposed Standard
--------
Last Call to expire on: 2003-5-14
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: Printer MIB v2 to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Printer MIB v2'
<draft-ietf-printmib-mib-info-15.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
This document provides definitions of models and manageable objects
for printing environments. The objects included in this MIB apply to
physical, as well as logical entities within a printing device. This
document obsoletes RFC 1759.
The task of managing the production of printed documents can be divided
into two overlapping pieces, the management of printing and the
management of the printer. Printing encompasses the entire process of
producing a printed document from generation of the file to be
printed, selection of a printer, choosing printing properties,
routing, queuing, resource management, scheduling, and final printing
including notifying the user. Most of the printing process is
outside the scope of the model presented here; only the management of
the printer itself is covered in this document.
Working Group Summary
This document was reviewed by the Internet Print Protocol Working Group
but is not a product of that group.
Protocol Quality
Bert Wijnen and Ned Freed reviewed the document 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-klyne-msghdr-registry - Registration procedures
for message header fields to BCP
--------
Last Call to expire on: 2002-12-4
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: Registration procedures for message header
fields to BCP
-------------
The IESG has approved the Internet-Draft 'Registration procedures for
message header fields' <draft-klyne-msghdr-registry-06.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 specification defines registration procedures for the message
header field names used by Internet mail, HTTP, newsgroup feeds and
other Internet applications.
Benefits of a central registry for message header field names
include:
o providing a single point of reference for standardized and widely-
used header field names;
o providing a central point of discovery for established header
fields, and easy location of their defining documents;
o discouraging multiple definitions of a header field name for
different purposes;
o helping those proposing new header fields discern established
trends and conventions, and avoid names that might be confused
with existing ones;
o encouraging convergence of header field name usage across multiple
applications and protocols.
Working Group Summary
This has been reviewed in the IETF but is not the product of an IETF
Working Group.
Protocol Quality
Ned Freed reviewed the document for the iESG.
RFC Editor note
The IPR boilerplate is missing from this document and needs to be added.
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-ymbk-6bone-arpa-delegation - Delegation of
E.F.F.3.IP6.ARPA to BCP
--------
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 [ ] [ ] [ ] [ X ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ X ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ X ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
COMMENTS:
=========
Randy:
i am an author
^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: Delegation of E.F.F.3.IP6.ARPA to BCP
-------------
The IESG has approved the Internet-Draft 'Delegation of
E.F.F.3.IP6.ARPA' <draft-ymbk-6bone-arpa-delegation-01.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 Thomas Narten and Erik
Nordmark.
Technical Summary
The 6bone, whose address space was allocated by RFC 2471, has
provided a network for IPv6 experimentation for numerous purposes
for seven years. Up to the present time, reverse lookups for 6bone
addresses in the DNS have been accomplished through IP6.INT. It is
now important that the thousands of 6bone users be able to update
their IPv6 software to use IP6.ARPA as defined in RFC 3152.
Although the 6bone has a limited life, and a phaseout plan is being
discussed at the IETF at this time, there is likely to be 2.5 to
3.5 more years of operation. During this remaining 6bone lifetime
IP6.ARPA reverse lookup services for the 3ffe::/16 address space
are required. This document requests that the IANA delegate the
E.F.F.3.IP6.ARPA domain to the 6bone as will be described in
instructions to be provided by the IAB.
Working Group Summary
This was not a WG document, but has been discussed on various
mailing lists (e.g., 6bone, v6ops, dnsops). No issues were raised
during the IETF Last Call.
Protocol Quality
This document has been reviewed for the IESG by Thomas Narten.
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-zeilenga-ldap-collective - Collective
Attributes in LDAP to Proposed Standard
--------
Last Call to expire on: July 11, 2002
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ X ] [ ] [ ]
Steve Bellovin [ ] [ ] [ X ] [ ]
Scott Bradner [ ] [ XX] [ X ] [ ]
Randy Bush [ ] [ X ] [ ] [ ]
Patrik Faltstrom [ X ] [ ] [ ] [ ]
Bill Fenner [ ] [ XX] [ 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:
-------
Scott:
note: shesh - we tell people that they should not refer to IDs
draft-legg-ldap-gser-abnf-03.txt does so in its abstract
draft-legg-ldap-gser-00.txt
draft-legg-ldap-gser-abnf-03.txt
the reference in the IPR section to BCP 11 is wrong
(it's wrong in RFC 2026 but I did not notice that before)
the reference should be to RFC 2026 BCP 9
we have not been putting this text into RFCs - even though
RFC 2026 says we should - maybe that is why this problem
has not been noticed before
the above issues could be delt with by an RFC Editor note
the rest of the docs look OK to me
Steve: If I understand this correctly -- and I'm not at all sure that
I do -- the security considerations should specify that the same security
checks must be made on retrieval or update of the collective attribute
as for the actual entry. This is a minor point and can, I think, be
handled with an RFC editor note.
Alternatively, I have no idea what I'm talking about and this DISCUSS
should be ignored...
Bert: Has anybody (or is anyone) checked(ing) the ABNF syntax
in those documents?
In here I see a request to IANA to assign a set of OIDs, for example:
c-FacsimileTelephoneNumber A 2.5.4.23.1
c-InternationalISDNNumber A 2.5.4.25.1
c-PhysicalDeliveryOffice A 2.5.4.19.1
When I go to
http://www.alvestrand.no/objectid/2.5.4.23.1.html
then it seems they are already assigned.
but certainly, the OID starts with a 2 and that is ISO/ITU-T
jointly assigned OIDs. So I wonder (did I so earlier on too
and did I forget the answer) why IANA has anything to do
with it. Does not IANA (in principle) only make
assignments in Internet owned Name spaces. So for OIDs that
is underneath 1.3.6.1 (which is the Internet OID) ??
I assume that PAF or someone makes sure that assignments are
not overlapping with anything else?
I guess that it is historical, but these attribute names
c-l A 2.5.4.7.1
c-o A 2.5.4.10.1
c-ou A 2.5.4.11.1
c-st A 2.5.4.8.1
are kind of short and cryptic, are they not?
To follow up on my own questions below, at the bottom of
IANA Considerations section it says:
This document uses in this document were assigned by the ISO/IEC
Joint Technical Committee 1 - Subcommitte 6 to identify elements of
X.500 schema. This document make no OID assignments, it only
associates LDAP schema descriptions with existing elements of X.500
schema.
Which I cannot parse. But potentially it means to say:
The OIDs used in this document were assigned by the ISO/IEC Joint
Technical Committee 1 - Subcommitte 6 to identify elements of X.500
schema. This document make no OID assignments, it only associates
LDAP schema descriptions with existing elements of X.500 schema.
So if this document makes no OID assignments, is it then the idea
that IANA still registers them? I guess it needs to be added then
that authoritative "registration" or "OID assignment" is done
in that other place, possibly witha ptr to it (if any).
Bill: draft-zeilenga-ldap-subentry-06.txt has an ABNF error in Appendix
A. ABNF rule names are case-insensitive, however it has one rule
specificExclusions and one SpecificExclusions. One of them should
be renamed. This would be easily done with an RFC-Editor note.
draft-legg-ldap-gser-abnf-03.txt and draft-legg-ldap-gser-00.txt
have syntactically correct ABNF.
Jeff: ]7. Security Considerations
]
] The Generic String Encoding Rules do not necessarily enable the exact
] octet encoding of values of the TeletexString, VideotexString,
] GraphicString or GeneralString types to be reconstructed, so a
] transformation from DER to GSER and back to DER may not reproduce the
] original DER encoding. This has consequences for the verification of
] digital signatures.
I am not sure this is an acceptable restriction. I would recommend
that the author come up with a way that permits transformation from
DER to GSER to DER in a way that doesn't break signatures.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>,
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Collective Attributes in LDAP to Proposed
Standard
-------------
The IESG has approved publication of the following Internet-Drafts as
Proposed Standards:
o Collective Attributes in LDAP
<draft-zeilenga-ldap-collective-07.txt>
o Subentries in LDAP
<draft-zeilenga-ldap-subentry-07.txt>
o Generic String Encoding Rules for ASN.1 Types
<draft-legg-ldap-gser-00.txt>
The IESG also approved publication of Common Elements of GSER Encodings
<draft-legg-ldap-gser-abnf-03.txt> as an Informational RFC.
These documents have been reviewed in the IETF but are not the product
of an IETF Working Group. The IESG contact persons are Ned Freed and
Patrik Faltstrom.
Technical Summary
X.500 collective attributes allow common characteristics to be shared
between collections of entries. This document summarizes the X.500
information model for collective attributes and describes use of
collective attributes in LDAP (Lightweight Directory Access Protocol).
The information needed are stored as subentries (special entries used
to hold information associated with a subtree or subtree refinement).
"Collective Attributes in LDAP" provides schema definitions for collective
attributes for use in LDAP.
"Subentries in LDAP" adapts X.500 subentries mechanisms for use with LDAP.
"Generic String Encoding Rules for ASN.1 Types" defines a set of ASN.1
encoding rules that produce a human readable text encoding for values of
any given ASN.1 data type.
Working Group Summary
The documents have been discussed on the mailing lists for the LDAP
working groups in the IETF, and in the LDAP Directorate. There is
consensus for publication of these documents.
Protocol Quality
The specification has been reviewed for the IESG by Patrik Faltstrom.
To: RFC Editor <rfc-editor@isi.edu>
Cc: iesg@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Document Action: Developing High Quality SNMP Agents
to Informational RFC
The IESG has no problem with the publication of 'Developing High Quality
SNMP Agents' <draft-aromanov-snmp-hiqa-04> as an Informational RFC.
RFC-Editor Note:
The IESG would like to see an IESG note added on the front-page of
the document.
IESG Note
This document represents the opinions of the author. It has not
been widely reviewed in the IETF.
Publication of this document does not mean endorsement by the IESG
or the IETF (or SNMP) community.
And also FIX some problems:
- The suggestion on page 6, bullet (b) is questionable:
(b) an agent must return `inconsistentValue' if the complexity of
the SetRequest-PDU exceeds the agent's ability to perform consistency
checking: e.g. if the PDU contains any other variable. If an agent
Many people will think that a 'genErr' is more appropriate. The author
may have a defendable position. If so, it would be good to add that.
- Section 3.2 is believed to be conflicting with the RFC 3416 specification,
sect 4.2.5, specifically the text on page 22 towards the end of that
section 4.2.5.
Sect 3.2 of the internet-draft says:
Since the `commitFailed' error code does not convey any meaningful
information to NMS, an SNMP agent may substitute some meaningful
error code (e.g. `resourceNotAvailable') for such cases. An SNMP
agent should not ever find itself in the situation where it will
return `undoFailed'.
And so that recommendation should be taken out.
If the intention is to indicate that an SNMP agent should try its
utmost to first do as much checking as possible (rfc3416 says so too)
and if it concludes that committing the SET operation would fail,
that it then sends a 'resourceNotAvailable', then that is fine.
But that is not what it says.
And RFC3416 clearly states that IF a commit fails, then you MUST
return a commitFailed. And if an undo fails, then you MUST return
an undoFailed.
And that we have suggestions for changes as follows:
- Change the title from
Developing High Quality SNMP Agents
into something aka:
Considerations for SNMP agent developers
Justification:
- the doc itself is (in my view) not high quality itself.
- the doc discussus only a small part of the whole problem
space and the many tricky things in SNMP agent development
- one needs to be an SNMP expert to understand what is
being described.
- Change the "recommendations", i.e.
- The author often speaks like "It is recommended", where
it seems to make more sense to say "I recommend"
- References need to be made to the new SNMP STD documents (that
is in the 341x range instead of 257x range). We understand that
those were not yet RFCs when the I-D was submitted to RFC-Editor.
- Instead of talking about an "index string", we strongly recommend
to talk about an "index sequence". Otherwise people too easily
think about an ascii representation of OID components in the
dotted notation, and the author means an array (or sequence) of
unsigned integers that represent OID components (or sub-IDs).
- Same for "string of Object Identifiers"
- In many places, when the author talks about "OID" he really means
an OID component (i.e. one unsigned integer instead of a
sequence of unsigned integers).
- Bullet 3 on page 4 and 5. Strongly recommend to move the 1st
sentence of the last para (i.e.
This OID range checking must start at the end of index string and
progress towards its beginning.
to the beginning of bullet 3. Otherwise it is impossible to
understand what the steps mean.
- We suggest that the author explains what he means by non-implied
and explains that it is about INDEX objects that have the keyword
IMPLIED associated with it. SO it would then also be better to
us non-IMPLIED instead of "non-implied".
IP Telephony (iptel)
--------------------
Charter
Last Modified: 2003-05-16
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
naming and routing for Voice over IP (VoIP) protocols.
Naming is accomplished through the use of the tel URI, which specifies a URI
for telephone numbers. The tel URI was originally defined in RFC 2806, which
was developed outside of any IETF working group. The iptel working group is
responsible for updating the specification based on extensive experience
with the tel URI. It is chartered to develop any extensions to the tel URI,
such as support for number portability indicators and trunk groups.
Routing protocols for VoIP allow intermediaries, such as SIP proxies and
H.323 gatekeepers, to make call routing decisions based on reachability
information learned from peer elements. The iptel group has already defined
a protocol, Telephony Routing over IP (TRIP), RFC 3219, 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 specification for gateway to server route exchange.
2. A proposed standard TRIP MIB specification, based heavily on the existing
BGP-4 MIB documents.
3. A standards track update to the tel URI.
4. Standards track extensions to the tel URI for PSTN interoperability, such
as number portability and trunk group identification.
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
June 03 Gateway to Server Route Exchange document submitted to IESG for
consideration as proposed standard.
July 03 Tel URI revisions submitted to IESG
Sept 03 Number portability extensions submitted to IESG for consideration
as proposed standard.
Oct 03 Trunk Group extensions submitted to IESG for consideration as
proposed standard.
Nov 03 Consider closing
Next Steps in Signaling (nsis)
------------------------------
Charter
Last Modified: 2003-05-22
Current Status: Active Working Group
Chair(s):
J. Loughney <john.loughney@nokia.com>
Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Advisor:
Allison Mankin <mankin@psg.com>
Mailing Lists:
General Discussion: nsis@ietf.org
To Subscribe: nsis-request@ietf.org
In Body: (un)subscribe
Archive:
www.ietf.org/mail-archive/working-groups/nsis/current/maillist.html
Description of Working Group:
The Next Steps in Signaling Working Group is responsible for
standardizing an IP signaling protocol with QoS signaling as the first
use case. This working group will concentrate on a two-layer signaling
paradigm. The intention is to re-use, where appropriate, the protocol
mechanisms of RSVP, while at the same time simplifying it and applying a
more general signaling model.
The existing work on the requirements, the framework and analysis of
existing protocols will be completed and used as input for the protocol
work.
NSIS will develop a transport layer signaling protocol for the transport
of upper layer signaling. In order to support a tool box or building
block approach, the two-layer model will be used to separate the
transport of the signaling from the application signaling. This allows
for a more general signaling protocol to be developed to support
signaling for different services or resources, such as NAT & firewall
traversal and QoS resources. The initial NSIS application will be an
optimized RSVP QoS signaling protocol. The second application will be
a middle box traversal protocol. It may be that a rechartering of the
working group occurs before the completion of this milestone.
Security is a very important concern for NSIS. The working group will
study and analyze the threats and security requirements for signaling.
Compatibility with authentication and authorization mechanisms such as
those of Diameter, COPS-PR, and RSVP-PR auth-session, will be addressed.
It is a non-goal of the working group to develop new resource allocation
protocols. Resource reservation and traffic engineering are out of scope
of this working group. Additionally, third party signaling is out of
scope of this working group. Mobility protocols and AAA work are out of
scope of the working group. The work produced in this Working Group
should work with existing IETF mobility and AAA protocols, including
(but not limited to) Mobile IP, Seamoby, AAA, Midcom and RAP. It
will also welcome participation and expression of requirements from
non-IETF standards organization members, for instance 3GPP and 3GPP2
and ITU-T.
Goals and Milestones:
MAY 03 Submit "Requirements for Signaling Protocols" to IESG for
publication as Informational RFC
JUN 03 Submit "RSVP Security Properties" to IESG as Informational RFC
JUN 03 Submit "NSIS Threats" to IESG as Informational RFC
JUL 03 Submit "Analysis of Existing Signaling Protocols" to IESG as
Informational RFC
SEP 03 Submit "Next Steps in Signaling: Framework" to IESG for
publication as Informational RFC
FEB 04 Submit "NSIS Transport Protocol" to IESG for publication for
Proposed Standard
MAR 04 Submit "NSIS QoS Application Protocol" to IESG for publication
for Proposed Standard
SEP 04 Submit "NSIS Middle Box Signaling Application Protocol" to
IESG for publication for Proposed Standard
SEP 04 Conclude WG