Re: Last calling draft-resnick-on-consensus
Pete, On 10/10/2013 11:08 PM, Pete Resnick wrote: On 10/7/13 7:48 AM, Lou Berger wrote: I think it misses two important points that should be addressed prior to publication: 1) The role WG/IETF mailing lists play in building and gauging consensus Yeah, as I just replied to Tom, I think this is worth adding, probably in section 2 or 3. great. 2) That some participants/chairs/I*s like seeing hands, and that's okay Yes, this is directly said in section 4, paragraphs 4 5. What do you think is missing? It says hum+hands. My point is hands-only is okay and can be essentially equivalent to the humming described in your document. I think it would be valuable to make this point explicitly, as I essentially everything else you say in the document. And I completely agree with your point that a show of hands ( a poll on the list) are not votes. There are different ways to achieve and determine consensus. As stated in RFC2418: Consensus can be determined by a show of hands, humming, or any other means on which the WG agrees (by rough consensus, of course). Note that 51% of the working group does not qualify as rough consensus and 99% is better than rough. It is up to the Chair to determine if rough consensus has been reached. As I said in my reply to Dave, there's part of the above that I disagree with, or at least think is an oversimplification. But it definitely need citing. got it, but as you say this document is Informational and doesn't propose any change to IETF process, while RFC2418 is a BCP which does define process. Lou pr
Re: Last calling draft-resnick-on-consensus
Hi, I definitely agree that this is a really useful document. Lots of good background and general considerations. But I think it misses two important points that should be addressed prior to publication: 1) The role WG/IETF mailing lists play in building and gauging consensus The draft leaves me with an impression that mailing lists don't play any substantive role. (Said another way: if I'm participating remotely, or miss a meeting, how do I hum/participate?) Clearly this is the wrong conclusion! I suspect/hope that with all the recent discussion on remote participation that I really don't need to elaborate on this point any further. 2) That some participants/chairs/I*s like seeing hands, and that's okay There are different ways to achieve and determine consensus. As stated in RFC2418: Consensus can be determined by a show of hands, humming, or any other means on which the WG agrees (by rough consensus, of course). Note that 51% of the working group does not qualify as rough consensus and 99% is better than rough. It is up to the Chair to determine if rough consensus has been reached. I've been in and run many WG sessions where a show of hands is used to help gauge consensus of those present. I can't speak for others, but hands are my preference for a pretty simple reason: my hearing is such that in a large room, hums just don't provide me any real input -- I can gauge silence vs hums, but that's about it. I know that I've been in rooms where my conclusion of which hummed response was greater differed from others. Perhaps based on where we were each sitting, perhaps based on hum frequency, perhaps on my/our hearing. I just don't know. I think a show of hands can provide the same input into the consensus principles described in the draft, and this should be mentioned. Even just quoting the 1st sentence from RFC2418 listed above in the draft should help. Adding some words on how a show of hands differs from a formal vote would be even better. Lou On 10/6/2013 5:03 PM, Jari Arkko wrote: The document talks about ways in which consensus processes can be successfully run in the IETF. After the last few rounds of versions, I believe this document is ready to move forward. My goal is to publish it as an Informational RFC. It is an explanation of principles and how they can be applied to productively move IETF discussions forward. While there is no change to IETF processes or any presumption that guidance from this document must be followed, I have found the document very useful. It has been referred to numerous times in IETF and IESG discussions. Consensus is hard and many WG discussions have complex trade-offs and differing opinions. I believe having this document become an RFC would help us apply the useful principles even more widely than we are doing today. The abstract says: The IETF has had a long tradition of doing its technical work through a consensus process, taking into account the different views among IETF participants and coming to (at least rough) consensus on technical matters. In particular, the IETF is supposed not to be run by a majority rule philosophy. This is why we engage in rituals like humming instead of voting. However, more and more of our actions are now indistinguishable from voting, and quite often we are letting the majority win the day, without consideration of minority concerns. This document is a collection of thoughts on what rough consensus is, how we have gotten away from it, and the things we can do in order to really achieve rough consensus. Note (to be removed before publication): This document is quite consciously being put forward as Informational. It does not propose to change any IETF processes and is therefore not a BCP. It is simply a collection of principles, hopefully around which the IETF can come to (at least rough) consensus. The draft can be obtained from http://tools.ietf.org/html/draft-resnick-on-consensus You should see a last call announcement soon, and both me and Pete look forward to your feedback. Jari
Re: Anonymity versus Pseudonymity (was Re: [87attendees] procedural question with remote participation)
+1. On August 2, 2013 1:13:05 PM Scott Brim scott.b...@gmail.com wrote: I'm completely against participating anonymously because of IPR issues. I'm mostly against pseudonymous participation for the same reason. I need to be able to know who I'm dealing with, in order to know if there are IPR issues that should be brought up.
Re: When to adopt a WG I-D
On 5/28/2013 10:52 AM, Stewart Bryant wrote: ... The only requirement is that the chairs conclude that the existence such a draft has WG consensus. ... Strictly speaking, I believe the only requirement for a document to be published as a WG document is that a WG chair approves it. I do agree/think there are many practical restrictions, notably charter WG support. WRT to the I-D: the text in section 2.4 that says the chairs need to... can mislead some to believe that this is the required process. I think the the chairs typically... would be more accurate. Lou
Re: IETF Meeting in South America
For Americans, is it much more expensive than a trip to Prague? I just happen to be looking at flights for berlin at the moment. BA is pretty much the same +-$1600 if I'm willing to take an extra hop, closer to $2K for one hop. I generally find going to Europe in the summer to be pretty expensive so am not sure this is the best comparison. As metioned elsewhere in this thread, time of year does matter. I personally am a big fan for going to uninteresting locations in their off season. Although, perhaps I'm alone in liking Minneapolis in the winter as an IETF destination... Lou On 5/24/2013 11:28 AM, Yoav Nir wrote: I used Expedia to price flights for me on March 2014: - Buenos Aires: $1401 (21h each way) - London (where the meeting actually happens): $413 (7h each way. Direct costs a bit more) - Vancouver: $1217 (24 h each way? $1288 with a more reasonable 16h) - Honululu: $1535 (28h each way) - Melbourne (to minimize the pain for Mark): $2155 (36h) - Minneapolis: $1020 (18h) So Buenos Aires is not much more painful than some other destinations we've been talking about, and I believe the same will be true for most Europeans. For Americans, is it much more expensive than a trip to Prague? Yoav On May 24, 2013, at 5:12 PM, Michael Richardson mcr+i...@sandelman.ca wrote: The == The IAOC bob.hin...@gmail.com writes: The The venues are in Buenos Aires. They meet our requirements for the meeting The space, networking, nearby restaurants and bars, hotel room rates in the mid $200 The dollar range, nearby alternate hotels at a broad range of prices, nice area in the The city, safe, direct international flights, and accessible visas. The IAOC thinks we The could have a successful IETF meeting in Buenos Aires and that attendees would The like the venues. My question is about whether we would be there during the peak season, and when exactly is that season? I priced flights for me in July, November and March (2014). It seems that most flights go through Santiago or Sao Paulo, one went through Atlanta. The lowest cost flight for me is similiar to travel to Europe not in the summer, but the price rises quite quickly to the $4K range. The worse rise seems to be March, but that was also the furthest in the future. The Things to consider are that it will be a long trip for the majority of IETFers and the The air fares are more expensive (about 10% to 20% higher than average), though The restaurants are less expensive. This would be a case where most IETFers would The bear more travel pain and expense. What are the hotel costs? (I fund my own attendance) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails [
Re: IETF Diversity Question on Berlin Registration?
Did anyone notice the NPR piece this AM? http://www.npr.org/blogs/alltechconsidered/2013/04/29/178810467/blazing-the-trail-for-female-programmers Perhaps it's time for an IETF equivalent/chapter of http://railsbridge.org/, http://blackfounders.com/, http://wisecampaign.org.uk/, etc. ... Lou On 4/29/2013 12:46 PM, Dave Crocker wrote: Let's not confuse activity with progress.
Re: IETF Diversity Question on Berlin Registration?
Melinda, I'm not so sure debating the merits of a specific measure has value or not is really that helpful, and I probably just should have ignore this small point. Let's say some limited measure of diversity is valid, what do we learn from it? Is the conclusion that only one group is being discriminated against and that the IETF needs to address this one specific form of discrimination, or is it that the top of the IETF is far from diverse? If the latter, I buy it -- the IETF has a diversity issue. As many others have said, there are many forms of bias and discrimination -- all of which are harmful, and only some of which have the legal protection (in your favorite country) that they should. Irrespective of any specific statistic, I think this discussion has shown that there is consensus that working to eliminate bias and discrimination *in all forms* from the IETF is worth paying attention to. Do you disagree, are you saying that the IETF should only/first try to address only gender bias? I personally think all IETF participants should have voice in this discussion, no matter if they fall into an obviously discriminated against group or not. This includes the full range of participants, even newcomers, folks who have never authored an I-D, folks who by any measure are significant I* contributors, and even western white guys. IMO the exclusion of any voice is itself a manifestation of bias. Lou On 4/12/2013 10:22 PM, Melinda Shore wrote: On 4/12/13 1:26 PM, Lou Berger wrote: No argument from me, I'm just asking that a comment/position/question that I don't understand be substantiated. And I'm telling you that I think the numbers are highly suggestive of bias. We can take a swing at getting a very rough handle on that but I'm actually not sure that we should because it appears to be the case that the cost of any remediation that some of us might want to undertake would be higher than the cost of living with bias in the system (this would be the considerable downside to consensus decision-making processes with a very large participant base). And I don't know if you intended to or not, but what you communicated is The best candidates are nearly always western white guys, since that's who's being selected. That's a problematic suggestion. I certainly, in no way, shape, or form intended such an implication. I have not idea how one could read it that way, [ ... ] A (male) friend once said that men are no more likely to notice sexism than fish are to notice water. I think that was far too broad but generally true. If I think that white western men are being selected in disproportion to their presence in the candidate pool, and I do, then telling me that we only choose the best is telling me that white, western men tend to be the best. Pretty much every organization that applauds itself for its meritocratic reward structure (to the extent that an I* gig is a reward) and yet only advances white guys says the same thing. It is a trope, and a familiar one. Melinda
Re: IETF Diversity Question on Berlin Registration?
On April 13, 2013 12:57:09 PM Melinda Shore melinda.sh...@gmail.com wrote: On 4/13/13 4:09 AM, Lou Berger wrote: Do you disagree, are you saying that the IETF should only/first try to address only gender bias? Clearly not, Lou. Great. Glad to hear we agree. That said, some may prefer to focus on just gender (or some other form of) bias first, and I wouldn't fault them for that... Lou
Re: IETF Diversity Question on Berlin Registration?
On April 12, 2013 2:33:13 PM Melinda Shore melinda.sh...@gmail.com wrote: On 4/12/2013 10:12 AM, Toerless Eckert wrote: I still think that the IETF community at large has no intentional diversity bias, so the process of discussing and analyzing diversity in the context of leadership is to help better describe diversity induced job qualifications as well as uncovering any potential unconscious bias to help overcoming it. I think it's unintentional, as well, but I'm not sure that's *much* of an improvement over malicious bias. It certainly makes it far, far, far more difficult to address. As I said I think that looking at the pool of nominees who've accepted their nominations and comparing it to the pool of people selected would provide one very rough measure of bias (explicit or otherwise) in one stage of the process. While I've been very reluctant to jump on this topic, I have to ask what's the basis for this assertion? A willingness to do/volunteer for a job says nothing about one's qualifications for a job. Now if we somehow could compare 'qualified' nominees vs selected, I'd agree that that could be interesting Lou Melinda
Re: raw meeting minutes (Re: meetecho praise)
Etherpad is an awesome tool and we've found out to be hugely useful over a number of IETFs, but be forewarned that on a couple of rare occasions the notes have disappeared. In the first case, it took a manual step for it to be restored. In the second we had a private copy... Lou On March 18, 2013 12:35:49 PM Dave Crocker d...@dcrocker.net wrote: On 3/18/2013 9:28 AM, Mary Barnes wrote: it seems to take a long time for many to get their meeting minutes uploaded. My suggestion is for chairs to at least upload the raw minutes as drafts If minutes takers used etherpad, the raw minutes would be available in real-time, rather than requiring everyone to wait for the polished version. It would also allow some crows-sourcing of corrections and additions to the raw minutes... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Mentoring
I think such a list is a great idea. Perhaps it would be good to have this available as a 'safe place' for any (newbie, twobie or whatever) to ask questions, and just call it a 'mentors' list... Lou On March 14, 2013 9:13:15 AM Dave Crocker d...@dcrocker.net wrote: On 3/14/2013 8:49 AM, Scott Brim wrote: On 03/14/13 08:23, Mary Barnes allegedly wrote: One question I have is whether there isn't a list for newcomers to ask questions that some of us can be on to help them before they get to the meeting? like +1 And well advertised on one or more IETF web pages. What else can be done to vector newbies (and mentors) to the list? On 3/14/2013 8:59 AM, Spencer Dawkins wrote: I wonder if the target audience for SOMEthing might be two-comers - people at their SECOND meeting. Perhaps better to merely have 'newcomers' refer to an initial phase of IETF involvement, rather than thinking of it as first-contact. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: 答复: Gen-ART review of draft-ietf-ccamp-lmp-behavior-negotiation-10
Dan/Richard, On 2/4/2013 10:05 PM, Lidan (Dan) wrote: Hi Richard, Thanks for the review of this draft! Section 2.1. Would be helpful to either include the old formats and/or say explicitly what is changing. Added the original format of Config, ConfigAck and ConfigNack messages which are defined in RFC4204. I personally think it's a mistake to repeat definitions in non-bis RFCs. I think this increases the possibility of mistakes and confusion (e.g., when the text isn't copied properly or when the original document is replaced). My original thought was to propose text to follow Richard's suggestion of explicitly saying what has changed, but I see such text is there at the start of section 2: LMP Config, ConfigNack and ConfigAck messages are modified by this document to allow for the inclusion of multiple CONFIG objects. The Config and ConfigNack messages were only defined to carry one CONFIG object in [RFC4204]. The ConfigAck message, which was defined without carrying any CONFIG objects in [RFC4204], is modified to enable explicit identification of negotiated configuration parameters. The inclusion of CONFIG objects in ConfigAck messages is triggered by the use of the BehaviorConfig object (defined below) in a received Config message. Richard, Is this text sufficient? Alternatively, this text can be moved to immediately proceed the BNF. Much thanks Lou (document co-author)
Re: Gen-ART review of draft-ietf-ccamp-lmp-behavior-negotiation-10
Richard, Thank you for the review. I have one additional question/response on your comments: On 2/3/2013 2:13 PM, Richard Barnes wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please seehttp://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-ccamp-lmp-behavior-negotiation-10 Reviewer: Richard Barnes Review Date: 2013-02-02 IETF LC End Date: 2012-01-21 IESG Telechat date: 2012-02-07 Summary: Ready, with a couple of minor questions / clarifications. Comment: Overall, this document seems very clear and readable. Thanks! The one concern I have is over the use of likely in the discussion of backward compatibility; I would like to see more precise language there. Section 2.1. Would be helpful to either include the old formats and/or say explicitly what is changing. Section 2.2. Nodes which support - nodes that support Ordering of CONFIG objects - ... With different C-type values Section 3.1.MBZ. Might help to clarify that this means that the number of bits MUST be a multiple of 32. (I got a little confused between bits and bytes here.) I think you're right. The current text can easily result in confision between the size of the MBZ field and the setting of the length field define in RFC4204. It's probably best to just remove the reference to the length field. How about this: OLD The number of bits present is based on the Length field of the LMP object header and MUST include enough bits so the Length field MUST be at least 8, and MUST be a multiple of 4. NEW This field MUST be sized to ensure 32 bit alignment of the object. Lou (co-author) Section 4. Likely Is it possible for a 4204-compliant implementation to not do one of these? If so then remove likely. If not, then why happens on the exceptional case?
Re: I'm struggling with 2219 language again
On 1/4/2013 12:15 AM, Dean Willis wrote: ... Are we deliberately evolving our language to use RFC 2119 terms as the principle verbs of a formal specification language? ... My view on this has evolved over time. I used to follow the practice of using 2219 language only for emphasis. Over time, primarily motivated by reviewers comments and reader questions, I've migrated to the position that 2119 language should be used whenever and wherever a point of conformance is being made. While this may be a bit of an extreme position, it ensures that authors, reviewers, readers, implementors, etc. are in sync as to what is expected from an interoperable implementation that conforms to a standard. I think the importance of such unambiguity has increased over time as the number of implementors and non-native English speakers in our community have increased. I also think it's important to follow section 6 of 2119, i.e., if it's not a point of interoperability or harmful behavior, there's no need to use 2119 conformance language. So, my view is now: a) lower case usage of 2119 key words *in RFCs* means the normal English meaning of such words, but does not place any requirement on implementations, i.e., is purely informative text. b) upper case usage of 2119 key words *in RFCs*, as stated in [RFC2119], places requirements in the specification, i.e., is conformance language with which an implementation must follow to ensure interoperability (or harm). (And does not = shouting as would be the case in other contexts). I take this view when writing and reviewing PS drafts... Lou
Re: Last Call: draft-kumaki-murai-l3vpn-rsvp-te-06.txt (Supportfor RSVP-TE in L3VPNs) to Experimental RFC
Peng, Thanks for the quick response! Please see in line below. On 10/22/2012 9:39 PM, Peng JIANG wrote: Hello Lou, As to the technical details, the next hop as identified by the Path message in the VPN context, will have a route and associated label within the VPN context. This VPN label can be added to the Path message, just as it would be for any VPN IP packet, and additional labels may be added for PE-PE transport. In implementations that rewrite the IP header, the IP destination can be set to the next hop. The remote PE/next hop will receive the Path message with the VPN label which will identify the VPN context/VRF. This PE will then need to identify the packet as RSVP using either the router alert mechanism or based on the IP header destination address. So I see no reason for the modifications when the VAN-specific MPLS labels are used. Shout if you think I missed something. We think you are correct about the Path message. But Resv messages are different. The Resv messages are sent hop- by-hop. The destination is not the remote PE but the unicast address of a previous RSVP hop when a PE send out a Resv message. Therefor, there will be no VPN label and the remote PE will have no method to identify the VPN context/VRF. I'd expect it to be represented in the HOP object. Lou In RFC 2205: 3.1.3 Path Messages A Path message travels from a sender to receiver(s) along the same path(s) used by the data packets. The IP source address of a Path message must be an address of the sender it describes, while the destination address must be the DestAddress for the session. 3.1.4 Resv Messages Resv messages carry reservation requests hop-by-hop from receivers to senders, along the reverse paths of data flows for the session. The IP destination address of a Resv message is the unicast address of a previous-hop node, obtained from the path state. My high-order take away is that it seems to me that this draft runs counter to hierarchy-based solutions that can solve this problem just fine without any additional RSVP modifications. I therefore think this draft should be run through a WG that is willing to reconcile the approaches (and fully document their uses case supported by hierarchy). Failing that, I think the draft should have an IESG applicability note added saying that this is experimental only and that standard hierarchy should be used to solve the problem in any operational implementation/network. As I have explained, For Resv messages, hierarchy-based solutions are not able to identify the VPN context/VRF at a remote PE. Hope the above explaination will make sense to you. Please let us konw if you have any further comments. Thanks. Best Regards, Peng JIANG KDDI Hello, I made this comment privately during the LC period. I don't mind sharing it more widely: My high-order take away is that it seems to me that this draft runs counter to hierarchy-based solutions that can solve this problem just fine without any additional RSVP modifications. I therefore think this draft should be run through a WG that is willing to reconcile the approaches (and fully document their uses case supported by hierarchy). Failing that, I think the draft should have an IESG applicability note added saying that this is experimental only and that standard hierarchy should be used to solve the problem in any operational implementation/network. As to the technical details, the next hop as identified by the Path message in the VPN context, will have a route and associated label within the VPN context. This VPN label can be added to the Path message, just as it would be for any VPN IP packet, and additional labels may be added for PE-PE transport. In implementations that rewrite the IP header, the IP destination can be set to the next hop. The remote PE/next hop will receive the Path message with the VPN label which will identify the VPN context/VRF. This PE will then need to identify the packet as RSVP using either the router alert mechanism or based on the IP header destination address. So I see no reason for the modifications when the VAN-specific MPLS labels are used. Shout if you think I missed something. Lou On 9/5/2012 6:43 PM, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Support for RSVP-TE in L3VPNs' draft-kumaki-murai-l3vpn-rsvp-te-06.txt as Experimental 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 ietf@ietf.org mailing lists by 2012-10-03. 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 IP Virtual Private Networks (VPNs) provide connectivity between sites across an IP/MPLS
Re: Last Call: draft-kumaki-murai-l3vpn-rsvp-te-06.txt (Support for RSVP-TE in L3VPNs) to Experimental RFC
Hello, I made this comment privately during the LC period. I don't mind sharing it more widely: My high-order take away is that it seems to me that this draft runs counter to hierarchy-based solutions that can solve this problem just fine without any additional RSVP modifications. I therefore think this draft should be run through a WG that is willing to reconcile the approaches (and fully document their uses case supported by hierarchy). Failing that, I think the draft should have an IESG applicability note added saying that this is experimental only and that standard hierarchy should be used to solve the problem in any operational implementation/network. As to the technical details, the next hop as identified by the Path message in the VPN context, will have a route and associated label within the VPN context. This VPN label can be added to the Path message, just as it would be for any VPN IP packet, and additional labels may be added for PE-PE transport. In implementations that rewrite the IP header, the IP destination can be set to the next hop. The remote PE/next hop will receive the Path message with the VPN label which will identify the VPN context/VRF. This PE will then need to identify the packet as RSVP using either the router alert mechanism or based on the IP header destination address. So I see no reason for the modifications when the VAN-specific MPLS labels are used. Shout if you think I missed something. Lou On 9/5/2012 6:43 PM, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Support for RSVP-TE in L3VPNs' draft-kumaki-murai-l3vpn-rsvp-te-06.txt as Experimental 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 ietf@ietf.org mailing lists by 2012-10-03. 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 IP Virtual Private Networks (VPNs) provide connectivity between sites across an IP/MPLS backbone. These VPNs can be operated using BGP/MPLS and a single provider edge (PE) node may provide access to multiple customer sites belonging to different VPNs. The VPNs may support a number of customer services including RSVP and RSVP-TE traffic. This document describes how to support RSVP-TE between customer sites when a single PE supports multiple VPNs. The file can be obtained via http://datatracker.ietf.org/doc/draft-kumaki-murai-l3vpn-rsvp-te/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-kumaki-murai-l3vpn-rsvp-te/ballot/ No IPR declarations have been submitted directly on this I-D. Due to an error by the sponsoring Area Director, the Last Call on this document (which completed on 3rd September) incorrectly stated that this draft was intended that it be published as Informational. The correct intention (as stated in the draft itself) is that it be published as Experimental. This Last Call is to verify community consensus for publication of this draft as Experimental.
Re: Gen-ART review of draft-ietf-ccamp-assoc-ext-04
Peter, Thank you for the comments. Please see below for responses in-line. On 8/29/2012 11:31 PM, Peter Yee 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 Document: draft-ietf-ccamp-assoc-ext-04 Reviewer: Peter Yee Review Date: Aug-28-2012 IETF LC End Date: Aug-29-2012 IESG Telechat date: Not known Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. [Ready with nits.] This document provides extensions to the scope of use of the RSVP ASSOCIATION object as well as providing an extended ASSOCIATION object capable of handling a longer Association ID. Nits: In the last example (Symmetric NAT), last sentence: mechanisms - mechanism. Section 2, 4th paragraph (the replacement text): the the - the. Section 3.2.1, 2nd paragraph, 1st sentence: are - is. Alternatively, you could change format to formats. Section 3.2.2, 1st sentence: apply - applies. Section 4.2, 1st sentence: a - an in both occurrences. Section 4.2, last paragraph, 2nd sentence: a - an. Thank you! Questions: These are questions you may wish to answer but the draft is acceptable without response: 1) In Section 4.2, 4th bullet, is there any implied relationship between the Extended Association ID and the Association ID? Or are they independent values that simply must be matched? The latter (as the text says.) 2) Section 4.2, 5th bullet, you make a first and only mention of padding bytes. Are you using a specific method for generating these padding bytes or are they random? No, as it is completely up to the creator of the object to use it consistently. Given the matching requirement on ASSOCIATION objects, it might be best to specify the padding generation so that if the object is regenerated, it will still be matched by intermediary nodes. I've presumed that the padding bytes are for meeting the 4-byte multiple requirement, but I don't know if implementations would ever be free to regenerate the object for subsequent transmissions of that object. I'll add , without modification, to the last sentence of 3.1.2 and 3.2.2. Thank you for the comments! Lou
Fwd: Re: Gen-ART review of draft-ietf-ccamp-assoc-ext-04
Adrian, Shout (or change the ID state) when you're ready for the update to be submitted. Thanks, Lou Original Message Subject:Re: Gen-ART review of draft-ietf-ccamp-assoc-ext-04 Date: Thu, 30 Aug 2012 10:25:19 -0400 From: Lou Berger lber...@labn.net To: Peter Yee pe...@akayla.com CC: draft-ietf-ccamp-assoc-ext@tools.ietf.org, gen-...@ietf.org, ietf@ietf.org Peter, Thank you for the comments. Please see below for responses in-line. On 8/29/2012 11:31 PM, Peter Yee 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 Document: draft-ietf-ccamp-assoc-ext-04 Reviewer: Peter Yee Review Date: Aug-28-2012 IETF LC End Date: Aug-29-2012 IESG Telechat date: Not known Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. [Ready with nits.] This document provides extensions to the scope of use of the RSVP ASSOCIATION object as well as providing an extended ASSOCIATION object capable of handling a longer Association ID. Nits: In the last example (Symmetric NAT), last sentence: mechanisms - mechanism. Section 2, 4th paragraph (the replacement text): the the - the. Section 3.2.1, 2nd paragraph, 1st sentence: are - is. Alternatively, you could change format to formats. Section 3.2.2, 1st sentence: apply - applies. Section 4.2, 1st sentence: a - an in both occurrences. Section 4.2, last paragraph, 2nd sentence: a - an. Thank you! Questions: These are questions you may wish to answer but the draft is acceptable without response: 1) In Section 4.2, 4th bullet, is there any implied relationship between the Extended Association ID and the Association ID? Or are they independent values that simply must be matched? The latter (as the text says.) 2) Section 4.2, 5th bullet, you make a first and only mention of padding bytes. Are you using a specific method for generating these padding bytes or are they random? No, as it is completely up to the creator of the object to use it consistently. Given the matching requirement on ASSOCIATION objects, it might be best to specify the padding generation so that if the object is regenerated, it will still be matched by intermediary nodes. I've presumed that the padding bytes are for meeting the 4-byte multiple requirement, but I don't know if implementations would ever be free to regenerate the object for subsequent transmissions of that object. I'll add , without modification, to the last sentence of 3.1.2 and 3.2.2. Thank you for the comments! Lou
Re: Fwd: Re: Gen-ART review of draft-ietf-ccamp-assoc-ext-04
Eek, I somehow managed to broadcast this! My apologies. Lou On 8/30/2012 10:27 AM, Lou Berger wrote: Adrian, Shout (or change the ID state) when you're ready for the update to be submitted. Thanks, Lou Original Message Subject:Re: Gen-ART review of draft-ietf-ccamp-assoc-ext-04 Date: Thu, 30 Aug 2012 10:25:19 -0400 From: Lou Berger lber...@labn.net To: Peter Yee pe...@akayla.com CC: draft-ietf-ccamp-assoc-ext@tools.ietf.org, gen-...@ietf.org, ietf@ietf.org Peter, Thank you for the comments. Please see below for responses in-line. On 8/29/2012 11:31 PM, Peter Yee 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 Document: draft-ietf-ccamp-assoc-ext-04 Reviewer: Peter Yee Review Date: Aug-28-2012 IETF LC End Date: Aug-29-2012 IESG Telechat date: Not known Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. [Ready with nits.] This document provides extensions to the scope of use of the RSVP ASSOCIATION object as well as providing an extended ASSOCIATION object capable of handling a longer Association ID. Nits: In the last example (Symmetric NAT), last sentence: mechanisms - mechanism. Section 2, 4th paragraph (the replacement text): the the - the. Section 3.2.1, 2nd paragraph, 1st sentence: are - is. Alternatively, you could change format to formats. Section 3.2.2, 1st sentence: apply - applies. Section 4.2, 1st sentence: a - an in both occurrences. Section 4.2, last paragraph, 2nd sentence: a - an. Thank you! Questions: These are questions you may wish to answer but the draft is acceptable without response: 1) In Section 4.2, 4th bullet, is there any implied relationship between the Extended Association ID and the Association ID? Or are they independent values that simply must be matched? The latter (as the text says.) 2) Section 4.2, 5th bullet, you make a first and only mention of padding bytes. Are you using a specific method for generating these padding bytes or are they random? No, as it is completely up to the creator of the object to use it consistently. Given the matching requirement on ASSOCIATION objects, it might be best to specify the padding generation so that if the object is regenerated, it will still be matched by intermediary nodes. I've presumed that the padding bytes are for meeting the 4-byte multiple requirement, but I don't know if implementations would ever be free to regenerate the object for subsequent transmissions of that object. I'll add , without modification, to the last sentence of 3.1.2 and 3.2.2. Thank you for the comments! Lou
Re: Last Call: draft-ietf-ccamp-rfc5787bis-05.txt
Stephen, To add to what Adrian said, the 1:1 mapping is only for node identifiers, interface identifiers have no such restriction. I think it's reasonable to add some informative text to the draft on this point as it may help avoid such confusion in the future. Lou On 8/22/2012 1:01 PM, Adrian Farrel wrote: Hi Stephen, No, there is no requirement for the control plane topology to match the data plane topology in GMPLS. There is simply a 1:1 mapping between identifiers. We might note, however, that there is a virtual overlay in the SCN such that protocol controllers that control devices that are adjacent in the data plane can be made virtually adjacent in the control plane. Your final assumption is how an operator might manage their network. But it is not a requirement since mappings can always be made at domain boundaries. Adrian *From:* Shew, Stephen [mailto:ss...@ciena.com] *Sent:* 22 August 2012 17:35 *To:* Acee Lindem; Ong, Lyndon *Cc:* ietf@ietf.org; draft-ietf-ccamp-rfc5787bis@tools.ietf.org; Andrew G. (Andy) Malis *Subject:* RE: Last Call: draft-ietf-ccamp-rfc5787bis-05.txt Thanks for the reply. If I understand correctly, this means that the SCN topology must match the transport topology when applying OSPF for ASON routing. This is because the Local TE Router Identifier and the Remote TE Router Identifier in the Local and Remote TE Router ID sub-TLV are the same as the TE Router ID in the TE Router Address TLV. If this is correct, then I think the draft should state the assumption that the SCN topology and transport plane topology are aligned. It’s an important assumption to state since management systems of SDH/OTN networks have topologies of the transport network in non-IP address formats (esp. TL-1 TIDs) and these need to be mapped to TE Router IDs in the SCN space when this draft is applied. I assume it implies that there should be a single SCN or non-overlapping IP address spaces if there are multiple SCNs, for a given transport topology otherwise the SCN topology representing the transport topology could have duplicate identifier values. Stephen *From:* Acee Lindem [mailto:acee.lin...@ericsson.com] *Sent:* 21 August, 2012 17:23 *To:* Ong, Lyndon *Cc:* ietf@ietf.org; Shew, Stephen; draft-ietf-ccamp-rfc5787bis@tools.ietf.org; Andrew G. (Andy) Malis *Subject:* Re: Last Call: draft-ietf-ccamp-rfc5787bis-05.txt Hi Stephen, Lyndon, Andy and I have had discussions with the CCAMP chairs and AD. We have come to the conclusion that we cannot merely change the name space for the advertised TE Router ID since this would imply a change to the GMPL model for setting up LSPs. In GMPL, the LSP endpoints are in the Signaling Control Network (SCN) and this cannot be changed without a distinct model for ASON LSP establishment complete with the specification of the changes to path computation, RSVP path signaling, and RSVP Explicit Route Object (ERO) handling. In essence, this change would add a level of indirection from the SNPP to the SCN. In the context of this draft, we are not going to deviate from the GMPLS LSP model and, hence, will not incorporating the suggested changes. Thanks, Acee On Aug 17, 2012, at 7:58 PM, Ong, Lyndon wrote: (Submitted on behalf of Stephen Shew) I would like to raise an issue with draft-ietf-ccamp-rfc5787bis-05.txt. The issue does not affect the proposed sub-TLVs or their semantics, so it would not affect an implementation. I believe some statements in the document should be edited to avoid confusion over ASON terminology as defined in ITU-T Recommendation G.8080, for which I am editor. It concerns the definition of “ASON reachability” which changed during the course of the document from being a transport plane address, the SubNetwork Point Pool (SNPP) space, to the Signalling Control Network (SCN) address space. I think the root of the issue is that the visibility of the three address spaces described in ASON (G.8080) is not always made clear when discussing using OSPF for ASON Routing. Section 3 of G.8080 states that: There are three categories of identifiers used for ASON routing (G7715.1): transport plane names, control plane identifiers for components, and Signaling Communications Network (SCN) addresses. In -03 of the document, the term SNPP was used. This is the SubNetwork Point Pool space that describes the data plane and is defined in G.8080 Section 10. It names the subnetwork (and/or containing subnetworks) to which Subnetwork Points (SNPs) are scoped. From G.8081: “The SNP is an abstraction that represents an actual or potential underlying connection point (CP) (or connection termination point (CTP)) or an actual or potential termination connection point (TCP) or trail termination point (TTP). Several SNPs (in different subnetwork partitions) may represent the
Re: Forthcoming draft: draft-farrresnickel-ipr-sanctions
I agree there are many gray area cases that I think it would be best to shy away from over specifying. But what do we do when there is a bright line violation of RFC3979? IMO I think we should have consensus on a very small set of repercussions for blatant violations of RFC3979. Even if the consensus is no repercussions. (In which case we've established that compliance with the IPR policy is optional.) While I understand the desire for the WG chairs to deal with such cases on an as-needed basis, it means that the WG chairs scope is being expanded from managing the development of technical consensus to enforcing IPR disclosure rules (including needing to consider about legal repercussions.) I don't think this is a good idea. Lou On 1/26/2012 6:35 PM, Richard L. Barnes wrote: I appreciate that there need to be disincentives to infringing the IPR policy, but I'm a little wary of the idea of codifying a system of sanctions. Mainly for the sorts of gaming the system thinking they engender: -- Is the benefit of infringing worse than the cost of the sanction? -- If it's not sanctionable, it must be ok! Plus, if there are sanctions, then you need a judgement process to decide when the sanctions will be applied. Is the IETF set up for that? Rather than bright lines and clear sanctions, it seems like a general culture of conservatism, staying far away from things that could possibly be construed as violations, would be more in tune with the way other things work at the IETF. No real answers here, just expressing a gut reaction. --Richard On Jan 26, 2012, at 6:11 PM, Pete Resnick wrote: Just a heads-up: Adrian Farrel and I started work on a draft to focus discussion on sanctions that could be applied to violators of the IETF's IPR policy. Because of incidents like the present one, we've each been asked by WG chairs and others what can be done in response to such violations. We've centered our draft around sanctions that are available under current IETF procedures, not introducing new ones. The draft should be available in the I-D repository soon. We think this could usefully become an RFC and we would welcome discussion. Thanks, pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ 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: Hyatt Taipei cancellation policy?
Ole, In the (somewhat far) past, my memory was that the IETF rate was *less* then the normal available rate. This trend to higher rates is something I only remember seeing over the last 5 or so years. Perhaps my memory is just flawed, as I haven't done the work to verify this, but I don't think so. I think in the spirit of transparency we really need to understand why this trend has occurred. From looking at the list of things we get for the IETF rate, the only thing I see in the list that is really important to the individuals paying the room-fees is in-room (typically) IETF-class internet. Breakfast is great, but it is included only when this is the norm for the region/hotel, so really isn't a real benefit compared to rack rates. I strongly feel that the free or subsidized meeting rooms should come out of the meeting fees, not *hidden* in the hotel rates. You also don't mention the free hotel rooms/suites. Again the value here and subsidy in the IETF rates really should be known, but in either case, these too should come out of the meeting fees. I personally think the issues to focus on/fix are the lack of transparency and the current approach of distributing meeting costs to the hotel rate. Lou On 8/23/2011 2:07 PM, Ole Jacobsen wrote: You said: At root is that we are trying to negotiate a purchase at a discounted price without committing to buying any particular number of rooms, versus only a limited number of possible sellers. When negotiating a group rate we actually ARE committing to buying a certain number of rooms (the room block). There are certainly pros and cons with group rates. On the pro side: guaranteed rate (but not necessarily the absolute lowest available at any time), included benefits (breakfast, Internet, if applicable), free or subsidized meeting rooms where applicable. On the cons side is of course the cancellation policy (not that it has to be as onerous as this one). Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj Skype: organdemo ___ 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: Why the IESG needs to review everything...
+1 On 7/28/2011 11:22 AM, Warren Kumari wrote: ... While not all ADs read all drafts, most read a large fraction of them (and read them carefully and thoughtfully enough to catch a number of large issues (and nits) *that were not caught in LC*) -- I think that they deserve recognition for performing a valuable and un-fun function... ... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Has anyone found a hotel for Quebec City that isn't exorbitant?
I agree with Thomas, the meeting fees should cover the meetings and the hotel bill should cover only an individual's room. This would be more transparent! Please feel free to take this as criticism (of the current fee distribution policy). Lou On 6/21/2011 1:31 AM, Thomas Heide Clausen wrote: On Jun 21, 2011, at 06:30 , Joel Jaeggli wrote: It has been repeated ad-nausieum that conference rates subsidize the rental of the meeting room block... The fact that the conference rates are more expensive ( on a contract signed 24 months out) than a spot check of the room rate at any given time should come as no surprise to anyone. You can cruise the IETF finances if for some reason you don't believe this. If the room block doesn't get filled you can expect your fees to go up accordingly over time. I will observe that I have generally not paid the conference rate or stayed in the meeting hotel while attending the IETF on my own dime (and have stayed in some rather nicer hotels (paris, stockholm, etc) for less money as a result. When I attend on behalf my employer I make it clear what we paying for when participating. Just one additional data-point here. For some of us, getting reimbursed for a higher meeting fee is actually a lot easier than getting reimbursed for a higher hotel-fee. Such would be the case when, for example, traveling on a fixed per-diem intended for covering accommodation/food, but reimbursed on cost for the meeting fee. For me, not an eyelid would be bat if I presented a quadruple (or more) meeting-fee-bill -- whereas it is a recurring administrative hassle to actually get a hotel-bill exceeding the per-diem to pass accounting (and, actually quite a lottery each time if it will be reimbursed) Not wanting to criticize, but I would encourage that such situations also be considered when making plans for the IETF meeting payment structure. Sincerely yours Thomas ps: Other than that, I am actually excited to go to Quebec City which - for those who've never been there - is a very very pleasant place to be. Also, when there, my French colleagues tend to mock me a whole lot less for my accent ;) please look at the balance sheet here: http://iaoc.ietf.org/documents/Meeting-Financials-2010-77.pdf and note both the hotel commission, a credit, and the zero charge associated with meeting rooms. It's not clear to me that this can be made more transparent, but if you'd like to try I'm sure that someone would be happy to nominate you for an open iaoc position when available. joel ___ 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: [79all] IETF Badge
Xiangsong, I suspect you may have misunderstood me. I'm endorsing the old practice of letting in (to meetings) any who wish *without* payment or badge. Sure they won't be able to go into the terminal room, but that isn't a significant issue. Them eating the snacks could possibly turn into an issue, but it hasn't to date. Lou On 11/14/2010 9:30 PM, Xiangsong Cui wrote: Hey, Don't misunderstand me, although I'm telling a fantastic idea. Maybe I'm just old fashioned, at least from an IETF perspective, but why not just let them drop in, i.e. attend the meeting without a badge? I didn't say attending without a badge, I just said some guest may attend IETF meeting wearing GUEST BADGE. Notice the applicant should explain why he/she should be issued the guest badge there in my message. I've always felt this served the community well and is not really different from our mailing list subscription policy. (I hope no one proposes to start charging for that, but if you take the current trend/discussion a few steps farther, that's where we may end up!) I didn't oppose charging for meeting, I just suggest we may allow a few guest to attend IETF meeting (without fee) and myself would like to pay the normal meeting fees. For example, if IETF chair (or WG chair) wants to invite somebody to give IETF community (or specific WG) some speaking during the meeting week (maybe like Thursday speaking or some others), should the invited guy also register and pay the money for the speaking? Maybe HE/SHE doesn't attend any other IETF meeting. So here I just said, there MAY be the possibility that Guest can attend the meeting, I didn't say there MUST some guys who can attend IETF without fee payment. Lou BTW There was one IETF, perhaps Columbus, where I attended just one day and I still paid the full amount. Although, it cost a bit less, back then. IMO contributors will do the right thing, and we should make it easy to be a lurker as they may turn into a direct or indirect contributor. You did contribute to IETF community, maybe some other friends paid full fee but didn't go to the meeting, they even didn't get any IETF service (network, beverage, etc.). All of you deserve my respect. Regards, Xiangsong ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [79all] IETF Badge
Humm, seeing that's what we just had, I'm not sure where you're coming from. BTW I don't think there was any real surprise in this, and it doesn't diminish from our local hosts' fabulous job. I thank them for their efforts and hospitality. Lou On 11/15/2010 2:44 PM, Ole Jacobsen wrote: On Mon, 15 Nov 2010, Lou Berger wrote: Xiangsong, I suspect you may have misunderstood me. I'm endorsing the old practice of letting in (to meetings) any who wish *without* payment or badge. Sure they won't be able to go into the terminal room, but that isn't a significant issue. Them eating the snacks could possibly turn into an issue, but it hasn't to date. Lou I am sure this happens already to some extent and I don't think it's an issue (having a guest speaker, someone who wants to find out about a specific working group, whatever...). So long as this does not turn into a way to abuse the system, I don't think anyone is suggesting TSA style security at our meetings. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [79all] IETF Badge
Ole, I took your TSA reference as hyperbole referring to strict enforcement of a badge requirement. I apologize if I misunderstood. I don't think anyone would dispute that the level of badge enforcement and security was substantively different than any other IETF, and this is what I was referring to. I was also voicing support for the old badge enforcement policy for future meetings. (I also support less restrictions on the issuing of visas, at least for IETF attendees, but there's not much I/we can do about that either.) Lou On 11/15/2010 5:47 PM, Ole Jacobsen wrote: Lou, I see. So you had to take off your shoes, leave water behind and be frisked and/or scanned at this meeting? I can't say I went to every meeting room, but I did not notice any of that going on. Also, when I say suggesting it's sort of meant to be a forward looking statement not some idea that what we had will be the new norm. I'd love to not have to write this down, but if I did it would be something along the lines of Entrance to IETF meetings is for registered attendeed, wear you badge at all times, you may be challenged if you don't do so. And maybe add specifics as was done in this case. I agree that this was a great meeting, thanks to the host and everyone else involved including the hotel staff! Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj On Mon, 15 Nov 2010, Lou Berger wrote: Humm, seeing that's what we just had, I'm not sure where you're coming from. BTW I don't think there was any real surprise in this, and it doesn't diminish from our local hosts' fabulous job. I thank them for their efforts and hospitality. Lou On 11/15/2010 2:44 PM, Ole Jacobsen wrote: On Mon, 15 Nov 2010, Lou Berger wrote: Xiangsong, I suspect you may have misunderstood me. I'm endorsing the old practice of letting in (to meetings) any who wish *without* payment or badge. Sure they won't be able to go into the terminal room, but that isn't a significant issue. Them eating the snacks could possibly turn into an issue, but it hasn't to date. Lou I am sure this happens already to some extent and I don't think it's an issue (having a guest speaker, someone who wants to find out about a specific working group, whatever...). So long as this does not turn into a way to abuse the system, I don't think anyone is suggesting TSA style security at our meetings. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [79all] IETF Badge
On 11/12/2010 08:21 PM, Xiangsong Cui wrote: As to IETF registration and badge, I would like to suggest (maybe this is crazy), IETF should design another type participant, I mean Guest Participant, they are free and more limited than one day pass. For example, the Guest Participant can only attend one session (half day or 2 hours), for the given WG seesion. And, the amount of Guest Participant should be strictly limited. Maybe I'm just old fashioned, at least from an IETF perspective, but why not just let them drop in, i.e. attend the meeting without a badge? I've always felt this served the community well and is not really different from our mailing list subscription policy. (I hope no one proposes to start charging for that, but if you take the current trend/discussion a few steps farther, that's where we may end up!) Lou BTW There was one IETF, perhaps Columbus, where I attended just one day and I still paid the full amount. Although, it cost a bit less, back then. IMO contributors will do the right thing, and we should make it easy to be a lurker as they may turn into a direct or indirect contributor. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Above market hotel room rates
Phil, I've been booking lower non-ietf rates at most IETFs for quite some time now. I don't remember when I started, but it certainly was after AMS took over. If the problem is really as you suggest, that rates go down from the time of contract signing to when the meeting is actually held, then this can be easily addressed in the contract. If one had checked rates at the time this hotel was announced, you would have found like I did that the adjacent weeks had much lower rates than this week. This was the context for my question to Ray in Hiroshima. Clearly those who are negotiating on our behalf could be doing a better job on pricing. If they can't get obtain better prices, what's the point of having a IETF/group rate? We should all just book individually. I don't think anyone, including myself, need someone to cry to, but I do want an IAD/secretariat that works to the benefit of the IETF. I can't speak for anyone but myself, I come to the IETF to work. I really don't come to the IETF for the nearby attractions or the right brownies. In order to do our work, I think we need a reasonable and safe meeting environment (which includes no construction, a past problem that the secretariat thankfully ensures no longer occurs), a meeting location that is easily accessible, and costs that are contained (because if they're not, my and many others ability to attend will be limited.) Perhaps I'm misinformed or being unreasonable, but I expect that it is the IAD/secretariat's job to deliver these. Lou On 3/23/2010 8:19 PM, pjnes...@gmail.com wrote: Well I am not in the secretariat but I expect it is something along the lines of: The ietf reserves the hotel a year or more in advance and signs a contract for a block or rooms at rate X which is a discount on what the hotel expects room rates to be in the future. Then a year goes by and the economy dictates what the actual room rates are at the time of the conference. Usually its a lot more. Occasionally its not. Anyone making reservations should always ask what rate is available at the time. Of the standard rate is less then book that. People need to be responsible for themselves and not cry to the secretariat to manage their lives for them. I paid for my own way when I went to meetings and you can be sure I asked when making reservations. Phil --Original Message-- From: Lou Berger Sender: ietf-boun...@ietf.org To: Samuel Weiler Cc: ietf@ietf.org Subject: Re: Above market hotel room rates Sent: Mar 23, 2010 7:36 PM I asked Ray about this problem in Hiroshima, his response was something along the lines of conference rates are different and more complicated from regular hotel rates. I have to say, I really think the community deserves a detailed response on this topic from the secretariat... Lou On 3/23/2010 6:44 PM, Samuel Weiler wrote: Once again, we appear to be meeting in a hotel that's offering lower rates to the general public than they're offering to us. As of right now, the Best Available Rate at the Anaheim Hilton for tonight, 23 March 2010, is $119. The senior rate is $113. That's from hilton.com. With a 2 day cancellation policy. The same rate is also available for a three night stay, leaving on Friday. -- Sam ___ 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 Sent from my Verizon Wireless BlackBerry ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Above market hotel room rates
Don, Now this is the explanation I expected to hear. I was explicitly told that this wasn't the case for the IETF. If there is a subsidy, I think it should be disclosed, and doing something along the lines of what the 802 does would be completely reasonable. Lou On 3/23/2010 11:54 PM, Donald Eastlake wrote: On Tue, Mar 23, 2010 at 10:36 PM, Lou Berger lber...@labn.net mailto:lber...@labn.net wrote: I asked Ray about this problem in Hiroshima, his response was something along the lines of conference rates are different and more complicated from regular hotel rates. I have to say, I really think the community deserves a detailed response on this topic from the secretariat... Lou I don't know why you would expect a different answer from the answer that has previously been provided. Its complicated and each meeting is a little different but in general, the lower the room rates the higher the registration fee. If, in effect, registration fees are being subsidized by room rates and enough people evade the room rates one way or another, the registration fees have to go up. For an interesting and unusual example, here is some registration information for the March 2010 IEEE 802 Plenary meeting, which I attended in Orlando, Florida, last week: http://ieee802.facetoface-events.com/files/sessions/63/update2.pdf You will note (see red text at near the bottom of the page) that, if you didn't stay in one of the two official meeting hotels, you had to pay an extra $300 registration fee. Thanks, Donald On 3/23/2010 6:44 PM, Samuel Weiler wrote: Once again, we appear to be meeting in a hotel that's offering lower rates to the general public than they're offering to us. As of right now, the Best Available Rate at the Anaheim Hilton for tonight, 23 March 2010, is $119. The senior rate is $113. That's from hilton.com http://hilton.com. With a 2 day cancellation policy. The same rate is also available for a three night stay, leaving on Friday. -- Sam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Above market hotel room rates
FWIW My rate in Hiroshima was both lower than the IETF rate and included breakfast. I asked at check in if the IETF rate included anything not included in my cheaper rate, and was told no by the hotel staff. Lou On 3/24/2010 8:23 AM, Tony Hansen wrote: Another factor is that the going IETF room rate may include other items as part of the package. For example, in Hiroshima breakfast was included in the IETF room rate, but not the off the shelf rate. Other amenities will vary. Tony Hansen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Above market hotel room rates
I have no issue if the hotel rates subsidizes the meeting. I've been told that this is not the case, even though it is what I/many expect. I guess I should just accept that there is one and that there is no transparency on this point. Lou On 3/24/2010 10:33 AM, Dave Cridland wrote: On Wed Mar 24 17:25:41 2010, Lou Berger wrote: FWIW My rate in Hiroshima was both lower than the IETF rate and included breakfast. I asked at check in if the IETF rate included anything not included in my cheaper rate, and was told no by the hotel staff. Maybe it includes a warm fuzzy feeling that you're helping the IETF keep registration costs low. Maybe if you get an official room, you'll see that as a line item on the bill at checkout. Dave. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Above market hotel room rates
I asked Ray about this problem in Hiroshima, his response was something along the lines of conference rates are different and more complicated from regular hotel rates. I have to say, I really think the community deserves a detailed response on this topic from the secretariat... Lou On 3/23/2010 6:44 PM, Samuel Weiler wrote: Once again, we appear to be meeting in a hotel that's offering lower rates to the general public than they're offering to us. As of right now, the Best Available Rate at the Anaheim Hilton for tonight, 23 March 2010, is $119. The senior rate is $113. That's from hilton.com. With a 2 day cancellation policy. The same rate is also available for a three night stay, leaving on Friday. -- Sam ___ 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: Hiroshima room rates (was Re: Non-smoking rooms at the Hiroshima venue?)
Yes. I checked Sept 14-18. Try it yourself, I expect you'll get the same results... Lou On 9/4/2009 7:32 AM, Andrew G. Malis wrote: Lou, Does that online rate you saw include in-room Internet, service charges, and taxes? Those are included in the IETF rate. Cheers, Andy On Thu, Sep 3, 2009 at 12:43 PM, Lou Bergerlber...@labn.net wrote: Out of curiosity, why is the IETF rate ~2000Y higher than their standard internet room rate (try to book next week to get an example rate, and see Best Flexible Rate w/ Breakfast)? Thanks, Lou ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Hiroshima room rates (was Re: Non-smoking rooms at the Hiroshima venue?)
Out of curiosity, why is the IETF rate ~2000Y higher than their standard internet room rate (try to book next week to get an example rate, and see Best Flexible Rate w/ Breakfast)? Thanks, Lou On 9/1/2009 2:00 PM, Alexa Morris wrote: 60% of our room block is considered non smoking but, as our room block is on the smaller side, it is possible that all non smoking rooms are indeed sold out. We have contacted the hotel to see how we can best work through this issue, but at the moment it is only 3am in Hiroshima so it will be a number of hours before we hear back. We will update everyone as soon as we know more. Alexa On Sep 1, 2009, at 10:33 AM, Ole Jacobsen wrote: Mike, I am going to let AMS answer that since they have the contract with the ANA. My understanding as of right now is that about 60% of the rooms are non-smoking. The ANA has been aware of our desire for non-smoking rooms for a long time so I am sure they are working on whatever solution they can find. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj On Tue, 1 Sep 2009, Michael StJohns wrote: Hi Ole - As of today, I was only able to book a twin room SMOKING at 19,000y at the ANA - there are no singles at the lower rate. There are no non-smoking rooms even at the higher rate. Given that I believe you're correct that most of the IETF will be looking for a non-smoking room, I'm not convinced that the hotel will be able to air clean all the necessary rooms in time. It's possible, but would seem to be a lot of effort (and cost?) for the hotel that already has a signed agreement with the IETF - unless that agreement specifically requires that all non-smoking requests be accommodated? Since you're on the IAOC I believe, could you comment if that was part of the booking agreement? Could you also comment on the mix of rooms that the agreement covers? E.g. how many singles, doubles, etc? I find it problematic that less than 18 hours after registration opens, we're already out of the lower cost rooms and the non-smoking rooms. Mike ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf --- 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: XML2RFC must die, was: Re: Two different threads - IETF Document Format
I *strongly* support please don't ever *mandate* it [XML2RFC]. Although, I'm perfectly happy using the obscure syntax of nroff (when combined with a set of macros I received from George Swallow about 10-12 years ago). I produced a couple of drafts using xml and decided that nroff was much easier and let me focus on the the document rather than the document production... Lou On 7/5/2009 7:25 PM, Hadriel Kaplan wrote: At 11:01 AM 7/5/2009, Joel M. Halpern wrote: I have seen some folks arguing that we should make XML2RFC normative and mandatory. If they can figure out how to automatically and accurate convert the other mechanisms people use, then that can be considered. Otherwise, mandating would be inappropriate, as some folks do indeed find it difficult. +1 For those who are used to MS-Word, XMLMind is frustrating and truly requires an XML mind. Even simple things like cut/paste are done in a very different (and frankly inconsistent) way, as are references and such. In theory a WYSIWYG word processor shouldn't require an author to know the internal representation and underlying language of the document format. I know a large number if not outright majority of IETF authors do not use MS-Word, so XML2RFC is a fine *option* - but please don't ever *mandate* it and force the rest of us have to write documents in a syntax only a tiny fraction of the planet uses and understands. -hadriel ___ 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: IETF Cheerleaders?
see http://www.fightforchildren.org/events_2_1.asp At 03:57 PM 11/11/2004, William Gilliam wrote: OK, I'll ask. Who convinced the Washington Redskins Cheerleaders to show up during today's afternoon break? C'mon, raise your hand. WG ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietfhttps://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
