[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Agenda and Package for May 29, 2003 Telechat
Fixed.
The 2nd draft of agenda packet that is about to be sent out will reflect
this change.
Michael
On Fri, 2003-05-23 at 21:18, hardie@qualcomm.com wrote:
> Hi,
> The returning item for draft-legg-ldap-gser-abnf-06.txt
> should be the whole flight (that is, all the drafts that were
> previously balloted with that draft.
> thanks,
> Ted Hardie
>
>
> At 3:12 PM -0400 5/23/03, Michael Lee wrote:
> > 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 ...
> >...snip...
> > > 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
>