Re: watersprings.org archive of expired Internet Drafts
On 10/10/11 02:23 , t.petch wrote: Original Message - From: Julian Reschke julian.resc...@gmx.de To: t.petch daedu...@btconnect.com Cc: Frank Ellermann hmdmhdfmhdjmzdtjmzdtzktdkzt...@gmail.com; ietf@ ietf.org Sent: Saturday, October 08, 2011 3:07 PM On 2011-10-08 09:20, t.petch wrote: If I'm looking for an internet draft where I only know parts of the name I usually use a search engine; that's what they are for. With the current flavour of the IETF web site, I usually go via charters - WG - I-D list and then find 103 I-Ds in an order I cannot divine, give up and accept that I will have to type in d r a f t - i e t f - w g etc etc. Another waste of my time along with gif download, xml processing etc oh, did I mention all the javascripts that try to out think me and get in the way? mutter mutter ... What does XML have to do with all of this? Julian On a thread on this list some time ago, IANA reported progress in converting their web site to XML and at the same time, apologised for how long it now takes to access the Port Registry. Having accessed it - a good chance to complete The Times crossword! - I found an XML file in excess of 1Mbyte on my workstation. It's in excess of a bit more than a megabyte. Zorch:Desktop jjaeggli$ du -h service-names-port-numbers.xml 3.8M(as rendered using the xsl) service-names-port-numbers.xml 3.0M(bare) service-names-port-numbers.xml Making a wild leap of imagination, I guessed that the time it took to access the web page was due, at least in part, to these multi-megagbytes of XML, but I could be wrong. when we make dogfood, we can be expected to eat it from time to time. just maybe a flat file of structured data isn't the best way to render 9125 registerd ports and 4330 people for the web. Tom Petch Best regards, Julian ___ 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: Last Call draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Hi, This is good input and made me realize what I disliked in the document which made me oppose to its publication. People (rightfully) pressed on the significance of the document to be about a general principle - one solution to any given problem. The IETF, _without_ external help, has a history of going down this road. Nobody stood up to stop that. Nobody wrote such a document then. Why now? Turf war, not invented here syndrome? I think it doesn't really matter. What would make my opposition go away is if we could write a more general document in which we point our own failings in the past, take this current issue into consideration and make it clear - in general - that the IETF is committed to follow this general principle more strictly in the future. _That_ would be a useful document and one which I would support. And it would be good if we could have such kind of pushback for multiple solutions in the future. WG chairs can take this document, show it to their WG and say Guy s, this is a guiding IETF principle. Get your act together and come up with a single solution. We will not have two or more.. Just ranting about this particular case is not helpful with all the multi-solutions we have created ourselves. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Stephen Kent Sent: Montag, 10. Oktober 2011 21:41 To: ietf@ietf.org Subject: Re: Last Call draft-sprecher-mpls-tp-oam-considerations- 01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC I support this doc, and concur with Stewart's comments. Contrary to what some have suggested, we sometimes (ofttimes?) have more than one standard for no good technical reason. Sometimes very large, competing companies back different standards for parochial reasons, to the detriment of consumers, service providers, etc. This appears to be one of those cases. Moreover, not opposing a two-standard approach sends a bad message, and encourages similar, bad behavior in the future. As the co-chair of PKIX, which has two standards for cert management (CMC and CMP), for exactly the bad reasons I cite above, I am intimately familiar with this sort of problem. I failed, in my role as PKIX co-chair, to prevent this in that WG. Let's not repeat that sort of mistake here. Steve ___ 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: [mpls] R: FW: Last Call:draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons forSelecting a Single Solution for MPLS-TP OAM) to Informational RFC
Hi, Same here: Yes/Support. Cyril -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext John E Drake Sent: Thursday, October 06, 2011 1:11 PM To: David Sinicrope; David Allan I Cc: m...@ietf.org; ietf@ietf.org Subject: RE: [mpls] R: FW: Last Call:draft-sprecher-mpls-tp-oam- considerations-01.txt (The Reasons forSelecting a Single Solution for MPLS-TP OAM) to Informational RFC As do I -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of David Sinicrope Sent: Wednesday, October 05, 2011 7:11 PM To: David Allan I Cc: m...@ietf.org; ietf@ietf.org Subject: Re: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam- considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC I concur with Dave's comment and support publication of the draft. Dave On Oct 5, 2011, at 7:06 PM, David Allan I david.i.al...@ericsson.com wrote: I think it is unfortunate that we are in a situation where such a document has utility. But ultimately it does. Therefore I support the publication of draft-sprecher... D MPLS Working Group, Please be aware of the IETF last call as shown below. The document was presented for publication as an individual RFC with IETF consensus and AD sponsorship. This draft is clearly close and relevant to the work you do, but after discussing with the chairs I came to the conclusion that it does not comment on the technical or process decisions of the MPLS working groups, and it does not attempt to make any technical evaluations or definitions within the scope of the MPLS working group. It is more of a philosophical analysis of the way the IETF approaches the two solutions problem with special reference to MPLS-TP OAM. Thus, I am accepting the document as AD Sponsored rather than running it through the MPLS working group. My reasoning is that the working group has got plenty to do working on technical issues without being diverted into wider IETF philosophy. As an AD Sponsored I-D it is subject to a four week IETF last call. That is plenty of opportunity for everyone to comment and express their views. Please send your comments to the IETF mailing list as described below, or (in exceptional circumstances) direct to the IESG. Thanks, Adrian ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Huub, you are partly right - slide 9 says that there are open issues. But at the last meeting with the JWT consensus on the *summary* was the issue. The questions was put explicitly. At that time no one voiced another opinion! /Loa On 2011-10-09 12:58, Huub van Helvoort wrote: Hello Russ, You write: RFC 5317 calls for one, and only one, protocol solution. At least that is how I read JWT Agreement. How the JWT report should be read is written on slide 9 in the PDF: This presentation is a collection of *assumptions*, discussion points and decisions that the combined group has had during the months of March and April, 2008 This represents the *agreed upon starting point* for the technical analysis of the T-MPLS requirements from the ITU-T and the MPLS architecture to meet those requirements The most relevant text seems to be in Section 9: This text is one of the assumptions, that is why we wrote: *They stated that in their view*: it is technically feasible that the existing MPLS architecture can be extended to meet the requirements of a Transport profile, and that the architecture allows for a single OAM technology for LSPs, PWs, and a deeply nested network. The OAM technology in this text refers to to way the OAM frames can be detected in a data-stream. The text you quote is from the summary section, it summarizes the slides 19 - 22: *MPLS-TP Major Solution Constructs* which address the GAL-GAch solution. We now have the GAL-GAch technology (RFC5586) to detect OAM frames and this technology will be used in PW and LSP, and enables the use of OAM in deeply nested networks. Since the publication of RFC 5317, the MPLS WG consensus continues to be that only one OAM solution should become a standard. All MPLS-TP OAM tools should comply with RFC5586. A service provider can now pick any set or sub-set of the available OAM tools and use them without fear to disrupt the internet. Looking at the current discussions, there is no consensus (yet) on whether we need a comprehensive set of OAM tools, or a very limited set of OAM tools. Best regards, Huub (JWT, Ad-Hoc, MEAD member). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 6302: Internet-Facing Server Logging: No Word about Privacy?
Hi Dan, I missed your mail. Sorry. Yes, I understand what the document is trying to say. The insight that the presence of NAT also requires you to log the port number is certainly not a new insight. My worry with the document is that if you have to give someone who deploys services such trivial information (as it is done with the draft) then it is quite likely that they also need to be told something about privacy. As the discussion around Web tracking shows there is little understanding of meet the privacy expectations of regulators. Cullen had also raised privacy concerns in his review, see http://www6.ietf.org/mail-archive/web/ietf/current/msg65610.html, but his remarks had not been taken into consideration. Ciao Hannes On Jul 27, 2011, at 9:22 PM, Dan Wing wrote: -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Wednesday, July 27, 2011 1:52 PM To: ietf@ietf.org IETF Subject: RFC 6302: Internet-Facing Server Logging: No Word about Privacy? Hi all, I just noticed this document about Internet-Facing Server Logging: http://tools.ietf.org/html/rfc6302 It does not contain any privacy considerations even thought it would be a very natural thing to do. Does anyone know the history of this document? It's trying to say that today, servers routinely log: * timestamp * source IPv4 address * resource accessed and that servers, compliant with RFC6302, need to additionally log: * source port -d Ciao Hannes ___ 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: [mpls] R: FW:LastCall: draft-sprecher-mpls-tp-oam-considerations-01.txt(TheReasons for Selecting a Single Solution for MPLS-TP OAM)toInformational RFC
Hi, I support publication of this document, although I do have some comments on the composition of sections 4 5 that I will privately provide the editors. Yaacov Weingarten -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of ext Luyuan Fang (lufang) Sent: Thursday, October 06, 2011 5:24 PM To: John E Drake; David Sinicrope; David Allan I Cc: m...@ietf.org; ietf@ietf.org Subject: Re: [mpls] R: FW:LastCall: draft-sprecher-mpls-tp-oam-considerations-01.txt(TheReasons for Selecting a Single Solution for MPLS-TP OAM)toInformational RFC Same here. I support publication of the draft. Luyuan -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of John E Drake Sent: Thursday, October 06, 2011 7:11 AM To: David Sinicrope; David Allan I Cc: m...@ietf.org; ietf@ietf.org Subject: Re: [mpls] R: FW: LastCall: draft-sprecher-mpls-tp-oam- considerations-01.txt (TheReasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC As do I -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of David Sinicrope Sent: Wednesday, October 05, 2011 7:11 PM To: David Allan I Cc: m...@ietf.org; ietf@ietf.org Subject: Re: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam- considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC I concur with Dave's comment and support publication of the draft. Dave On Oct 5, 2011, at 7:06 PM, David Allan I david.i.al...@ericsson.com wrote: I think it is unfortunate that we are in a situation where such a document has utility. But ultimately it does. Therefore I support the publication of draft-sprecher... D MPLS Working Group, Please be aware of the IETF last call as shown below. The document was presented for publication as an individual RFC with IETF consensus and AD sponsorship. This draft is clearly close and relevant to the work you do, but after discussing with the chairs I came to the conclusion that it does not comment on the technical or process decisions of the MPLS working groups, and it does not attempt to make any technical evaluations or definitions within the scope of the MPLS working group. It is more of a philosophical analysis of the way the IETF approaches the two solutions problem with special reference to MPLS-TP OAM. Thus, I am accepting the document as AD Sponsored rather than running it through the MPLS working group. My reasoning is that the working group has got plenty to do working on technical issues without being diverted into wider IETF philosophy. As an AD Sponsored I-D it is subject to a four week IETF last call. That is plenty of opportunity for everyone to comment and express their views. Please send your comments to the IETF mailing list as described below, or (in exceptional circumstances) direct to the IESG. Thanks, Adrian ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 6302: Internet-Facing Server Logging: No Word about Privacy?
On Tue, Oct 11, 2011 at 04:42:17PM +0300, Hannes Tschofenig hannes.tschofe...@gmx.net wrote a message of 58 lines which said: it is quite likely that they also need to be told something about privacy. For me, the most important mention of privacy is: It is RECOMMENDED as best current practice that Internet-facing servers logging incoming IP addresses from inbound IP traffic also log: Do note Internet-facing servers ***logging incoming IP addresses***. It means that noone recommends to log IP addresses, the RFC just says that, ***if you do log***, logging the IP address without the port number is not very sensible. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 6302: Internet-Facing Server Logging: No Word about Privacy?
Hannes Tschofenig wrote: Yes, I understand what the document is trying to say. The insight that the presence of NAT also requires you to log the port number is certainly not a new insight. My worry with the document is that if you have to give someone who deploys services such trivial information (as it is done with the draft) then it is quite likely that they also need to be told something about privacy. As the discussion around Web tracking shows there is little understanding of meet the privacy expectations of regulators. What this document describes will often be illegal in Germany, and you risk a fine up to 30 Euro for doing it on an Internet-Facing server. 3.5 years ago there was an illegal data privacy violation of a technically different kind that made the german news: http://content.stuttgarter-zeitung.de/stz/page/1629475_0_9223_-reinigungsrechnung-an-kundin-volksbank-macht-rueckzieher.html It was about some smelly mess (allegedly dog shit) on the floor near a bank's ATM, and the bank examined their video surveillance tapes to find who caused the mess and found out that it was from a 3 year old girl whose mother had withdrawn money at the ATM (and they got the mother's name from the ATMs log). They sent this mother a cleaning bill of 50 Euros. Besides the fact that childs below the age of 7 can not be legally held responsible for their actions in Germany--and their parents (or whoever was in charge of supervision) can only be held responsible in case of gross negligence, it was a violation of german privacy laws for the bank to examine the video and ATM logs to determine the mother's name. And although the bank back-pedaled the day _after_ this story made the news, their privacy violation resulted in a formal investigation by the public authorities against the bank. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 6302: Internet-Facing Server Logging: No Word about Privacy?
I believe there is room to do better: A quick look at the Fair Information Practices (FIPs) would provide a good starting point: Notice and Consent: Before the collection of data, the data subject should be provided: notice of what information is being collected and for what purpose and an opportunity to choose whether to accept the data collection and use. Collection Limitation: Data should be collected for specified, explicit and legitimate purposes. The data collected should be adequate, relevant and not excessive in relation to the purposes for which they are collected. Use/Disclosure Limitation: Data should be used only for the purpose for which it was collected and should not be used or disclosed in any way incompatible with those purposes. Retention Limitation: Data should be kept in a form that permits identification of the data subject no longer than is necessary for the purposes for which the data were collected. Accuracy: The party collecting and storing data is obligated to ensure its accuracy and, where necessary, keep it up to date; every reasonable step must be taken to ensure that data which are inaccurate or incomplete are corrected or deleted. Access: A data subject should have access to data about himself, in order to verify its accuracy and to determine how it is being used. Security: Those holding data about others must take steps to protect its confidentiality. On Oct 11, 2011, at 5:17 PM, Stephane Bortzmeyer wrote: On Tue, Oct 11, 2011 at 04:42:17PM +0300, Hannes Tschofenig hannes.tschofe...@gmx.net wrote a message of 58 lines which said: it is quite likely that they also need to be told something about privacy. For me, the most important mention of privacy is: It is RECOMMENDED as best current practice that Internet-facing servers logging incoming IP addresses from inbound IP traffic also log: Do note Internet-facing servers ***logging incoming IP addresses***. It means that noone recommends to log IP addresses, the RFC just says that, ***if you do log***, logging the IP address without the port number is not very sensible. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [apps-discuss] Last Call: draft-ietf-appsawg-rfc3462bis-01.txt (The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages) to Draft Standard
08.10.2011 17:11, Mykyta Yevstifeyev wrote: 26.09.2011 17:05, The IESG wrote: The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages' draft-ietf-appsawg-rfc3462bis-01.txt as a Draft Standard The IESG has already approved draft-housley-two-maturity-levels, so Draft Standard isn't now available as a target maturity level. How is IESG going to handle this? Now, RFC 6410 is what this document has been published as, so the changes are indeed in the force. So should we rather advance the document to Full Standard or recycle at Proposed? Mykyta Yevstifeyev ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Gen-art] Gen-ART Last Call Review of draft-ietf-pwe3-static-pw-status-08
Hi, Thanks for the response. Some comments inline. I removed sections that seem to be resolved. Thanks! Ben. On Oct 7, 2011, at 6:21 PM, Luca Martini wrote: Ben, Thank you for the review . Some comments below. Luca On 10/04/11 16:13, Ben Campbell wrote: 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-pwe3-static-pw-status-08 Reviewer: Ben Campbell Review Date: 2011-10-04 IETF LC End Date: 2011-10-05 Summary: The draft is almost ready for publication as a proposed standard, but there are a few minor issues and editorial issues that need addressing first. Major issues: None Minor issues: -- 5.3: Has the work group considered how the retransmit scheme and 30 second refresh default will scale to very large deployments? Seems like this could result in a lot of retransmissions. Yes. that is correct. This will most likely not scale for large deployments. We have another document draft-ietf-pwe3-status-reduction-00.txt that addresses this issue. That extension is not necessary for most common small deployments in the order of 100 PWs per access PE. That's reasonable--a few words to that effect might be helpful. […] -- 5.3.1, 1st paragraph: The receiving PE will then set its timeout timer according to the timer value that is in the packet received, regardless of what timer value it sent. It's probably worth making a normative statement here, since it seems like this could easily result in an argument if the PEs disagree on the timer value. An argument between who ? Between the sending and receiving PE. I see a problem is the fact that we need to state a good practice implementation policy. Basically the PE should not insist on the value that was just refused. I'll add some text to clarify this. What that what you intended ? Something along those lines, yes. […] -- 5.5, last paragraph: This could use some elaboration. What is the purpose of having to send both ways? Keep the state of S-PEs in sync between LDP and the in-band bypass mode. That is what is stated here. S-PEs are PE that are in the middle of the path. They can also originate PW status messages , but only using LDP. There is fairly complicated state machine described in rfc6073 that would break if the messages are not sent in LDP as well. That makes sense. A sentence to that effect might be helpful (but not absolutely required) […] -- 8 : IANA Considerations It would help to include the formal definition tables here, or reference them here. Also, can you include the URLs for each registry? Tables have always been called out by name. What are formal definition tables ? I do not understand this comment. Iana section is quite clear. I meant figures instead of tables. But on reflection, I should have said sections. For example, section 5.1 of this draft formally defines the PW OAM message. It would be helpful if the IANA consideration section for PW OAM referred back to that section. A reader who is tracing back to an RFC from an IANA definition will often start out looking in the IANA consideration section, and such a reference makes things a bit friendlier when the definition is in another section of the document. […] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-pim-port-08.txt
Thanks for the review Gorry, please see below. On 10/7/2011 4:28 AM, Gorry Fairhurst wrote: Hi, all, I've reviewed this document as a part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. The document describes a protocol that is designed to use a TCP or SCTP transport. The use of TCP is application-limited and a negotiation mechanism is provided that helps select whether TCP or SCTP should be used. The note below includes transport issues, as well as additional comments that I hope are also useful. I hope this feedback will be useful to the authors, and will be glad to provide further assistance either on- or off-list as useful. Gorry - Overall this document seems complete and uses standard IETF transport mechanisms that support congestion control. Introduction: Recommend to specify the IANA-assigned port. Since this specifies a protocol that runs over a specific IANA-allocated port it would be good if the port number was mentioned in the Introduction. This may confirm that this is the correct document to read to find out about what happens when port 8471 is used (e.g. someone interpreting IPFIX or building a NAT, Firewall, etc). OK, can do that. I think they would typically check the IANA registry first though? Section 4 (and others, including section 7): AF for transport. I understand there is a rule to prefer SCTP over TCP when both transports are available. This seems OK. Various sections refer to the support for multiple address families (IPv4, IPv6) and I understand that the PORT information for an AF does need not to be carried over a transport connection using the same AF. What I do not yet understand is how PORT knows whether to use an IPv4 transport for IPv6 or to use an IPv6 transport for IPv6. I'd like this to be clear, so that I can understand what happens when TCP is available over Ipv4 and SCTP only over IPv6 and similar combinations. Which address family and address to use is determined by the Connection ID in the PORT Hello Option. It is up to the implementation and admin to choose which address the connection should go to. There are several implementation choices, but I think it will be common to use the primary interface address (the source address of PIM messages) as a default Connection ID, but allow the administrator to configure another address. The administrator can then choose which address and family to configure. Section 4.2: TCP keep-alive. SCTP heartbeat is described. I understand PORT also includes an optional keep-alive mechanism using the transport service. TCP also contains an optional keep-alive mechanism. This should be mentioned. Is TCP keep-alive recommended for PORT or does the protocol recommend a keep-alive at the PORT layer? We chose to have our own keep-alive mechanism, as we believe that is better. There is nothing stopping an implementation from enabling TCP keep-alive if they want though. I guess we could do this change: OLD: SCTP has a heart beat mechanism that can be used to detect that a connection is working, even when no data is sent. NEW: SCTP has a heart beat mechanism that can be used to detect that a connection is not working, even when no data is sent. Many TCP implementations also support sending keep-alives for this purpose. Note that I changed working to not working, I think it makes more sense that way. We're trying to not give any specific recommendations here, only enough to ensure interoperability. Both TCP keep-alive and the use of PORT keep-alive can be decided by independently by the peers. Note that this is an experimental protocol, and hopefully what works best, or is the preferred solution will become clearer with real use. Section 4.2: TCP Reset The present text says that the TCP connection will be reset after a few reties. This does not seem clear. A lack of acknowledgement for a sent data segment will result in the underlying TCP tansport retransmitting after the Retransmission Time Out (RTO). Furthermore this would cause the RTO to be doubled with each retransmission, until the RTO exceeds the maximum value when the connection will be reset, this is typically many 10s of seconds later. OK, what if I change it into a few TCP retransmissions? The main purpose here is to explain that we notice the connection is going down as long as we periodically send data. We're not going into details about exactly how long it takes. Section 5: Unexpected corruption of the stream It is good to see the service using the transport, in this case PORT verifies the integrity of the transported data. The recommendation seems to be
RE: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Huub van Helvoort wrote 09 October 2011 12:42 To: IETF Discussion Subject: Re: Last Call: draft-sprecher-mpls-tp-oam-considerations- 01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC All, I still do not support this draft. Section 6 focusses on the interworking between two toolsets In transport networks we *never* have peer-2-peer OAM interworking. If it was required it would have explicitly been mentioned in the MPLS-TP requirements RFC. Indeed, to have any peer to peer OAM simply removes the ability of the OAM to do its job. regards, Neil Why don't you simply read draft-tsb-mpls-tp-ach-ptn or Annex B of G.8110.1 where it is documented how different toolsets can be deployed in a network without any issues. Section 6 is totally irrelevant. Regards, Huub. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
This is not actually correct. The IETF has a very long history of pushing back on multiple redundant solutions to the same problem. There are a great many cases of ADs, working group chairs, and others pushing quite hard to prevent multiple solutions when one would work fine. In the very many previous cases it was not necessary to write a document because the second (or third, or ...) solution was within the same standards body, and it was possible to either prevent publication, or publish the second solution as informational, or publish the second solution with a disclaimer up front saying some form of we recommend this other solution [add normative reference] which is the agreed IETF standard. Ross -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Rolf Winter Sent: Tuesday, October 11, 2011 3:51 AM To: Stephen Kent; ietf@ietf.org Subject: RE: Last Call draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC Hi, This is good input and made me realize what I disliked in the document which made me oppose to its publication. People (rightfully) pressed on the significance of the document to be about a general principle - one solution to any given problem. The IETF, _without_ external help, has a history of going down this road. Nobody stood up to stop that. Nobody wrote such a document then. Why now? Turf war, not invented here syndrome? I think it doesn't really matter. What would make my opposition go away is if we could write a more general document in which we point our own failings in the past, take this current issue into consideration and make it clear - in general - that the IETF is committed to follow this general principle more strictly in the future. _That_ would be a useful document and one which I would support. And it would be good if we could have such kind of pushback for multiple solutions in the future. WG chairs can take this document, show it to their WG and say Guy s, this is a guiding IETF principle. Get your act together and come up with a single solution. We will not have two or more.. Just ranting about this particular case is not helpful with all the multi-solutions we have created ourselves. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Stephen Kent Sent: Montag, 10. Oktober 2011 21:41 To: ietf@ietf.org Subject: Re: Last Call draft-sprecher-mpls-tp-oam-considerations- 01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC I support this doc, and concur with Stewart's comments. Contrary to what some have suggested, we sometimes (ofttimes?) have more than one standard for no good technical reason. Sometimes very large, competing companies back different standards for parochial reasons, to the detriment of consumers, service providers, etc. This appears to be one of those cases. Moreover, not opposing a two-standard approach sends a bad message, and encourages similar, bad behavior in the future. As the co-chair of PKIX, which has two standards for cert management (CMC and CMP), for exactly the bad reasons I cite above, I am intimately familiar with this sort of problem. I failed, in my role as PKIX co-chair, to prevent this in that WG. Let's not repeat that sort of mistake here. Steve ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
This is not actually correct. The IETF has a very long history of pushing back on multiple redundant solutions to the same problem. There are a great many cases of ADs, working group chairs, and others pushing quite hard to prevent multiple solutions when one would work fine. In the very many previous cases it was not necessary to write a document because the second (or third, or ...) solution was within the same standards body, and it was possible to either prevent publication, or publish the second solution as informational, or publish the second solution with a disclaimer up front saying some form of we recommend this other solution [add normative reference] which is the agreed IETF standard. as ops ad, i had to do that with cops randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Ross, See inline. This is not actually correct. The IETF has a very long history of pushing back on multiple redundant solutions to the same problem. There are a great many cases of ADs, working group chairs, and others pushing quite hard to prevent multiple solutions when one would work fine. I didn't mean to say that the IETF in general allows multiple solutions but I think it is accurate to say that the IETF has a less than 100% success rate of preventing multiple solutions. In the very many previous cases it was not necessary to write a document because the second (or third, or ...) solution was within the same standards body, and it was possible to either prevent publication, or publish the second solution as informational, or publish the second solution with a disclaimer up front saying some form of we recommend this other solution [add normative reference] which is the agreed IETF standard. You are making a point on which I picked earlier because it is stated in the document as well. In case there are multiple solutions, documenting, but at the same time discouraging the other one has happened before. Why is this not possible in this case? Make one the default, the other optional with a big red warning sign. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
I didn't mean to say that the IETF in general allows multiple solutions but I think it is accurate to say that the IETF has a less than 100% success rate of preventing multiple solutions. Correct. We are not perfect. In the very many previous cases it was not necessary to write a document because the second (or third, or ...) solution was within the same standards body, and it was possible to either prevent publication, or publish the second solution as informational, or publish the second solution with a disclaimer up front saying some form of we recommend this other solution [add normative reference] which is the agreed IETF standard. You are making a point on which I picked earlier because it is stated in the document as well. In case there are multiple solutions, documenting, but at the same time discouraging the other one has happened before. Why is this not possible in this case? Make one the default, the other optional with a big red warning sign. Best, Rolf This is indeed possible in this case. It has been privately suggested multiple times, but I agree that this should have been publicly suggested as well (and thus I guess that I am publicly suggesting it now). Ross ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
meeting slots
In deciding whether to attend a IETF meeting or not it would be useful to know if chairs have requested a meeting slot or have decided not to meet or are still undecided. This information is known well before a actual agenda is drawn up. Why is it, effectively, hidden until the agenda is published? Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
WG Review: Binary Floor Control Protocol Bis (bfcpbis)
A new IETF working group has been proposed in the Real-time Applications and Infrastructure 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, October 18, 2011. Binary Floor Control Protocol Bis (bfcpbis) Status: Proposed Working Group Last Updated: 2011-09-20 Chairs: TBD Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo gonzalo.camari...@ericsson.com Robert Sparks rjspa...@nostrum.com Real-time Applications and Infrastructure Area Advisor: Gonzalo Camarillo gonzalo.camari...@ericsson.com Mailing Lists: General Discussion: TBD To Subscribe: TBD Archive:TBD The BFCPBIS working group is chartered to specify a revision of BFCP (RFC 4582) to support using both TCP and UDP as transports. The current version of BFCP only supports TCP, which when both endpoints are behind NATs or firewalls, has a lower success rate than using the ICE techniques with a UDP based transport for BFCP. The need for video endpoints to work in these types of environments is driving a strong need to support a UDP based transport as well as TCP. This WG will create a revision of RFC 4582 which adds optional support for UDP to BFCP. The security when using UDP will be based on DTLS. The updated protocol will use an existing approach (e.g., stop and wait with a single outstanding transaction) to provide a reliable, congestion safe, and TCP friendly transport. In addition to providing a way for dealing with the reliable delivery of client-initiated transactions, the updated protocol will also be able to deliver server-initiated transactions reliably when needed. The WG will research the size of messages used and decide if fragmenting a request or response over multiple UDP packets is required. The new protocol will be backwards compatible with RFC 4582 when used in TCP mode. The BFCPBIS WG will coordinate closely with the MMUSIC WG to create a revision of RFC 4583 specifying how BFCP is signaled in SDP so that it supports UDP as well as TCP transports. This WG would ask the MMUSIC WG to add a milestone to create a revisions of RFC 4583 to address signaling the use of UDP in SDP. The WG will coordinate with International Multimedia Telecommunications Consortium (IMTC) and other industry fora. Milestones: April 2012 Draft revision of RFC 4582 to IESG ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Review: Managed Incident Lightweight Exchange (mile)
A new IETF working group has been proposed in the Security 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, October 18, 2011. Managed Incident Lightweight Exchange (mile) Status: Proposed Working Group Charter Last Updated: 2011-09-21 Chairs: TBD Security Area Directors: Stephen Farrell stephen.farr...@cs.tcd.ie Sean Turner turn...@ieca.com Security Area Advisor: Sean Turner turn...@ieca.com Mailing Lists: General Discussion: m...@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/mile Archive:http://www.ietf.org/mail-archive/web/mile Description: The Managed Incident Lightweight Exchange (MILE) working group will develop standards and extensions for the purpose of improving incident information sharing and handling capabilities based on the work developed in the IETF Extended INCident Handling (INCH) working group. The Incident Object Description Exchange Format (IODEF) in RFC5070 and Real-time Inter-network Defense (RID) in RFC6045 were developed in the INCH working group by international Computer Security Incident Response Teams (CSIRTs) and industry to meet the needs of a global community interested in sharing, handling, and exchanging incident information. The extensions and guidance created by the MILE working group assists with the daily operations of CSIRTs at an organization, service provider, law enforcement, and at the country level. The application of IODEF and RID to interdomain incident information cooperative exchange and sharing has recently expanded and the need for extensions has become more important. Efforts continue to deploy IODEF and RID, as well as to extend them to support specific use cases covering reporting and mitigation of current threats such as anti-phishing extensions. An incident could be a benign configuration issue, IT incident, an infraction to a service level agreement (SLA), a system compromise, socially engineered phishing attack, or a denial-of-service (DoS) attack, etc. When an incident is detected, the response may include simply filing a report, notification to the source of the incident, a request to a third party for resolution/mitigation, or a request to locate the source. IODEF defines a data representation that provides a standard format for sharing information commonly exchanged about computer security incidents. RID enables the secure exchange of incident related information in an IODEF format providing options for security, privacy, and policy setting. MILE leverages collaboration and sharing experiences with the work developed in the INCH working group which includes the data model detailed in the IODEF, existing extensions to the IODEF for Anti-phishing (RFC5901), and RID (RFC6045, RFC6046) for the secure exchange of information. MILE will also leverage the experience gained in using IODEF and RID in operational contexts. Related work, drafted outside of INCH will also be reviewed and includes RFC5941, Sharing Transaction Fraud Data. The MILE working group provides coordination for these various extension efforts to improve the capabilities for exchanging incident information. MILE has several objectives with the first being a description a subset of IODEF focused on ease of deployment and applicability to current information security data sharing use cases. MILE also describes a generalization of RID for secure exchange of other security-relevant XML formats. MILE produces additional guidance needed for the successful exchange of incident information for new use cases according to policy, security, and privacy requirements. Finally, MILE produces a document template with guidance for defining IODEF extensions to be followed when producing extensions to IODEF as appropriate, for: * labeling incident reports with data protection, data retention, and other policies, regulations, and laws restricting the handling of those reports * referencing structured security information from within incident reports * reporting forensic data generated during an incident investigation (computer or accounting) The WG will produce the following: * An informational document on IODEF Guidance. * A Standards Track document specifying the Real-time Inter-network Defense (RID). * A Standards Track document specifying the transport for RID. * An informational template for extensions to IODEF. * A Standards Track document for IODEF Extensions in IANA XML Registry. * A Standards Track document for IODEF Extension to support structured cybersecurity information. * A Standards Track document for Labeling for data protection, retention, policies, and regulations. * A Standards Track
CUSS Working Group Virtual Interim Meeting: October 25, 2011
The CUSS working group will hold a virtual interim meeting, with WebEx support, as follows: Date/Time: Tue, October 25 2011 @ 10:00 AM - 12:00 PM Chicago / 5:00 PM - 7:00 PM Frankfurt, Rome WebEx details for this meeting will be posted to the CUSS mailing list (http://www.ietf.org/mail-archive/web/cuss/). ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-kitten-sasl-openid-06.txt (A SASL GSS-API Mechanism for OpenID) to Proposed Standard
The IESG has received a request from the Common Authentication Technology Next Generation WG (kitten) to consider the following document: - 'A SASL GSS-API Mechanism for OpenID' draft-ietf-kitten-sasl-openid-06.txt as a Proposed Standard 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 2011-10-25. 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 OpenID has found its usage on the Internet for Web Single Sign-On. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL and GSS-API mechanism for OpenID that allows the integration of existing OpenID Identity Providers with applications using SASL and GSS-API. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-openid/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-openid/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-geopriv-policy-uri-02.txt (Location Configuration Extensions for Policy Management) to Informational RFC
The IESG has received a request from the Geographic Location/Privacy WG (geopriv) to consider the following document: - 'Location Configuration Extensions for Policy Management' draft-ietf-geopriv-policy-uri-02.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-10-25. 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 Current location configuration protocols are capable of provisioning an Internet host with a location URI that refers to the host's location. These protocols lack a mechanism for the target host to inspect or set the privacy rules that are applied to the URIs they distribute. This document extends the current location configuration protocols to provide hosts with a reference to the rules that are applied to a URI, so that the host can view or set these rules. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-geopriv-policy-uri/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-geopriv-policy-uri/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-geopriv-deref-protocol-03.txt (A Location Dereferencing Protocol Using HELD) to Proposed Standard
The IESG has received a request from the Geographic Location/Privacy WG (geopriv) to consider the following document: - 'A Location Dereferencing Protocol Using HELD' draft-ietf-geopriv-deref-protocol-03.txt as a Proposed Standard 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 2011-10-25. 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 This document describes how to use the Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS) as a dereferencing protocol to resolve a reference to a Presence Information Data Format Location Object (PIDF-LO). The document assumes that a Location Recipient possesses a URI that can be used in conjunction with the HELD protocol to request the location of the Target. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-geopriv-deref-protocol/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-geopriv-deref-protocol/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Nomcom 2011-2012: Call for community feedback
As per RFC 5680, NomCom 2011-2012 is issuing a call to the entire IETF community for feedback on the Willing Nominees for the open IETF positions. Nominations for the open positions are now closed and the list of willing nominees is now quite stable. Why is feedback important? == Feedback is information you think will help NomCom make a decision on selecting candidates for open IETF positions. Feedback should be based on information you know first hand about an individual nominee. Community feedback is the most important input that determines who fills the open positions. We cannot properly execute the task of selecting the best candidates for the open positions without **YOUR** participation and feedback. Review the list of willing nominees and open positions == The open list is currently available on the Nomcom page and the entire community is invited to provide feedback on all nominees. You can provide your comments on all willing nominees at the following URL: https://www.ietf.org/group/nomcom/2011/input/ where the list of willing nominees is available and sorted by open position. IMPORTANT NOTE: Access to the Provide Feedback pages requires an www.ietf.org login. Logins used for previous years' nomcom pages used the tools.ietf.org login, which is separate. To get a www.ietf.org login if you don't already have one, please go to this page: https://datatracker.ietf.org/accounts/create/ Means of providing feedback to the NomCom = You can use one (or more) of the following methods to provide feedback to the Nomcom: - The best method is to enter it directly on the NomCom website at https://www.ietf.org/group/nomcom/2011/input/ . Click on the name of the person who you are providing feedback about and enter the text you want to provide us. - Send an email to nomco...@ietf.org and be sure to identify the nominee and position the feedback pertains to. - Contact one (or more) of the Nomcom members by email. - Contact us in person in Taipei during our office hours. (to be announced soon) - You can provide **anonymous** feedback by contacting either the Nomcom chair or any of the Nomcom members who will anonymize it for the rest of the members. I would like to thank everyone who has provided us feedback already, and hope that more people from the community will take time to provide us further feedback. Suresh Krishnan Chair, NomCom 2011-2012 nomcom-ch...@ietf.org suresh.krish...@ericsson.com ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control' to Proposed Standard (draft-ietf-sipcore-event-rate-control-09.txt)
The IESG has approved the following document: - 'Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control' (draft-ietf-sipcore-event-rate-control-09.txt) as a Proposed Standard This document is the product of the Session Initiation Protocol Core Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sipcore-event-rate-control/ Technical Summary This document specifies mechanisms for adjusting the rate of Session Initiation Protocol (SIP) event notifications. These mechanisms can be applied in subscriptions to all SIP event packages. Working Group Summary Many working group members tended to express mild confusion or bewilderment upon first encountering the behavior described in section 5 (minimum notification rate). It is worth noting that this is the exact behavior that is required by the GEOPRIV work. This confusion is typically ameliorated when they are presented with use cases similar to those being considered by GEOPRIV. Document Quality Martin Thompson provided significant input to the document on behalf of the GEOPRIV working group, who is an immediate customer for this document. Brian Rosen identified the suitability of this mechanism in satisfying GEOPRIV's requirements, and made the initial proposal for the minimum rate mechanism for that purpose. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
IETF 88 in Vancouver
The IAOC is pleased to announce Vancouver, BC, Canada as the site for IETF 88 from November 3 - 8, 2013. This will be the IETF's fifth meeting in Vancouver, the others being 18, 64, 70 and 84. IETF 88 was targeted to be held in Asia-Pacific, however after a 7 month search we were unable to find a venue on our dates, that was reasonably priced for attendees and sponsors, met our meeting space and technology requirements, and had an acceptable visa policy. We looked at a total of 43 venues in 11 cities including: Singapore Hong Kong Kuala Lumpur Shanghai Manila Seoul Vietnam Macau Auckland Bangkok, and Honolulu and Waikoloa In some venues guest room rates were over $300 a night, and for others the meeting space cost was among the very highest we have ever seen. Those disqualifying factors together with our commitment to completing venue selections three years in advance compelled us to make a decision and move on. The venue in Vancouver had been pre-qualified, has a guest room rate of $169 CAD including Internet, complimentary meeting space and a Welcome Reception sponsorship. And for the first time we negotiated an option for a future meeting with the same attractive features. While Vancouver clearly isn't in the Asia-Pacific region, it at least minimizes travel from many places in Asia. Our commitment to finding Asia-Pacific venues is unwavering, however as we have reported at Plenary we have experienced difficulties. We are moving ahead. We have a site visit scheduled in October for IETF 91 in 2014 and have a solid Host interest for 2015. Furthermore we are investigating the use of paid 3rd party intermediaries to negotiate arrangements in the region. We welcome your assistance and volunteering to Host or sponsor meetings in Asia-Pacific, and elsewhere. Ray Pelletier IETF Administrative Director ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
IETF 82 - Social Event
82nd IETF Meeting Taipei, Taiwan November 13-18, 2011 Host: Taiwan Network Information Center (TWNIC) Host Website: http://ietf82.tw/ Meeting venue: Taipei International Convention Center (TICC) http://www.ticc.com.tw/index_en.aspx Register online at: http://www.ietf.org/meetings/82/ 1. Registration 2. Social Event 1. Registration A. Early-Bird Registration - USD 650.00 Pay by Friday, 11 November 2011 1700 PT (00:00 UTC) B. After Early-Bird cutoff - USD 800.00 C. Full-time Student Registrations - USD 150.00 (with proper ID) D. One Day Pass Registration - USD 350.00 E. Registration Cancellation Cut-off for registration cancellation is Monday, 07 November 2011 at 1700 PT ( UTC). Cancellations are subject to a 10% (ten percent) cancellation fee if requested by that date and time. F. Online Registration and Payment ends Friday, 11 November 2011, 1700 local Taipei time. G. On-site Registration starting Sunday, 13 November 2011 at 1100 local Taipei time. 2. Social Event: Cultural Night in Taipei Venue: Taipei World Trade Center Club at TWTC International Trade Building Taiwan Network Information Center is honored to welcome IETF delegates to the Cultural Night in Taipei held at the top of the TWTC International Trade Building, overlooking Taipei's latest developed business district. Taiwan is a place mixed with a variety of cultures. The Cultural Night in Taipei will present all the guests the most popular traditional ritual theatre performance, Techno Prince (Nezha), and the traditional Chinese orchestra. All the guests will also be given souvenirs made by folk artists. Date: Tuesday, November 15, 2011 Time: 7:00 PM - 10:00 PM Cost: US$ 40.00 Additional information can be found at: http://ietf82.tw/social_events.html To Register for social: https://www.ietf.org/registration/ietf82/eventticket.py NOTE: You must first register for IETF 82 to purchase a social ticket. Only 32 days until the Taipei IETF! ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
