Re: Call for a Jasmine Revolution in the IETF: Privacy, Integrity, Obscurity
On Sun, Mar 6, 2011 at 10:52 AM, Marc Petit-Huguenin petit...@acm.orgwrote: I any case, may I suggest a Bar BOF in Prague? Plotting revolutions in coffeehouses is a very old tradition. I am told that http://www.cafeslavia.cz/ was a popular hangout for Czech revolutionaries. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-intarea-shared-addressing-issues-02.txt (Issues with IP Address Sharing) to Informational RFC
On Wed, Feb 16, 2011 at 09:22, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Richard L. Barnes wrote: As an example, consider a system we built for the IETF meeting network a few years ago. The server queried a series of tables inside of NetDisco to map an IP address to the WiFi AP that it was connected to: IP address -- MAC address -- Connected AP As the MAC addresses are NOT reliable, it is a lot more straight forward to directly map between IP addresses and APs. In the (excellent!) experiment, you associated yourself with one or more MAC addresses. Your IP address is more likely to change than your MAC. Since the locations of the APs are known, this gives you the location of the endpoint to within a few tens of meters (empirically, within the IETF network). Directional antenna makes it imprecise. In the (truly excellent) experiment, the goal was to find out which room someone was in so you could find them. swb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RE: Optimizing for what? Was Re: IETF Attendance by continent
First I like the idea of Hawaii because flights and hotels can be inexpensive even from Europe (although Hilo might be cheaper and just as easy to get to as Honolulu). However I still think we need to account for actual participation in the equation to decide which places to hold meetings. Participation is more than just registering. Scott On Aug 30, 2010 7:54 PM, Robin Uyeshiro uyesh...@ifa.hawaii.edu wrote: The island that would probably best address most of the concerns brought up recently is Oahu. Large hotels on the neighbor islands tend to be resorts, where the idea is to keep you in the one hotel while not sightseeing. While there are several large hotels on Oahu that have meeting facilities, there is also the Hawaii Convention Center (http://www.hawaiiconvention.com/). Honolulu International Airport (HNL) has extensive direct connections to North America and Asia. The hotels in Waikiki are an easy taxi/bus/shuttle/rental car ride away. There are many restaurants and bars (of various repute) an easy walk from the Convention Center, as well as a major shopping center. There are several large hotels within 10 minutes walk. Hotel and airline prices will depend on the season. Spring and Fall would probably be the least expensive. The main problem would probably be finding a sponsor. Robin Uyeshiro Inst. for Astronomy Univ. of Hawaii -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Randall Gellens Sent: Monday, August 30, 2010 12:21 PM To: Hadriel Kaplan Cc: IETF-Discussion list S... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Ad Hoc BOFs
Throwing a draft at the IETF without a lot of supporting work rarely gets anywhere, but some people find it hard to figure out just what supporting work is actually effective and to execute on it. It's the non-procedural parts of the IETF process that confound people, and lead to various end runs. I suspect that the way to lessen the number of on the edge activities is to (1) encourage interim meetings including BOFs with good teleconferencing, and (2) make the process for getting work considered in the IETF even more procedural than it is, to make it easier for sumner to work with it. On Jul 30, 2010 3:07 PM, Yoav Nir y...@checkpoint.com wrote: On Jul 30, 2010, at 7:32 PM, Melinda Shore wrote: Yoav Nir wrote: First is people who have an... True. The implication that there needs to be a session, with a room and slides and humans sitting in ... There doesn't need to be, but that is one way to do things. There are hundreds of drafts posted every week. We all ignore most of them. A short presentation might get enough people interested to start a discussion on some mailing list. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.o... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Ad Hoc BOFs
Once upon a time Bob Braden would alternate WG sessions, one open and then one only for people who were actually contributing. On Jul 31, 2010 7:00 AM, Peter Saint-Andre stpe...@stpeter.im wrote: At 9:32 AM -0800 7/30/10, Melinda Shore wrote: The implication that there needs to be a session, with a room and slides and humans sitting in c... Double bingo. The number of WG sessions (which are ostensibly scheduled for the purpose of working) in which folks have not read the drafts or otherwise prepared themselves to actively contribute is also distressingly high. Perhaps we all simply have too much work to do, or perhaps many drafts are written in such a way that folks can't easily grok the problem and its proposed solution. Regarding the latter, one of the WGs I advise held a small tutorial session in a side room on Friday morning and that turned out to be quite useful because it forced some of the key contributors (in this case the chairs) to clearly explain the core concepts behind the protocol under development within the WG, and I think that effort will pay off in the form of a much clearer and more readable specification. Peter ___ Ietf mailing list Ietf@ietf.org https://www.ietf.or... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: On the IETF Consensus process
I believe I agree with Brian. It sounds like you are hoping for clear deterministic procedures, but imho the IETF should avoid too much deterministic procedure. We shouldn't say Mr. Chairman, you evaluated consensus within the last 10 minutes, therefore your new request is disallowed!. Sometimes when issues are tricky you need to break them down into small steps and be very clear at each step. Sometimes everything is easy and you can sail through major milestones. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ADs speaking for their WGs
On 04/20/2007 08:35 AM, Brian E Carpenter wrote: It seems fairly clear in RFC 2418 section 6.1: The Chair has the responsibility and the authority to make decisions, on behalf of the working group, regarding all matters of working group process and staffing, in conformance with the rules of the IETF. The AD has the authority and the responsibility to assist in making those decisions at the request of the Chair or when circumstances warrant such an intervention. So the AD *does* have authority *when circumstances warrant*, but only on matters of process and staffing. I'm sure Jeff Schiller didn't mean any more than that - this rule doesn't allow an AD to take technical decisions unilaterally, but does allow an AD to make a consensus call if for some reason the WG Chairs can't do so. (And all subject to the regular appeal process, of course.) My recollection is that Jeff made a technical decision and announced it, because everyone agreed the process was deadlocked. I don't recall that he ever took over for a WG chair, but there was agreement that the WG was stuck and a decision was required. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
On 04/11/2007 05:22 AM, Simon Josefsson wrote: I am working on a document with guidelines for free standards in the IETF Please don't use free standards this way. The IETF produces free standards. Some of those standards have IPR licenses that you don't like. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
On 03/30/2007 13:56 PM, John C Klensin wrote: For whatever it is worth, I think we need to step carefully around the distinction Paul makes above: there are almost certainly circumstances in which we should accept a broader grant of rights conditional on standardization and a narrower one if the technology is not standardized. I wish the IPR WG were paying a bit more attention to this sort of issue. This is a WG decision. IPR WG could produce guidance on the subject, but that's all. What are you looking for? On 03/30/2007 14:36 PM, Jeffrey Hutzelman wrote: If the IPR issues are the sole remaining factor in the IETF's decision as to whether to make a protocol a standard, then I think it is entirely reasonable for the IETF to consider an offer which would eliminate or at least mitigate those issues if the protocol were to become a standard. As Spencer pointed out, text like If included in a standard is common. We already do this implicitly. swb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Identifying meeting attendees
On 03/29/2007 21:23 PM, Yao Jiankang wrote: Maybe, when we register the IETF meeting, we not only register the English name but also the Native character name. further, IETF may print both the English name and the Native character name on the Name Tag. :) +1 Native language biggest on the badge ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: gen-art review of draft-ietf-ipv6-2461bis-09.txt
Thomas, I agree with everything you say below except that some of what you say may, in fact, be the justifications we are looking for. I didn't say examples, I said explanations. See below ... On 11/22/2006 09:06 AM, Thomas Narten allegedly wrote: Scott W Brim [EMAIL PROTECTED] writes: I have one question on the protocol, and several on documentation. Since this is a significant protocol, documentation is very important. For the sake of new implementors I have a number of suggestions for clarity. Many of them have to do with the use of SHOULD, since we have been polishing up its use and advice to implementors. ... We've been tightening up SHOULDs recently. RFC2119 says: SHOULD This word, or the adjective RECOMMENDED, mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. In this draft, otherwise ... SHOULD implies that there are situations in which the link layer address is known, and the source address is included, but the link layer address may be omitted. RFC2119 says that deserves explanation. I don't agree with your last sentence. Where exactly does 2119 say that deserves explanation? It says the full implications must be understood and carefully weighed before choosing a different course. How do you expect implementors to carefully way the full implications if you don't give them information with which to do so? Why did you choose to say only SHOULD? Tell them. The point is to give implementors the benefit of the weeks of debate that went on in the WG. If you say something SHOULD be done, you should also go on to say, for example, in the case of implementations that don't support option Y, it can't, and you need to take that into account. If the IESG is now requring all uses of SHOULD to give examples of when the SHOULD might not apply, I think that goes a bit far. In some cases, SHOULD is chosen because we can imagine a future spec taking advantage of something that would not be consistent with the SHOULD. If that's the justification for the SHOULD, then that is all you need to say. Also, anyone familiar with WG discussions knows that there is often support for SHOULD, but not for MUST. Absolutely. This isn't about SHOULD versus MUST, it's about helping implementors understand your reasoning. swb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ieprep] Re: WG Review: Recharter ofInternet Emergency Preparedness (ieprep)
On 11/09/2006 18:43 PM, Sam Hartman allegedly wrote: Scott == Scott W Brim [EMAIL PROTECTED] writes: Scott However, it is important that the IETF not *just* do Scott protocols. The IETF needs to consider how proposed Scott architectures fit in with all the other requirements on Scott the Internet. The IETF doesn't do protocol engineering, it Scott does Internet engineering. It is fine for other Scott organizations (not necessarily SDOs) to do service Scott requirements and scenarios. They can *propose* Scott architectures. If the IETF can support those architectures Scott in ways that are consistent with overall Internet design, Scott then fine. Otherwise the IETF should not be restricted to Scott just protocol extension/definition. The IETF has to think Scott of a bigger picture. Completely agree. I'd rather see architectures and systems proposed elsewhere, reviewed by the ietf, and then us develop the protocols. There may be some cases where we do architecture work; I don't think this is one of them. Please help me figure out the essential differences between architecture that should be done in the IETF and architecture that can be done elsewhere. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
gen-art review of draft-ietf-ipv6-2461bis-09.txt
I am the assigned Gen-ART reviewer for draft-ietf-ipv6-2461bis-09.txt. For background on Gen-ART, please see the FAQ at http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html. Please resolve these comments along with any other Last Call comments you may receive. Summary statement: This draft is basically ready for publication, but has nits that should be fixed before publication. I have one question on the protocol, and several on documentation. Since this is a significant protocol, documentation is very important. For the sake of new implementors I have a number of suggestions for clarity. Many of them have to do with the use of SHOULD, since we have been polishing up its use and advice to implementors. I'll start with my protocol question: 7.2.7 Anycast neighbor announcements - Second, the Override flag in Neighbor Advertisements SHOULD be set to 0, so that when multiple advertisements are received, the first received advertisement is used rather than the most recently received advertisement. How does the Override flag work when you advertise an included prefix? In this case, I'm advertising a single route to you with the Override flag off. What if you already have a route to a larger prefix that includes it? Do I punch a hole? Am I discarded? Is this documented? OK, onward to non-protocol issues. 3.0 protocol overview - Duplicate address detection Duplicate Address Detection: How a node determines that an address it wishes to use is not already in use by another node. should be Duplicate Address Detection: How a node determines whether or not an address it wishes to use is already in use by another node. - Router advertisement: the phrase on-link determination has not appeared before. It should be explained. 4.1 router solicitation message - Source link-layer address The link-layer address of the sender, if known. MUST NOT be included if the Source Address is the unspecified address. Otherwise it SHOULD be included on link layers that have addresses. We've been tightening up SHOULDs recently. RFC2119 says: SHOULD This word, or the adjective RECOMMENDED, mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. In this draft, otherwise ... SHOULD implies that there are situations in which the link layer address is known, and the source address is included, but the link layer address may be omitted. RFC2119 says that deserves explanation. As guidance to implementors, who are supposed to understand the full implications and carefully weigh them, when would this be appropriate? For load balancing? If so just say so. For example down below in Router Advertisement Message, you say A router MAY omit this option in order to enable inbound load sharing across multiple link-layer addresses. Something like that would work here -- if nothing else add a pointer to text elsewhere. There are more issues with SHOULDs not being thoroughly explained below. I'm only listing the ones where I believe naive implementors might benefit from explanation. 4.2 router advertisement - Note: If neither M nor O flags are set this indicates that no information is available via DHCPv6. This means that the responding router always knows if DHCPv6 is definitely available or definitely not available. Is there any possibility that the responding router might not know? If so, how about changing the text to is known to be available? - SHOULD be sent on links that have a variable MTU (as specified in the document that describes how to run IP over the particular link type). MAY be sent on other links. Same comment on undocumented SHOULD. How about changing it to MUST be sent ... (where specified ...)? 4.3 neighbor solicitation - Source link-layer address The link-layer address for the sender. MUST NOT be included when the source IP address is the unspecified address. Otherwise, on link layers that have addresses this option MUST be included in multicast solicitations and SHOULD be included in unicast solicitations. Same thing about SHOULD. If it SHOULD be included, under what conditions is it expected that it would not be? 4.4 Neighbor advertisement - Override Flag: It SHOULD NOT be set in solicited advertisements for anycast addresses and in solicited proxy advertisements. It SHOULD be set in other solicited advertisements and in unsolicited advertisements. SHOULD and SHOULD NOT without explanation. Should these be MUSTs? - Target link-layer address: When responding to a unicast Neighbor Solicitation this option SHOULD be
Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)
Excerpts from Sam Hartman on Thu, Nov 02, 2006 02:30:43PM -0500: To propose concrete action, I think the IETF should draft a liaison statement for action to the ITU asking for them to comment on whether they see any current conflicts and on whether there are parts of this work they would be interested in picking up. The liaison from ITU-T is supposed to be posted on the IETF liaison site on Monday. Watch for it. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ieprep] Re: WG Review: Recharter ofInternet Emergency Preparedness (ieprep)
Excerpts from Dolly, Martin C, NPE on Mon, Nov 06, 2006 01:22:26PM -0600: 1) Should this work be done within the IETF? Not all the work in this space is appropriate for the IETF (e.g., architecture dependent). The appropriate work (protocol extension/definition) should be done in the IETF. If a protocol extension or new capability is required, the protocol/capability work MUST be done in the IETF. WRT, the problem definition and requirements: the initial analysis MAY be done in another SDO (eg,. ATIS), and be brought to the IETF when a gap/need has been identified. A service like ETS is supported and deployed in certain architecture/deployment scenarios, whereby the expertise is not in the IETF. ETS Service Definition requirements are appropriate for ATIS. Side note: my focus is on the ETS service. All of the major players (vendors, service providers, contractors, and most importantly CUSTOMER), attend and participate in the ATIS work. However, it is important that the IETF not *just* do protocols. The IETF needs to consider how proposed architectures fit in with all the other requirements on the Internet. The IETF doesn't do protocol engineering, it does Internet engineering. It is fine for other organizations (not necessarily SDOs) to do service requirements and scenarios. They can *propose* architectures. If the IETF can support those architectures in ways that are consistent with overall Internet design, then fine. Otherwise the IETF should not be restricted to just protocol extension/definition. The IETF has to think of a bigger picture. swb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)
Excerpts from Sam Hartman on Wed, Nov 01, 2006 04:34:20PM -0500: [I could not find the ITU's liaison to the IETF. Scott, if such exists, I'd appreciate you forwarding this to them.] The ITU-T's liaison from SG13 to the IETF is Hui-Lan Lu. CCed. FYI SG13 is about to send something to the IETF asking for help on technical issues in emergency telecommunications. I'll ask them to expedite it but you shouldn't expect it before the middle of next week. swb Hi. I'm speaking here as an individual. I'd like to build consensus for my position both within the IESG and within the community, but I realize that if I fail to build that consensus, I cannot make this objection as a single IESG member. I don't believe the new charter of ieprep working group belongs in the IETF. I understand why we chartered it here, and I believe that by doing as much work as we have done so far in the IETF, we have done something useful. We've described the broad problem and have helped to explain how it fits in the Internet context. That was an important thing for us to do. However the work that remains belongs somewhere else--probably the ITU-T. I propose that we work with ITU to see if they are interested in the work and if so, use this as an opportunity to foster cooperation with work going to the ITU. In order for the proposed charter to be successful, the working group will need to go far outside the IETF's normal technical mandate and venture into the space of network design to come up with requirements documents. The technical aspects of this problem are only one of the things going into successful requirements. Based on my limited knowledge I believe that the ITU is in a better position than the IETF to specify requirements and mechanisms for national and government telecommunications networks. I think we should let them do their job just as we ask them to let us do our job and to design the technical protocols that are increasingly being used on those networks. Naturally, the IETF should make any necessary modifications to IETF protocols to implement IEPREP work regardless of where it takes place. The main argument I've heard throughout the existence of ieprep for why it needed to happen in the IETF is that if it happens elsewhere, they'll do something we don't like or do it wrong. Perhaps that was once a valid argument. However, I think we have enough of the details of technical approaches that we find appropriate documented that we can give sufficient input to another body on what approaches work on the Internet. I would assume we'd ask people working in this space to take a look at the existing ieprep output, RFC 4542, RFC 4411, draft-ietf-tsvwg-vpn-signal-preemption and other appropriate documents. I think that given this input another group could understand what works well on the internet and could work both on requirements related to the technology as well as the overall system architecture so we end up with deployable solutions at national and governmental levels. In addition, I believe that since the first part of the ieprep work happened here, we would be in a good position to work with whatever standards body did the work to scope the charter to favor technologies that would work well on the Internet. Thanks for your consideration, --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: San Diego (was RE: Meetings in other regions)
On 07/19/2006 20:08 PM, Clint Chaplin allegedly wrote: Another data point; San Diego is hosting Comic-Con this weekend: they're expecting on the order of 100,000 attendees. The weekend before the IETF? Hey, that's an advantage! ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meetings in other regions
On 07/17/2006 15:46 PM, Andy Bierman allegedly wrote: - I didn't find a terminal room, but instead a giant 'break room' for ad-hoc meetings and food breaks. This was wonderful, and about time! 802.11 has thankfully made the terminal room obsolete. I want this format every time. Please consider 2 enhancements: Ignoring the subject, I just want to add enthusiastic praise for the big all-day break room. It was great for meeting people and getting work done, instead of sitting on the floor in the hallways or out in a park (well, we did that once). It's a big productivity enhancer and I hope it wouldn't cost too much to continue something like it. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meetings in other regions
Can you normalize like this? 1523 drafts have authors from North America, and so on. If a draft has three authors from North America and two from Europe, is the draft counted five times or two times? swb On 07/15/2006 00:18 AM, Noel Chiappa allegedly wrote: From: Henrik Levkowetz [EMAIL PROTECTED] (Note that since drafts can have multiple authors, the sum of the following percentages are more than 100%), # 1523 drafts (73.08%) have authors from North America. # 1116 drafts (53.55%) have authors from Europe. # 417 drafts (20.01%) have authors from Asia. # 33 drafts (1.58%) have authors from Australia. # 9 drafts (0.43%) have authors from South America. # 3 drafts (0.14%) have authors from Africa. # 1 drafts (0.05%) have authors from OTHER. Renormalizing percentages so that they sum to 100%, we get: 49.09% of authors are from North America. 35.97% of authors are from Europe. 13.44% of authors are from Asia. 1.06% of authors are from Australia .28% of authors are from South America. .09% of authors are from Africa. .03% of authors are from OTHER. Sounds like out of every 6 IETF's, one should be in Asia, two in Europe, and the other three in North America: NA/Europe/NA/Europe/NA/Asia spreads things out evenly. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meetings in other regions
On 07/14/2006 10:01 AM, Fred Baker allegedly wrote: Once upon a time, the guideline I followed was that about 1/6 of the IETF was from Europe, a smattering was from elsewhere, and the lion's share was from the US, so I scheduled a meeting every other year in Europe, the odd one in random places, and the lion's share in the US. Those statistics are essentially meaningless now. Why are they meaningless? The IETF should overwhelmingly meet where the participants are, wherever that might be. I still like your algorithm. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meetings in other regions
Thanks for the clarification. I just wanted to be sure what those statistics referred to. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Additionto ASCII Text' to Experimental RFC (draft-ash-alt-formats)
On 06/25/2006 15:55 PM, Stephen Sprunk allegedly wrote: the IETF is supposedly about running code, and complex equations that the average programmer cannot understand without digging up a college math book are unimplementable in the real world. Pseudocode is far, far more valuable than pretty equations. Good point. While I agree completely with the proponents of richer formats that plaintext is poor for communicating how things work, it can't be beat for discipline in creating implementation specs. Perhaps we should have rich formats for background documents, framework documents, etc., but stick to plaintext for documents that actually define protocols for implementation. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IDs first? RE: Last Call: 'Proposed Experiment: Normative Format in AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)
From: Keith Moore [mailto:[EMAIL PROTECTED] Creating one of these archives is easy, just view the HTML page and click 'save as archive'. My copy of firefox doesn't seem to have that feature. Maybe you need to include the archive extension: http://maf.mozdev.org. When I do I get three options: MAF archive, MAF ZIP archive and MAF MHT archive. On Windows, if I save it in Firefox as an MHT archive, then doubleclick on it, it opens apparently correctly in Internet Explorer. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Acknowledgements section in a RFC (Was: Last Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching)
On 06/07/2006 09:22 AM, Stephane Bortzmeyer allegedly wrote: These rules are perfectly reasonable (even if they would cost me my acknowledgment in draft-ietf-ltru-matching) but: 1) They do not seem to be written somewhere. I cannot find them in the RFCs talking about RFCs (meta-RFCs? IPODs?). 2) They are not currently applied or enforced, as anyone can see when comparing a RFC with the work in the WG which created it. (Not a big deal but good to keep in mind when you read an Ack section.) They should not be *rules*. If you try to formalize the definition of a contribution, then we get into eternal niggling. If you feel like you have been unjustly left out of an acknowledgments section in a specific draft or RFC, argue your case. Let's not have yet more process and procedure and administration for issues that don't affect running code. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: Proposed 2008 - 2010 IETF Meeting Calendar
On 05/30/2006 12:17 PM, Yaakov Stein allegedly wrote: I also don't imagine that there are that many co-participants of SG4 and IETF. Well, we have at least one SG4 rapporteur who is pretty active. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: Proposed 2008 - 2010 IETF Meeting Calendar
On 05/17/2006 12:15 PM, Dave Crocker allegedly wrote: This is a community. It extends beyond the boundaries of the IETF and the IETF is not the center' of that community. Is there a center? Is there a centroid? If so, what/where? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On Tue, Mar 28, 2006 04:12:24PM -0500, Noel Chiappa allegedly wrote: locators are a lot easier to deal with if they're location-independent Huh? Did you mean identifiers are a lot easier to deal with if they're location-independent? I really was talking about locators, not identifiers. Now that I understand what you actually meant, I'm not freaked out! However, you phrased your point in a way that almost guaranteed confusion! You didn't mean locators are a lot easier to deal with if the name has nothing to do with where the thing it names is, you meant locators are a lot easier to deal with if their meaning (i.e. the thing they are bound to) is the same no matter where you are when you evaluate them. This is a problem for PIP-like schemes and mobility. At any point in the network, the locator to use to reach a particular target is unique. However, the locator to use to reach a particular target is different at every point. That would be okay except that when *I* move, the way I address a target changes. That's more of a problem than having to adjust as my target moves. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: About cookies and refreshments cost and abuse
On Tue, Mar 28, 2006 11:16:33AM -0500, Steve Silverman allegedly wrote: In Paris, we switched to a late dinner which was necessary in Paris but we did this in Dallas. Was this a general decision that I missed? I prefer dinner from 6 - 8 and a night session where the local customs support this. This might also cut down the need for afternoon sugar consumption. Oh good, this isn't about cookies anymore. I for one was against using the Paris schedule in Dallas, but I came around quickly, especially with the -- do I have to say it? -- late afternoon cookies. I now think the new schedule is excellent and would like to see it at all future IETFs. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Proposed 2008 - 2010 IETF Meeting dates
On Mon, Mar 27, 2006 04:18:42PM +0100, Tim Chown allegedly wrote: On Mon, Mar 27, 2006 at 10:38:03AM +0200, Brian E Carpenter wrote: I don't think the analogy holds, for a number of reasons. (As a matter of interest, there were about 6 participants out of 350 with addresses in Europe at the March 1991 IETF meeting, and about 19 out of 530 in March 1993. At that point, scheduling against RIPE would certainly have become a practical problem.) You have to consider the most important clashes; IETF66 clashes with the World Cup Final on July 9th. I hope Canada has good coverage, if not a good football team :) There are plenty of bars in Montreal. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: the iab net neutrality
On Fri, Mar 24, 2006 05:00:07AM -0500, John C Klensin allegedly wrote: There are two strategies that make more sense and have more chance of success. One is precisely what 4084 attempted to do: lay out categories and boundaries that, if adopted, make better information available to potential users/customers and provide a foundation for regulation about what must be accurately disclosed (as compared to what is required).That said, I've been quite disappointed with the results of 4084: from the comments and input I got before we did the work, I was optimistic that we would see at least some ISPs, and maybe even some regulators, pick the concepts and terminology up. To put it mildly, it hasn't happened. The other approach, with thanks to Dave Clark for pointing it out to me a few years ago, is to carefully write a neutral and balanced document whose theme is of course the Internet architecture permits you do this, but, if you do, it will have the following good and bad consequences which you should understand in making your decisions. Either approach requires serious work and people on the IAB who are interested, willing, and have the skills to do it. I can't speak for the current IAB at all but, if the sort of output Tony and I are talking about is wanted, then people need to tell the Nomcom(s) that the ability and willingness to generate it should be an important candidate selection criterion. These are great, John, but as you say, both approaches require serious work -- both before and after publication. In fact spreading an idea can take much more work, over a longer time, than agreeing on it, writing it up, and implementing it in the first place. A healthy Internet requires effort on three fronts: innovation to start with, deployment (not just of new ideas, but of what we have already to lesser developed areas), and finally trying to get our principles, conceptual framework, and attitudes accepted elsewhere. The first is the usual focus of IETF WGs. These days the third is increasingly important. In all cases it's not enough to launch something -- it needs to be nursed and championed for a long time after its birth. The IAB's primary orientation should be toward breadth, not depth. Individual members can focus in particular areas but the IAB as a whole needs to cover a great deal of material on all three of these fronts. Doing a good job on all three legs of the stool takes hundreds of people. We non-IABers can generate the sort of thing you're talking about as well as the IAB, and we should. We should use the IAB as a focal point, lookouts, facilitators, instigators, conveners, as well as as individuals for their expertise and dedication. I think these capabilities are at least as important as being able to write up results of deliberation. We should take as least as much responsibility for doing the grunt work, including coming up with innovative ideas, writing documents like those you describe, and making sure results happen in the real world, as we expect IAB members to. See you in Montreal. swb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: 2 hour meetings
On Fri, Mar 24, 2006 02:29:23PM +, Dave Cridland allegedly wrote: I don't actually have the choice, but I find remote participation generally okay, for the most part, albeit I have the slight advantage of starting off my internet experience in telnet BBS systems, so I'm generally used to the text chat thing, the lag, etc. The audio lag is more unnerving, in the cases where the Jabber scribe is helpfully typing in what people are going to say before they say it. Many thanks to all the jabber scribes in those meetings I virtually attended, and, just as important, thanks to those physically present who also monitored and used the Jabber rooms, and thus made me feel somewhat like an attendee (albeit in the cheap seats) rather than a not present. I'm somewhat hoping that the use of the Jabber server outside the meetings might be able to take off as a method for more high-bandwidth discussion, paradoxically leaving more time in the real meetings for the kind of presentations that Keith hates, but this time having them aimed at cross pollination between groups and areas. I love what you can do in text-based systems and support the idea of having ongoing issue-specific discussions available. In text-based environments, input takes a little time, but everyone can speak at once so progress can be rapid (if facilitated well when needed). However, jabber is relatively primitive. I don't need video or audio but I would like to be able to collaborate on a figure with you, highlight text I'm talking about, that sort of thing. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Clarification of my comment on giving up on process issues
On Wed, Mar 22, 2006 05:00:14PM -0800, Hallam-Baker, Phillip allegedly wrote: I would like to see a two tier scheme for standards (i.e. eliminate the illogical and misleading status 'DRAFT') but on the understanding that standards require periodic review. By periodic I mean that there should be fixed windows that are scheduled in advance when the standard will be reviewed. There would be a fixed interval in which defect reports could be submitted. One of the topics of the general session for each area would be a report on the defect reports and discussion of whether a new revision WG was required. It might be easier to close WGs down if this was not quite so final. Allowing a 'fast track' for defect reports would encourage proposers to come to the IETF with complete proposals with a substantial degree of consensus in the user and developer communities. If the defect report is justified the need should be widely felt, if as is likely the report is describing existing field practice addressing that need there should not be a need for substantial discussion. In some cases it would be appropriate to reactivate the working group concerned, in others a mini-WG might address multiple protocols. The need is most common in the security area where crypto practices need to be revised every 5 years or so. An area wide activity describing use of SHA-256 would be an example. It seems to me that if we can't motivate people to review/evaluate/fix a proposed|draft standard once, how can we motivate them to commit to doing so periodically? Are you saying that if we allow them to slap a standard together and declare it done more easily, that they will be more willing to come back and fix it later? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Anatole in-room net confusion
Last night the nice desk lady said go ahead and agree to pay for access, and that at checkout the charges will be disappeared. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Ietf Digest, Vol 21, Issue 63
On 01/22/2006 01:19 AM, Elwyn Davies allegedly wrote: - EGP Modifications FGP, the follow-on gateway protocol. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: how to declare consensus when someone ignores consensus
On 01/22/2006 22:27 PM, John Loughney allegedly wrote: Look at various peer-to-peer protocols as a good examples of things that people use everyday, but wouldn't stand a chance of getting an RFC. Why not? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Normative figures
On 01/09/2006 10:41 AM, Sam Hartman allegedly wrote: Are you looking for normative figures? If so, can you point to an example where you think they are necessary? (I'd like to avoid a discussion of packet diagrams for the moment if that's OK) Normative figures perhaps. Normative equations definitely. Is there any input format for *just* equations (or figures), standing by themselves, which we can agree is open, standardized, stable and deterministic in output? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: objection to proposed change to consensus
On 01/09/2006 14:02 PM, John C Klensin allegedly wrote: While I agree that diagrams are not simply a religious issue, I think that there are many cases in which the use of diagrams, especially complex ones, leaves people with the impression that they have understood something when, in fact, they do not. the need to describe a complex concept in text or in ASCII art imposes a discipline that is actually quite useful. Yup, although we've seen plenty of cases where people understand text differently as well. I think I'm beginning to like TeX again. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Baby Steps (was RE: Alternative formats for IDs)
On 01/05/2006 11:28 AM, John C Klensin allegedly wrote: Even those of us who are strongly supportive of ASCII as our primary base format and those who believe that the effort needed to simplify illustrations and diagrams sufficiently that they can be accurately represented in ASCII artwork is helpful in forcing clarity are reluctant to say never. Unless the IESG has changed the rules while I was not looking, it has been permitted to post I-Ds in PDF in addition to ASCII for some years. Yes. I support ASCII as the output format. I appreciate the discipline it encourages of separating protocol specification from descriptive text and figures, and of being very clear about state machines, etc. However, there are cases where descriptive text and figures are much more informative in some other format, so I wouldn't say never (nor should I be forced into a position of choosing between never and always). I find it interesting that it has not been taken advantage of more often (and, for the record, I'm one of those who has taken advantage of it). For heuristic value ... Do you think there is a correlation between restricting ourselves to formats which are good for protocol specifications but not much else, and the skew in our success record toward problems solved by protocol specifications as opposed to the really complex system problems? :-) By the way, I like emacs picture mode. You can bind the keypad keys so that e.g. 3 means draw toward the upper right. swb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: EARLY submission deadline - Fact or Fiction?
The reason we have the deadline is to protect the Secretariat from having to be heroes. However, best would be if the need for such protection didn't arise. Instead of assuming that things to be discussed in the meetings will be written just before the meeting, and creating complexity and bureaucracy around that assumption, institute a policy that nothing *will* be discussed in the meeting unless it has already been discussed on the mailing list and the WG has failed to reach agreement on the issue (note this is about issues, not documents). This will reduce the number of drafts which must get out just before the meeting to only those which capture the result of ongoing discussion. The others won't get discussed anyway. OK, I'm optimistic, but I see all this discussion of mechanisms to elaborate a situation we don't want to be in in the first place. swb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: EARLY submission deadline - Fact or Fiction?
On Wed, Nov 30, 2005 10:07:27AM -0500, Gray, Eric allegedly wrote: Making your - admittedly optimistic - assumption and following it to a conclusion leads me to suspect that many (possibly most) WG meetings would likely be subject to last-minute cancellation if all remaining issues are resolved immediately before the meetings. You're even more optimistic than I am. Essentially every WG has problems that are not resolved by e-mail (and are rarely resolved even in person). I wouldn't expect any change in who meets, just in the meeting logistics. Those that are free of these problems need never meet in person. And don't for a minute think that Employers would fail to note that issues got resolved prior to a trip to Iceland but not before a similar meeting in Hawaii. :-). There you go, another criterion for venue selection. swb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: On revising 3777 as in draft-klensin-recall-rev-00
On Tue, Nov 15, 2005 08:15:45AM -0800, Dondeti, Lakshminath allegedly wrote: Perhaps that's one way to prove that the bar is high/low. Another way is to ask around with this in mind and see if we all run into old rumors of what has been tried and with what results :-). It would be an interesting experiment. If we don't get any recall requests, we keep making it easier until we get one or more ... but then you can't ever raise the bar back up if you then think you're getting too many. Let's get some statistics. Regarding attempts to get a group of 20 together in recent history, how many co-petitioners did they actually get? Reports solicited, details unnecessary. swb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Vancouver schedule
On 11/10/2005 07:29 AM, John C Klensin allegedly wrote: I basically like this schedule. The idea of having the evening free for a leisurely dinner, off-agenda work, or both is, and remains, very attractive. I like the idea of being done with sessions and having time for a leisurely dinner and evening discussion ... in theory. In reality ending at 8pm doesn't leave enough time. Here's a suggestion: start the mornings earlier. Do we have to wait until 9:00? How about 8:00? Everyone is awake anyway. Then we can be done in the evening at 7:00. Agreed on the interval between lunch and dinner being too long. That can be adjusted within the day's schedule. I would like to start earlier so that we can finish earlier so I can get the rest of my work done in the evening. Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Pesci-discuss] Growing concerns about PESCI
On Tue, Oct 25, 2005 08:48:23AM -0400, John C Klensin allegedly wrote: Brian, since PESCI is your show, could you reflect and comment on at least some of this before we hold a BOF and plenary presentation... a BOF that, were this an effort that was not driven by the IETF Chair, might well not be considered coherent enough to get meeting time, much less plenary time? I think the problem here is that we only have a few categories of activities. What do you call a non-plenary activity that is not a WG? All we have is a BOF, but BOF has a lot of connotations. (2) We try to avoid situations in the IETF in which the same person occupies so many roles as to be, even potentially, the sole determiner of what occurs. We tend to use pejorative terms like acting as judge and jury or conflict of interest to describe such situations, although neither term is precisely correct. But, in the instance of PESCI, we have a single person who: * Has a known and strong position on how the standards track should evolve etc. I think this is silly. This isn't about power, it's about initiative. We avoid concentrating too much power in one place but if you want something to move forward you had better be glad that someone pushes it, and please note there is a difference between taking the steps necessary to *offer* ideas and *imposing* them. In my opinion this list is a red herring. Otherwise please show me a specific abuse of power. (3) The team is expected to report at the Plenary, partially on the basis of its BOF meeting, but the BOF ends only one 50-minute break before the plenary. Not exactly time for the team to meet, carefully consider the discussion at the BOF, and prepare a report. Indeed, while it is reasonable to hope for something else, this would appear to be a setup for the well, we just got a lot of input and are thinking about it, stay tuned reports that characterized the admin restructuring process. Declaring guilt before the crime is yet another rhetorical trick. (4) We still don't have any real idea how the results of PESCI will be interpreted and processed. Exactly. So calm down and let's not cry doom just yet. On Tue, Oct 25, 2005 12:14:22PM -0400, John C Klensin allegedly wrote: More important, there have been hints of the work of this effort being approved by extraordinary means, it is reasonably rare that a design team gets a BOF and then a significant block of plenary time to present and discuss the results of that BOF at the same IETF meeting, etc. Precisely because of the complications of the leadership roles, other activities of this effort need to be far more open, public, careful, and generally sensitive to an open process and IETF community involvement than usual. I remained silent because I hoped that level of sensitivity would prevail and that this would be efficient. I am not feeling very good about that right now. Suppose the IETF Chair wanted to come up with an idea to present. He writes up a draft and then circulates it among a small group for discussion and polishing. He submits it and, being the IETF Chair, gets a time slot for presentation and discussion. The only thing Brian did that you wouldn't do is that he announced beforehand that he was getting a group together. Every IETF Chair has polished process ideas in this way. Way back, when we first tossed around the concept of working groups and areas and the IESG, Phill Gross called a few of his friends to help him work out how to organize things before presenting his ideas. I didn't think PESCI needed to be as organized as it was, but Brian did so *because* he was trying to be sensitive. So I think you have completely the wrong attitude toward this. Everyone has done something like this; Brian is doing it in a more public, process-oriented way than his predecessors. On Wed, Oct 26, 2005 09:50:28AM -0400, John C Klensin allegedly wrote: --On Wednesday, 26 October, 2005 15:06 +0200 Brian E Carpenter [EMAIL PROTECTED] wrote: And I really don't see the value of cross-posting when the pesci-discuss list exists for exactly this discussion. Much of the discussion has moved to that list. However... To the extent to which there is a serious concern that the operation of PESCI and the pesci-discuss list are an abuse of process, the IETF list is exactly the right place to have that particular discussion. All right, but only for that one question (which is a red herring, since there is no operation of pesci). Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Fwd: Can the USA welcome IETF
OK, this is getting silly. Have you ever been to an IETF meeting? You should understand the IETF culture before presuming to advise governments. The IETF is not a puppet of any government, and even if it were, that has nothing to do with RFC3683. The Last Call was reissued precisely to support the rights of the accused (your word). Because it was issued on the wrong list, some people might not have seen it. It was given *more* exposure time, not less, in order to be *more* fair, not less. Your implications that the rulers and their lackeys are gaming the system to take away rights is completely absurd. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Fwd: Can the USA welcome IETF
On 10/17/2005 13:12 PM, Eduardo Mendez allegedly wrote: Mr. Scott, IANAL. But I know when you hurt someone with others, all have to pay. I'm done. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Meeting Venue Selection Criteria
On Fri, Oct 14, 2005 01:54:10PM -0700, Dave Crocker allegedly wrote: It certainly makes sense to reword it for a pattern of difficulty or exclusion. and the method of making objective, verifiable assessments that this pattern exists will be...? Don't even try. Choose people who listen to you, give them your requirements and desires, and give them the power to evaluate the tradeoffs on the behalf of the whole group. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Beyond conflict
On Mon, Oct 10, 2005 03:17:56PM -0400, Michael StJohns allegedly wrote: At 02:43 PM 10/10/2005, you wrote: Michael StJohns wrote: Jabber room dedicated for the specific discussion. im systems do not have threading, nor is it clear how threading could/should be done. -- E.g. Jabber room for discussion on foo, jabber room for discussion on bar, etc. The key is that Jabber rooms can be created pretty much on the fly without requiring subscriptions and have tools such as archiving (e.g. I can still get the discussion from last ietf on dnsext). So Let's take this discussion to [EMAIL PROTECTED] Live discussion at 11am daily edt, but feel free to place comments at any time. for example. I haven't a clue if this will work - but that's a cultural discussion not a technical discussion best resolved by experimentation. I suggest one or more Wikis. We know the problems of mail. We know the problems of instantaneous discussion. In between you have Wikis, which allow time for contemplation before posting, archives with rather interesting non-hierarchical interconnection of posts, no need to create/destroy mailing lists, RSS, etc. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: delegating (portions of) ietf list disciplinary process
On Tue, Sep 27, 2005 05:15:05PM +0200, Brian E Carpenter allegedly wrote: I'm interested to know whether people would see arguments for either or both of 1. An IETF Ombudsman (or Ombudscommittee), to act as a dispute mediator. Good idea. These disputes take a lot of care and interested parties are often not willing or able to put the time into them that they need. Discussion can get abrupt and counterproductive. Even the very existence of an ombudsman will ensure that parties approach a dispute more carefully. 2. An IETF netiquette committee, to offload list banning procedures from the IESG. I don't think so. I prefer that this responsibility stay with a few individuals, so that it is taken very seriously -- not only by them but by everyone. A committee would lead to dilution of responsibility as well as endless discussion on every dispute. swb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Possible new Real-Time Applications and Infrastucture (RAI) Area
On Sat, Sep 24, 2005 11:15:51AM -0500, Pete Resnick allegedly wrote: On 9/23/05 at 3:59 PM -0700, Dave Crocker wrote: So far, references have been made to time-sensitive and to signalling, yet it is not clear how this applies to the work that is being defined as seeding the area. Since SIP is really a signalling protocol, yes, that part is clear. But where is the time-sensitive technology component to the work in the area? Dave, I'm not entirely clear here: Do you have a problem with Ted's reformulation of this potential new area as the Signalling Applications and Infrastructure Area? That is, does his description concretely define the new area well enough? (If SAI is reasonable, and I think it is, let's use that reformulation and be done with it.) Hi. I'm just catching up but I think signaling is not an essential discriminator of what we're talking about, and thus this name is in fact unreasonable. Some relationships are established or tailored through signaling that have nothing to do with interactiveness or delay tolerance (or SIP). Some are established through management. Delay-sensitive interpersonal communications seems to be an excellent description of the scope. Instant messaging should be included. TDM should not, and one-way multimedia should only be ancillary, even if SIP-based. I'm not sure what the name should be but please, putting signaling in the name is worse than real-time. swb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)
On 09/15/2005 17:09 PM, Paul Hoffman allegedly wrote: At 1:50 PM -0700 9/15/05, Michael Thomas wrote: Which is pretty much the elephant in the room, I'd say. How much of the net traffic these days is, essentially, not in any way standardized, and in fact probably considers ietf old and in the way? Not sure why this is an elephant; who cares? I have seen numbers that show that a huge percentage of traffic is P2P of various flavors, but I haven't seen anyone saying that this is having any negative effects. The metaphor I'm trying to use this week is that the IETF is landscapers and we provide a fertile, beautiful area for people to go wild and create excellent gardens. What you're describing is not a bug, it's feature. It means the IETF have done their job. If there were interoperability problems in the fundamental and/or widespread technologies being used in the Internet, then there would be a problem (we're working on those). Congratulations. swb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02
I would appreciate not hearing the same arguments again and again. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Two laptops lost right inside IETF WG meeting room
On 08/09/2005 09:37 AM, DENG, HUI -HCHBJ allegedly wrote: Dear all We two people lost our laptop right inside the WG meeting room during the break time of the 63rd IEF meeting. We are wondering whether we could accuse the La De Congress for their security guard and get some compensation? I believe conference centers are not liable for such loss. I'm sorry to say there was more theft at this IETF than any other I can recall. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Why have we gotten away from running code?
On 08/06/2005 19:07 PM, Brian Rosen allegedly wrote: If two groups are arguing with one another, and one has implemented code and the other has not, I think we would give great weight to the running code. Weight yes, but great weight? Many things have been implemented that only work in specific situations. You're absolutely right that running code should be considered, because it proves the idea implemented can work, but it's just one factor. Probably more importantly, I think we should be VERY suspicious of new, complex specifications before we have running code. We are very clearly NOT doing this. Yes We are willing to publish a proposed standard for an entirely new protocol that has very significant complexity, where there are people openly skeptical that it will work at all, with nothing but some sketchy simulations and a (admittedly well reviewed) draft. We are routinely publishing complex protocols and significant changes/additions without even simulations. But that's specifically what proposed is for (currently). Here's something we think we want to make a standard -- now test it. Perhaps there are a large number of you out there that are able to claim reasonably complex things work based on reading a document and looking at simulations. I am not. My experience is that getting something to actually do what you want it to do is very illuminating. See RFC 3439 :-). Maybe you can't tell if something complex will work, but at least you can reduce complexity as a factor in determining whether it will work. I wonder if we should change our bias towards bestowing Experimental status on drafts that ask to be published as RFCs without running code. Absolutely. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Keeping this IETF's schedule in the future...?
On 08/03/2005 13:39 PM, Brian E Carpenter allegedly wrote: I haven't heard *any* negative comments so far. We will attempt a systematic survey to be sure. Sorry to disappoint you :-) It's absolutely the right thing to do in Paris where restaurants aren't open until 7:30, but I don't like going to bed soon after eating if I can avoid it (and I don't like living without sleep either). I think in general we should just fit into the local culture. Have the breaks when the locals break. In Minneapolis that might mean 6-8. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Keeping this IETF's schedule in the future...?
On 08/03/2005 15:36 PM, John C Klensin allegedly wrote: PS: the key point is restaurants serve after 8pm... This can be an issue in some places in winter. Of course, we could make that -- which really should be “restaurants serve after 9PM” to allow for meetings running over or the need for immediate after-meeting conversations -- a site selection criterion :-) Where I come from many restaurants close at 9pm. Let's follow local culture. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
The IETF has difficulty solving complex problems
This conjecture was disturbing, but calling it a feature was even more disturbing. After a bit of pondering, and wondering what different groups in the IETF might mean by complex, my first thought was that the IETF has never, ever solved one. For example, we do QoS in small pieces that don't fit together well. Some claim that CIDR was such a solution but imho it was just a tweak on what we already had. Our routing protocols have been fertile ground for evolution but not revolution -- the path vector idea came directly from deprecating EGP metrics, we still aren't very stable and our policy capabilities are frustrating. However, after talking to a few people I thought that perhaps we are very good at solving complex problems but we don't recognize our greatness. Again let me take QoS as an example. The problem is huge and essentially intractable because of all the competing goals. What we have done, without a lot of architectural planning that I am aware of, is to find ways to divide the problem up where there is minimum coupling across the boundaries (see footnote (*)). That lowers the complexity greatly. It is a lot cheaper to have independent, apparently unarchitected solutions for different kinds of traffic and situations. I want us to understand what our skills are and use them consciously. I don't know if we will have time tonight, but I'd like to hear from the IESG/IAB on the foundation for Brian's statement and what was initially a negative assessment of our skill. Let's look at some example problems and think about what we have done poorly and well. I predict we are better than we think, but that we are hard to satisfy. We may think of some of the things we have done as crude hacks but they are actually pretty good solutions. Look at tunnels, for example. They are kind of abhorrent when thought of in isolation but turn out to be an appropriate means to reduce complexity in specific situations. Reducing complexity through cutting up the problem at the right points is implicit now. We could make it one of our explicit basic paradigms. As a corollary to making it explicit, we should be aware of where we use this kind of decoupling and be vigilant about it. Some users of the IETF product set want to reintroduce coupling that we have eliminated. Be sure the trade-offs are explicitly examined. swb (*) like Chuang Tzu's butcher ... The joints have openings, And the knife's blade has no thickness. Apply this lack of thickness into the openings, And the moving blade swishes through, With room to spare! ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-klensin-nomcom-term-00.txt
Discussion has been couched in terms of whether term limits are a good thing. Really, what the discussion should be about is whether limits on the NomCom are a good thing. It's one thing to give the NomCom guidelines, it's another to constrict them. The NomCom is pivotal in IETF governance and is also vulnerable to attacks. The NomCom should be defended strongly against people who don't like the way things are going in IETF management. Ideally, term limits should be ad hoc, per person, as needed. If you don't like the fact that some AD has been around forever, tell the NomCom. If you believe that competency in the job is just one criterion, and that potential competency should be considered important ... tell the NomCom. That's what they are there for. I'm assuming you're already volunteering to be on it. If there is justification for the firing of a long-time AD, well, the AD probably should feel embarrassed. Forcing *all* IESG or IAB members out, even if doing so hurts the IETF and the Internet, to avoid embarrassment of someone who shouldn't be there is just too politically correct. Those who have left IESG/IAB positions and taken up others have done so because they are capable and want to contribute. The fact that they can do so does not mean it is all right to force them out of positions where they might be even better for the IETF. As for learning the trade, I don't know. IESG/IAB members could have an apprentice program from their directorates etc., but as has been said, there is nothing like actually being in it. Certainly, forcing people out at inappropriate times is way off the path of wisdom. In summary, give guidelines and opinions to the NomCom but don't restrict them unless they have too much power. swb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-klensin-nomcom-term-00.txt
On 08/01/2005 11:24 AM, John Loughney allegedly wrote: Scott, I dunno. I thought that some of the discussion has been about circulation of folks in leadership positions. Some feel its good, some feel its bad. Its not strictly term-limits as in goverment posts, as quite many former IAB IESG members are extremely active in technical discussions, writing drafts, chairing bofs working groups. In my experience, this is a really good thing. I'm not entirely convinced that its important for IESG members to stay in a position for a long time. I don't have a strong opinion, so I'm definately open for discussion on this. I'm not saying it is, nor am I saying you shouldn't have circulation. I'm saying that institutionalizing this, bureaucratizing it, is a mistake. This has the same feel as the end-to-end argument. Institutionalized, general-purpose rules will rarely meet the needs of a particular situation. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meeting Locations
On Fri, Jul 15, 2005 05:27:45PM +0200, Brian E Carpenter allegedly wrote: My expectation is that we'll stick to the pattern of two N American meetings plus one in another region - but meeting planning is an art, not a science. I like the deterministic formula based on the number of drafts written. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Paris Social EVent - EMail from Kim Wallet - Legitimate or phishing?
On 07/12/2005 11:48 AM, Steve Silverman allegedly wrote: I registered for the social event in Paris, paid for it, and then received several emails asking for my credit card info from Kim Wallet, purportedly from france-connection. Is this legitimate or a phishing expedition? No I haven't responded to the emails. How did you pay? Kim wants a fax of the payment form, with your credit card number on it. She seems to be honest. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: When to DISCUSS?
On Mon, Jul 11, 2005 03:42:14PM +0200, Brian E Carpenter allegedly wrote: Phill, Just picking out the nub of your message: There is however one area that should be made very explicit as a non issue for DISCUSS, failure to employ a specific technology platform. I have been concerned on a number of occasions where it has appeared that in order to get a specification approved by the IESG it would be necessary to adopt a particular technology being promoted by IESG members. I think the last phrase is unfair - if the IETF is putting a lot of effort into technology Foo, then it's a legitimate question to ask Why aren't you re-using Foo? But we do have as a non-criterion: o Disagreement with informed WG decisions that do not exhibit problems outlined in Section 3.1. In other words, disagreement in preferences among technically sound approaches. As I read this, it would be legitimate for an AD to ask Did the WG consider Foo, and if so, have good reasons for rejecting it in favour of Bar? and illegitimate to say I like Foo more than Bar, so I'm blocking this. If we agree on this, some wordsmithing may be needed. Brian There are occasions when limiting the number of deployed solutions is very good for the future of the Internet, and in those cases, pushing for Foo even when Bar is just as good is quite legitimate. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: When to DISCUSS?
On Mon, Jul 11, 2005 08:21:57AM -0700, Yakov Rekhter allegedly wrote: There are occasions when limiting the number of deployed solutions is very good for the future of the Internet, and in those cases, pushing for Foo even when Bar is just as good is quite legitimate. Limiting the number of deployed solutions should be done based on the operational experience/market forces, and not by ADs/IESG pushing for a particular solution. So you would have blessed IPv8? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: S stands for Steering [Re: Should the IESG rule or not?]
On 07/01/2005 13:02 PM, Ken Carlberg allegedly wrote: My view is that your impression of the reaction is incorrect. in taking the position that respondents can be classified as either: a) being satisfied with the IESG *decision*, b) dissatisfied or uncomfortable with the decision, or c) could not be clearly determined by the content of their response, I came up with the following list. You can add me to the satisfied column. The IESG is asked to take positions and to lead (despite what a few think). That's risky -- no matter what they do they get criticism from somewhere. Maybe they didn't *phrase* the announcement perfectly, but the decision is correct. Something like this must have a serious, long-term IETF review. We need to take the overall design of the Internet into account and not just be administrators. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option
On Sat, Jun 25, 2005 12:30:44PM -0700, Dr. Lawrence G. Roberts allegedly wrote: Steve, Thank you for your thoughts. I am not sure about the next step, but I can clarify some of the points that were unclear. British Telecom submitted it to the ITU SG12 in January and we had unanimous approval to be included as a concept for QoS in Y-1221. Then BT submitted it to SG13 as a detailed proposal of a signaling protocol and it again had unanimous approval to go forward as the basis of a recommendation. Larry please be straightforward. Just because people allowed work to go forward in each case does not mean there was unanimous approval. In SG12 the proposed text was objected to and sent back. There was approval to include the concept as you say, but only if the text is improved. In SG13 there was considerable debate, and at the end the group *allowed* exploration of the topic through development through a new draft recommendation. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Uneccesary slowness.
On 5/19/2005 11:20, Dave Crocker allegedly wrote: Thomas, 1) You can't hurry the above, e.g., by imposing artificial deadlines, or by saying no objections during LC, therefor ready to go. You have to have the reviews, and you have to iterate. The IETF is supposed to produce a product that has market relevance. The IETF does not have a market beyond its mission statement (qv.). The markets addressed by IETF activity depend on IETF participants. The model you describe fits my own sense of research efforts, not product development. To the extent that the problems the IETF participants choose to work on are hard, the activities will in fact be research. The point here is to make the process efficient, not to hurry the work when it shouldn't be. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaining about ADs to Nomcom (Re: Voting (again))
I don't understand why making names public would increase electioneering over what we already have. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Requirements for IETF Draft Submission Toolset' to Informational RFC
On 4/7/2005 10:36, Brian E Carpenter allegedly wrote: Regardless of the interesting side-discussion about 'voting', what the toy shows after about a day is: prefer nroff: 8 prefer xml: 37 neither: 9 I wonder how many of those have actually written a draft using both? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Requirements for IETF Draft Submission Toolset' to Informational RFC
On 4/6/2005 11:20, Bruce Lilly allegedly wrote: Using an XML-specific editor basically substitutes manually typing tags by a search for a pointing device, selection from a menu, etc. (avoiding typos while entering long tags, but interrupting the mental flow of writing content to search for menu items, etc.). I agree that balanced tags make editing more awkward but the above is a caricature. As an example I rarely hunt for the mouse when doing xml2rfc XML. You need a better editor. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF onsite networks; discussion, cash, knowledge
On Sat, Mar 19, 2005 11:14:33AM -0500, John C Klensin allegedly wrote: While I've suggested scrapping the terminals in the terminal room on and off for years, I'd be reluctant to give up on the printers. Perhaps it is a sign of advancing age, but, when a document gets above some length or level of complexity, I simply have to have it on paper that I can flip through and mark up in order to make sense of it. plus for printing boarding passes ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: New ground transportation option in Minneapolis
On Fri, Mar 04, 2005 11:54:10AM -0600, Christopher A Bongaarts allegedly wrote: In the immortal words of lafur Gumundsson: The good news: Last December Minneapolis started a Light Rail Service between downtown and Mall of America with a stop at the airport. The ride costs $1.25 each way and the trains seem to be running every 10 minutes during the weekend and more frequently during the week. The bad news: The closest stop (at 5'th St. and Nicollet Mall) is about 5 blocks from the Hilton Towers hotel. Train tickets can be used to transfer to buses, and there are several routes that go down Nicollet Mall between the LRT stop and the hotel. Also, according to the city web site it's only 0.4 miles to the hotel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Proposed consensus text: #725 Appealing decisions
On Fri, Jan 28, 2005 03:02:00PM +0100, Harald Tveit Alvestrand allegedly wrote: The request for review is addressed to the IAOC chair and should include a description of the decision or action to be reviewed, an explanation of how the decision or action violates the BCPs or violates - is presumed to violate operational guidelines, and a suggestion for how the situation could be rectified. All requests for review will be publicly posted, and the IAOC is expected to respond to these requests within a reasonable period, typically within 90 days. It is up to the IAOC to determine what type of review and response is required, based on the nature of the review request. Based on the results of the review, the IAOC may choose to overturn their own decision and/or to change their operational guidelines to prevent further misunderstandings. or may do nothing, or may do a whole lot of other things in between. Providing this choice implies that one of these two must be chosen. Is this sentence necessary? Does anything prohibit them from doing either of these things if the sentence is removed? In exceptional cases, when no other recourse seems reasonable, the IESG, IAB or ISOC BoT may overturn or reverse a non-binding decision or action of the IAOC. This should be done after careful consideration and consultation with the IAOC regarding the ramifications of this action. In no circumstances may the IESG or IAB overturn a decision of the IAOC that involves a binding contract or overturn a personnel-related action (such as hiring, firing, promotion, demotion, performance reviews, salary adjustments, etc.). In another message, I have suggested removing the last paragraph - but it's not a show-stopper for me to leave it in. Comments? Either way. Thanks ... Scott (Brim) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Legal review results 1: Intellectual property
On 1/21/2005 10:49, Bruce Lilly allegedly wrote: Verbosity aside, I don't believe that sole control and custodianship applies to open source software. I am not a lawyer, but the Old text seems not only more easily comprehended [I am reminded of Jonathan Swift's satirical look at lawyers in Gulliver's Travels, and dismayed that things haven't improved in 275 years] but seems to be considerably more favorable to open source software than the proposed new text; the latter appears to be heavily biased towards commercial software. I think Jorge's text is much better than what we had. It fills in gaps and eliminates ambiguities. IETF can still decide whether software developed for it should be made available on an open source basis, but that should be up to the IETF. Jorge's text makes that possible. Scott Brim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: iasa-bcp-04: unanimity in section 3.4
On 1/14/2005 19:05, John C Klensin allegedly wrote: Proposed change: Get rid of unanimous (both times), replacing it with consensus and appropriate editorial smoothing. wfm ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus search: #725 3.4b Appealing decisions
On Thu, Jan 13, 2005 02:11:28PM -0500, [EMAIL PROTECTED] allegedly wrote: To start, I must admit I have trouble equating an individual or community's disagreement with a decision to a DOS attack, though I do know how disconcerting and distracting an insistent complaint can be. I just don't see equating people's concerns with maliciously motivated attacks, no matter how persistent or obnoxious. I also have no problem believing that the better option in any such disagreement would be to respond early and with due diligence with a public response (accountable and transparent) as opposed to just deleting it because it appears frivolous. I think we need to be very careful in defining an objection as frivolous before having given it due diligence. The problem in both paragraphs is that there is no frivolous bit to check -- it's a subjective judgment, depending on the situation. We could reach an objective definition, but it would be hard to do so, the definition would be invalidated as conditions change, and we actually don't need to take the time. We can leave it up to those receiving the requests to judge frivolity, but also have ways to rein them in if necessary. If someone feels they are being unfairly judged frivolous, they can bring in support. If *they* think the person is being frivolous, then he/she probably is. If he/she still disagrees, we have the appeal process to bring in even more opinions. We don't need to build everything into rules if the process has the right characteristics. But once having reviewed an issue and publishing a response, then there would be no reason to re-review, thus avoiding an effect similar to that from a DOS attack. I'm not very good at being devious, but even I can think of small things one could do that would force a re-review under any terms along those lines. I also think that history has shown us that appeals are relatively rare and generally not frivolous. It is for this reason that I advocate extending the current model of appeal, with the caveats about not voiding contracts etc, to the IAD and IAOC. I think creating the procedure to avoid so called 'DOS attacks' is, in effect, fighting a problem we do not have. But it costs no more to make sure we don't have it, using the process currently on the table. I am not concerned that the IESG (or IAB) would unreasonably protect the IAOC, but if they do, we have a process for that as well. swb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? #733 Outsourcing principle
On 1/12/2005 04:51, Harald Tveit Alvestrand allegedly wrote: In principle, IETF administrative functions should be outsourced. Decisions to perform specific functions in-house should be explicitly justified by the IAOC and restricted to the minimum staff required, with these decisions and staffing reviewed by the IAOC on a regular basis and against a zero base assumption. Minimum staff required is a little difficult. One can do anything with existing staff if quality and timeliness don't matter. The IAOC has to determine those parameters as part of deciding staffing levels. I suggest minimum staff required to perform the functions satisfactorily as determined by the IAOC, or something along those lines. Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? #733 Outsourcing principle
On 1/12/2005 07:44, Harald Tveit Alvestrand allegedly wrote: --On onsdag, januar 12, 2005 07:29:27 -0500 Scott W Brim sbrim@cisco.com wrote: On 1/12/2005 04:51, Harald Tveit Alvestrand allegedly wrote: In principle, IETF administrative functions should be outsourced. Decisions to perform specific functions in-house should be explicitly justified by the IAOC and restricted to the minimum staff required, with these decisions and staffing reviewed by the IAOC on a regular basis and against a zero base assumption. Minimum staff required is a little difficult. One can do anything with existing staff if quality and timeliness don't matter. The IAOC has to determine those parameters as part of deciding staffing levels. I suggest minimum staff required to perform the functions satisfactorily as determined by the IAOC, or something along those lines. I thought that was implied by required.. if we don't like required, I think we should drop the subsentence, leaving us with: In principle, IETF administrative functions should be outsourced. Decisions to perform specific functions in-house should be explicitly justified by the IAOC, with these decisions and staffing reviewed by the IAOC on a regular basis and against a zero base assumption. OK Less is more Apparently so. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? #770 Compensation for IAOC members
On 1/10/2005 06:12, Wijnen, Bert (Bert) allegedly wrote: OK, I have added the text (in my edit buffer) as proposed by Mike. So that is: t The IAOC shall set and publish rules covering reimbursement of expenses and such reimbursement shall generally be for exceptional cases only. /t at the end of section 4, so just before section 4.1 Bert If this is still open to nits ... I don't think you want generally. It doesn't go with exceptional. Isn't reimbursement *always* for exceptional cases only? If it's exceptionally for common cases, would those not also be exceptional? :-) I suggest eliminating generally. Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? #770 Compensation for IAOC members
On 1/10/2005 14:41, Michael StJohns allegedly wrote: Hmm... No, actually I think this is right. This is guidance to the IAOC for publishing the rules not the rules themselves. In general, the rules should only cover exceptional expenses (e.g. spent $1000 paying the teleconference bill for xxx), but the IAOC can also establish rules for non-exceptional expenses (e.g. mileage for meetings) because its the only way they can get people to come to do something for example. OK At 09:12 AM 1/10/2005, Scott W Brim wrote: On 1/10/2005 06:12, Wijnen, Bert (Bert) allegedly wrote: OK, I have added the text (in my edit buffer) as proposed by Mike. So that is: t The IAOC shall set and publish rules covering reimbursement of expenses and such reimbursement shall generally be for exceptional cases only. /t at the end of section 4, so just before section 4.1 Bert If this is still open to nits ... I don't think you want generally. It doesn't go with exceptional. Isn't reimbursement *always* for exceptional cases only? If it's exceptionally for common cases, would those not also be exceptional? :-) I suggest eliminating generally. Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? #770 Compensation for IAOC members
On 1/7/2005 10:56, Harald Tveit Alvestrand allegedly wrote: I think this line of thought has died down without any great disagreement the consensus seems to be that the following sentence: The IAOC members shall not receive any compensation (apart from exceptional reimbursement of expenses) for their services as members of the IAOC. belongs in the document. I think that placing it at the end of 4.0 makes for the most reasonable placement (together with all the stuff about membership selection). (Personally, I'm not fond of the word exceptional. It begs the question of who grants exceptions, and what the criteria for exceptions are. But the debaters seem to favour it. I'd rather say possible, and add IAOC sets and publishes rules for reimbursement of expenses, if that ever becomes necessary. But I can live with the current text). I find possible to be more prone to confusion than exceptional, but I like the idea of adding your extra sentence even with exceptional. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-phillips-langtags-08, process, sp ecifications, stability, and extensions
Dave Crocker wrote: It occurs to me that a Last Call for an independent submission has an added requirement to satisfy, namely that the community supports adoption of the work. We take a working group as a demonstration of community support. (However we used to pressure for explicit statements during Last Call.) My feeling is that an independent submission MUST show significant support during Last Call. In other words, a working group document getting IETF Last Call has something of a Default Yes. And independent submission needs to be Default No. Pretty close. Certainly the default can't be Yes. However the reason why many things come in as individual submissions is that the community doesn't care much. So if the IESG is satisfied enough to put out a last call, and nobody responds -- it doesn't have community support -- the default community position shouldn't be no but no objection. (In this specific case it appears to me, as an outsider, that there has been significant objection, and not all of it dismissable.) swb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? #771 Powers of the Chair of the IAOC
Harald Tveit Alvestrand wrote: - There is nothing clear about whether the IAOC chair is peer, superior or subordinate to the IAB chair or the IETF chair (or, for that matter, the ISOC President). I don't think the last point should be addressed. This document lays out the specific mechanisms for appointment of the IAOC and its chair; it is clear that the document does not specify a hierarchy, but a network relationship. wfm ... The relationship of the chairs should be set by the relationship of the entities, so we should focus there. To the first point, I think it's reasonable to remove the language that doesn't have a referent. It also seems to me that it fits better if rearranged a bit. What about this? The members of the IAOC shall select one of its appointed voting members to serve as the chair of the IAOC. The chair of the IAOC shall have the authority to manage the activities and meetings of the IAOC. The term of the IAOC chair shall be one year, with no restriction on renewal. The chair of the IAOC may be removed at any time by the affirmative vote of two-thirds of the voting members of the IAOC, or as a result of his or her departure from the IAOC. OK. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: BCP -03: Compensation for IAOC members
The other Scott's approach looks like it's clearly the most reasonable, and follows a model we have used before. No reimbursement for performance of services; no reimbursement for meetings that are associated with IETF; reimbursement for travel to special (not IETF-associated) meetings where necessary. As usual, we have to be careful not to get too specific. This might be just specific enough. swb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IASA BCP Conflict of Interest Clause?
Stephen Sprunk [EMAIL PROTECTED] on Wednesday, December 22, 2004 13:08: We can require that the IAOC establish rules for dealing with conflicts of interest, and if a member does not follow them (or perhaps does so too frequently) they can be recalled; if that fails, particular decisions can be appealed by the community. IMHO, this is enough. Do you really mean that the IAOC should establish its own procedures for conflict of interest? This is something the IETF should at least set boundaries on. I suspect recusal is probably good enough if (1) it's quite thorough, i.e. it means even being absent from discussion where the conflict of interest is an issue, and (2) recusals are public information. swb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IASA BCP Conflict of Interest Clause?
Margaret Wasserman on Wednesday, December 22, 2004 13:49: I agree with Stephen and others. We could probably just add something in the BCP saying that the IAOC should define and publish an appropriate conflict of interest policy and leave it up to them. Margaret Can you think of any policy that would not be appropriate? I thought so. If so then surely (I mean, Margaret) we can give them a sense of what would be considered appropriate up front? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Issue: #751: Section 7 - Removability, using term BCP
On Tue, Dec 21, 2004 09:19:12PM +0100, Wijnen, Bert (Bert) allegedly wrote: See: https://rt.psg.com/Ticket/Display.html?id=751 The text suggested by Scott would mean to change: Removability: While there is no current plan to transfer the legal and financial home of the IASA to another corporation, the IASA shall be structured to enable a clean transition in the event that the IETF community decides, through BCP publication, that such a transition is required. into: Removability: While there is no current plan to transfer the legal and financial home of the IASA to another corporation, the IASA shall be structured to enable a clean transition in the event that the IETF community decides, through the publication of a procedure document where a formal assertion of IETF consensus is required (currently called BCP), that such a transition is required. I find that latter sentence harder to read, but I can live with it. I saw Scott (as only one) in favor of the change, while at least 2 people (Harald and Sam) objected. Not clear what I should do. Unless instructed otherwise, I will leave the text alone. Bert It is harder to read. I suggest: ... shall be structured to enable a clean transition in the event that the IETF community decides that such a transition is required and documents its consensus in a formal document (currently called a BCP). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Why old-standards (Re: List of Old Standards to be retired)
On Fri, Dec 17, 2004 11:47:10AM -0500, John C Klensin allegedly wrote: Harald, while I agree in principle, I would suggest that some of the comments Eric, Bill, and others have pointed out call for the beginnings of an evaluation of your experiment. I further suggest that evaluation is appropriate at almost any time, once data start to come in. I hope it can be a relatively sloppy process. Let's not insist on perfection. An RFC is identified as possibly outdated, the suggestion is posted, and people respond -- just as is happening now. Sometimes the suggestions are wrong. The experiment is going fine as long as you realize it's an experiment in process as much as discovering how much cleaning is possible. My recent response to Pekka's analysis of the CIDR documents is one suggestion about where such an evaluation might lead. And, of course, this whole firestorm of discussion on the IETF list, while a welcome distraction from hairsplitting debates about administrative structures, adds strength to the position of those who argued in newtrk that this effort might not be worth the amount of community energy it would take up. Yup. The jury is still out on whether it's worthwhile. Let's be forgiving of the first attempt, and let it run for a little longer and see if it becomes more polished. Scott ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: iasa-bcp-01 - Open Issues - Separate bank accounts
On Wed, Dec 08, 2004 08:19:16AM -0500, Margaret Wasserman allegedly wrote: The IETF meeting fees and IASA/IETF-designated donations will only be used to support IASA and the IETF. If the total of these funding sources is larger than the total cost of the IASA function, the surplus will be held in the IASA account for later use to support IASA and the IETF. If the total of these funding sources is smaller than the total cost of the IASA function, resulting in a deficit, we are expecting ISOC to cover that deficit from non-IASA/IETF designated funds. IMHO this is cleaner and makes the point completely. The sentence about irrevocable donations felt redundant and limited in what it covered. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? IPR rights and all that
On Mon, Dec 06, 2004 07:00:32AM -0500, Margaret Wasserman allegedly wrote: I agree with what you are trying to say, but I'm not sure about this wording: The IAD is responsible for ensuring that all contracts give the IASA and the IETF the rights in data that is needed to satisfy the principle of data access. Maybe: The IAD is responsible for ensuring that all contracts give the IASA and the IETF the data access rights that are needed...? I believe you want the data itself? ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF hotels charging the deposits and not reimbursing?
On Thu, Nov 18, 2004 06:15:03PM +0200, Pekka Savola allegedly wrote: At IETF60, the Sheraton hotels charged me both for the deposit of one day, and for all days I stayed there. Now at IETF61, I noticed that the Hilton has also charged me for the deposit (one day), but did not take that into the account, but at the hotel charged me for the full rate for all the days as well. I didn't have this problem. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Why the IPnG effort failed.
On Thu, Nov 18, 2004 04:38:37PM +0100, Brian E Carpenter allegedly wrote: It didn't. For an effort always expected to take at least 15 years, we are doing OK. It is always good to learn from history, of course. That's funny. I recall that when we started we expected it to *last* 15 years, or less, during which time we would come up with a truly new routing addressing architecture. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Why the IPnG effort failed.
On Thu, Nov 18, 2004 09:27:55PM +0100, JFC (Jefsey) Morfin allegedly wrote: At 17:52 18/11/2004, Scott W Brim wrote: That's funny. I recall that when we started we expected it to *last* 15 years, or less, during which time we would come up with a truly new routing addressing architecture. any hint of what was dreamed at that time ? The real issue is here. We will certainly go THROUGH IPv6 just in order to get a /128 plan, on our way to the /256 one. The real issue is what is going to be the new routing architecture? jfc That was a long time ago and we've been through quite an evolution in our thinking, including (as Frank Kastenholz points out) realizing that anything we did was going to have to last a long time -- no stopgaps -- and a lot of work on architecture that is still going on. swb ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Disfranchise - use of language [Was: Re: [Inquiry #19085] Issue with Meeting Schedule change at the lastmoment]
On Sun, Nov 07, 2004 01:23:19PM -0700, Stephane Maes allegedly wrote: Carsten, You may be confusing my concern. It is not an issue of voting or having no voice in reaching consensus. It is an issue that if people who intended or needed to participate FTF are prevented to do so by late schedule changes, they are disfranchised from the discussion process (if they believe that the FTF was the best venue to discuss issues, input, whatever matter to them. That is the problem and anybody who allows that to happen indeed fails to cater to this fundamental issue. Thanks Stephane Late schedule changes did not prevent you from participating. You are not a victim. Your lack of knowledge of, and assumptions about, the IETF's scheduling process led you to make a mistake in your scheduling. Now you know, and you won't make the mistake again. However, you can't blame the IETF, which very clearly marked non-final versions of the agenda DRAFT. Are we done yet? ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 consumption statistics and extrapolations
On Sun, Nov 07, 2004 12:00:09PM -0500, Noel Chiappa allegedly wrote: From: Dave Crocker [EMAIL PROTECTED] *IPv6 only exists because of a previous round of FUD about IPv4 address exhaustion* - one spread by the proponents of yet another protocol that was going to replace IPv4 - i.e. CLNP. Noel, this assertion is just plain wrong. So what was Kobe and the ensuing Boston Tea party about, then? Look, I'm not saying there wasn't concern about address space usage rates, and eventual exhaustion - clearly there was. (And - and how ironic is this - one of the *earliest* references to comlete address space exhaustion was in a presentation *I* gave at the 19th IETF, in December 1990, at Boulder, Colorado - up until then we had mostly been worried about the usage rate of class B's.) However, my perception was that the IPng effort was started in response to concerns raised by backers of CLNP, who did so in an attempt to push adoption of CLNP. Would we have started work on IPng without those efforts? I don't think so, but YMMV. My recollection is that CLNP was not a motivator, it was recommended as a bandaid, in reaction to the perceived problems. After we did that, the CLNP proponents ran with it (and we got Kobe). Remember the ROAD meeting where you said CLNP is only slightly less paleolithic than IP? ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Shuffle those deck chairs!
Is there anything in this message that disagrees with 3668? 3668 is a little more nuanced, for example you don't have to disclose until it looks like your idea is going to be incorporated in something headed towards standards track, but generally I think what you describe is how things work now. swb On Wed, Oct 20, 2004 05:49:10AM +, Paul Vixie allegedly wrote: somebody asked me... What is your position on these issues then? i think that anyone who comments on the mailing list, or in WG meeting minutes, or as a draft author, should have to disclose any relevant IPR of which they are then aware or of which they become subsequently aware, whether or not such awareness is due to prospective benefit by them, or their employers, or their heirs or assigns. i also think contributors to ietf specifications, whether verbally, or in e-mail forums, or as authors, should have to quit-claim any relevant IPR except that which they have disclosed in advance of a draft being submitted to the RFC editor. i think that the ensuing ietf-isoc-malamud hairball should pay for IPR searches of all final-drafts before they reach the RFC editor, to get some kind of reasonable belief that all relevant IPR has in fact been disclosed, even though no warranties as to IPR should be expressed or implied. if working groups want a standard to use protected IPR, their only responsibility is to ensure that all IPR claims are properly disclosed. if implementors want to build products on a standard that uses protected IPR, they should be able to read the IPR legend in the RFC and make an informed business decision as to whether they like what they see. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Shuffle those deck chairs!
On Thu, Oct 21, 2004 08:56:15PM +0300, Pekka Savola allegedly wrote: On Wed, 20 Oct 2004, Scott W Brim wrote: Is there anything in this message that disagrees with 3668? 3668 is a little more nuanced, for example you don't have to disclose until it looks like your idea is going to be incorporated in something headed towards standards track, but generally I think what you describe is how things work now. Please do NOT spread that kind of total misinformation. You have to disclose your IPR as soon as reasonably possible when an internet-draft or RFC potentially infringing on it has been published, no matter the category it's headed. True. I was replying in the standards track context. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Shuffle those deck chairs!
On Wed, Oct 06, 2004 09:59:53AM +0200, Iljitsch van Beijnum allegedly wrote: On 6-okt-04, at 6:12, Scott W Brim wrote: However, there appears to be rough consensus emerging that an IPR assertion is acceptable if any of the following are true: - a license is explicitly not required. - a license is explicitly free with no restrictions. - a license is explicitly free with rights of defensive suspension (what Harald calls no first use). This makes a lot of sense in cases where a patent is legit (for lack of a better word). Great. However, the reason we're in such a big mess is that more and more companies are registering patents of questionable merit. Even if an IPR claim is illegitimate, explicit free licensing lowers the risk to the point where you can separate the questions of technical merit and legitimacy, and hand off dealing with legitimacy. This brings us right back to: As Ted says, the IETF should stay out of passing judgment on the validity of claims and/or fighting patents. It's really way outside of our charter. I gather that the US patent office pretty much rubber stamps patent applications in the IETF's area of interest because they don't know how to evaluate them. Maybe I'm being naive here, but it seems to me that some kind of clue transfer from the IETF to the US patent office would be beneficial to all except the patent lawyers who would then have to start to do actual work to make a living. The US patent office is overwhelmed, and acting like it's under a DoS attack. I agree it would be great if we all offered technical assistance, but not as the IETF. If needed we could create some other organization. Let the IETF have a clear focus. swb ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Shuffle those deck chairs!
As Ted says, the IETF should stay out of passing judgment on the validity of claims and/or fighting patents. It's really way outside of our charter. Anyone can set up a separate organization to do that if he/she wants. However, this case is just the worst of many. It is abundantly clear that the IETF's current approach of treating each IPR claim on a case-by-case, ad hoc basis is really hurting us. I've been involved in IETF IPR issues for a while and time after time I see Working Groups get totally stuck trying to evaluate the impact of a particular patent claim (and then sometimes another, and another ...). At this point we need more than guidelines. Our productivity is suffering because they just aren't effective enough, soon enough. We would benefit greatly from something deterministic, IETF-wide. Eliminating IPR altogether will be difficult at best, probably impossible, and I don't think trying to do so is worth our time. However, there appears to be rough consensus emerging that an IPR assertion is acceptable if any of the following are true: - a license is explicitly not required. - a license is explicitly free with no restrictions. - a license is explicitly free with rights of defensive suspension (what Harald calls no first use). I know of a couple cases where any encumbrance at all was considered unacceptable, but the great majority have found one of these acceptable. If an IPR assertion falls into any of these categories, then Working Groups no longer need to consider it as an issue, and no longer should. They can actually make progress. What an idea -- to have a general rule worked out in advance by which you can deal with an IPR issue in one or two minutes, and then go on. So that's a proposal: If a claim falls into one of those three categories it is acceptable, and WGs shouldn't consider it as an issue. Let's get some time at the Washington meeting to talk about this. swb ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: My views on the Scenario O C
I agree completely with Bob. I want to point out one issue where vigilance will be important: On Fri, Sep 24, 2004 12:39:53PM -0700, Bob Hinden allegedly wrote: Housing the IETF administrative activity in ISOC seems to me to be a much simpler solution to our administrative problems and will require much less work to get it set up. I am concerned that the independent approach will take considerably more cycles and work from the IETF leadership to get it set up and functioning. This will take away from working on what I consider to be more important problems. I agree in principle but part of what got us into this situation was the feeling that we could just let ISOC (and/or CNRI) just take care of the non-technical details. Let's avoid even leaning that way this time. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: My views on the Scenario O C
On Sat, Sep 25, 2004 01:57:50PM +0200, Erik Huizer allegedly wrote: Your remark suggests that ISOC let the IETF down on non-technical issues that the IETF was expecting to handle. Erik, that was not my intention. What I want to avoid is the feeling that the friendliness of who we deal with, whoever it might be, might allow us to be more relaxed in our handling of non-technical issues. Does that make sense? ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Upcoming: further thoughts on where from here
On Tue, Sep 21, 2004 01:19:15PM +0200, Brian E Carpenter allegedly wrote: Harald Tveit Alvestrand wrote: Brian, I've seen some argument that Scenario C, being more well-defined, is actually less complex than Scenario O. I would really dispute that. There are layers of complexity in either case, and I think the scenario O analysis, because it's based on a real, existing organisation rather than a hypothetical one, simply contains more detail. I'm with Brian, in favor of O. The way I see it, the critical issue is tightening up *our* processes, not who we deal with. Once we do that we can work out contracts with anyone who meet our criteria, and it will be at least as easy to do so with an entity we have experience with and whose actions we can predict well. We will be much less at risk once our own procedures are clearly established. swb ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
