Re: Gen-ART LC Review of draft-ietf-mipshop-mos-dhcp-options-13
Thanks for your review! Authors, can you prepare a new version that addresses these issues? Jari Ben Campbell wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-mipshop-mos-dhcp-options-13 Reviewer: Ben Campbell Review Date: 2009-04-27 IETF LC End Date: 2009-04-27 IESG Telechat date: (if known) Summary: This draft is ready for publication as a proposed standard. I do have a small number of nit comments which may or may not be worth consideration. Major issues: None. Minor issues: None. Nits/editorial comments: -- Section 1, paragraph 6: Please expand MN on first use. (I see you expand it in the following paragraph. It's also in the abstract, but it's worth doing it again in the body.) -- Section 2, sub-opt code table I find it a bit odd to reserve the entire remaining sub-code space with a normative MUST NOT be used, when the IANA section defines a table for it. The fact that you define an IANA table with the standards action criteria seems sufficient. (Note that this applies to the other options in this draft as well.) -- Section 2, last paragraph before the sub-option format diagram: Its minimum length is 4, and the length MUST be a multiple of 4. In case there is no MIH server available, the length is set to 0. I know I'm being pedantic, but technically that means the minimum length is 0. (Note this applies to the IPv6 version as well.) -- idnits reports the following, which I include without prejudice. idnits 2.11.09 tmp/draft-ietf-mipshop-mos-dhcp-options-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): No issues found here. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to http://www.ietf.org/ID-Checklist.html: No issues found here. Miscellaneous warnings: == The document seems to lack a disclaimer for pre-RFC5378 work, but was first submitted before 10 November 2008. Should you add the disclaimer? (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.). Checking references for intended status: Proposed Standard (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 2 warnings (==), 0 comments (--). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Second Last Call: rfc3852 (Cryptographic Message Syntax (CMS)) to Draft Standard
The IESG wrote, On 2009-04-27 06:58 PDT: The IESG has received a request from the smime WG (smime) to consider the following document: - 'Cryptographic Message Syntax (CMS) ' RFC 3852 as a Draft Standard No technical issues were raised during the first Last Call. However, the Last Call failed to highlight two normative references to standards track documents of lower maturity: RFCs 3280 and 3281. lower maturity? Did you perhaps mean greater maturity or lower number ? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Second Last Call: rfc3852 (Cryptographic Message Syntax (CMS)) to Draft Standard
Nelson, I was referring to the maturity level as defined in RFC 2026, not the date of publication. For standards track specifications, Section 4.1 of RFC 2026 states Internet specifications go through stages of development, testing, and acceptance. Within the Internet Standards Process, these stages are formally labeled maturity levels. The three maturity levels for standards track specifications are Proposed Standard (the entry level), Draft Standard, and Standard. As noted in section 4.2.4 of 2026: Note: Standards track specifications normally must not depend on other standards track specifications which are at a lower maturity level or on non standards track specifications other than referenced specifications from other standards bodies. I would like to advance RFC 3852 from Proposed Standard to Draft Standard even though it depends on two standards track specifications with maturity level below that of Draft Standard: RFCs 3280 and 3281, which are both Proposed Standards. This last call is intended to gauge community support for that action. Thanks, Tim Polk On Apr 27, 2009, at 9:46 PM, Nelson B Bolyard wrote: The IESG wrote, On 2009-04-27 06:58 PDT: The IESG has received a request from the smime WG (smime) to consider the following document: - 'Cryptographic Message Syntax (CMS) ' RFC 3852 as a Draft Standard No technical issues were raised during the first Last Call. However, the Last Call failed to highlight two normative references to standards track documents of lower maturity: RFCs 3280 and 3281. lower maturity? Did you perhaps mean greater maturity or lower number ? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Last Call: draft-ietf-dkim-rfc4871-errata (RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update) to Proposed Standard
http://tools.ietf.org/html/draft-ietf-dkim-rfc4871-errata-04 Errata: Original Text: ,--- The tendency is to have the MUA highlight the address associated with this *signing identity* in some way, in an attempt to show the user the address from which the mail was sent. '--- Corrected Text: ,--- The tendency is to have the MUA highlight the SDID, in an attempt to show the user the identity that is claiming responsibility for the message. '--- This text revises the meaning of the original RFC . The over-reaching errata represents an effort to simplify output elements that are obtained from DKIM signatures. This simplification is already in conflict with the recent Authentication-Results header RFC5451, and misrepresents the i= value as an unimportant element contained within the DKIM signature. In addition, when the i=value (AUID) is not present within the signature, it defaults to being the d= value (SDID). Properly corrected without changing definitions or roles, the text could be as follows: ,--- The tendency is to have the MUA highlight the address associated AUID, in some way, in an attempt to show the user the address from which the mail was sent.. '--- or ,--- The tendency is to have the MUA highlight the AUID, in an attempt to show the user the on-behalf-of identity asserted by the authoritative SDID. Please note that the AUID or its default value will always include the SDID, the domain claiming responsibility for the message. '--- Use of the AUID ensures intra-domain sources can be differentiated by recipients. Section 3.5 of the current RFC4871: ,--- d= The domain of the signing entity (plain-text; REQUIRED). This is the domain that will be queried for the public key. This domain MUST be the same as or a parent domain of the i= tag (the signing identity, as described below), or it MUST meet the requirements for parent domain signing described in Section 3.8. When presented with a signature that does not meet these requirement, verifiers MUST consider the signature invalid. '--- Here are some examples that argue against making this errata simplification: Scenario: A domain establishes a mailing-list within a sub-domain of their user domain. The user domain asserts ADSP restrictions based upon the From email-address domain. In the case of a sub-domain use, the Authentication-Results header presently collects the i= value, where the i= value is expected to provide information to assist the MUA with message annotations. A message from the mailing list might signed as follows: Sender: mailing-l...@ml-subd.example.com From: jon@example.com DKIM-Signature: i=mailing-l...@ml-subd.example.com; d=example.com; ... A message from a user within the domain might be signed as follows: From: jon@example.com DKIM-Signature: i=jon@example.com; d=example.com; ... By allowing annotation of the Sender header field when from the Mailing-List versus the From header field when from authenticated users, a recipient can recognize different sources within the domain that might provide different levels of authentication while still purporting to be from the same author. Another example might be: Sender: office-ad...@example.com From: jon@example.com DKIM-Signature: i=office-ad...@example.com; d=example.com; ... Here a message may have been authenticated as being sent by the office- admin on behalf of jon.doe, The DKIM signature indicates it was added on behalf of the office-admin. Another example of a possible valid signatures that might be: Sender:sally@example.com From: jon@example.com DKIM-Signature: i=1234567.rad...@example.com; d=example.com; ... A valid DKIM signature by the SDID verifies that it is authoritative for the namespace used within the AUID. This namespace may not always match against header fields, nor is this namespace assured to always represent valid email-addresses. When the i= value does not match against a signed header field, it may instead represent an internal on- behalf-of identifier. Perhaps the MUA may wish to annotate both header fields, or perhaps none when the Sender header field is not being displayed. Either way, the i= value represents a important output of the DKIM signature header specifically intended for consumption by the MUA as currently stated by RFC4871 and supported by RFC5451. A valid DKIM signature would be analogous to a tamper resistant laminate placed on a driver's license. The signing domain, or SDID, would be analogous to the State issuing the license. The i= value, or AUID, would be analogous to the driver's ID registered with the State. Both the State and the registered driver ID represent critical and essential identifiers. A driver's license lacking any driver ID would be fairly useless whenever there is a need to assess responsibility, and yet the change being made in the errata
Re: Second Last Call: rfc3852 (Cryptographic Message Syntax (CMS)) to Draft Standard
Nelson: The IESG has received a request from the smime WG (smime) to consider the following document: - 'Cryptographic Message Syntax (CMS) ' RFC 3852 as a Draft Standard No technical issues were raised during the first Last Call. However, the Last Call failed to highlight two normative references to standards track documents of lower maturity: RFCs 3280 and 3281. lower maturity? Did you perhaps mean greater maturity or lower number ? ... at a lower rung on the standards-track maturity ladder. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Beyond reproach, accountability and regulation
Here is a dictionary definition of Beyond reproach: Beyond reproach: So good as to preclude any possibility of criticism. Last time I looked, RFC 3777 did not include this definition as a requirement for the nomcom in selection of I* candidates. Good thing, too. We seem to have gotten by with candidates with occasional imperfections over the years. Given the impossibility of populating all leadership positions with individuals beyond reproach, or even defining all potentially problematic behaviors, what is the way forward? How do we move beyond reproach? Years ago, the Direct Marketing Association Nonprofit Federation (of all people) published an article called 'Moving Beyond Reproach' that talks about moving beyond accountability initiatives: http://www.the-dma.org/nonprofitfederation/March2005final.pdf Some quotes: though nonprofits could seemingly drown in the flood of accountability initiatives, there is virtually no support for nonprofit leaders in dealing with actual ethical crises... it is clear that the nonprofit sector can do more good by focusing on ways to provide real support for dealing with actual crises than by trying to abolish them by decree. Some food for thought. == On Wednesday, April 22, 2009 Clint Chaplin said: ...Popper said that it is reasonable to assume that sooner or later some rotten scoundrels will gain power. It's not important who they will be precisely, but whatever your political views might be you must agree that a likelihood of such an event is rather high. So whatever law you want to have in your country, don't ask yourself the question how this law can be used in good hands. Ask the question how this law can be used when the filthiest, dirtiest, stupidest bastards will rule my country (and sooner or later they probably will). Only the law that cannot be used to do anything wrong EVEN by the most vicious ruler is truly good On 4/22/09, Phillip Hallam-baker also wrote: One of the commentators in a recent thread suggested that another person was beyond reproach. That has been worrying me as a security person for a number of reasons. Not least the fact that in my business nobody is ever beyond reproach. For the past eight years the establishment press in this country told us daily that suggesting that the 'president' was not beyond reproach was tantamount to committing treason, It seems to me that many of the social infrastructures that have developed over the years by IETF members suffer from being dependent on being run by individuals who are and must be beyond reproach. That is a very fragile model. If someone is beyond reproach they are beyond accountability. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Beyond reproach, accountability and regulation
Bernard Aboba wrote: Here is a dictionary definition of Beyond reproach: Beyond reproach: So good as to preclude any possibility of criticism. Last time I looked, RFC 3777 did not include this definition as a requirement for the nomcom in selection of I* candidates. Good thing, too. We seem to have gotten by with candidates with occasional imperfections over the years. One might also simply conclude that that the statement that an individual was beyond reproach was baseless or rooted in hyperbole rather than on some epistemological fallacy that asserts that there exist individuals who are beyond reproach. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-geopriv-sip-lo-retransmission (Implications of 'retransmission-allowed' for SIP Location Conveyance) to Informational RFC
The IESG has received a request from the Geographic Location/Privacy WG (geopriv) to consider the following document: - 'Implications of 'retransmission-allowed' for SIP Location Conveyance ' draft-ietf-geopriv-sip-lo-retransmission-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 i...@ietf.org mailing lists by 2009-05-12. 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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-geopriv-sip-lo-retransmission-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17497rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Mobile IPv6 Support for Dual Stack Hosts and Routers' to Proposed Standard
The IESG has approved the following document: - 'Mobile IPv6 Support for Dual Stack Hosts and Routers ' draft-ietf-mext-nemo-v4traversal-10.txt as a Proposed Standard This document is the product of the Mobility EXTensions for IPv6 Working Group. The IESG contact persons are Jari Arkko and Ralph Droms. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-v4traversal-10.txt Technical Summary The current Mobile IPv6 and NEMO specifications support IPv6 only. This specification extends those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the home agent. This specification also allows the Mobile Node to roam over both IPv6 and IPv4, including the case where Network Address Translation is present on the path between the mobile node and its home agent. Working Group Summary This document is a product of the Mobility EXTensions for IPv6 (MEXT) working group. Document Quality Pasi Eronen reviewed the specification and his comments regarding interaction of DSMIPv6 with the IPsec architecture were resolved. Personnel The Document Shepherd for this document is Julien Laganier (MEXT WG co-chair). The Responsible Area Director is Jari Arkko (Internet Area Director). RFC Editor Note Please add the following paragraph to the end of Section 5.4.4: This specification does not support mobile nodes returning home while using IPv4. That is, the IPv4 support is only defined for mobile nodes that are in a visited network. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: Multiple Interfaces (mif)
A new IETF working group has been formed in the Internet Area. For additional information, please contact the Area Directors or the WG Chairs. Multiple Interfaces (mif) --- Current Status: Active Working Group Chairs: Margaret Wasserman m...@lilacglade.org Hui Deng denghu...@hotmail.com Internet Area Directors: Ralph Droms rdr...@cisco.com Jari Arkko jari.ar...@piuha.net Internet Area Advisor: Jari Arkko jari.ar...@piuha.net Mailing Lists: General Discussion: m...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mif Archive: http://www.ietf.org/mail-archive/web/mif Description of Working Group: Many hosts have the ability to attach to multiple networks simultaneously. This can happen over multiple physical network interfaces, a combination of physical and virtual interfaces (VPNs or tunnels), or even indirectly through multiple default routers being on the same link. For instance, current laptops and smartphones typically have multiple access network interfaces. A host attached to multiple networks has to make decisions about default router selection, address selection, DNS server selection, choice of interface for packet transmission, and the treatment of configuration information received from the various networks. Some configuration objects are global to the node, some are local to the interface, and some are related to a particular prefix. Various issues arise when contradictory configuration objects that are global to the node are received on different interfaces. At best, decisions about these matters have an efficiency effect. At worst, they have more significant effects such as security impacts, or even lead to communication not being possible at all. A number of operating systems have implemented various techniques to deal with attachments to multiple networks. Some devices employ only one interface at a time and some allow per-host configuration of preferences between the interfaces but still use just one at a time. Other systems allow per-application preferences or implement sophisticated policy managers that can be configured by users or controlled externally. The purpose of the MIF working group is to describe the issues of attaching to multiple networks on hosts and document existing practice. The group shall also analyze the impacts and effectiveness of these existing mechanisms. The WG shall employ and refer to existing IETF work in this area, including, for instance, strong/weak models (RFC 1122), address selection (RFC 3484), ICE and other mechanisms higher layers can use for address selection, DHCP mechanisms, Router Advertisement mechanisms, and DNS recommendations. The focus of the working group should be on documenting the system level effects to host IP stacks and identification of gaps between the existing IETF recommendations and existing practice. The working group shall address both IPv4 and IPv6 as well as stateless and stateful configuration. Network discovery and selection on lower layers as defined by RFC 5113 is out of scope. Also, the group shall not develop new protocol or policy mechanisms; recommendations and gap analysis from the group are solely based on existing solutions. The group shall not assume any software beyond basic IP protocol support on its peers or in network nodes. No work will be done to enable traffic flows to move from one interface to another. The group recognizes existing work on mechanisms that require peer or network support for moving traffic flows such as RFC 5206, RFC 4980 and the use of multiple care-of addresses in Mobile IPv6. This group does not work on or impact such mechanisms. Once the group has completed its work items, the IETF can make an informed decision about rechartering the working group to define new mechanisms or asking other, specialized working groups (such as DHC or 6MAN) to deal with specific issues. Goals and Milestones: May 2009 WG chartered Jul 2009 Initial draft on problem statement adopted by the WG Sep 2009 Initial draft on existing practices adopted by the WG Dec 2009 Initial draft on analysis of existing practices adopted by the WG Mar 2010 Problem statement draft submitted to the IESG for publication as an Informational RFC Jul 2010 Existing practices draft submitted to the IESG for publication as an Informational RFC Sep 2010 Analysis draft submitted to the IESG for publication as an Informational RFC Oct 2010 Recharter or close ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Internet Calendaring and Scheduling Core Object Specification (iCalendar)' to Proposed Standard
The IESG has approved the following document: - 'Internet Calendaring and Scheduling Core Object Specification (iCalendar) ' draft-ietf-calsify-rfc2445bis-10.txt as a Proposed Standard This document is the product of the Calendaring and Scheduling Standards Simplification Working Group. The IESG contact persons are Lisa Dusseault and Alexey Melnikov. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2445bis-10.txt Technical Summary This document defines the iCalendar data format for representing and exchanging calendaring and scheduling information such as events, to-dos, journal entries and free/busy information, independent of any particular calendar service or protocol. Working Group Summary The working group proceeded with the work in an orderly fashion, opening tickets for all the found issues in the original RFC2445, and then systematically closing them until no known issues remained. Document Quality There are a number of existing implementations of the original RFC2445 specification that are likely to upgrade their implementation to the new specification. During the process of developing this document, the CalConnect.org industry consortium provided various types of vendor feedback and errata over the original specification. The working group took special care to take into account this feedback as well as the feedback received from a number of other contributors, some of which are also mentioned in the document's Acknowledgements section. Personnel Document Shepherd: Aki Niemi aki.ni...@nokia.com Responsible AD: Lisa Dusseault l...@osafoundation.org The IANA Expert(s) for the registries in this document are Cyrus Daboo and Bernard Desruisseaux. Note to RFC Editor Please ensure that the ABNF is valid, including semi-colons or explicit spaces in empty lines within rules. OLD in section 3.2.19: The parameter MUST be specified on properties with a DATE-TIME value if the DATE-TIME is not either a UTC or a floating time. NEW: The parameter MUST be specified on properties with a DATE-TIME value if the DATE-TIME is not either a UTC or a floating time. Failure to include and follow VTIMEZONE definitions in iCalendar objects may lead to inconsistent understanding of the local time at any given location. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'BGP IPsec Tunnel Encapsulation Attribute' to Proposed Standard
The IESG has approved the following document: - 'BGP IPsec Tunnel Encapsulation Attribute ' draft-ietf-softwire-encaps-ipsec-03.txt as a Proposed Standard This document is the product of the Softwires Working Group. The IESG contact persons are Ralph Droms and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-encaps-ipsec-03.txt Technical Summary The BGP Encapsulation Subsequence Address Family Identifiers (SAFI) provides a method for the dynamic exchange of encapsulation information, and the indication of encapsulation protocol types to be used for different next hops. Currently support for GRE and L2TPv3 tunnel types are defined. This document defines support for IPsec tunnel types. Working Group Summary The SOFTWIRE WG supports the development and advancement of this document. Protocol Quality This document was thoroughly reviewed by WG chairs and WG members, including those with expertise in IPv4 to IPv6 transitions and interworking. Dave Ward is the WG chair shepherd. Ralph Droms is the responsible Area director. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: Locator/ID Separation Protocol (lisp)
A new IETF working group has been formed in the Internet Area. For additional information, please contact the Area Directors or the WG Chairs. Locator/ID Separation Protocol (lisp) -- Last Modified: 2009-04-23 Current status: Working Group Chair(s): Sam Hartman hartmans-i...@mit.edu Darrel Lewis darle...@cisco.com Internet Area Director(s): Jari Arkko jari.ar...@piuha.net Ralph Droms rdr...@cisco.com Internet Area Advisor: Jari Arkko jari.ar...@piuha.net Technical Advisor(s): Joel Halpern j...@joelhalpern.com Mailing Lists: General Discussion: l...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lisp Archive: http://www.ietf.org/mail-archive/web/lisp/current/maillist.html Description of Working Group: The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) rekindled interest in scalable routing and addressing architectures for the Internet. Among the many issues driving this renewed interest are concerns about the scalability of the routing system and the impending exhaustion of the IPv4 address space. Since the IAB workshop, several proposals have emerged which attempt to address the concerns expressed there and elsewhere. In general, these proposals are based on the locator/identifier separation. The basic idea behind the separation is that the Internet architecture combines two functions, routing locators, (where you are attached to the network) and identifiers (who you are) in one number space: The IP address. Proponents of the separation architecture postulate that splitting these functions apart will yield several advantages, including improved scalability for the routing system. The separation aims to decouple locators and identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the identifier space. LISP supports the separation of the IPv4 and IPv6 address space following a network-based map-and-encapsulate scheme (RFC 1955). In LISP, both identifiers and locators are IP addresses. In LISP, identifiers are composed of two parts: a global portion that uniquely identifies a particular site and a local portion that identifies an interface within a site. The local portion may be subdivided to identify a particular network within the site. For a given identifier, LISP maps the global portion of the identifier into a set of locators that can be used by de-capsulation devices to reach the identified interface; as a consequence a host would typically change identifiers when it moves from one site to another or whenever it moves from one subnet to another within an site. Typically, the same IP address will not be used as an identifier and locator in LISP. LISP requires no changes to end-systems or to most routers. LISP aims for an incrementally deployable protocol. A number of approaches are being looked at in parallel in the IRTF and IETF. At this time, these proposals are at an early stage. All proposals (including LISP) have potentially harmful side-effects to Internet traffic carried by the involved routers, have parts where deployment incentives may be lacking, and are NOT RECOMMENDED for deployment beyond experimental situations at this stage. Many of the proposals have components (such as the identifier to locator mapping system) where it is not yet known what kind of design alternative is the best one among many. However, despite these issues it would be valuable to write concrete protocol specifications and develop implementations that can be used to understand the characteristics of these designs. The LISP WG is chartered to work on the LISP base protocol (draft-farinacci-lisp-12.txt), the LISP+ALT mapping system (draft-fuller-lisp-alt-05.txt), LISP Interworking (draft-lewis-lisp-interworking-02.txt), LISP Map Server (draft-fuller-lisp-ms-00.txt), and LISP multicast (draft-farinacci-lisp-multicast-01.txt) for these purposes, with the given drafts as a starting point. The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems. The Working Group will also develop security profiles for the ALT and/or other mapping systems. It is expected that the results of specifying, implementing, and testing LISP will be fed to the general efforts at the IETF and IRTF (e.g., the Routing Research Group) that attempts to understand which type of a solution is optimal. The LISP WG is NOT chartered to develop the final or standard solution for solving the routing scalability problem. Its specifications are Experimental and labeled with accurate disclaimers about their limitations and not fully understood implications for Internet traffic. In addition, as these issues are understood, the working group will analyze and document the implications of LISP on Internet traffic, applications, routers, and security. This analysis will explain what role LISP can play in scalable routing. The
75th IETF - Hotels
75th IETF Meeting Stockholm, Sweden July 26-31, 2009 Host: .SE Be sure to make your reservation at one of the four Stockholm hotels where we have a block of rooms held. Cut-off dates for release of our block are earlier than usual. Hotel information can be found at: http://www.ietf.org/meetings/75/hotels.html Only 89 days until the Stockholm IETF! ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5510 on Reed-Solomon Forward Error Correction (FEC) Schemes
A new Request for Comments is now available in online RFC libraries.
RFC 5510
Title: Reed-Solomon Forward Error Correction (FEC)
Schemes
Author: J. Lacan, V. Roca,
J. Peltotalo, S. Peltotalo
Status: Standards Track
Date: April 2009
Mailbox:jerome.la...@isae.fr,
vincent.r...@inria.fr,
jani.peltot...@tut.fi, sami.peltot...@tut.fi
Pages: 28
Characters: 57493
Updates/Obsoletes/SeeAlso: None
I-D Tag:draft-ietf-rmt-bb-fec-rs-05.txt
URL:http://www.rfc-editor.org/rfc/rfc5510.txt
This document describes a Fully-Specified Forward Error Correction
(FEC) Scheme for the Reed-Solomon FEC codes over GF(2^^m), where m is
in {2..16}, and its application to the reliable delivery of data
objects on the packet erasure channel (i.e., a communication path
where packets are either received without any corruption or discarded
during transmission). This document also describes a Fully-Specified
FEC Scheme for the special case of Reed-Solomon codes over GF(2^^8)
when there is no encoding symbol group. Finally, in the context of
the Under-Specified Small Block Systematic FEC Scheme (FEC Encoding
ID 129), this document assigns an FEC Instance ID to the special case
of Reed-Solomon codes over GF(2^^8).
Reed-Solomon codes belong to the class of Maximum Distance Separable
(MDS) codes, i.e., they enable a receiver to recover the k source
symbols from any set of k received symbols. The schemes described
here are compatible with the implementation from Luigi Rizzo.
[STANDARDS TRACK]
This document is a product of the Reliable Multicast Transport 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
USC/Information Sciences Institute
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5511 on Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications
A new Request for Comments is now available in online RFC libraries. RFC 5511 Title: Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications Author: A. Farrel Status: Standards Track Date: April 2009 Mailbox:adr...@olddog.co.uk Pages: 14 Characters: 27026 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-farrel-rtg-common-bnf-09.txt URL:http://www.rfc-editor.org/rfc/rfc5511.txt Several protocols have been specified in the Routing Area of the IETF using a common variant of the Backus-Naur Form (BNF) of representing message syntax. However, there is no formal definition of this version of BNF. There is value in using the same variant of BNF for the set of protocols that are commonly used together. This reduces confusion and simplifies implementation. Updating existing documents to use some other variant of BNF that is already formally documented would be a substantial piece of work. This document provides a formal definition of the variant of BNF that has been used (that we call Routing BNF) and makes it available for use by new protocols. [STANDARDS TRACK] 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 USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5520 on Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism
A new Request for Comments is now available in online RFC libraries. RFC 5520 Title: Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism Author: R. Bradford, Ed., JP. Vasseur, A. Farrel Status: Standards Track Date: April 2009 Mailbox:rbrad...@cisco.com, j...@cisco.com, adr...@olddog.co.uk Pages: 19 Characters: 43125 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-pce-path-key-05.txt URL:http://www.rfc-editor.org/rfc/rfc5520.txt Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. However, in some cases (e.g., when ASes are administered by separate Service Providers), it would break confidentiality rules for a PCE to supply a path segment to a PCE in another domain, thus disclosing AS-internal topology information. This issue may be circumvented by returning a loose hop and by invoking a new path computation from the domain boundary Label Switching Router (LSR) during TE LSP setup as the signaling message enters the second domain, but this technique has several issues including the problem of maintaining path diversity. This document defines a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS). The CPS may be replaced by a path-key that can be conveyed in the PCE Communication Protocol (PCEP) and signaled within in a Resource Reservation Protocol TE (RSVP-TE) explicit route object. [STANDARDS TRACK] This document is a product of the Path Computation Element 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 USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5521 on Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions
A new Request for Comments is now available in online RFC libraries. RFC 5521 Title: Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions Author: E. Oki, T. Takeda, A. Farrel Status: Standards Track Date: April 2009 Mailbox:o...@ice.uec.ac.jp, takeda.tomon...@lab.ntt.co.jp, adr...@olddog.co.uk Pages: 16 Characters: 36294 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-pce-pcep-xro-06.txt URL:http://www.rfc-editor.org/rfc/rfc5521.txt The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering (TE) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. When a Path Computation Client (PCC) requests a PCE for a route, it may be useful for the PCC to specify, as constraints to the path computation, abstract nodes, resources, and Shared Risk Link Groups (SRLGs) that are to be explicitly excluded from the computed route. Such constraints are termed route exclusions. The PCE Communication Protocol (PCEP) is designed as a communication protocol between PCCs and PCEs. This document presents PCEP extensions for route exclusions. [STANDARDS TRACK] This document is a product of the Path Computation Element 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 USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
