Re: IANA Considerations
On Thu, 7 Jul 2005, Brian E Carpenter wrote: RFC 2434 doesn't discuss null IANA sections at all. Right. The requirement for null IANA Considerations sections first appeared in the May 2004 version of http://www.ietf.org/ID-Checklist.html, without prior notice to the community. RFC2434bis does discuss them, and we will need to form consensus about whether the RFC Editor is required to retain them, as we discuss RFC2434bis. Which we need to do fairly soon. In what venue will this discussion take place? While I can understand the value (to the IANA) of a null IANA Considerations section in an Internet Draft, I'm strongly opposed to having them appear in published documents. Mike Heard ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
A word about the plenaries in Paris
We're just putting together the agendas for the plenary sessions in Paris. They will be Wednesday and Thursday at new timings: 17:30 through 20:00, before dinner, to match Paris restaurant hours. Wednesday will focus on IETF operations, administration and process (led by me as IETF Chair). Thursday will focus on technical issues (led by Leslie Daigle, IAB Chair). We have lots of material for both days. We're going to try something slightly different for the open mike sessions. Both plenaries will have the final hour reserved for a town hall meeting. Rather than putting a row of IESG or IAB people up on a stage, we want to aim at a less confrontational style of discussion. We'll work out the details when we see the room layout. Meanwhile (and in Leslie's absence on vacation), I'd like to ask people to think about possible high level topics for those two town hall meetings: ops/admin/process topics for Wednesday and technical topics for Thursday. Brian Carpenter IETF Chair ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
When to DISCUSS?
As most RFC authors know, when an IESG member identifies a problem in a draft under IESG review, he or she casts a DISCUSS ballot, with accompanying text, and the DISCUSS has to be cleared before the document can advance. draft-iesg-discuss-criteria-00.txt talks about this. Even within the IESG, we still have one or two points to resolve, but we wanted to get this out before the cutoff date. This isn't in any way intended to change any of the principles of the standards process, but we'd welcome community comment. Brian [EMAIL PROTECTED] wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Engineering Steering Group Working Group of the IETF. Title : DISCUSS Criteria in IESG Review Author(s) : J. Peterson, et al. Filename: draft-iesg-discuss-criteria-00.txt Pages : 10 Date: 2005-7-7 This document describes the role of the 'DISCUSS' position in the IESG review process. It gives some guidance on when a DISCUSS should and should not be issued. It also discusses procedures for DISCUSS resolution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iesg-discuss-criteria-00.txt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
On role conflict
This is a somewhat personal note, expanding on something I hinted at in plenary in Minneapolis. The person appointed as IETF Chair actually gets three jobs today: IETF Chair IESG Chair General Area Director The IETF Chair is clearly responsible to the IETF as a whole. A fairly large amount of this role is, under BCP 101, in the process of being handed over to the IASA and the IAD in particular. But there remains a major role of listening to the IETF, trying to form consensus on IETF-wide issues, and trying to carry that consensus forward into action. The IESG Chair is of course responsible to the IETF too, but the role is different: the IESG Chair must form IESG consensus, drive the standards process, and respresent IESG decisions collegially. The General AD has the usual AD responsibilities, but with the peculiarity that General Area documents tend to be ones that change the IETF process itself - potentially including the above two roles and the IESG's role. If you put yourself hypothetically in those three roles, you will easily see that there is potential for role conflict, especially if the community wants A and the IESG wants B. This isn't a complaint - but I think, in view of some of the recent list discussions, that people need to understand very clearly that this potential role conflict is built into our present way of doing things. Speaking personally, I believe that in the end, the community wins; but when I speak for the IESG, you can expect me to represent the collegial view of the IESG. When the community reaches a clear view on something, which is frankly much harder to judge, I'll represent that. Brian-Three-Hats ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 2434 term IESG approval
Date:Thu, 7 Jul 2005 22:25:18 -0700 (PDT) From:C. M. Heard [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | Would it be unreasonable to ask that you point to some text in the | document to support your claim? Or lacking that, to point to some | publically archived discussion (e.g. last call comments) that | support your position? My memory isn't good enough for last call comments, certainly not 7 years ago. I actually doubt that there were many, 2434 as it stands isn't something that would have evoked much controversy I suspect. The relevant part is from section 2, basicly all of page 5 of the doc. The section that starts The following are example policies... and goes to the end of section 2 (into page 6) - though the last paragraph of section 2 isn't really material (that just says about being able to have some parts of a name space assigned under one policy and other parts under a different one - which 2780 does not do for IPv6 options). All that text in 2434 is just 'examples' but becomes normative when incorporated by reference in another rfc (like 2780) which is quite common. Read the examples (which have turned into the de-facto policy choice list) to see the text in question. Every one of the 'examples' is about what documentation is required. This is no surprise - what's being done is to give working groups example policies that show what is reasonable to give as a policy to IANA in order to register a name in one of the registries. The range from nothing at all (not even any registry, just self assignment) at the begining to the existance of a standards track RFC at the high end. I suspect that many people are getting confused by the process necessary to get a standards track RFC, and assuming that all of the review that happens there is relevant. It is, but only to the process of defining the protocol, IANA does not need to care about any of that - for IANA, the simple existence of a standards track RFC that calls for (or assigns) a name from a registry is enough for a Standards Action 'example' registry. Everything between is about documentation requirements, just read them ... Anyone can obtain an assigned number, so long as they provide a point of contact and a brief description ... Values and their meaning must be documented in an RFC or other permanent ... New assignments must be approved by the IESG, but there is no requirement that the request be documented in an RFC (though the IESG has discretion to request documents or other supporting materials ... ...new assignments are made via RFCs approved by the IESG Values are assigned only for Standards Track RFCs ... They're all centred around the documentation that needs to be available (or does not need to be available). There isn't one word about any other criteria for IANA to use (or anyone else to use) when deciding on assignments. Nothing about refusing assignments from blue haired Klingons on alternate Thursdays, or anything else like that. True, it doesn't explicitly say that hair colour of the applicant cannot be considered, as it doesn't say that lots of other things cannot be considered - but nor does it need to. There's no question but that a WG could, if it wanted, impose any kind of bizarre requirements (there is no requirement to stick to the list of example assignment policies), but to do so it would have to justify what it wants when asked during last call, and anything peculiar (such as: only to protocols that we approve of) would likely get considerable pushback. The bulk of the doc is advice to working groups about which policies might be useful under what circumstances, and some requirements that WG's must handle in order to get IANA to create a registry and perform parameter assignment. That's all relevant when a WG is creating a new registry (or modifying one) and not relevant at all right now. kre ps: I believe this is my last word on this topic. It has gone on long enough. I have no idea what is currently happening with the request for this particular option, but I certainly hope that an IAB appeal is under way (as the IESG have quite clearly refused to reconsider their position, I would take it that that part of the 2026 requirememts of the appeal process is now well and truly satisfied). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: When to DISCUSS?
re draft-iesg-discuss-criteria-00.txt I think this is a very helpful document - if followed by the IESG it should reduce the number of what appears to be blocking actions by ADs but I did not see any enforcement mechanism - i.e. if an AD enters a DISCUSS over a section 3.2 reason how does the IESG tell that AD to back off? It seems like the alternate voting process is not needed to have the IESG look at a DISCUSS comments and reach a consensus that it is not (or is) a legit DISCUSS area maybe somthing like a 'review of comment' process that gets kicked off by another AD or a WG chair after an AD files their DISCUSS comment. The process just involving a requirement for all ADs to review the comment in question and discuss the issue on the next IESG call ending in a vote - if there is not majority support that the comment is a blocking type then the DISCUSS is changed to a non-blocking comment Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: When to DISCUSS?
At 11:22 08/07/2005, Brian E Carpenter wrote: As most RFC authors know, when an IESG member identifies a problem in a draft under IESG review, he or she casts a DISCUSS ballot, with accompanying text, and the DISCUSS has to be cleared before the document can advance. draft-iesg-discuss-criteria-00.txt talks about this. Even within the IESG, we still have one or two points to resolve, but we wanted to get this out before the cutoff date. This isn't in any way intended to change any of the principles of the standards process, but we'd welcome community comment. I have a problem It concerns the need of non IESG DISCUSS by concerned authoritative entities whose personal opposition may block the adhesion of the Internet community to the RFC. I will illustrate with the IANA aspects. When a RFC calls for a IANA Registry management, the IANA under RFC 2860 should comply with it. We however have a grey area which concerns the applications involving for example ISO 3166 (country codes), ISO 639 (languages), ISO 11179 (Registires), etc. I name some which are in the current debate today. But it is likely that the convergence, the universal development of the Internet, etc. will lead to such situations where an IETF defined registry using external standards leads to correlations opposed by those who accepted the standard. This problem is obviously a ransom of the Internet success, but it is a key problem for the Internet and IETF integration. I have no specific solution here, but I say two things: 1. the joint committes and liaisons with other SDOs should have the possibility to rise a DISCUSS flag 2. the IANA should not be forced to accept the management of a Directory without the issue being agreed with all the concerned parties. The major evolution of the Internet we face is the distribution of the IANA functions (USA initiated a move I work on for four years). It is of the utmost importance that we avoid an alt-root situation here, all the more than the first partners will most probably include Governements and the next ones concerned cultures. It is therefore of the essence that the conference of the distributed National/Regional/Local/Corporate/Private Centers of References, whatever it may be built as, has the capacity to DISCUSS a Registry specified in an RFC and prevent its parameter polution by disagreeing Reference Centres Managers. This is particularly true for the Registries where the ISO standards above are considered (ISO 3166 is the most widely used ISO table and is clearly identified in the Internet to ccTLDs for national communities and to GAC for Governments, ISO 639 series identifies languages, what means commonly cultures [English speaking people and young cultures use to attach more their culture to Nations, Religions, etc.]). I know some will object that this is not the way the Internet is specified. Or that this is not the way it should work. Or this is L8/L9 concerns out of IETF/IESG scope. The same as some said and may be continue to say that for the root. This will not change that this is the way the root works today and this is the way the IANA starts being considered today. Establishing rules taking reality into account, will only permit to smooth the transition from a mono-default to a multi-enacted parametered internet. The Internet partitionning (legacy, regalian, national, cultural, proximity, trade, kids, private, etc.) is a necessity: the USA just affirmed it for their own account; I identified and documented it here nearly two years ago. We have now to progressively acknowledge it and build the procedures and projects which will help making it a concerted compartmentalisation rather than to close our eyes on the wild balkanisation now engaged. jfc Brian [EMAIL PROTECTED] wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories.is draft is a work item of the Internet Engineering Steering Group Working Group of the IETF. Title : DISCUSS Criteria in IESG Review Author(s) : J. Peterson, et al. Filename: draft-iesg-discuss-criteria-00.txt Pages : 10 Date: 2005-7-7 This document describes the role of the 'DISCUSS' position in the IESG review process. It gives some guidance on when a DISCUSS should and should not be issued. It also discusses procedures for DISCUSS resolution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iesg-discuss-criteria-00.txt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: What's the value of specification consistency?
Note that this is not purely hypothetical; I asked the same question of the IESG in a comment on draft-ietf-pkix-pkixrep-03.txt: For draft-ietf-impp-srv-04, we required an IANA maintained registry that allowed someone to map _im._bip to a specification of how _bip used SRV records. Seems very similar, in that PKIXREP will actually map to different using protocols like OCSP, LDAP, or HTTP; these aren't just transports, like tcp or udp, they have different syntax (and frankly the use of HTTP for this means a convention at a level even SRV can't handle). In that particular case the consistency was utterly irrelevant. XKMS already defines SRV prefixes that are not IANA registered at all. If you make it too difficult for people to get code points registered they are simply going to define them themselves. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Internationalization, IPR (was IANA Considerations)
Date: 2005-07-08 01:08 From: Frank Ellermann [EMAIL PROTECTED] Bruce Lilly wrote: BCP 18 (RFC 2277, Frank) recommends an internationalization considerations section Oh, that beast, a MUST UTF-8, not less. Didn't make it into RfC 3912, can I declare it broken by design and return to RfC 954, please ? Not now. Within two months of the public announcement of the decision, (BCP 9, a.k.a. RFC 2029, section 6.5.4) you could have initiated an appeal or a discussion with the IETF Chair if you felt that there was some sort of process failure and if you thought such an approach would be productive. At this late date, you can of course still send comments to the author. While we're at it, did you see draft-hoffman-utf8-rfcs-00.txt ? I saw it, downloaded it, glanced through it. Not surprising to me, since some time ago (IIRC during review of the I-D Checklist here) I briefly mentioned the ASCII-only rule and explicitly deferred discussion of that to those who are most directly affected, e.g. authors whose names contain non-ASCII characters (I didn't wish to open that particular can of worms at that particular time). If the IETF feels that internationalization is an important issue, a similar guideline prompting authors/editors to include, and reviewers to review such a section might be worth adding. Maybe. OTOH it wouldn't be polite to write SMTP error texts are i-default US-ASCII, stupid, so that's what you put in an SPF exp= explanation, for more I18N you could use a http URL. It also wouldn't be of much interest, as SMTP requires protocol actions based solely on the reply code (first digit), and the text must not be used as the basis for action (with a notable pseudo-exception, where the text is a public name rather than text in the BCP 18 (RFC 2277) sense). There might, however, be cause to examine the SMTP protocol in terms of providing a BCP 18 conforming mechanism for tagging the text charset and language, and for provision for charsets other than US-ASCII (considering the application, adoption of the BCP 18 conforming mechanism specified in RFC 2047 as amended by RFC 2231 and errata might be a good choice). The IPR boilerplate makes me mad, but unfortunately the authors of xml2rfc didn't adopt my ipr=fullmeep or ipr=fulleula proposals. Insert four-letter word for meep. At most three lines pointing to a creative commons BY SA license should be good enough for most I-Ds. Ah, but you misunderstand the purpose of legal boilerplate -- it isn't supposed to make sense, it's supposed to confound common sense (see Jonathan Swift's Gulliver's Travels), and to provide full employment for lawyers (which may explain why it always seems to be in need of revision) .-, (- that's half a smiley :-)). If you look at the IPR boilerplate in those terms, it's fulfilling its purposes (HE/SHE applied to all-male or all-female authors, reference to this standard for mere drafts and all RFCS (Not All RFCs are Standards hasn't been rescinded AFAIK), etc.). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: When to DISCUSS?
draft-iesg-discuss-criteria-00.txt talks about this. Even within the IESG, we still have one or two points to resolve, but we wanted to get this out before the cutoff date. This isn't in any way intended to change any of the principles of the standards process, but we'd welcome community comment. This is actually quite good. In particular I think that it does go a long way in returning to the original concept of the IETF rather than what it had been turning into. There is however one area that should be made very explicit as a non issue for DISCUSS, failure to employ a specific technology platform. I have been concerned on a number of occasions where it has appeared that in order to get a specification approved by the IESG it would be necessary to adopt a particular technology being promoted by IESG members. This issue is not unique to the IETF, at one point there was a major issue in W3C when some members suspected that Semantic Web would be imposed in this manner. I believe that a similar dynamic played a major role in causing OSI to become what it became. There are some cases where this is a good idea, it is clearly important that every IETF standard protocol is capable of making the transition to IPv6. But there are other cases where this really comes down to second guessing the WG or worst of all promoting a pet project. For example when I submit a draft proposing a prefix for use with SRV I do not expect to have to explain my reasons for using a technology that is widely supported by existing infrastructure over NAPTR, a technology which is only partially supported, has yet to gain a major constituency of users and may well end up being superceeded before it is widely adopted. Now some might say that the role of the IESG should be precisely to do this sort of thing, to encourage the adoption of technology that deserves to be employed as a technology base. I disagree because this leads working groups to think that its not their job to promote their work product and drive its adoption, they can simply rely on the IESG to do their work for them by forcing other groups who have killer applications to do the heavy lifting for them. I spend a great deal of time working out how to get a protocol adopted, how to build the necessary coalitions of support to drive deployment. If I have a choice of technology platforms I am not going to necessarily pic the one that is the newest, brightest and shinyest. In the first place I have been caught out in the past several times following that route and finding that my spec is the only system built on the new platform. But more importantly the more infrastructure innovations a proposal requires the harder it is to build a coalition and the harder it is to keep it together. The most worrying version of this approach is when a group is told that in order to gain approval of the IESG it MUST take a particular technical approach. This is why I would like a very concrete statement in the DISCUSS document saying that a WG is free to choose an approach that uses deployed technology over another proposal without market traction. I know of two cases where a group has been essentially forced to significantly compromise their design in order to support BEEP. At this point it should be clear to anyone who follows the Web Services area that there is universal agreement amongst vendors and developers that the SOAP stack is the only one that will be used. This outcome has been clear to anyone who has followed this area for at least four years. I watched the SACRED group being bullied into adopting BEEP as a substrate. This makes even less sense when you know that SACRED was intended to be a compliment to XKMS which is defined to be a Web Service running over SOAP. The only argument I saw made at the meeting was that the IESG would expect BEEP to be supported so the WG better get in line. There is at this point a huge difference in the capabilities of BEEP and the capabilities of Web Services based on the SOAP, WSDL etc. It is a major imposition on a working group to require them to support BEEP because it then forces the group to re-invent the work that has gone into WS-Security. Developers are then required to implement the DIY security infrastructure developed by the group rather than use the existing libraries in the Web Services development environments. It would be much easier for me to get INCH/RID adopted as an incident notification protocol in the anti-phishing world in its original Web Services compliant form than in the current incarnation that was imposed on the group by an area director. If I am talking to Microsoft, IBM, Sun or any bank that uses their technology it is much easier to get them to buy into a protocol that they can build in an afternoon using standard toolkits than something that will require bespoke work. In summary, the DISCUSS draft is header in the right direction and the above is implicit in its text but it should be made
RFC 4068 on Fast Handovers for Mobile IPv6
A new Request for Comments is now available in online RFC libraries. RFC 4068 Title: Fast Handovers for Mobile IPv6 Author(s): R. Koodli, Ed. Status: Experimental Date: July 2005 Mailbox:[EMAIL PROTECTED] Pages: 42 Characters: 93591 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-mipshop-fast-mipv6-03.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4068.txt Mobile IPv6 enables a Mobile Node to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. This handover latency resulting from standard Mobile IPv6 procedures, namely movement detection, new Care of Address configuration, and Binding Update, is often unacceptable to real-time traffic such as Voice over IP. Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link switching latency. This document is a product of the MIPv6 Signaling and Handoff Optimization Working Group of the IETF. 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 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 ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4068.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4065 on Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations
A new Request for Comments is now available in online RFC libraries. RFC 4065 Title: Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations Author(s): J. Kempf Status: Experimental Date: July 2005 Mailbox:[EMAIL PROTECTED] Pages: 8 Characters: 16179 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-seamoby-iana-02.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4065.txt The Seamoby Candidate Access Router Discovery (CARD) protocol and the Context Transfer Protocol (CXTP) are experimental protocols designed to accelerate IP handover between wireless access routers. These protocols require IANA allocations for ICMP type and options, Stream Control Transmission Protocol (SCTP) Payload Protocol Identifiers, port numbers, and registries for certain formatted message options. This document contains instructions to IANA about which allocations are required for the Seamoby protocols. The ICMP subtype extension format for Seamoby has been additionally designed so that it can be utilized by other experimental mobility protocols, and the SCTP port number is also available for other experimental mobility protocols. This document is a product of the Context Transfer and Handoff Candidate Discovery, and Dormant Mode Host Alerting Working Group of the IETF. 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 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 ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4065.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4067 on Context Transfer Protocol (CXTP)
A new Request for Comments is now available in online RFC libraries. RFC 4067 Title: Context Transfer Protocol (CXTP) Author(s): J. Loughney, Ed., M. Nakhjiri, C. Perkins, R. Koodli Status: Experimental Date: July 2005 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 33 Characters: 77718 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-seamoby-ctp-11.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4067.txt This document presents the Context Transfer Protocol (CXTP) that enables authorized context transfers. Context transfers allow better support for node based mobility so that the applications running on mobile nodes can operate with minimal disruption. Key objectives are to reduce latency and packet losses, and to avoid the re-initiation of signaling to and from the mobile node. This document is a product of the Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting Working Group of the IETF. 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 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 ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4067.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4066 on Candidate Access Router Discovery (CARD)
A new Request for Comments is now available in online RFC libraries. RFC 4066 Title: Candidate Access Router Discovery (CARD) Author(s): M. Liebsch, Ed., A. Singh, Ed., H. Chaskar, D. Funato, E. Shim Status: Experimental Date: July 2005 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 46 Characters: 116733 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-seamoby-card-protocol-08.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4066.txt To enable seamless IP-layer handover of a mobile node (MN) from one access router (AR) to another, the MN is required to discover the identities and capabilities of candidate ARs (CARs) for handover prior to the initiation of the handover. The act of discovery of CARs has two aspects: identifying the IP addresses of the CARs and finding their capabilities. This process is called candidate access router discovery (CARD). At the time of IP-layer handover, the CAR, whose capabilities are a good match to the preferences of the MN, is chosen as the target AR for handover. The protocol described in this document allows a mobile node to perform CARD. This document is a product of the Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting Working Group of the IETF. 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 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 ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4066.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
