Last Call: 'Softwire Problem Statement' to Informational RFC (draft-ietf-softwire-problem-statement)
The IESG has received a request from the Softwires WG to consider the following document: - 'Softwire Problem Statement ' draft-ietf-softwire-problem-statement-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 any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-09-28. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-softwire-problem-statement-02.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field' to BCP
The IESG has approved the following document: - 'Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field ' draft-ietf-tsvwg-ecn-alternates-02.txt as a BCP This document is the product of the Transport Area Working Group Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-ecn-alternates-02.txt Technical Summary This document discusses how alternate semantics of the ECN field can co-exist where not all routers in a network are configured for a single interpretation of codepoints. Also discussed are the issues raised by nodes, including endsystems, configured for alternate-ECN usages. This document can be used as a means of migration from one alternate-ECN to another, where not all nodes can be configured to change at the same time. Additionally, means for a node (router) to determine which alternate to use with which packet is specified. And finally, this document discusses how well alternate-ECN traffic performs where it co-exists with competing traffic on a path. Working Group Summary There is strong consensus in the WG to publish this document. It has been reviewed by several people prior to the WG last call. Comments raised earlier have all been addressed. There are no outstanding open issues wrt this document. Protocol Quality This document has been well reviewed in the WG and comments raised have been addressed. James Polk ([EMAIL PROTECTED]) has acted as PROTO Document Shepherd for this document. Lars Eggert ([EMAIL PROTECTED]) has reviewed this document for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4641 on DNSSEC Operational Practices
A new Request for Comments is now available in online RFC libraries. RFC 4641 Title: DNSSEC Operational Practices Author: O. Kolkman, R. Gieben Status: Standards Track Date: September 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 35 Characters: 79894 Obsoletes: RFC2541 See-Also: I-D Tag:draft-ietf-dnsop-dnssec-operational-practices-08.txt URL:http://www.rfc-editor.org/rfc/rfc4641.txt This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies. This document obsoletes RFC 2541, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the new DNSSEC specification. This memo provides information for the Internet community. This document is a product of the Domain Name System Operations 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
