[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Agenda and Package for May 29, 2003 Telechat (Final Version)
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 28, 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
DONE 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.
DONE 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.
DONE 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
DONE 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
o Registration Revocation in Mobile IPv4 (Proposed Standard)
<draft-ietf-mobileip-reg-revok-07.txt>
Token: Narten, Thomas
Note: Note: 3GPP2 wants this to be an RFC by May 31,
2003. New version should address smb's discuss.
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
- Subentries in LDAP (Proposed Standard)
<draft-zeilenga-ldap-subentry-07.txt>
- Common Elements of GSER Encodings (Informational)
<draft-legg-ldap-gser-abnf-06.txt>
- 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-20.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 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
o SIP for Instant Messaging and Presence Leveraging Extensions
Token: Ted
4.2.2 Proposed for Approval
o IP Telephony
Token: Jon
Note: under discussion
5. Working Group News We Can Use
5.1 WG Closing
WG Name: Content Distribution Internetworking (cdi)
Note: This is an explicit request to close a working group
which has Informational documents in the RFC Editor's
queue, but no other work planned.
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.
o Does ballot text need a change.
Proposed change is at bottom.
It comes from the postings where
Bill answers Bert:
> > Oi, here's the problem with keeping the templates as templates!
> >
> > >Copies of the IESG approval notes to the RFC Editor are appended
> > >below (copied from the IETF Data Tracker search engine).
> >
> > If you visit the printmib-finishing document, for example, in the
> > public datatracker, we see:
> >
> > IESG Discussion: Available
> >
> > and following that link gets us
> >
> >
https://www.ietf.org/IESG/EVALUATIONS/draft-ietf-printmib-finishing.bal
>
> and, of course, the ballot includes the email message that would be
> sent upon approval after the ^L.
>
So can we change the online ballots to not say:
^L
To: IETF-Announce:;
Dcc: *******
But instead say:
^L
---- following is a DRAFT of message to be sent AFTER approval ---
To: IETF-Announce:;
Dcc: *******
So that whoever looks at them can clearly see it is a draft message?
Bert
> Bill
>
*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'
<draft-ietf-provreg-epp-09.txt>
o 'Extensible Provisioning Protocol Domain Name Mapping'
<draft-ietf-provreg-epp-domain-07.txt>
o 'Extensible Provisioning Protocol Host Mapping'
<draft-ietf-provreg-epp-host-07.txt>
o 'Extensible Provisioning Protocol Contact Mapping'
<draft-ietf-provreg-epp-contact-07.txt>
o 'Extensible Provisioning Protocol Transport Over TCP'
<draft-ietf-provreg-epp-tcp-06.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 [ ] [ ] [ 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'.
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.
Ted:
I think the reference to Appendix A of 2327 is not quite right.
That reference uses unicast-address where this uses connection-address. The
relevant text in Appendix A seems to be:
unicast-address := IP4-address | IP6-address
IP4-address := b1 "." decimal-uchar "." decimal-uchar "." b4
b1 := decimal-uchar ;less than "224" not "0" or "127"
b4 := decimal-uchar ;not "0"
IP6-address := ;to be defined
This last, of course, tends to mean that there must be a
later definition for the IP6-address. Perhaps that is where
the connection-address is defined?
STUN is also listed as an informative reference, which seems
a bit odd. It seems normative to me.
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
Ted:
As a personal note, I'm not a big fan of STUN, but this does
seem to be the case it is a hack for, so I think that is a done
deal.
A fair number of typos and subject-verb agreement problems, as
well as non-ASCII characters. In the introduction:
"my the various" should be "by the various"; "conforming" should be
"conformant". In 3.1, "allocate" should "allocates" and, in 4., "port"
should be "ports". In the security section, "require" should be "requires".
^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.
Xo: 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-mobileip-reg-revok - Registration
Revocation in Mobile IPv4 to Proposed Standard
--------
Last Call to expire on: 2003-3-7
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ X ] [ ]
Randy Bush [ ] [ X ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Ted Hardie [ ] [ X ] [ ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ X ] [ ] [ ]
Thomas Narten [ X ] [ ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
Jon Peterson [ ] [ X ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
========
Steve:
3.2: Is there some reason why the "I|M|Reserved" field doesn't come
before the timestamp? That would permit the timestamp to be aligned.
(Or is that not helpful for this sort of TLV?)
3.5: Delete the phrase "man-in-the-middle" attack -- these aren't.
They're "active attacks".
7.2 is not clear enough on what the mandatory-to-implement security is.
It says
Revocation messages
defined in this document which are passed between home and
foreign agents in the revocation process MUST be protected by
either the same foreign-home authenticators defined in [1], or
another authentication mechanism at least as secure and agreed
upon by the end agents, e.g., IPSec and IKE.
That's not acceptable. Apart from the question of how a home and a
foreign agent "agree" upon another mechanism, it doesn't mandate
support for [1]'s mechanism (or some other strong-enough mechanism).
(Earlier comments about MITM attacks apply here, too.)
COMMENTS:
=========
Bert:
However, I do see (non-compliance with ID-NITS):
- citation in abstract
- Page 11:
e.g. revoke: 10.1.1.128, prefixLen: 25 means all mobile nodes
whose addresses fall within the range 10.1.1.128 - 10.1.1.254
and revoke: 10.1.1.129, prefixLen: 25 has the same meaning,
but revoke: 10.1.1.0, prefixLen:25 means all mobile nodes
whose addresses fall within the range 10.1.1.0 - 10.1.1.127.
(e.g. revoke: 10.1.1.240, prefixLen: 28).
and there is more of that on following page(s)
ID-NITS says
Addresses used in examples should prefer use of fully qualified
domain names to literal IP addresses, and prefer use of example
fqdn's such as foo.example.com to real-world fqdn's
See RFC 2606 for example domain names that can be used
There is also a range of IP addresses set aside for this purpose.
These are 192.0.2.0/24 (see RFC 3330). Private addressess that
would be used in the real world should be avoided in examples.
- References not split
Bert:
>From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
>To: "Steven M. Bellovin" <smb@research.att.com>,
>Subject: RE: Evaluation: draft-ietf-mobileip-reg-revok - Registration Revo
> In message
> <7D5D48D2CAA3D84C813F5B154F43B15501483EF2@nl0006exch001u.nl.lucent.c
> om>, "Wijnen, Bert (Bert)" writes:
> >> Yes No-Objection Discuss * Abstain
> >> Bert Wijnen [ ] [ X ] [ ] [ ]
> >
> >However, I do see (non-compliance with ID-NITS):
> >
> >- citation in abstract
> >
> >- Page 11:
> >
> > e.g. revoke: 10.1.1.128, prefixLen: 25 means all
> mobile nodes
> > whose addresses fall within the range 10.1.1.128
> - 10.1.1.254
> > and revoke: 10.1.1.129, prefixLen: 25 has the
> same meaning,
> > but revoke: 10.1.1.0, prefixLen:25 means all mobile nodes
> > whose addresses fall within the range 10.1.1.0 -
> 10.1.1.127.
> >
> >
> > (e.g. revoke: 10.1.1.240, prefixLen: 28).
> >
> > and there is more of that on following page(s)
> >
> > ID-NITS says
> > Addresses used in examples should prefer use of fully qualified
> > domain names to literal IP addresses, and prefer use of example
> > fqdn's such as foo.example.com to real-world fqdn's
> > See RFC 2606 for example domain names that can be used
> > There is also a range of IP addresses set aside for
> this purpose.
> > These are 192.0.2.0/24 (see RFC 3330). Private addressess that
> > would be used in the real world should be avoided in examples.
>
>
> But the document is talking about IP addresses and prefixes here; I
> don't think FQDNs would make any sense.
>
Correct. But there are also IP addresses set aside for such use and
they are using other IP addresses.
(I personally can live with it though... I just noticed).
Bert
Randy:
i can't deal with this. too fried. i would defer, but i am
willing to trust my peer ad as this is time sensitive.
Steve:
>> Bert Wijnen [ ] [ X ] [ ] [ ]
>
>However, I do see (non-compliance with ID-NITS):
>
>- citation in abstract
>
>- Page 11:
>
> e.g. revoke: 10.1.1.128, prefixLen: 25 means all mobile nodes
> whose addresses fall within the range 10.1.1.128 - 10.1.1.254
> and revoke: 10.1.1.129, prefixLen: 25 has the same meaning,
> but revoke: 10.1.1.0, prefixLen:25 means all mobile nodes
> whose addresses fall within the range 10.1.1.0 - 10.1.1.127.
>
>
> (e.g. revoke: 10.1.1.240, prefixLen: 28).
>
> and there is more of that on following page(s)
>
> ID-NITS says
> Addresses used in examples should prefer use of fully qualified
> domain names to literal IP addresses, and prefer use of example
> fqdn's such as foo.example.com to real-world fqdn's
> See RFC 2606 for example domain names that can be used
> There is also a range of IP addresses set aside for this purpose.
> These are 192.0.2.0/24 (see RFC 3330). Private addressess that
> would be used in the real world should be avoided in examples.
But the document is talking about IP addresses and prefixes here; I
don't think FQDNs would make any sense.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, mobile-ip@sunroof.eng.sun.com
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Registration Revocation in Mobile IPv4 to
Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Registration Revocation in
Mobile IPv4' <draft-ietf-mobileip-reg-revok-05.txt> as a Proposed
Standard. This document is the product of the IP Routing for
Wireless/Mobile Hosts Working Group.
The IESG contact persons are Thomas Narten and Erik Nordmark.
Technical Summary
This document defines a Mobile IPv4 Registration Revocation mechanism
whereby a mobility agent (i.e., either a Home Agent or Foreign Agent)
that provides Mobile IP services to a mobile node can notify its peer
mobility agent (or co-located mobile node) that it is discarding one
or more of its mobility bindings and for this notification to be
acknowledged. In addition, the signaling mechanism already defined by
the Mobile IPv4 protocol is extended so that a mobility agent can also
inform the mobile node(s) of the revocation of their binding(s).
Working Group Summary
There was support for this document in the WG.
Protocol Quality
This document has been reviewed for the IESG by Thomas Narten.
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Scretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-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 [ ] [ X ] [ ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
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 [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ X ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>,
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 [ X ] [ ] [ ] [ ]
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'.
COMMENTS:
========
Ted Hardie:
Two notes:
In section 3.2.1 "An header" should be "A header".
In section 3.4, the draft says:
Publication in an IESG-approved RFC or other form of Open Standard
document (per RFC 2026 [1], section 7) is sufficient grounds for
publication in the permanent registry.
Note that the text IESG-approved suggests a different test from
the one set out above--which would allow Experimental and
Informational RFCs which the IESG may choose to advise the RFC editor
on, but does not exactly "approve". To avoid the swamp, I'd suggest
the text here
be shifted to "published RFC" to be in accord with the text above.
^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 [ ] [ X ] [ ] [ ]
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
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-28
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.
TRIP and the gateway registration protocol are orthogonal to the
DNS-based mechanisms specified in ENUM and RFC 3264. Those mechanisms
are used to translate a URI, representing a name, to an address. If
that address is a phone number in the telephone network, trip and
tgrep can be used to assist in determining the right route (through
various gateways) to that number.
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
SIP for Instant Messaging and Presence Leveraging Extensions (simple)
---------------------------------------------------------------------
Charter
Last Modified: 2003-05-20
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. Included might be 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.
Each of these mechanisms will be consistent with a SIP-based architecture, as
well as meeting the constraints otherwise described in this charter.
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:
DONE Submission of event package for presence to IESG for publication as
Proposed Standard
DONE Submission of watcher information drafts to IESG for publication as
Proposed Standards
May 03 Submission of proposed event list mechanism to the SIP working group.
Jun 03 Submission of requirements for event publishing to the IESG for
publication as Proposed Standard
Jun 03 Submission of proposed mechanism for event publishing to the SIP
working group.
Jun 03 Submission of presencelist auth/modify requirements draft to IESG for
publication as Informational
Jun 03 Submission of requirements for presence partial notification and
filtering to the IESG for publication as Informational
Jul 03 Submission of CPIM mapping draft to IESG for publication as
Informational
Jul 03 Submission of instant messaging session drafts to IESG for
publication as Proposed Standards
Jul 03 Submission of SIMPLE PIDF profile to IESG for publication as Proposed
Standard
Jul 03 Submission of advanced messaging requirements draft to IESG for
publication as Informational
Jul 03 Submission of presencelist auth/modify mechanism drafts to IESG for
publication as Proposed Standard
Aug 03 Submission of proposed mechnisms meeting the advanced messaging
requirements to the IESG or appropriate working group
Sep 03 Submission of Presence/IM System Architecture draft to IESG for
publication as Informational