ION approved
An IETF Operational Note has been approved and posted: http://www.ietf.org/IESG/content/ions/ion-agenda-and-minutes.html RFC 2418 outlines the procedures for IETF Session operation. However, it contains little information about post-IETF meeting working group chair responsibilities. In particular, it provides little guidance with respect to either form or submission deadlines for the artifacts of the meeting, namely, session minutes and presentation materials. This document addresses these issues and provides suggestions about the form and content of Working Group agendas and minutes. The use of the templates is not mandatory and the guidance herein may be safely ignored. For the general ION page, see http://www.ietf.org/IESG/content/ions.html ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-pwe3-aii-aggregate (AII Types for Aggregation) to Proposed Standard
The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'AII Types for Aggregation ' draft-ietf-pwe3-aii-aggregate-02.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-03-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pwe3-aii-aggregate-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=14352rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-trill-routing-reqs (TRILL Routing Requirements in Support of RBridges) to Informational RFC
The IESG has received a request from the Transparent Interconnection of Lots of Links WG (trill) to consider the following document: - 'TRILL Routing Requirements in Support of RBridges ' draft-ietf-trill-routing-reqs-02.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-03-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=15187rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-pkix-scvp (Server-based Certificate Validation Protocol (SCVP)) to Proposed Standard
The IESG has received a request from the Public-Key Infrastructure (X.509) WG (pkix) to consider the following document: - 'Server-based Certificate Validation Protocol (SCVP) ' draft-ietf-pkix-scvp-31.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-04-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-31.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=4376rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
PGP Key Signing
Once again, we will be holding a PGP Key signing party at the 68th IETF meeting in Prague. We have been scheduled to meet at 1620 on the evening of Wednesday, March 21 in the Roma/Vienna/Madrid room. Note that we have a very tight time-slot between the last afternoon and the plenary, so please be on time. The procedure we will use is the following: o People who wish to participate may do so in one of two ways. You may bring slips of paper with your name, e-mail address, key-id, and key fingerprint. (One way of generating this if using gpg is gpg --list-keys --fingerprint [EMAIL PROTECTED]) You should bring enough for everyone who may attend; given recent attendance patterns, around 50 should be more than enough. (You can generally fit 10-12 strips containing your key fingerprint on a single sheet of paper, and then cut out strips to hand out.) o Alternatively, you may email an ASCII extract of their PGP public key to [EMAIL PROTECTED] by noon on Wednesday, March 21. Please include a subject line of IETF PGP KEY, and please DO NOT MIME-ENCRYPT your e-mail; send it to me as plain text. The method of generating the ASCII extract under Unix is: pgp -kxa my_email_address mykey.asc (pgp 2.6.2) pgpk -xa my_email_address mykey.asc (pgp 5.x) gpg --export -a my_email_address mykey.asc (gpg) If you're using Windows or Macintosh, hopefully it will be Intuitively Obvious (tm) using the GUI interface how to generate an ASCII armored key that begins -BEGIN PGP PUBLIC KEY BLOCK-. o By 1500 on Wednesday, you will be able to fetch complete key ring from any of the following locations with all of the keys that were submitted: /afs/grand.central.org/project/ietf-pgp/ietf68/ietf68.pgp http://grand.central.org/dl/ietf-pgp/ietf68/ietf68.pgp ftp://grand.central.org/pub/ietf-pgp/ietf68/ietf68.pgp o At 1620, come prepared with the PGP Key fingerprint of your PGP public key; we will have handouts with all of the key fingerprints of the keys that people have mailed in. o In turn, readers at the front of the room will recite people's keys; as your key fingerprint is read, stand up, and at the end of reading of your PGP key fingerprint, acknowledge that the fingerprint as read was correct. o Later that evening, or perhaps when you get home, you can sign the keys corresponding to the fingerprints which you were able to verify on the handout; note that it is advisable that you only sign keys of people when you have personal knowledge that the person who stood up during the reading of his/her fingerprint really is the person which he/she claimed to be. o Send the signed keys to the owners, and, optionally, to the PGP key servers. Some poeple opt to NOT send the signed keys to the keyservers, but rather choose to send them only to the e-mail address on the key's userid, encrypted for that particular key. This tends to ensures the validity of the e-mail address. Note that you don't have to have a laptop with you; if you don't have any locally trusted computing resources during the key signing party, you can make notes on the handout, and on the strips of papers, and then take these and sign the keys later. Acknowledgement: The bulk of the text of this message was taken from the messages usually sent by Ted Ts'o to announce IETF key signing parties. -- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED] Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'IANA Considerations for PPP over Ethernet (PPPoE)' to Informational RFC
The IESG has approved the following document: - 'IANA Considerations for PPP over Ethernet (PPPoE) ' draft-arberg-pppoe-iana-03.txt as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-arberg-pppoe-iana-03.txt Technical Summary This document provides for an IANA registry of PPPoE TAG and Code fields. Known existing usages are reserved, and a first come first served policy is established for future codes. Working Group Summary The PPPEXT working group reviewed the document and there are no known concerns with the work. PPPoE itself is not a standard protocol (L2TP and DHCP are standards-track alternatives), and future extensions are thus not encouraged. However, the new registry will help prevent possible conflicts that may develop before the standards-based solutions are adopted by PPPoE users. Protocol Quality This document does not specify any protocol. The registry established reflects current practice within the community. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: '6LoWPAN: Overview, Assumptions, Problem Statement and Goals' to Informational RFC
The IESG has approved the following document: - '6LoWPAN: Overview, Assumptions, Problem Statement and Goals ' draft-ietf-6lowpan-problem-08.txt as an Informational RFC This document is the product of the IPv6 over Low power WPAN Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-problem-08.txt Technical Summary 6LoWPAN is specification describing how to utilize IPv6 on top of low power, low data rate, low cost personal area networks. These networks today being built using IEEE 802.15.4 standard radios. These radios have an extremely limited frame size which makes it necessary to define an adaptation layer to support link layer fragmentation and reassembly. Additionally since these networks utilize low power transmission it is necessary for the adaptation layer to support network layer mesh capabilities. This specification defines the header format for this adaptation layer. Working Group Summary The working group reached consensus on this document. Document Quality There are at least 6 independent implementations of this protocol being worked on and all concerns raised during the review and WGLC have been addressed. Geoff Mulligan is the Document Shepherd. Note to RFC Editor 1) The draft indicates in its 3rd line that the intended status is Standards Track. However, the document should be Informational. 2) The document does not contain any normative statement (capitalized MUST, MAY, SHOULD, etc.), Section 1.1 and the reference to RFC 2119 could be safely deleted. 3) Normative references should be [ieee802.15.4] and [RFC2460], with the remaining informative. 4) OLD: An admittedly non-technical but important consideration is that intellectual property conditions for IP networking technology are either more favorable or at least better understood than proprietary and newer solutions. NEW: An admittedly non-technical but important consideration is that IP networking technology is specified in open and freely available specifications which is favorable or at least able to be better understood by a wider audience than proprietary solutions. OLD: As alluded to above, devices within LoWPANs are expected to be deployed in exceedingly large numbers. Additionally, they are expected to have limited display and input capabilities. Furthermore, the location of some of these devices may be hard to reach. Accordingly, protocols used in LoWPANs should have minimal configuration, preferably work out of the box, be easy to bootstrap, and enable the network to self heal given the inherent unreliable characteristic of these devices. Network management should have little overhead yet be powerful enough to control dense deployment of devices. NEW: As alluded to above, devices within LoWPANs are expected to be deployed in exceedingly large numbers. Additionally, they are expected to have limited display and input capabilities. Furthermore, the location of some of these devices may be hard to reach. Accordingly, protocols used in LoWPANs should have minimal configuration, preferably work out of the box, be easy to bootstrap, and enable the network to self heal given the inherent unreliable characteristic of these devices. The size constraints of the link layer protocol should also be considered. Network management should have little overhead yet be powerful enough to control dense deployment of devices. OLD: Network Management: One of the points of transmitting IPv6 packets, is to reuse existing protocols as much as possible. Network management functionality is critical for LoWPANs. [RFC3411] specifies SNMPv3 protocol operations. SNMP functionality may be translated as is to LoWPANs. However, further investigation is required to determine if it is suitable, or if an appropriate adaptation is in order. This adaptation could include limiting the data types and simplifying the Basic Encoding Rules so as to reduce the size and complexity of the ASN.1 parser, thereby reducing the memory and processing needs to better fit into the limited memory and power of LoWPAN devices. NEW: Network Management: One of the points of transmitting IPv6 packets, is to reuse existing protocols as much as possible. Network management functionality is critical for LoWPANs. However, management solutions need to meet the resource constraints as well as the minimal configuration and self healing functionality described in section 4.4. The Simple Network Management Protocol (SNMP) [RFC3410] is widely used for monitoring data sources and sensors in conventional networks. SNMP functionality may be translated as is to LoWPANs with the benefit to utilize existing tools. However, due to the memory,
