Query regarding Additional Mode transition logic for IR IR-Dyn Packets (Interoperabilty)
Dear RoHC ers, I am facing ambiguity regarding handling of Mode Cancellation for IR IR-Dyn Packets in Profile -0x0004 (RFC 3843). RFC 3843 says: The Mode parameter for the value mode = 0 (packet types UOR-2, IR and IR-DYN) is redefined to allow the compressor to decline a mode transition requested by the decompressor: Mode: Compression mode. 0 = (C)ancel Mode Transition Upon receiving the Mode parameter set to '0', the decompressor MUST stay in its current mode of operation and SHOULD refrain from sending further mode transition requests for the declined mode for a certain amount of time. Q.1) How do we communicate mode parameter (i.e, '0' for Mode cancellation) to Decompressor for IR IR-Dyn Packets? RFC 3095/ 3843 has not defined any field indicating 'Mode' in IR /IR-Dyn Packet formats for Profile-0x0004. But UOR-2 Packet can communicate mode value in the form of Extension-3. Q.2) Is this interpretation correct? Can we define a field for mode parameter in Dynamic chain (in IR IR-Dyn packets) and communicate the mode value to De-compressor, by indicating it as '0' for handling of Mode Cancellation. Will the above implementation give any impact in Interoperabilty? Pls share your valuble thoughts regarding the same. Thanks, Pradeep. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Repair of Public Mail List Archives Complete
Alexa I noticed the lists were down and would normally have flagged it, as many another organisation knows. I did not do so partly because of the usual problem of where to flag it but more because what is the point? These are not so much archives as current affairs. I can look at what has been posted so far today, or yesterday or last week. But when I really need an archive, to see what was agreed in 2006, I have to get there day by day by painstaking day by tedious day at a time. I can see no other more direct way. Where the ietf does not host the archive, and there are still some, then I get a menu inviting me to start in March 2006, which takes me where I want to be in seconds. So when the ietf archives are down, well, I don't really miss them. Tom Petch - Original Message - From: Alexa Morris amor...@amsl.com To: wgcha...@ietf.org Cc: ietf@ietf.org Sent: Tuesday, March 03, 2009 10:20 PM Subject: Repair of Public Mail List Archives Complete As I mentioned late last week, as a side effect of a recent Mailman upgrade some mail lists with previously public archives had their list configuration reset to private archiving, resulting in inaccessible archives. This archiving issue has now been repaired and the missing archives have been transferred from private to public. All lists with public archives should now have the complete set of messages. As always, please contact me with any questions or concerns. Regards, Alexa --- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amor...@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com http://www.amsl.com/ ___ 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: Abstract on Page 1?
On an allied topic, I notice that a recent I-D - draft-ietf-sidr-arch-06.txt - published March 9, 2009, had a running heading which included 'November 2008'. Paranoid as I am, I immediately link this date to RFC5378 and the time when the IETF Trust introduced the new rules for IPR. Is there a connection orr is there some more innocent explanation as to why the running heading is not March 2009? Tom Petch - Original Message - From: Julian Reschke julian.resc...@gmx.de To: Scott Lawrence scott.lawre...@nortel.com Cc: John C Klensin john-i...@jck.com; ietf@ietf.org Sent: Saturday, March 07, 2009 9:45 AM Subject: Re: Abstract on Page 1? Scott Lawrence wrote: ... This is a trivial change for the generation tools to make - at worst it will make one generation of diffs slightly more difficult (and I'd be happy to trade one generation of poor diffs for this, so for me just don't worry about fixing the diff tools). ... At this point, no change to the boilerplate is trivial anymore. For xml2rfc, we need to - define how to select the new behavior (date? ipr value? rfc number?); if the behavior is not explicitly selected in the source, we need heuristics when to use the old one and when to use the new one (keep in mind that the tools need to be able to generate historic documents as well) - add new test cases - add documentation So, I'm not against another re-organization, but, in this time, PLEASE: - plan it well (think of all consequences for both I-Ds and RFCs) - make the requirements precise and actually implementable (remember: must be on page 1 :-) - give the tool developers sufficient time; optimally let *then* decide when the cutover date should be BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Abstract on Page 1?
At 08:23 17-03-2009, Tom.Petch wrote: On an allied topic, I notice that a recent I-D - draft-ietf-sidr-arch-06.txt - published March 9, 2009, had a running heading which included 'November 2008'. Paranoid as I am, I immediately link this date to RFC5378 and the time when the IETF Trust introduced the new rules for IPR. Is there a connection orr is there some more innocent explanation as to why the running heading is not March 2009? Cc to the authors of draft-ietf-sidr-arch-06.txt for the more innocent explanation. The date for the Expires footer is May 2009 whereas the I-D expires on September 9, 2009. There is a Pre-5378 Material Disclaimer section at the end of the I-D. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC review of draft-atlas-icmp-unnumbered-06
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-atlas-icmp-unnumbered-06 Reviewer: Ben Campbell Review Date: 2009-03-07 IETF LC End Date: 2009-04-06 IESG Telechat date: (unknown) Summary: I previously reviewed this draft in it's first IETF LC. Further correspondences with the authors addressed all of my comments, however as far as I know the draft has not been updated. I pasted in my previous review below for reference. Thanks! Ben. On Jan 8, 2009, at 4:39 PM, 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-atlas-icmp-unnumbered-06 Reviewer: Ben Campbell Review Date: 2009-01-08 IETF LC End Date: 2009-01-27 IESG Telechat date: (unknown) Summary: This draft is very close to ready for publication as a proposed standard. I have a couple of minor comments and questions that should be considered prior to publication, and some editorial nits. Substantive Comments: -- Section 4.1, definition of Next-Hop flag: This MUST be clear unless the Interface Role is 3, indicating an outgoing interface. The interface role definition listed the value for outgoing interface to be 1. Am I misreading something? -- Security Considerations: Are there any concerns about the extension data being available to intermediary devices? Is there any concern about unauthorized modification of the extension data (beyond what is mentioned in the NAT section)? (I'm not saying they are concerns--just checking to see if they have been thought about.) Editorial Comments: -- Abstract: Please expand acronyms on first use for MIB and OSPF. ( ICMP is probably well known enough to skip expanding.) The Abstract should stand alone; even though they may be expanded in the body, they should be expanded here. -- Section 2: Please expand ECMP on first use. -- 6th paragraph from end of section: s/permit/permits -- Section 4.3, between figure 3 an figure 4: It's not clear from the formatting if the line Class-Num = 2 is part of figure 4, part of the caption for figure 3, or just orphaned. -- Section 4.3, Figure 4: I find it confusing to have all the examples in a single figure. I think it would be easier to read if you split them up. -- idnits reports the following: ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see http://trustee.ietf.org/license-info), which is required from December 16, 2008. Version 1.34 of xml2rfc can be used to produce documents with boilerplate according to the mentioned Trust License Policy document. ... and ... == Outdated reference: A later version (-11) exists of draft-ietf-behave-nat-icmp-10 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Repair of Public Mail List Archives Complete
Hi - From: Tom.Petch sisyp...@dial.pipex.com To: Alexa Morris amor...@amsl.com Cc: ietf@ietf.org Sent: Tuesday, March 17, 2009 2:34 AM Subject: Re: Repair of Public Mail List Archives Complete ... But when I really need an archive, to see what was agreed in 2006, I have to get there day by day by painstaking day by tedious day at a time. I can see no other more direct way. The files at ftp://ftp.ietf.org/ietf-mail-archive/ are much better suited for such searches, especially when the time frame is fuzzy. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Repair of Public Mail List Archives Complete
Randy Presuhn wrote: Hi - From: Tom.Petch sisyp...@dial.pipex.com To: Alexa Morris amor...@amsl.com Cc: ietf@ietf.org Sent: Tuesday, March 17, 2009 2:34 AM Subject: Re: Repair of Public Mail List Archives Complete ... But when I really need an archive, to see what was agreed in 2006, I have to get there day by day by painstaking day by tedious day at a time. I can see no other more direct way. The files at ftp://ftp.ietf.org/ietf-mail-archive/ are much better suited for such searches, especially when the time frame is fuzzy. Or provide anonymous IMAP access to the archives and use an email client to search. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
FW: ANNOUNCEMENT: The IETF Trustees Announce the start of a new 30-day Community Review ...
The purpose of this message is to announce the start of a 30-day community review period for a proposed revision to the IETF Trust's Legal Provisions Relating to IETF Documents (TLP) policy. The intended purpose of this TLP revision is to delete the hard requirement for copyright boilerplate text to appear on the first page of every IETF document. This is in response to recent suggestions from the community and discussion amongst the Trustees. The details of the proposed revision to the TLP are as follows: - delete the requirement that copyright text must appear on the first page of every new IETF Document, - add text to say the IESG will specify where copyright and other legal boilerplate text should appear in Internet Drafts, and - add text that the RFC Editor will specify the manner and location of copyright text for RFCs The new text is for the start of Section 6 in the TLP document. The proposed text is as follows: 6.Text To Be Included in IETF Documents. The following text must be included in each IETF Document so as to give reasonable notice of the claim of copyright. The IESG shall specify the manner and location of such text for Internet Drafts. The RFC Editor shall specify the manner and location of such text for RFCs. A marked-up version of the TLP document is available on the IETF Trust website under the heading: Draft Policies and Procedures for IETF Documents at http://trustee.ietf.org/policyandprocedures.html Please accept this message as a formal request by the IETF Trustees for your review and feedback on the proposed revision to the TLP document. Today marks the beginning of a 30-day community review period. I expect the Trustees will appreciate all comments and suggestion received during this review period, and then decide on whether to adopt this revision shortly after April 15th, 2009. Regards, and Thanks in advance, Ed Juskevicius IETF Trust Chair edj@gmail.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Repair of Public Mail List Archives Complete
Hi Tom, On 17/03/09 05:34 AM, Tom.Petch wrote: Alexa I noticed the lists were down and would normally have flagged it, as many another organisation knows. I did not do so partly because of the usual problem of where to flag it but more because what is the point? These are not so much archives as current affairs. I can look at what has been posted so far today, or yesterday or last week. But when I really need an archive, to see what was agreed in 2006, I have to get there day by day by painstaking day by tedious day at a time. I can see no other more direct way. Dont be so sad :-). Try the IETF mailing list search engine developed by Lars and Jari http://www.google.com/coop/cse?cx=006728497408158459967%3Aybxjdw-bjjw Cheers Suresh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RFC 5431 on Diameter ITU-T Rw Policy Enforcement Interface Application
A new Request for Comments is now available in online RFC libraries. RFC 5431 Title: Diameter ITU-T Rw Policy Enforcement Interface Application Author: D. Sun Status: Informational Date: March 2009 Mailbox:dong...@alcatel-lucent.com Pages: 5 Characters: 10412 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-sun-dime-itu-t-rw-02.txt URL:http://www.rfc-editor.org/rfc/rfc5431.txt This document describes the need for a new pair of IANA Diameter Command Codes to be used in a vendor-specific new application, namely for the ITU-T Rec. Q.3303.3 - Rw interface used to send a request/ response for authorizing network Quality of Service (QoS) resources and policy enforcement in a network element, as one of the recommendations of the International Telecommunication Union - Telecommunication Standardization Sector (ITU-T). This memo provides information for the Internet community. 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 USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Review: Locator/ID Separation Protocol (lisp)
A new IETF working group has been proposed in the Routing Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by Tuesday, March 24, 2009. Locator/ID Separation Protocol (lisp) -- Last Modified: 2009-03-12 Current status: Proposed Working Group Chair(s): TBD Internet Area Director(s): TBD Routing Area Advisor: TBD Mailing Lists: General Discussion: https://www.ietf.org/mailman/listinfo/lisp Description of Working Group: The IAB's October 2006 workshop on 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 that the Internet architecture combines two functions, Routing Locators, or RLOCs (where you are attached to the network) and Endpoint Identifiers, or EIDs (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 location and identity, thus allowing for efficient aggregation of the RLOC space and providing persistent identity in the EID space. LISP supports the separation of the Internet address space into Endpoint Identifiers and Routing Locators following a network-based map-and-encap scheme (RFC 1955). It employs EIDs that represent a mixture of locators and identifiers; it could also be classified as a multi-level locator scheme. A number of other 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 EID-to-RLOC 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 analysis should also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on (draft-meyer-loc-id-implications). Goals and Milestones: Mar 2010 Submit base LISP specification to the IESG as Experimental Mar 2010 Submit base ALT specification to the IESG as Experimental Mar 2010 Submit the LISP Interworking specification to the IESG as Experimental June 2010 Submit the LISP Map Server specification to the IESG as Experimental June 2010 Submit Recommendations for Securing the LISP Mapping System to the IESG as Experimental Jul 2010 Submit LISP for Multicast Environments to the IESG as Experimental Dec 2010 Submit a preliminary analysis as Informational Dec 2010 Re-charter or close. ___ IETF-Announce mailing
