RE: Gen-art review of draft-ietf-netlmm-proxymip6-11.txt
Hi Elwyn, The need for the L2 interface identifier (such as MAC address) is to predictably identify the interface of a mobile node. The Access Technology Type in combination with the interface identifier is used as the index field in the BCE. Looks like this is not implied. We can point to the MN-Interface-Identifier term and that should probably make it clear. OK.. I think some clarification is required to make sure that you always get the same IID. As specified I didn't grok that it had to be the same one from wherever the node roams to. I think a few extra words will sort that out and then we are done. Sure. Will clarify this. Regards Sri ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IONs discuss criteria
All of this depends on the quality of the review and how it's followed up on. Having to push back on insistent nonsense is a problem. A good review that engenders a lot of discussion on substantial issues is very worthwhile. We should foster those -- they are important. This is no different than what happens within a WG. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IONs discuss criteria
Thomas Narten wrote: IMO, one of the biggest causes of problems (and most under-appreciated process weakness) in the IETF (and any consensus based organization for that matter) is poor handling of review comments. Whereas all of my own experiences with groups having problematic handling of reviews (except for a recent one where I happened to be the reviewer), is with the reviewer. In all of the groups I've been involved with, reviewers were taken and pursued seriously by the group. Problems occurred when the reviewer was vague, misguided and/or intractable. Diligent reviews are hugely helpful, especially so the earlier they occur. But not all reviews (including AD Discuss vetoes, which frequently are part of a form of review) are offered so helpfully. These repeated discussions about reviews are forceful in demanding acknowledgment of the former, helpful type, while vigorously denying the damaging reality of the latter and the need to deal with the pattern of strategic problems they cause. One of the reasons I'm such a fan of issue trackers is that it tends to remove a lot of the above stuff by simply not allowing stuff to fall through the cracks. Sure, trackers have overhead and are overkill in some cases. But if one could somehow analyze the number of documents that have been delayed for some time due to poor handling of review comments... Mostly, we agree on these points. Handled properly, placing review items in an issues list can be helpful to all parties, as long as each issue is clearly stated and possible resolutions or constructive guidance are included. One caveat: Sometimes it is the aggregate review that is most significant and breaking it into constituent 'issues' loses the broader concerns. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Win Ice Hockey Tickets
And the winners of the tickets are 1 - KURT ZEILENGA 2 - W. MATTHYS MEKKING The winners should stop by the Comcast t-shirt table ASAP to pick up their tickets. Each winner received two club box tickets. If the tickets are not claimed by 3:00pm Wednesday, we will need to select another winner. Regards Jason Livingood Comcast -Original Message- From: Livingood, Jason Sent: Friday, March 07, 2008 1:42 PM To: [EMAIL PROTECTED] Subject: Win Ice Hockey Tickets Thanks to HP, our business partner in releasing Comcast SmartZone, we are raffling four club box tickets to the Philadelphia Flyers ice hockey game on Wednesday night. We'll be raffling TWO sets of two tickets each. To enter the raffle, drop a business card in the entry box at the Comcast table in the registration area. This is the same table where you will be picking up your t-shirts, starting on Sunday. The raffle will close on Tuesday, 3/11, at 3:00pm ET, and winners announced at that time. See you in Philly! Jason Livingood Comcast PS - The game is at the Wachovia Complex, and is accessible via subway from the Marriott. http://www.comcastspectacor.com/ParkingAndDirections/publicTra nsportatio n.asp ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Social Event - Transportation / Final Logistics Update
IETF 71 - Social Event Advisory The social begins at 7:00pm and runs until 10:30pm. This is a reminder regarding transportation from the Marriott to the Philadelphia Art Museum. We are providing buses (that look like trolleys, for what that's worth). These buses will run in a continuous loop between the hotel and the museum, with the first one leaving at 6:45pm. Thus, it will be easy for you to leave the hotel for the museum and leave the museum to return at just about any time. There is at least one handicap-accessible bus. FROM THE HOTEL: To board the buses from the hotel, please use the Filbert Street entrance of the hotel, where the hotel check in and curved driveway is located. There will be Comcast personnel on-site to assist in boarding buses and getting buses underway between approximately 6:45pm and 8:15pm. There will be Comcast personnel on-site to receive the buses at the museum and to assist you on your return throughout the evening. NO ADMISSION TO THE MUSEUM WITHOUT YOUR SOCIAL TICKET. The perforated stub will be torn off when you enter the museum, and the remaining part of the ticket will be turned in upon your departure, in exchange for a gift on your way out. There will be a coat check and a bag check at the museum. There is also a WiFi network at the museum. Should you make your way to the museum on your own, entry is from the west entrance, which is in the back of the museum. Please note that this is a 30 minute walk from the hotel. You can of course get taxi service to the museum easily, and if you drive, there is ample parking behind and around the perimeter of the museum. Regards Jason Livingood http://ietf71.comcast.net/?page_id=12 ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 only Plenary Makes the News
Subject: IPv6 only Plenary Makes the News Isn't that just a press release from ISOC, being distributed by wire services online? -- Cos ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 only Plenary Makes the News
On Mar 11, 2008, at 2:31 PM, Ofer Inbar wrote: Subject: IPv6 only Plenary Makes the News Isn't that just a press release from ISOC, being distributed by wire services online? That's why they say they are making the news. Carl ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 only Plenary Makes the News
On Tue, Mar 11, 2008 at 5:31 PM, Ofer Inbar [EMAIL PROTECTED] wrote:
Subject: IPv6 only Plenary Makes the News
Isn't that just a press release from ISOC, being distributed by wire
services online?
-- Cos
Yes, that's correct. Still interesting to see it picked up by
other publishers, though, to get others interested in the daily work
of the IETF.
--
/Dan
Daniel P. Brown
Senior Unix Geek
? while(1) { $me = $mind--; sleep(86400); } ?
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 only Plenary Makes the News
Yes. On Mar 11, 2008, at 5:31 PM, Ofer Inbar wrote: Subject: IPv6 only Plenary Makes the News Isn't that just a press release from ISOC, being distributed by wire services online? -- Cos ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf Marshall ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RFC 4693 Experiment Conclusion
The IETF Operational Notes (IONs) experiment has concluded. The IESG has determined that IONs will not be used in the future. It is clear that the IESG, IAB, and IAOC need the ability to publish documents that do not expire and are easily updated. Information published as web pages, including IESG Statements, are sufficient for this purpose. The IESG intends to employ some form of version control so that previous versions of IESG Statements will be available on line. As specified in RFC 4693, the existing ION documents now have the same status as any other Web page or file on the IETF servers. Accordingly, the IONs that were developed during the experiment will be republished as follows: + ion-ad-sponsoring will be published as an IESG Statement + ion-agenda-and-minutes will be published as a web page + ion-discuss-criteria will be published as an IESG Statement + ion-ion-format will be discarded + ion-ion-store will be discarded + ion-procdocs will be published as a web page + ion-rfc-2026-in-practice has already been published as an I-D + ion-tsv-alt-cc will be published as an IESG Statement The IESG has also recommended that the following documents be republished as IAOC web pages: + ion-execd-tasks + ion-meeting-network-requirements + ion-subpoena The discussion on the appropriate type of document for the ion-discuss- criteria will continue. The decision that this particular ION become an IESG Statement at this point in time is not intended to forecast the outcome of this discussion; rather, it is a fulfillment of the statement in RFC 4693, which says: If the IESG decides that the feedback warrants terminating the series, the repository will be closed for new documents, and the existing ION documents will be returned to having the same status as any other Web page or file on the IETF servers -- this situation will closely resemble the situation before the experiment started. Much thanks to the ION authors and the people that provided comments on the experiment. On behalf of the IESG, Russ Housley ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Looking for a social ticket
Hi, If anyone have an extra social event ticket, please respond to me directly. Thanks in advance! Regards, Ahmad ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
BBoF on Federated Roaming: Update
Hello, the BBoF on Federated Roaming issues is still scheduled for Wednesday, 20.00 hours, shortly after the plenary. The number of responses so far was low enough to warrant ad-hoc location determination. Let's meet at the registration area. As a rough indication what to expect: I'm almost 2m tall, and still in my late 20s (counting the days :-( ). Also I'm probably the most nervous person in the vicinity since this is my first BBoF-style thing :-) The easiest choice from the registration area will probably be the Champions Bar on the ground floor, but I'm open to better ideas at any time. Greetings, Stefan Winter ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Protocol Action: 'GSS-API Internationalization and Domain-Based Service Names and Name Type' to Proposed Standard
The IESG has approved the following documents: - 'GSS-API Internationalization and Domain-Based Service Names and Name Type ' draft-ietf-kitten-gssapi-domain-based-names-06.txt as a Proposed Standard - 'GSS-API Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism ' draft-ietf-kitten-krb5-gssapi-domain-based-names-05.txt as a Proposed Standard These documents are products of the Kitten (GSS-API Next Generation) Working Group. The IESG contact persons are Sam Hartman and Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-domain-based-names-06.txt Technical Summary This documentset describes domainname-based service principal names and the corresponding name type for the Generic Security Service Application Programming Interface (GSS-API) and the GSS-API Kerberos 5 mechanism. Domain-based service names are similar to host-based service names, but using a domain name (not necessarily an Internet domain name) in addition to a hostname. The primary purpose of domain-based names is to provide a measure of protection to applications that utilize insecure service discovery protocols. This is achieved by providing a way to name clustered services after the domain which they service, thereby allowing their clients to authorize the service's servers based on authentication of their service names. Working Group Summary The Kitten Working Group has achieved consensus that this document should be published as a Proposed Standard. Two weeks of discussion of the document and how applications would need to be modified to make use if its specification were extended by an additional week in order to reach consensus on additional examples. Protocol Quality This document has been reviewed by Sam Hartman for the IESG. Note to RFC Editor Create a new section after section 5: x. IANA Considerations The IANA should record the following new name-type OID in the IANA's SMI Security for Name System Designators Codes (nametypes) registry: 5 gss-domain-based [RFC] Add to the end of section 6 (Security Considerations): Note that, as with all service names, the mere existence of a domain-based service name conveys meaningful information that may be used by initiators for making authorization decisions; therefore, administrators of distributed authentication services should be aware of the significance of the service names for which they create acceptor credentials. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Handover Key Management and Re-authentication Problem Statement' to Informational RFC
The IESG has approved the following document: - 'Handover Key Management and Re-authentication Problem Statement ' draft-ietf-hokey-reauth-ps-09.txt as an Informational RFC This document is the product of the Handover Keying Working Group. The IESG contact persons are Tim Polk and Sam Hartman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hokey-reauth-ps-09.txt Technical Summary The current Extensible Authentication Protocol (EAP) keying framework is not designed to support re-authentication and handovers. This is often the cause of unacceptable latency in various delay-sensitive environments (such as mobile wireless networks). The HOKEY Working Group plans to address these problems by designing a generic mechanism to reuse derived EAP keying material for handover. This document describes the Handover Keying (HOKEY) problem statement. Working Group Summary This document is a product of the hokey working group, and represents rough consensus of the working group. Protocol Quality This document has been reviewed extensively and the Document Shepherd believes it to be of high quality. This document was reviewed for the IESG by Tim Polk. Note to RFC Editor Please replace Section 6.2 with the following text: 6.2. IEEE 802.11r Applicability One of the EAP lower layers, IEEE 802.11 [IEEE.802-11R-D9.0], is in the process of specifying a fast handover mechanism. Access Points (APs) are grouped into mobility domains. Initial authentication to any AP in a mobility domain requires execution of EAP, but handover between APs within the mobility domain does not require the use of EAP. Internal to the mobility domain are sets of security associations to support key transfers between APs. In one model, relatively few devices, called R0-KHs, act as authenticators. All EAP traffic traverses an R0-KH, and it derives the initial IEEE 802.11 keys. It then distribute cryptographically separate keys to APs in the mobility domain, as necessary, to support the client mobility. For a deployment with M designated R0-KHs and N APs, this requires M*N security associations. For small M, this approach scales reasonably. Another approach allows any AP to act as an R0-KH, necessitating a full mesh of N2 security associations, which scales poorly. The model that utilizes designated R0-KHs is architecturally similar to the fast re-authentication model proposed by HOKEY. HOKEY, however, allows for handover between authenticators. This would allow an IEEE 802.11r-enabled peer to handover from one mobility domain to another without performing an EAP authentication. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: Timing over IP Connection and Transfer of Clock (tictoc)
A new IETF working group has been formed in the Internet Area. For additional information, please contact the Area Directors or the WG Chairs. Timing over IP Connection and Transfer of Clock (tictoc) Last Modified: 2008-02-12 Current Status: Active Working Group Chairs: Yaakov Stein [EMAIL PROTECTED] Stewart Bryant [EMAIL PROTECTED] Internet Area Directors: Jari Arkko [EMAIL PROTECTED] Mark Townsley [EMAIL PROTECTED] Internet Area Advisor: Mark Townsley [EMAIL PROTECTED] Mailing list: General Discussion: [EMAIL PROTECTED] To Subscribe: [EMAIL PROTECTED] In Body: subscribe your_email_address Archive: http://www1.ietf.org/mail-archive/web/tictoc Description of Working Group: The Timing over IP Connections and Transfer Of Clock (TICTOC) WG is concerned with highly accurate time and frequency distribution over native IP and MPLS-enabled IP Packet Switched Networks (PSNs). While this need arises from a variety of sources (see draft-bryant-tictoc-probstat-01.txt), the application areas of focus for this WG are: (1) Network infrastructures with the need for highly accurate time and frequency distribution within well-engineered service provider or enterprise campus networks. On-path support with specialized hardware may be expected to be available at one or more hops on a given path. (2) Individual hosts and devices on the public Internet requiring functionality or performance not currently available in NTP. On-path support may be utilized if available, but is not expected. This application brings additional requirements beyond improved accuracy, for example, the traceable and authenticated distribution of UTC time, including correct handling of leap seconds. The NTP Working Group is currently standardizing the fourth version of NTP for time distribution over IP networks. The NTP WG has focused its deliverables largely on standardizing the currently deployed NTPv4, while collecting requirements for future extensions. These requirements will transition to the tictoc WG for further development. Meeting those requirements may include revision of the protocol to a new version level. However, in all cases backwards compatibility and coexistence with currently deployed NTPv4 is a paramount concern. An applicability statement will describe the use cases for which any extension of NTP is targeted. The IEEE Test and Measurement Society is in the closing stages of standardizing a second version of IEEE1588. This is unofficially known as IEEE1588v2 and is expected to be published as IEEE1588-2008. IEEE1588v2 is emerging as a viable solution for time transfer over service provider and campus Ethernet networks, and for which on-path hardware support is becoming available. IEEE1588v2 specifically encourages other standards organizations to adapt it to their requirements, and provides guidelines for doing so. TICTOC will determine whether a profile for IEEE1588v2 over IP or MPLS-enabled IP networks would be suitable for (1), and if so will produce a profile within the guidelines provided in the IEEE1588v2 specification. An applicability statement will describe the use cases for which any profile of IEEE1588v2 is targeted. Time and Frequency distribution is considered by many to be a complex and often esoteric subject area. The WG will develop a modular framework in order to map out components within the solution space, define terminology, and identify common areas of protocol work that can be capitalized upon. TICTOC will also consider the co-existence of IEEE1588v2 and NTP in the same network. In doing so, TICTOC will first verify that the data model of NTP can be accommodated by IEEE1588v2 protocol operation and document any deficiencies compared to NTP. If there is a need to map the data models, it will produce a specification for how to utilize IEEE 1588 in a localized region as one portion of an NTP-based system. TICTOC protocols will be applicable to a variety of link layer technologies. To get the highest quality time and frequency transfer the user should take advantage of two types of on-path service where they are available: Link based frequency transfer, and hop-by-hop delay correction (for time). Examples of link based frequency support are SONET/SDH, TDM, Synchronous Ethernet and DSL with timing reference support. The main types of support that can be provided by a network element are boundary clock (where the clock is regenerated at the node in a multistage master slave relationship) and transparent clock where corrections are applied to time transfer packets as they pass through to compensate for the queuing delay, and where known for asymmetry in the link delay. Transparent clock (queue delay correction) requires routers to identify a time transfer packet, record the queuing delay, and either apply an on the fly correction to the packet, or to generate a follow-up packet with
RFC 4693 Experiment Conclusion
The IETF Operational Notes (IONs) experiment has concluded. The IESG has determined that IONs will not be used in the future. It is clear that the IESG, IAB, and IAOC need the ability to publish documents that do not expire and are easily updated. Information published as web pages, including IESG Statements, are sufficient for this purpose. The IESG intends to employ some form of version control so that previous versions of IESG Statements will be available on line. As specified in RFC 4693, the existing ION documents now have the same status as any other Web page or file on the IETF servers. Accordingly, the IONs that were developed during the experiment will be republished as follows: + ion-ad-sponsoring will be published as an IESG Statement + ion-agenda-and-minutes will be published as a web page + ion-discuss-criteria will be published as an IESG Statement + ion-ion-format will be discarded + ion-ion-store will be discarded + ion-procdocs will be published as a web page + ion-rfc-2026-in-practice has already been published as an I-D + ion-tsv-alt-cc will be published as an IESG Statement The IESG has also recommended that the following documents be republished as IAOC web pages: + ion-execd-tasks + ion-meeting-network-requirements + ion-subpoena The discussion on the appropriate type of document for the ion-discuss- criteria will continue. The decision that this particular ION become an IESG Statement at this point in time is not intended to forecast the outcome of this discussion; rather, it is a fulfillment of the statement in RFC 4693, which says: If the IESG decides that the feedback warrants terminating the series, the repository will be closed for new documents, and the existing ION documents will be returned to having the same status as any other Web page or file on the IETF servers -- this situation will closely resemble the situation before the experiment started. Much thanks to the ION authors and the people that provided comments on the experiment. On behalf of the IESG, Russ Housley ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
