RE: New liaison from IESG to SG15
Hi Adrian, The attached email arrived from the tool on Friday and TD278/GEN was posted shortly afterwards: http://www.itu.int/md/T09-SG15-111205-TD-GEN-0278/en Regards, Greg -Original Message- From: Adrian Farrel [mailto:adr...@olddog.co.uk] Sent: Sunday, 20 November 2011 01:50 To: Jones, Greg Cc: hous...@vigilsec.com; ch...@ietf.org; i...@ietf.org; Johnson, Malcolm; yoichi.ma...@ttc.or.jp; ietf@ietf.org; Eliot Lear; ietf-secretar...@ietf.org Subject: New liaison from IESG to SG15 Hi Greg, Please find below a copy of a Liaison from the IESG to SG15. The liaison is entered in our tool at https://datatracker.ietf.org/liaison/1115/. Owing to some glitch in the tool, the liaison does not appear to have popped out as an email. Because everyone is en route back from IETF-82 in Taipei, this is going to take a couple of days to emerge, so I am sending you this direct such that you can get it into the ITU-T system in good time for the December plenary. Thanks for your work. Regards, Adrian (for the IETF Secretariat) === Liaison Statement: Email Correspondence Between IETF Chair and TSB Director Submission Date: 2011-11-18 From: The IESG (Russ Housley) To: ITU-T SG 15 (Greg Jones) Cc: The IETF Chair The IESG Malcolm Johnson Yoichi Maeda The IETF Response Contact: Russ Housley Technical Contact: Eliot Lear Purpose: For information Attachments: (none) Body: The IESG would like to draw your attention to an email from the IETF Chair, Mr. Russ Housley, to the TSB Director, Mr. Malcolm Johnson. The email is fully supported by the IESG, and reads as follows: From: Russ Housley hous...@vigilsec.com Date: November 15, 2011 5:23:15 AM EST To: Malcolm Johnson malcolm.john...@itu.int Subject: Re: MPLS Dear Malcolm: http://www.itu.int/ITU-T/newslog/Statement+Ahead+Of+IETF+Meeting.aspx Thanks for getting this posted. It has already gotten a lot of visibility. Just to make sure that we are on the same page, I'd like to repeat two things that came up while we were drafting the newslog article. These also reflect the IETF's understanding of the newslog article. I'll forward this note to the IETF participants to be sure that we're all in sync here. First, the text of the newslog article re-affirms the JWT agreement from 2008 as captured in RFC 5317. In particular, the IETF standards process will continue to be used for all MPLS-TP architecture and protocol documents. Second, since G.8113.1 contains a protocol that is not a product of the IETF standards process, it cannot be a part of MPLS-TP according to the conditions of the JWT agreement and the newslog article. The IETF anticipates one of the following actions will be taken to conform to this agreement. Either (1) G.8113.1 will be withdrawn, or (2) the title of G.8113.1 will be changed, and the content will be revised to reflect that it is not included as part of MPLS or MPLS-TP protocol suite. Also, thanks for sending me the TD527/P document from the SG15 Chairman. I note that it proposes the progression of both G.8113.1 and G.8113.2 as MPLS standards. This approach is not consistent with the JWT agreement or the newslog article. I believe this is a constructive step forward. I look forward to a resolution that fully respects the JWT agreement and moves our two organizations further toward collaborative standards development. Russ ---BeginMessage--- Title: Email Correspondence Between IETF Chair and TSB Director Submission Date: 2011-11-18 URL of the IETF Web page: /liaison/1115/ From: The IESG (Russ Housley hous...@vigilsec.com) To: ITU-T SG 15 (Greg Jones greg.jo...@itu.int) Cc: The IETF Chair ch...@ietf.org,The IESG i...@ietf.org,Malcolm Johnson malcolm.john...@itu.int,Yoichi Maeda yoichi.ma...@ttc.or.jp,The IETF ietf@ietf.org Reponse Contact: Russ Housley ch...@ietf.org Technical Contact: Eliot Lear el...@cisco.com Purpose: For information Body: The IESG would like to draw your attention to an email from the IETF Chair, Mr. Russ Housley, to the TSB Director, Mr. Malcolm Johnson. The email is fully supported by the IESG, and reads as follows: From: Russ Housley hous...@vigilsec.com Date: November 15, 2011 5:23:15 AM EST To: Malcolm Johnson malcolm.john...@itu.int Subject: Re: MPLS Dear Malcolm: http://www.itu.int/ITU-T/newslog/Statement+Ahead+Of+IETF+Meeting.aspx Thanks for getting this posted. It has already gotten a lot of visibility. Just to make sure that we are on the same page, I'd like to repeat two things that came up while we were drafting the newslog article. These also reflect the IETF's understanding of the newslog article. I'll forward this note to the IETF participants to be sure that we're all in sync here. First, the text of the newslog article re-affirms the JWT agreement from 2008 as captured in RFC 5317. In particular, the IETF standards process will continue to be used for all MPLS-TP architecture and protocol documents. Second,
Re: Plagued by PPTX again
On 11/17/11 4:14 PM, Randy Bush wrote: PDF/a is something browsers and natively by different OSs that can directly display. When submitting formats that are not PDF/a, convert and automatically link to the converted output with a prompt requesting approval. http://www.digitalpreservation.gov/formats/fdd/fdd000125.shtml so where is the web page that tells me for platform x how to convert my generated pdf, which i have been using as the pub format for years, into pdf/a? the link under Guidelines for Creating Archival Quality PDF Files is a broken link. The Florida Center for Library Automation website on the page: http://fclaweb.fcla.edu/content/pdfa-1 Includes a similar link: Guidelines for Creating Archival Quality PDF Files http://fclaweb.fcla.edu/uploads/Lydia%20Motyka/FDA_documentation/PDFGuideline.pdf Don't expect this link will remain stable either. :^( -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Plagued by PPTX again
On Nov 21, 2011, at 4:59 PM, Douglas Otis wrote: On 11/17/11 4:14 PM, Randy Bush wrote: PDF/a is something browsers and natively by different OSs that can directly display. When submitting formats that are not PDF/a, convert and automatically link to the converted output with a prompt requesting approval. http://www.digitalpreservation.gov/formats/fdd/fdd000125.shtml so where is the web page that tells me for platform x how to convert my generated pdf, which i have been using as the pub format for years, into pdf/a? the link under Guidelines for Creating Archival Quality PDF Files is a broken link. The Florida Center for Library Automation website on the page: http://fclaweb.fcla.edu/content/pdfa-1 Includes a similar link: Guidelines for Creating Archival Quality PDF Files http://fclaweb.fcla.edu/uploads/Lydia%20Motyka/FDA_documentation/PDFGuideline.pdf Don't expect this link will remain stable either. :^( Also see the NSF's guide to good PDF at https://www.fastlane.nsf.gov/NSFHelp/flashhelp/fastlane/FastLane_Help/create_pdf_files_introduction.htm -- it gives LaTeX instructions, too. --Steve Bellovin, https://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-6man-exthdr-05.txt (An uniform format for IPv6 extension headers) to Proposed Standard
The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'An uniform format for IPv6 extension headers' draft-ietf-6man-exthdr-05.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 i...@ietf.org mailing lists by 2011-12-05. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the transport layer header. There are a small number of such extension headers currently defined. This document describes the issues that can arise when defining new extension headers and discusses the alternative extension mechanisms in IPv6. It also provides a format for defining new IPv6 extension headers that would allow implementations to process past unknown extension headers. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-6man-exthdr/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-6man-exthdr/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6402 on Certificate Management over CMS (CMC) Updates
A new Request for Comments is now available in online RFC libraries. RFC 6402 Title: Certificate Management over CMS (CMC) Updates Author: J. Schaad Status: Standards Track Stream: IETF Date: November 2011 Mailbox:jim...@augustcellars.com Pages: 37 Characters: 66722 Updates:RFC5272, RFC5273, RFC5274 I-D Tag:draft-ietf-pkix-rfc5272-bis-08.txt URL:http://www.rfc-editor.org/rfc/rfc6402.txt This document contains a set of updates to the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This document updates RFC 5272, RFC 5273, and RFC 5274. The new items in this document are: new controls for future work in doing server side key generation, definition of a Subject Information Access value to identify CMC servers, and the registration of a port number for TCP/IP for the CMC service to run on. [STANDARDS-TRACK] This document is a product of the Public-Key Infrastructure (X.509) Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6403 on Suite B Profile of Certificate Management over CMS
A new Request for Comments is now available in online RFC libraries. RFC 6403 Title: Suite B Profile of Certificate Management over CMS Author: L. Zieglar, S. Turner, M. Peck Status: Informational Stream: IETF Date: November 2011 Mailbox:llzi...@tycho.ncsc.mil, turn...@ieca.com, mp...@alumni.virginia.edu Pages: 16 Characters: 36631 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-turner-suiteb-cmc-03.txt URL:http://www.rfc-editor.org/rfc/rfc6403.txt The United States government has published guidelines for NSA Suite B Cryptography, which defines cryptographic algorithm policy for national security applications. This document specifies a profile of the Certificate Management over CMS (CMC) protocol for managing Suite B X.509 public key certificates. This profile is a refinement of RFCs 5272, 5273, and 5274. This document is not an Internet Standards Track specification; it is published for informational purposes. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6412 on Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence
A new Request for Comments is now available in online RFC libraries. RFC 6412 Title: Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence Author: S. Poretsky, B. Imhoff, K. Michielsen Status: Informational Stream: IETF Date: November 2011 Mailbox:sporet...@allot.com, bimh...@planetspork.com, kmich...@cisco.com Pages: 29 Characters: 51856 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-bmwg-igp-dataplane-conv-term-23.txt URL:http://www.rfc-editor.org/rfc/rfc6412.txt This document describes the terminology for benchmarking link-state Interior Gateway Protocol (IGP) route convergence. The terminology is to be used for benchmarking IGP convergence time through externally observable (black-box) data-plane measurements. The terminology can be applied to any link-state IGP, such as IS-IS and OSPF. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Benchmarking Methodology Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6413 on Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence
A new Request for Comments is now available in online RFC libraries. RFC 6413 Title: Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence Author: S. Poretsky, B. Imhoff, K. Michielsen Status: Informational Stream: IETF Date: November 2011 Mailbox:sporet...@allot.com, bimh...@planetspork.com, kmich...@cisco.com Pages: 42 Characters: 90935 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-bmwg-igp-dataplane-conv-meth-23.txt URL:http://www.rfc-editor.org/rfc/rfc6413.txt This document describes the methodology for benchmarking Link-State Interior Gateway Protocol (IGP) Route Convergence. The methodology is to be used for benchmarking IGP convergence time through externally observable (black-box) data-plane measurements. The methodology can be applied to any link-state IGP, such as IS-IS and OSPF. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Benchmarking Methodology Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6418 on Multiple Interfaces and Provisioning Domains Problem Statement
A new Request for Comments is now available in online RFC libraries. RFC 6418 Title: Multiple Interfaces and Provisioning Domains Problem Statement Author: M. Blanchet, P. Seite Status: Informational Stream: IETF Date: November 2011 Mailbox:marc.blanc...@viagenie.ca, pierrick.se...@orange.com Pages: 22 Characters: 50537 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-mif-problem-statement-15.txt URL:http://www.rfc-editor.org/rfc/rfc6418.txt This document describes issues encountered by a node attached to multiple provisioning domains. This node receives configuration information from each of its provisioning domains, where some configuration objects are global to the node and others are local to the interface. Issues such as selecting the wrong interface to send traffic happen when conflicting node-scoped configuration objects are received and inappropriately used. Moreover, other issues are the result of simultaneous attachment to multiple networks, such as domain selection or addressing and naming space overlaps, regardless of the provisioning mechanism. While multiple provisioning domains are typically seen on nodes with multiple interfaces, this document also discusses situations involving single-interface nodes. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Multiple Interfaces Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6431 on Huawei Port Range Configuration Options for PPP IP Control Protocol (IPCP)
A new Request for Comments is now available in online RFC libraries. RFC 6431 Title: Huawei Port Range Configuration Options for PPP IP Control Protocol (IPCP) Author: M. Boucadair, P. Levis, G. Bajko, T. Savolainen, T. Tsou Status: Informational Stream: Independent Date: November 2011 Mailbox:mohamed.boucad...@orange.com, pierre.le...@orange.com, gabor.ba...@nokia.com, teemu.savolai...@nokia.com, tina.tsou.zout...@huawei.com Pages: 16 Characters: 33981 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-boucadair-pppext-portrange-option-09.txt URL:http://www.rfc-editor.org/rfc/rfc6431.txt This document defines two Huawei IPCP (IP Control Protocol) options used to convey a set of ports. These options can be used in the context of port range-based solutions or NAT-based solutions for port delegation and forwarding purposes. This document is not an Internet Standards Track specification; it is published for informational purposes. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6439 on Routing Bridges (RBridges): Appointed Forwarders
A new Request for Comments is now available in online RFC libraries. RFC 6439 Title: Routing Bridges (RBridges): Appointed Forwarders Author: R. Perlman, D. Eastlake, Y. Li, A. Banerjee, F. Hu Status: Standards Track Stream: IETF Date: November 2011 Mailbox:ra...@alum.mit.edu, d3e...@gmail.com, liyiz...@huawei.com, ayaba...@cisco.com, hu.fang...@zte.com.cn Pages: 15 Characters: 36978 Updates:RFC6325 I-D Tag:draft-ietf-trill-rbridge-af-05.txt URL:http://www.rfc-editor.org/rfc/rfc6439.txt The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides least cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to Intermediate System) link state routing and by encapsulating traffic using a header that includes a hop count. Devices that implement TRILL are called RBridges (Routing Bridges). TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and RBridges attached. Where multiple RBridges are attached to a link, native traffic to and from end stations on that link is handled by a subset of those RBridges called Appointed Forwarders, with the intent that native traffic in each VLAN (Virtual LAN) be handled by at most one RBridge. The purpose of this document is to improve the documentation of the Appointed Forwarder mechanism; thus, it updates RFC 6325. [STANDARDS-TRACK] This document is a product of the Transparent Interconnection of Lots of Links Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6419 on Current Practices for Multiple-Interface Hosts
A new Request for Comments is now available in online RFC libraries. RFC 6419 Title: Current Practices for Multiple-Interface Hosts Author: M. Wasserman, P. Seite Status: Informational Stream: IETF Date: November 2011 Mailbox:m...@painless-security.com, pierrick.se...@orange-ftgroup.com Pages: 21 Characters: 51809 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-mif-current-practices-12.txt URL:http://www.rfc-editor.org/rfc/rfc6419.txt An increasing number of hosts are operating in multiple-interface environments. This document summarizes current practices in this area and describes in detail how some common operating systems cope with challenges that ensue from this context. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Multiple Interfaces Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
