[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Agenda and Package for December 4, 2003 Telechat
THanks Dan, I will follow up on this.
Thanks,
Bert
> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
> Sent: dinsdag 2 december 2003 14:39
> To: Wijnen, Bert (Bert); Mreview (E-mail)
> Subject: RE: Agenda and Package for December 4, 2003 Telechat
>
>
> Bert,
>
> I have a documentation issue with
> draft-ietf-ipv6-rfc2096-update-05.txt. I do not know how
> often you are asked the question what does' MIB-II support'
> mean nowadays. It happens now and then to me. In pre-historic
> times I could prompt people to RFC 1213, but now I have no
> easy answer, taking into account that the functionality
> described originally in RFC 1213 and one MIB module is now
> fragmented in several MIB modules, which are now at the
> second generation of revisions or more. Two of them are in
> your list for this week, the IP Forwarding MIB, and the TCP
> MIB. Unless there is some text that I am not aware about
> describing all these, I prefer the approach taken by the TCP
> MIB - draft-ietf-ipv6-rfc2012-update-04.txt, which in its
> 'Relationship with other MIBs' section documents well the
> relationship with the MIB module ancestors. Such a section
> that helps a lot implementers and users of the MIB is missing
> from draft-ietf-ipv6-rfc2096-update-05.txt.
>
> Regards,
>
> Dan
>
>
> > -----Original Message-----
> > From: owner-mreview@ops.ietf.org
> > [mailto:owner-mreview@ops.ietf.org]On Behalf Of Wijnen, Bert (Bert)
> > Sent: 27 November, 2003 1:52 AM
> > To: Mreview (E-mail)
> > Subject: FW: Agenda and Package for December 4, 2003 Telechat
> >
> >
> >
> > If you have time between now and next wednesday (6pm EST),
> > pls review (from OPS perspective) the following documents
> > on the IESG agenda.
> >
> > Comments to mreview list or to me privately.
> > Pls let me know if you want to be identified as the source
> > of your comment or if you rather have me take the token in
> > my own name.
> >
> > Thanks in advance, you know already I need your help and
> > input/feedback.
> > I hope this gives you a nice break in between the Turkey
> and all that
> > (for those who are in that continent)
> >
> > Bert
> >
> > --------------
> >
> > 2. Protocol Actions
> >
> > 2.1 WG Submissions
> > 2.1.1 New Item
> > o draft-ietf-sip-callerprefs-10.txt
> > Caller Preferences for the Session Initiation Protocol
> > (SIP) (Proposed
> > Standard) - 1 of 14
> > Note: There was extensive mid-course review of
> callerprefs by the
> > Applications ADs (Patrik and then Ted), and Ted proposed
> > a very useful
> > split out of callee capabilities. There were many
> > other changes to
> > make callerprefs a more coherent design because of
> > this Applications
> > review. Callerprefs is a dependency of many SIP
> > applications, so the
> > improvements have been very important, and reaching
> > this point of
> > consensus and progress for the spec has been very important.
> > Token: Allison Mankin
> > o draft-ietf-ccamp-lmp-wdm-02.txt
> > Link Management Protocol (LMP) for Dense Wavelength
> > Division Multiplexing
> > (DWDM) Optical Line Systems (Proposed Standard) - 2 of 14
> > Note: No IETF Last Call comments were received.
> > Token: Bert Wijnen
> > o draft-ietf-ccamp-lmp-test-sonet-sdh-03.txt
> > SONET/SDH Encoding for Link Management Protocol (LMP)
> > Test messages
> > (Proposed Standard) - 3 of 14
> > Note: IETF Last Call did not raise any comments.
> > Token: Bert Wijnen
> > o draft-ietf-trade-ecml2-spec-08.txt
> > Electronic Commerce Modeling Language (ECML):Version 2
> > Specification
> > (Proposed Standard) - 4 of 14
> > Note: Four week last call requested
> > Token: Ned Freed
> > o draft-ietf-trade-voucher-lang-05.txt
> > XML Voucher: Generic Voucher Language (Proposed Standard)
> > - 5 of 14
> > Token: Ned Freed
> > o draft-ietf-enum-sip-00.txt
> > enumservice registration for SIP Addresses-of-Record
> > (Proposed Standard) -
> > 6 of 14
> > Note: Nits noted: splitting the references, correcting
> > FQDN examples not
> > in example.com form (and checking on use of a live phone
> > number example),
> > ref to old combined callerprefs/callee caps doc.
> > Token: Allison Mankin
> > o draft-ietf-krb-wg-kerberos-clarifications-04.txt
> > The Kerberos Network Authentication Service (V5)
> > (Proposed Standard) - 7
> > of 14
> > Token: Russ Housley
> > o draft-ietf-enum-h323-01.txt
> > ENUM Service Registration for H.323 URL (Proposed
> > Standard) - 8 of 14
> > Note: RFC Editor Note asks for removal of unnecessary
> > citations in
> > abstract and the few non-ascii characters.
> > Token: Allison Mankin
> > o draft-ietf-ipv6-rfc2096-update-05.txt
> > IP Forwarding Table MIB (Proposed Standard) - 9 of 14
> > Token: Thomas Narten
> > o draft-ietf-ipseckey-rr-07.txt
> > A method for storing IPsec keying material in DNS
> > (Proposed Standard) - 10
> > of 14
> > Token: Steve Bellovin
> > o draft-ietf-eap-rfc2284bis-06.txt
> > Extensible Authentication Protocol (EAP) (Proposed
> > Standard) - 11 of 14
> > Note: Please review the -07 version which contains
> > updates to address last
> > call comments.
> > Token: Margaret Wasserman
> > o draft-ietf-dhc-dhcpv6-stateless-01.txt
> > A Guide to Implementing Stateless DHCPv6 Service
> > (Proposed Standard) - 12
> > of 14
> > Note: Please review the -02 version, which has already
> > been submitted by
> > hasn't (yet) shown up in the tracker. It contains
> > changes to address
> > IETF last call comments.
> > Token: Margaret Wasserman
> > o draft-ietf-ipv6-rfc2012-update-04.txt
> > Management Information Base for the Transmission Control
> > Protocol (TCP)
> > (Proposed Standard) - 13 of 14
> > Note: Please review the -05 version, which has already
> > been submitted but
> > hasn't shown up in the tracker yet.
> > Token: Margaret Wasserman
> > o draft-ietf-pppext-vendor-protocol-01.txt
> > PPP Vendor Protocol (Proposed Standard) - 14 of 14
> > Note: IESG: This document has a normative reference to
> > RFC 2153, which is
> > an informational document. The reference could easily be made
> > non-normative. This document could also be made
> > informational instead.
> > Thoughts on best approach solicited.
> > Token: Thomas Narten
> >
> > 2.2 Individual Submissions
> > 2.2.1 New Item
> > o draft-daboo-sieve-spamtest-04.txt
> > SIEVE Spamtest and Virustest Extensions (Proposed
> > Standard) - 1 of 2
> > Note: On IESG agenda 4-Dec-2003
> > Token: Ned Freed
> > o draft-melnikov-imap-unselect-01.txt
> > IMAP UNSELECT command (Proposed Standard) - 2 of 2
> > Note: Known nits: Needs separate abstract and intro,
> needs. IANA
> > considerations section that says the UNSELECT. capability
> > is to be
> > registered.
> > Token: Ned Freed
> >
> > 3.1 WG Submissions
> > 3.1.1 New Item
> > o draft-ietf-pwe3-requirements-07.txt
> > Requirements for Pseudo-Wire Emulation Edge-to-Edge
> > (PWE3) (Informational)
> > - 1 of 4
> > Token: Jon Peterson
> > o draft-ietf-pwe3-arch-06.txt
> > PWE3 Architecture (Informational) - 2 of 4
> > Token: Jon Peterson
> > o draft-ietf-dnsext-dns-threats-05.txt
> > Threat Analysis Of The Domain Name System (Informational)
> > - 3 of 4
> > Token: Thomas Narten
> > o draft-ietf-sipping-e164-04.txt
> > Using E.164 numbers with the Session Initiation Protocol (SIP)
> > (Informational) - 4 of 4
> > Token: Allison Mankin
> >
> > 3.3 Individual Submissions Via RFC Editor
> > 3.3.1 New Item
> > NONE
> > 3.3.2 Returning Item
> > o draft-ogura-mapos-nsp-multiexp-02.txt
> > A Multicast Extension to MAPOS NSP (Node Switch Protocol)
> > (Informational)
> > - 1 of 1
> > Note: Here is a proposed DNP note:. . The IESG requests
> > that 'A Multicast
> > Extension to MAPOS NSP (Node. Switch Protocol)'
> > draft-ogura-mapos-nsp-multiexp-02.txt NOT be. published as an
> > Experimental RFC.. . MAPOS is a link-layer protocol for
> > transmitting
> > network-layer. datagrams encapsulated in HDLC frames over
> > SONET/SDH. Like
> > most. link-layer protocols, MAPOS has no particular
> > relationship with IP.
> > other than that it can carry IP datagrams. This
> > document describes.
> > NSP+, MAPOS-specific extensions whose scope is restricted
> > to MAPOS.
> > itself. The extensions described here are entirely an internal
> > MAPOS. issue and are not directly related to the
> > higher-layer protocols.
> > (e.g., IP) that MAPOS can carry. While we do not have an
> > issue with. the
> > technical content of the document per se, we do question
> > how the. scope of
> > the document relates to the RFC series, and in particular
> > its. focus of
> > being "about the Internet"..
> > Token: Thomas Narten
> >
> > -----------------------------------------------
> > Bert says: following are returning items.
> > normally we prefer to not see new issues raised, unless they
> > are absolutely fatal.
> > --------------------------------------
> > 2.1.2 Returning Item
> > o Two-document ballot: - 1 of 3
> > - draft-ietf-mpls-tc-mib-10.txt
> > Definitions of Textual Conventions for Multiprotocol
> > Label Switching
> > (MPLS) Management (Proposed Standard)
> > - draft-ietf-mpls-mgmt-overview-09.txt
> > Multiprotocol Label Switching (MPLS) Management Overview
> > (Informational)
> > Token: Alex Zinin
> > o draft-ietf-mpls-lsr-mib-14.txt
> > Multiprotocol Label Switching (MPLS) Label Switching Router
> > (LSR)Management Information Base (Proposed Standard) - 2 of 3
> > Token: Alex Zinin
> > o draft-ietf-pkix-x509-ipaddr-as-extn-03.txt
> > X.509 Extensions for IP Addresses and AS Identifiers
> > (Proposed Standard) -
> > 3 of 3
> > Token: Russ Housley
> >
> > 3.2 Individual Submissions Via AD
> > 3.2.1 New Item
> > o draft-sarcar-snoop-new-types-01.txt
> > Additional Snoop Datalink Types (Informational) - 1 of 1
> > Token: Thomas Narten
> >
> >
> >
>