Re: [IAB] Last Call: Modern Global Standards Paradigm
On 13/08/2012 04:03, Michael StJohns wrote: ... We've - collectively, through process established over many years - selected a team of our colleagues to perform a circumscribed set of tasks. Efficiency suggests we should mostly stand back and let them get on with it. At the risk of being at the top of the next Narten list, I can't help adding that in the matter of liaison with other SDOs, our process formally states that the IAB acts as representative of the interests of the IETF and the Internet Society. (See the same clause of BCP 39 that I cited yesterday.) Brian
Re: Last Call: Modern Global Standards Paradigm
On Aug 11, 2012, at 2:55 AM, Bob Hinden wrote: I support the IETF and IAB chairs signing document. +1 --Alain Bob On Aug 10, 2012, at 8:19 AM, IETF Chair wrote: The IETF Chair and the IAB Chair intend to sign the Affirmation of the Modern Global Standards Paradigm, which can be found here: http://www.ietf.org/proceedings/84/slides/slides-84-iesg-opsplenary-15.pdf An earlier version was discussed in plenary, and the IAB Chair called for comments on the IETF mail list. This version includes changes that address those comments. Th IETF 84 Administrative plenary minutes have been posted, so that discussion can be reviewed if desired. The minutes are here: http://www.ietf.org/proceedings/84/minutes/minutes-84-iesg-opsplenary On 8 August 2012, the IEEE Standards Association Board of Governors approved this version of the document. The approval process is underway at the W3C as well. The IETF Chair and the IAB Chair intend to sign the Affirmation in the next few weeks. Please send strong objections to the i...@iab.org and the ietf@ietf.org mailing lists by 2012-08-24. Thank you, Russ Housley IETF Chair
Re: [iucg] Last Call: Modern Global Standards Paradigm
On Mon 13/Aug/2012 03:22:52 +0200 JFC Morfin wrote: At 19:16 11/08/2012, John C Klensin wrote: On the other hand, irrational behavior would be nothing new in this area so I can't disagree with the possibility. Correct. This is why, if I understand the motivation, I strongly disagree with the wording of the document and your evaluation of the situation. The US/IETF rationale being used is disagreed by non-US related industries and most probably by every Government (including the USG) because it looks like SDOs wanted to decide alone, based upon market results, about the standards for the people they represent. FWIW, I'd like to recall that several governments endorse IETF protocols by establishing Internet based procedures for official communications with the relevant PA, possibly giving them legal standing. Francesco Gennai presented a brief review of such procedures[*] at the APPSAWG meeting in Paris. At the time, John Klensin suggested that, while a more in-depth review of existing practices would be appreciated, the ITU is a more suitable body for the standardization of a unified, compatible protocol for certified email, because of those governmental involvements. [*] http://www.ietf.org/proceedings/83/slides/slides-83-appsawg-1.pdf
Re: Last Call: draft-ietf-intarea-ipv4-id-update-05.txt (Updated Specification of the IPv4 ID Field) to Proposed Standard
Joe Touch wrote: Again, this doc is about updating the IPv4 ID specification in RFC791 - which has not yet been updated. But, the way you update rfc791 requires updating rfc2460, rfc2765 and their implementations, for which there is no consensus. That is, though your draft claims to more closely reflect current practice and more closely match IPv6, the way you update rfc791 does not reflect current practice nor match IPv6. As your draft states: it is clear that existing systems violate the current specification and rfc2026 states: 4.1.3 Internet Standard A specification for which significant implementation and successful operational experience has been obtained may be elevated to the Internet Standard level. there is no point to insist on the ID uniqueness requirement of rfc791 as a requirement of an Internet Standard. The IPv6-IPv4 translation that creates IPv4 IDs is currently non-compliant with RFC791 and does not override RFC791. This document's update might make that translation easier, Wrong. Insisting on rfc791 makes the translation a lot harder than just closely reflect current practice to loosen uniqueness request of rfc791, which is what almost all (if not all) the IPv4 and IPv6 implementations today are doing. If you disagree with that conclusion, please contact the INTAREA WG chairs directly. As we are in IETF last call stage, I can see no point you insist on the original conclusion of the WG, which overlooked the complication caused by 6-4 translation. Masataka Ohta
Re: Last Call: draft-ietf-intarea-ipv4-id-update-05.txt (Updated Specification of the IPv4 ID Field) to Proposed Standard
On 8/13/2012 2:45 AM, Masataka Ohta wrote: Joe Touch wrote: Again, this doc is about updating the IPv4 ID specification in RFC791 - which has not yet been updated. But, the way you update rfc791 requires updating rfc2460, rfc2765 and their implementations, for which there is no consensus. It certainly does not. That is, though your draft claims to more closely reflect current practice and more closely match IPv6, the way you update rfc791 does not reflect current practice nor match IPv6. It does - it doesn't reflect the errors in IPv6-IPv4 translation, which is not IPv6. Joe
Re: [IAB] Last Call: Modern Global Standards Paradigm
Hi Dave, I agree that procedure of ietf processes should be respected and followed by all, and/or community should understand such difference in process before asked its opinion. I hope your comments will be considered by IETF and IAB in the future. thanking you for your comments, AB -- From: Dave Crocker dcrocker at bbiw.net To: Barry Leiba barryleiba at computer.org Cc: IAB iab at iab.org, IETF ietf at ietf.org Date: Sun, 12 Aug 2012 08:50:10 -0700 Two weeks is normal process for spontaneous consensus calls? When did the community approve that change in process? No he didn't: Please send strong objections... This asserts a forceful bias against general comments and criticisms by establishing a very high threshhold for relevance. While no, no one is prevented from other kinds of postings, the bias is nonetheless established. Note that he didn't ask for support, although explicit support statements are exactly what is required for IETF consensus calls, absent a history to justify the kind of default yes assumption made in the announcement. We don't have any such documented history for this effort. Would any of us guess that the community would support the document? Sure. But guessing isn't the point. That folks have chosen to ignore the stricture specified in the announcement and to post public support shows how deeply ingrained our model is. And, yeah, enough such postings overwhelm problems with the last call wording... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: [iucg] Last Call: Modern Global Standards Paradigm
--On Monday, August 13, 2012 11:11 +0200 Alessandro Vesely ves...@tana.it wrote: ... FWIW, I'd like to recall that several governments endorse IETF protocols by establishing Internet based procedures for official communications with the relevant PA, possibly giving them legal standing. Francesco Gennai presented a brief review of such procedures[*] at the APPSAWG meeting in Paris. At the time, John Klensin suggested that, while a more in-depth review of existing practices would be appreciated, the ITU is a more suitable body for the standardization of a unified, compatible protocol for certified email, because of those governmental involvements. [*] http://www.ietf.org/proceedings/83/slides/slides-83-appsawg-1.pdf Alessandro, Please be a little careful about context, as your sequence of comments above could easily be misleading. For the very specific case of email certified by third parties, especially where there is a requirement for worldwide recognition (the topic of the talk and slides you cited), the biggest problem has, historically, been an administrative and policy one, not a technical standards issue. We know how to digitally sign email in several different ways -- there is actually no shortage of standards. While additional standards are certainly possible, more options in the absence of compelling need almost always reduces practical interoperability. Perhaps the key question in the certified mail matter is who does the certifying and why anyone else should pay attention. The thing that makes that question complicated was famously described by Jeff Schiller (I believe while he was still IETF Security AD) when he suggested that someone would need to be insane to issue general-purpose certificates that actually certified identity unless they were an entity able to invoke sovereign immunity, i.e., a government. For certified email (or certified postal mail), your ability to rely on the certification in, e.g., legal matters ultimately depends on your government being willing to say something to you like if you rely on this in the following ways, we will protect you from bad consequences if it wasn't reliable or accurate. If you want the same relationship with foreign mail, you still have to rely on your government's assertions since a foreign government can't do a thing for you if you get into trouble. That, in turn, requires treaties or some sort of bilateral agreements between the governments (for postal mail, some of that is built into the postal treaties). International organizations, particularly UN-based ones, can serve an important role in arranging such agreements and possibly even in being the repository organization for the treaties. In the particular case of certified email, the ITU could reasonably play that role (although it seems to me that a very strong case could be made for having the UPU do it instead by building on existing foundations). But that has nothing to do with the development of technical protocol standards. Historical experience with development of technical standards by governmental/legislative bodies that then try to mandate their use has been almost universally poor and has often included ludicrous results. A similar example arises with the spam problem. There are many technical approaches to protecting the end user from spam (especially malicious spam) and for facilitating the efforts of mail delivery service providers and devices to apply those protective mechanisms. Some of them justify technical standards that should be worked out in open forums that make their decisions on open and technical bases. But, if one wants to prevent spam from imposing costs on intended recipients or third parties, that becomes largely a law-making and law enforcement problem, not a technical one. If countries decide that they want to prevent spam from being sent, or to punish the senders, a certain amount of international cooperation (bilateral or multilaterial) is obviously going to be necessary. As with the UPU and email certification, there might be better agencies or forums for discussion than the ITU or there might not. But it isn't a technical protocol problem that the IETF is going to be able to solve or should even try to address, at least without a clear and actionable problem statement from those bodies. I do believe that the ITU can, and should, serve a useful role in the modern world. The discussion above (and some of the work of the Development and Radio Sectors) are good illustrations. But those cases have, as far as I can tell, nothing to do with the proposed statement, which is about the development and deployment of technical protocol standards. regards, john
Gen-ART LC review of draft-ietf-ccamp-rfc5787bis-05
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-ccamp-rfc5787bis-05. Reviewer: Roni Even Review Date:2012-8-12 IETF LC End Date: 2012-8-17 IESG Telechat date: Summary: This draft is almost ready for publication as a standard track RFC. Major issues: Minor issues: In section 6.1 If specified more than once, instances preceding the first will be ignored and condition SHOULD be logged for possible action by the network operator. I am not sure what is meant by preceding the first. Nits/editorial comments: 1. The following note appears in section 10.1, 10.2 and 10.3. Note that the same values for the Inter-RA Export Upward sub-TLV and the Inter-RA Export Downward Sub-TLV MUST be used when they appear in the Link TLV, Node Attribute TLV, and Router Address TLV. - why not have it in section 10 before section 10.1. 2. I saw in appendix B that one of the changes from RFC 5787 was to clarify the terminology before defining extensions, I would have found it easier to read if the ASON hierarchy and the relation to OSPF in section 2 were presented in figures. This was more an issue to me as a reader not familiar with the terminology and I would like to think that the more familiar reader will not have problem.
Re: [Gen-art] Gen-ART LC Review of draft-ietf-mptcp-api-05
On Aug 13, 2012, at 9:14 AM, philip.eard...@bt.com wrote: Ben, Thanks for your review. The right status isn't clear-cut (I think), but when we (Chairs Wes) discussed it, Info seemed best * mainly because precedent seems to be that API docs are informational, for example socket API extensions for SCTP http://datatracker.ietf.org/doc/rfc6458/ I'm willing to accept that there is precedent for doing this in an informational. (I wonder about the rational used previously, but that's probably neither here nor there.) * also the doc has two main parts - looking at the impact that MPTCP may have on application performance - and describing a basic API for MPTCP-aware applications. The first part seems clearly Informational. So if the API part is not Info, there is the effort of splitting the doc. Pragmatically I think this should only be done if clearly needed. Agreed. I'm afraid I don't know case history of how the IETF tries to extend non-IETF standards. On the status of Posix reference, which appears twice in the doc The abstract specification is in line with the Posix standard [17] as much as possible One commonly used TCP socket option (TCP_NODELAY) disables the Nagle algorithm as described in [2]. This option is also specified in the Posix standard [17]. The guidance: Normative references specify documents that must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work. On its second appearance, I think [17] is definitely being used informatively. The first appearance is less clear cut, I think. Am inclined to say this is still informative - it's just explaining the style adopted for the abstract specification (if [17] changed then it wouldn't be necessary to change this doc). Agree that the 2nd appearance is informational. But the paragraph containing the first citation also contains the language The de facto standard API for TCP/IP applications is the sockets interface. This document provides an abstract definition of MPTCP-specific extensions to this interface. It seems to me that one needs to understand the sockets api in order to understand an extension to the sockets api. . (And, as an additional nit, the first quoted sentence could probably also use a citation to [17]) Thanks also for the nits You're welcome :-) Thanks! Ben.
RE: Re: [IAB] Last Call: Modern Global Standards Paradigm
+1 Well said Mike. For what its worth I completely and unconditionally support the signing of the document on behalf of the entire IETF community. This support is personal and does not represent any official position of the SIP Forum its full members or its board. But if we were asked . It is totally clear to me that the WCIT process represents a substantive threat to the multistake holder process in standards development that has made the IETF and the Internet work. What is horrifying to me as well is this idea of mandatory ITU based protocol certification testing. The ITU has ZERO business imposing this requirement on nation states. Our Industry deals with compliance and certification testing in its own way without government sanctioned intervention. Weve seen this class of threat before multiple times over the past decade. Hopefully this will pass but it will certainly come up again and again. Vigilance Vigilance. Though our focus has been pure engineering we cannot ignore the forces building up to demand a return to some form of intergovernmental control of global communications. We won! Now the forces of darkness say .. well if its going to deal with SIP/IMS telephony ( voice ) well it has to be regulated! Right ..!! Wrong .. Granted the European PTTs are not helping here with totally absurd ideas about abandoning the privately negotiated transit peering model with some form of data sender pays abomination because they cant figure out their business models. Now they first had a Whine and Cheese party in Brussels , but getting no satisfaction there they now go to the UN to support their untenable position. Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 mailto:richard(at)shockey.us skype-linkedin-facebook: rshockey101 http//www.sipforum.org From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Michael StJohns Sent: Sunday, August 12, 2012 11:03 PM To: Glen Zorn; ietf@ietf.org Subject: Re: Re: [IAB] Last Call: Modern Global Standards Paradigm Glen and others - I wanted to go back and comment on the assertion that Glen made that the IETF and IAB chairs do not 'represent' [him] or any one other than themselves. I believe he is correct with respect to himself, and incorrect with respect to the IETF. I agree the IETF is not a representative democracy, the IESG and IAB (and not the IETF) are probably best described as electoral meritocracies. We randomly select electors from a qualified pool which self-selects mostly from the set of all participants which in turn selects the IESG and the IAB from that set of all participants. I'm pretty sure that Carsten was using elect to describe that process. While the IESG and IAB may not speak for the IETF participants, they de facto and de jure do speak for the IETF. It's a subtle difference, but an important one. [CF the various RFCs detailing the responsibilities and duties of the IESG, IAB and their respective chairs, the RFCs detailing the standards process, and the various liaison's that have been arranged over the years.] I've noted over the years that the constituency of IETF participants tends to have bouts with BSDS - back seat driver syndrome, and this is mostly not helpful. We (referring to the broad set of IETF participants going back 25+ years) have over time evolved and agreed upon various ways of moving forward for generally accepted values of forward. Those ways include having granted the IESG the power to set the standards agenda, the IAB to negotiate and approve liaison agreements with standards bodies, the IESG to ultimately approve the standards, and the IESG, IETF Chair and IAB chair to declare a perception of consensus. We (the participants) have reserved to ourselves the rights jointly and severally to comment on all of the above, to be heard on even items delegated to the IESG and IAB and at times to carp and cavil on every single point of order. Some of this is good for the process. But we go too far way too often. In this case, the IAB, IESG and their respective chairs are doing the jobs we've asked them to do. Russ, correctly I believe, asked for objections to the issuance of such statement, he didn't ask for consensus. I also believe it would have been well within the current job description of the IAB and IETF Chairs to just go ahead and sign the thing. I think it comes down to this: If you (an IETF participant) have an objection to the statement, make it here. If you have an objection to the process in general then - form your objections, write an ID, and socialize what you want changed. If consensus shows you correct, it will apply down the line. If you have a belief that the process has been violated, it's appropriate to make that point, but give details rather than vague intimations. If you have an objection related to the members of the IESG or IAB performance, make them to the
Re: [iucg] Last Call: Modern Global Standards Paradigm
+1. The ITU is not evil. It just is not the right place for Internet standards development. As John points out, there are potential uses of the ITU-T for good. On Aug 13, 2012, at 10:50 AM, John C Klensin wrote: --On Monday, August 13, 2012 11:11 +0200 Alessandro Vesely ves...@tana.it wrote: ... FWIW, I'd like to recall that several governments endorse IETF protocols by establishing Internet based procedures for official communications with the relevant PA, possibly giving them legal standing. Francesco Gennai presented a brief review of such procedures[*] at the APPSAWG meeting in Paris. At the time, John Klensin suggested that, while a more in-depth review of existing practices would be appreciated, the ITU is a more suitable body for the standardization of a unified, compatible protocol for certified email, because of those governmental involvements. [*] http://www.ietf.org/proceedings/83/slides/slides-83-appsawg-1.pdf Alessandro, Please be a little careful about context, as your sequence of comments above could easily be misleading. For the very specific case of email certified by third parties, especially where there is a requirement for worldwide recognition (the topic of the talk and slides you cited), the biggest problem has, historically, been an administrative and policy one, not a technical standards issue. We know how to digitally sign email in several different ways -- there is actually no shortage of standards. While additional standards are certainly possible, more options in the absence of compelling need almost always reduces practical interoperability. Perhaps the key question in the certified mail matter is who does the certifying and why anyone else should pay attention. The thing that makes that question complicated was famously described by Jeff Schiller (I believe while he was still IETF Security AD) when he suggested that someone would need to be insane to issue general-purpose certificates that actually certified identity unless they were an entity able to invoke sovereign immunity, i.e., a government. For certified email (or certified postal mail), your ability to rely on the certification in, e.g., legal matters ultimately depends on your government being willing to say something to you like if you rely on this in the following ways, we will protect you from bad consequences if it wasn't reliable or accurate. If you want the same relationship with foreign mail, you still have to rely on your government's assertions since a foreign government can't do a thing for you if you get into trouble. That, in turn, requires treaties or some sort of bilateral agreements between the governments (for postal mail, some of that is built into the postal treaties). International organizations, particularly UN-based ones, can serve an important role in arranging such agreements and possibly even in being the repository organization for the treaties. In the particular case of certified email, the ITU could reasonably play that role (although it seems to me that a very strong case could be made for having the UPU do it instead by building on existing foundations). But that has nothing to do with the development of technical protocol standards. Historical experience with development of technical standards by governmental/legislative bodies that then try to mandate their use has been almost universally poor and has often included ludicrous results. A similar example arises with the spam problem. There are many technical approaches to protecting the end user from spam (especially malicious spam) and for facilitating the efforts of mail delivery service providers and devices to apply those protective mechanisms. Some of them justify technical standards that should be worked out in open forums that make their decisions on open and technical bases. But, if one wants to prevent spam from imposing costs on intended recipients or third parties, that becomes largely a law-making and law enforcement problem, not a technical one. If countries decide that they want to prevent spam from being sent, or to punish the senders, a certain amount of international cooperation (bilateral or multilaterial) is obviously going to be necessary. As with the UPU and email certification, there might be better agencies or forums for discussion than the ITU or there might not. But it isn't a technical protocol problem that the IETF is going to be able to solve or should even try to address, at least without a clear and actionable problem statement from those bodies. I do believe that the ITU can, and should, serve a useful role in the modern world. The discussion above (and some of the work of the Development and Radio Sectors) are good illustrations. But those cases have, as far as I can tell, nothing to do with the proposed statement, which is about the development and deployment of technical
RE: Gen-ART LC review of draft-ietf-ccamp-rfc5787bis-05
Thanks Roni, Good catches. Adrian From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Roni Even Sent: 13 August 2012 22:07 To: draft-ietf-ccamp-rfc5787bis@tools.ietf.org Cc: gen-...@ietf.org; ietf@ietf.org Subject: Gen-ART LC review of draft-ietf-ccamp-rfc5787bis-05 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-ccamp-rfc5787bis-05. Reviewer: Roni Even Review Date:2012-8-12 IETF LC End Date: 2012-8-17 IESG Telechat date: Summary: This draft is almost ready for publication as a standard track RFC. Major issues: Minor issues: In section 6.1 If specified more than once, instances preceding the first will be ignored and condition SHOULD be logged for possible action by the network operator. I am not sure what is meant by preceding the first. Nits/editorial comments: 1. The following note appears in section 10.1, 10.2 and 10.3. Note that the same values for the Inter-RA Export Upward sub-TLV and the Inter-RA Export Downward Sub-TLV MUST be used when they appear in the Link TLV, Node Attribute TLV, and Router Address TLV. - why not have it in section 10 before section 10.1. 2. I saw in appendix B that one of the changes from RFC 5787 was to clarify the terminology before defining extensions, I would have found it easier to read if the ASON hierarchy and the relation to OSPF in section 2 were presented in figures. This was more an issue to me as a reader not familiar with the terminology and I would like to think that the more familiar reader will not have problem.
Last Call: draft-ietf-v6ops-wireline-incremental-ipv6-05.txt (Wireline Incremental IPv6) to Informational RFC
The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Wireline Incremental IPv6' draft-ietf-v6ops-wireline-incremental-ipv6-05.txt as 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 2012-08-27. 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 Operators worldwide are in various stages of preparing for, or deploying IPv6 into their networks. The operators often face difficult challenges related to both IPv6 introduction along with those related to IPv4 run out. Operators will need to meet the simultaneous needs of IPv6 connectivity and continue support for IPv4 connectivity for legacy devices with a stagnant supply of IPv4 addresses. The IPv6 transition will take most networks from an IPv4- only environment to an IPv6 dominant environment with long transition period varying by operator. This document helps provide a framework for wireline providers who are faced with the challenges of introducing IPv6 along with meeting the legacy needs of IPv4 connectivity utilizing well defined and commercially available IPv6 transition technologies. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-wireline-incremental-ipv6/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-wireline-incremental-ipv6/ballot/ No IPR declarations have been submitted directly on this I-D.
Protocol Action: 'Protocol Independent Multicast ECMP Redirect' to Proposed Standard (draft-ietf-pim-ecmp-05.txt)
The IESG has approved the following document: - 'Protocol Independent Multicast ECMP Redirect' (draft-ietf-pim-ecmp-05.txt) as Proposed Standard This document is the product of the Protocol Independent Multicast Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pim-ecmp/ Technical Summary This document introduces the ECMP Redirect, a mechanism to improve the RPF procedure over ECMPs. It allows ECMP path selection to be based on administratively selected metrics, such as data transmission delays, path preferences and routing metrics. Working Group Summary There is consensus within the PIM WG to publish this document. The document has been actively discussed on the wg list and in wg meetings. Document Quality There is at least one implementation that will soon ship. Personnel Mike McBride (mmcbri...@gmail.com) is the document shepherd. Adrian Farrel (adr...@olddog.co.uk) is the responsible AD.
Protocol Action: 'Access Network Identifier (ANI) Option for Proxy Mobile IPv6' to Proposed Standard (draft-ietf-netext-access-network-option-13.txt)
The IESG has approved the following document: - 'Access Network Identifier (ANI) Option for Proxy Mobile IPv6' (draft-ietf-netext-access-network-option-13.txt) as Proposed Standard This document is the product of the Network-Based Mobility Extensions Working Group. The IESG contact persons are Brian Haberman and Ralph Droms. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-netext-access-network-option/ Technical Summary The local mobility anchor in a Proxy Mobile IPv6 domain is able to provide access network and access operator specific handling or policing of the mobile node traffic using information about the access network to which the mobile node is attached. This specification defines a mechanism and a related mobility option for carrying the access network identifier and the access operator identification information from the mobile access gateway to the local mobility anchor using proxy mobile IPv6 signaling messages. Working Group Summary The I-D has followed normal IETF WG process and has consensus regarding the proposed extension to Proxy Mobile IPv6. There have been no controversies or opposition to this proposal. Document Quality No known or announced implementations of the protocol exist. However there may be unannounced implementations in progress. Multiple vendors have indicated interest in implementing these extensions in their products. The I-D has undergone multiple reviews and they have been acknowledged in the document itself. Personnel Document shepherd: Basavaraj Patil Responsible AD: Brian Haberman RFC Editor Note OLD: However, the location and access information MAY be exposed to specific parties outside the PMIPv6 Domain based on an agreement approved by the subscriber, otherwise, this information MUST NOT be exposed in the absence of such agreements. NEW However, the location and access information MAY be exposed to specific parties outside the PMIPv6 Domain based on an agreement approved by the subscriber, otherwise, this information MUST NOT be exposed in the absence of such agreements. If the location information is to be exposed outside the PMIPv6 Domain then that MUST be done using a PIDF-LO [RFC5139] carrying the usage rules to which the subscriber has agreed. In section 9.1, add: [RFC5139] Thomson, M. and J. Winterbottom, Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO), RFC 5139, February 2008.
RFC 6694 on The about URI Scheme
A new Request for Comments is now available in online RFC libraries. RFC 6694 Title: The about URI Scheme Author: S. Moonesamy, Ed. Status: Informational Stream: IETF Date: August 2012 Mailbox:sm+i...@elandsys.com Pages: 7 Characters: 11604 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-appsawg-about-uri-scheme-07.txt URL:http://www.rfc-editor.org/rfc/rfc6694.txt This document describes the about URI scheme, which is widely used by Web browsers and some other applications to designate access to their internal resources, such as settings, application information, hidden built-in functionality, and so on. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Applications Area Working Group 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
RFC 6701 on Sanctions Available for Application to Violators of IETF IPR Policy
A new Request for Comments is now available in online RFC libraries. RFC 6701 Title: Sanctions Available for Application to Violators of IETF IPR Policy Author: A. Farrel, P. Resnick Status: Informational Stream: IETF Date: August 2012 Mailbox:adr...@olddog.co.uk, presn...@qualcomm.com Pages: 12 Characters: 25078 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-farrresnickel-ipr-sanctions-07.txt URL:http://www.rfc-editor.org/rfc/rfc6701.txt The IETF has developed and documented policies that govern the behavior of all IETF participants with respect to Intellectual Property Rights (IPR) about which they might reasonably be aware. The IETF takes conformance to these IPR policies very seriously. However, there has been some ambiguity as to what the appropriate sanctions are for the violation of these policies, and how and by whom those sanctions are to be applied. This document discusses these issues and provides a suite of potential actions that can be taken within the IETF community in cases related to patents. 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
RFC 6702 on Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules
A new Request for Comments is now available in online RFC libraries. RFC 6702 Title: Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules Author: T. Polk, P. Saint-Andre Status: Informational Stream: IETF Date: August 2012 Mailbox:tim.p...@nist.gov, psain...@cisco.com Pages: 16 Characters: 35052 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-polk-ipr-disclosure-05.txt URL:http://www.rfc-editor.org/rfc/rfc6702.txt The disclosure process for intellectual property rights (IPR) in documents produced within the IETF stream is essential to the accurate development of community consensus. However, this process is not always followed by IETF participants. Regardless of the cause or motivation, noncompliance with IPR disclosure rules can delay or even derail completion of IETF specifications. This document describes some strategies for promoting compliance with the IPR disclosure rules. These strategies are primarily intended for use by area directors, working group chairs, and working group secretaries. 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
RFC 6706 on Asymmetric Extended Route Optimization (AERO)
A new Request for Comments is now available in online RFC libraries. RFC 6706 Title: Asymmetric Extended Route Optimization (AERO) Author: F. Templin, Ed. Status: Experimental Stream: IETF Date: August 2012 Mailbox:fltemp...@acm.org Pages: 33 Characters: 77250 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-templin-aero-12.txt URL:http://www.rfc-editor.org/rfc/rfc6706.txt Nodes attached to common multi-access link types (e.g., multicast- capable, shared media, non-broadcast multiple access (NBMA), etc.) can exchange packets as neighbors on the link, but they may not always be provisioned with sufficient routing information for optimal neighbor selection. Such nodes should therefore be able to discover a trusted intermediate router on the link that provides both forwarding services to reach off-link destinations and redirection services to inform the node of an on-link neighbor that is closer to the final destination. This redirection can provide a useful route optimization, since the triangular path from the ingress link neighbor, to the intermediate router, and finally to the egress link neighbor may be considerably longer than the direct path from ingress to egress. However, ordinary redirection may lead to operational issues on certain link types and/or in certain deployment scenarios. This document therefore introduces an Asymmetric Extended Route Optimization (AERO) capability that addresses the issues. This document defines an Experimental Protocol for the Internet community. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. 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
