Re: [IETF] Re: ORCID - unique identifiers for contributors
On Sep 17, 2013, at 11:20 AM, Michael Richardson m...@sandelman.ca wrote: I did not know about ORCID before this thread. I think it is brilliant, and what I've read about the mandate of orcid.org, and how it is managed, I am enthusiastic. I agree with what Joel wrote: Asking for ORCID support in the tool set and asking for IETF endorsement are two very different things. I must admit that I'm still somewhat confused by what exact problem we are trying to solve here. Things that I write in an IETF context are fundamentally different to things that I write on other contexts, so I don't really see a need for a *global* identifier (If folk think that I wrote a particularly funny anecdote about fish they are not likely to be looking for drafts that I have co-authored. Anyway, what I author in the IEFT context should reflect WG consensus, so who the actual author is is somewhat irrelevant). So, all I really need is to disambiguate myself in the IETF context. This seems simple -- when I arrived here, no-one mistook me for some other Warren Kumari, so I have stuck with that identifier. If there was already a Warren Kumari participating I would simply have used my middle name (embarrassingly enough, Kim) and been Warren Kim Kumari. Had there already been a Warren Kim Kumari, I could refer to myself as Warren Monkey Kumari, Warren Ace Kumari, Warren Dumbass Kumari, etc. If there were multiple Warren Kumari's participating folk are more likely to remember me as Dumbass Warren than that Warren guy with the ORCID -0002-2404-6244. If the purpose it to try prevent folk intentionally passing themselves off as someone else, well, putting in an ORCID doesn't really accomplish that either. I guess I see no harm in this, I just don't really get the point. W Having tool support for it is a necessary first step to permitting IETF contributors to gain experience with it. We need that experience before we can talk about consensus. So, permit ORCID, but not enforce. An interesting second (or third) conversation might be about how I could insert ORCIDs into the meta-data for already published documents. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails [ -- There are only 10 types of people in this world -- those who understand binary arithmetic and those who don't. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [IETF] Re: ORCID - unique identifiers for contributors
On Sep 17, 2013, at 4:52 PM, Yoav Nir y...@checkpoint.com wrote: On Sep 17, 2013, at 10:44 PM, Hector Santos hsan...@isdg.net wrote: On 9/17/2013 1:55 PM, Michael Tuexen wrote: On Sep 17, 2013, at 7:48 PM, Scott Brim scott.b...@gmail.com wrote: On Tue, Sep 17, 2013 at 1:37 PM, Michael Tuexen michael.tue...@lurchi.franken.de wrote: I was always wondering the authors can't get an @ietf.org address, which is listed in the RFC and is used to forward e-mail to another account. Me too! I would even suggest that all I-D authors, at the very least, should need to register with the IETF to submit documents. Optional @ietf.org offered. Having an IETF identity is OK if all you ever publish is in the IETF. Some of our participants also publish at other SDOs such as IEEE, W3C, ITU, and quite a few publish Academic papers. Using the same identifier for all these places would be useful, Would it? Why? I publish some papers in other places. I wear substantially different hats in other areas -- drafts published in the IETF reflect (in theory) IETF consensus, so they are not really *my* views, they are the views of a group of folk. So, it is not that folk can read a document in another context and then say Wow, that's interesting, let me see what Warren's views on IETF subjects is and then go find *my* IETF views (if they wanted that, looking at mailing lists is probably a better option :-)) I guess a universal identifier could be useful so that future employers / people in bars could look me up, see that I've contributed to N documents in M SDOs and then be all impressed. This does not seem very useful to me. W and that single identifier is not going to be an @ietf.org email address. -- Consider orang-utans. In all the worlds graced by their presence, it is suspected that they can talk but choose not to do so in case humans put them to work, possibly in the television industry. In fact they can talk. It's just that they talk in Orang-utan. Humans are only capable of listening in Bewilderment. -- Terry Practhett
Re: [IETF] Re: pgp signing in van
On Sep 9, 2013, at 1:12 PM, Peter Saint-Andre stpe...@stpeter.im wrote: Signed PGP part On 9/9/13 11:02 AM, Cyrus Daboo wrote: Hi Peter, --On September 8, 2013 at 5:19:51 PM -0600 Peter Saint-Andre stpe...@stpeter.im wrote: But until the MUAs across the board support it out of the box, I believe most people don't know about it or know what it means. So that's an opportunity to educate people. For instance, perhaps the Internet Society might be interested in taking on that task. Is there a reason you choose to use inline signing with PGP rather than multipart/signed? Is that a technical reason (e.g., poor interoperability)? Ignorance or misconfiguration in my use of Thunderbird, it seems. Or maybe you are not actually using PGP and are simply relying on http://xkcd.com/1181/ ? I''ve just added: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 to my .sig file collection. Wonder how many MUTs will become unhappy? :-P W Peter - -- Peter Saint-Andre https://stpeter.im/ -- It must be authentic: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://xkcd.com/1181/ W
Re: [IETF] RE: The Friday Report (was Re: Weekly posting summary for ietf@ietf.org)
On Aug 3, 2013, at 11:48 AM, Adrian Farrel adr...@olddog.co.uk wrote: I prefer if you post at end of Friday (as in the end of working days of 5 in each week). There are seven days in most weeks, in my experience. I suggested to Thomas to submit report in end of Friday I suggest that anyone who wants something different simply writes code for something different. I suggest eliminating the report. As it doesn't measure content quality, one's contribution can't be measured by the email they produce. So, it is only a guage of the distraction they produce. The report itself is a distraction. = Have you considered not reading it? Or, better yet, not appearing prominently on it? W Adrian -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman.
Re: [IETF] Re: Regarding call Chinese names
On Jul 12, 2013, at 8:06 PM, Eric Burger ebur...@standardstrack.com wrote: I kept my maiden name, too. And I took my wife's last name when we married. This caused no end of confusion at the marriage office, with their Borland C Turbo Vision Text menu system app, with a space for a maiden name for the female to change her name, but not the male… W Another Western option, hyphenation, was not for us. Who wants to be a Spear-Burger? Unless you want a Pepsi and chips with that. See http://en.wikipedia.org/wiki/Olympia_Cafe On Jul 10, 2013, at 9:00 PM, Ida ida_le...@yahoo.com wrote: Sent from my iPad On 2013-07-10, at 8:59 PM, Ida ida_le...@yahoo.com wrote: One comment: I think most of the Chinese women don't change to our husband's last name. So, my husband is not Mr Leung. We love to keep our own last name. ...Ida Sent from my iPad On 2013-07-10, at 8:04 PM, Hui Deng denghu...@gmail.com wrote: Hello all We submitted two drafts to help people here to correctly call chinese people names: http://tools.ietf.org/html/draft-deng-call-chinese-names-00 http://tools.ietf.org/html/draft-zcao-chinese-pronounce-00 Feel free to let us know if you have any other issues? Best regards, -Hui Deng -- Consider orang-utans. In all the worlds graced by their presence, it is suspected that they can talk but choose not to do so in case humans put them to work, possibly in the television industry. In fact they can talk. It's just that they talk in Orang-utan. Humans are only capable of listening in Bewilderment. -- Terry Practhett signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [IETF] Re: Appeal Response to Abdussalam Baryun regarding draft-ietf-manet-nhdp-sec-threats
On Jul 3, 2013, at 12:32 PM, Pete Resnick presn...@qti.qualcomm.com wrote: On 7/2/13 6:37 PM, l.w...@surrey.ac.uk wrote: Do we have any statistics on how many appeals to the IESG fail and how many succeed? My quick read of http://www.ietf.org/iesg/appeal.html: Accepted: 6 Denied: 25 Withdrawn: 1 One appellant appealed 12 times and all of the appeals were denied. One appellant appealed 4 times, all denied. One appellant appealed 3 times, all denied. At least two of the accepted appeals resulted in a different remedy than requested by the appellant (i.e., adding an IESG Note to a document instead of making other changes or rejecting the document). At least two of the denied appeals were on strictly procedural grounds; one came over two months after the action, one was appealing an IAB decision that was out of jurisdiction for the IESG to decide. Interpret the above as you see fit. Thank you -- another worthwhile thing to do is look at who all has appealed and ask yourself Do I really want to be part of this club? Other than a *very* small minority of well known and well respected folk the http://www.ietf.org/iesg/appeal.html page is basically a handy kook reference. W pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478 -- It is impossible to sharpen a pencil with a blunt axe. It is equally vain to try to do it with ten blunt axes instead. -- E.W Dijkstra, 1930-2002
Re: [IETF] Re: [IETF] Re: Appeal Response to Abdussalam Baryun regarding draft-ietf-manet-nhdp-sec-threats
On Jul 3, 2013, at 3:41 PM, Phillip Hallam-Baker hal...@gmail.com wrote: +1 And don't lets forget that plenty of people have proposed schemes that WGs have turned down and then been proven right years later. If people are just saying what everyone else is saying here then they are not adding any value. Rather too often WGs are started by folk seeking a mutual appreciation society that will get through the process as quickly as possible. They end up with a scheme that meets only the needs of the mutual appreciation society. On Wed, Jul 3, 2013 at 3:31 PM, Pete Resnick presn...@qti.qualcomm.com wrote: On 7/3/13 1:10 PM, John C Klensin wrote: --On Wednesday, July 03, 2013 13:02 -0400 Warren Kumari war...@kumari.net wrote: Thank you -- another worthwhile thing to do is look at who all has appealed and ask yourself Do I really want to be part of this club? Other than a *very* small minority of well known and well respected folk the http://www.ietf.org/iesg/appeal.html page is basically a handy kook reference. I think this is a bit overstated. Yes. It was a flippant response and there should probably have been a smiley somewhere in it... There are 14 unique names of appellants (2 of which are groups of appellants). As I stated, 3 of those appellants account for 19 appeals, all denied. Perhaps you don't want to be part of the club with those 3 who make up 60% of the appealing, Yup, that is the club I was meaning. but if you simply remove those, you get: 13 appeals for 11 appellants (2 of them appealed twice, with years in between appeals) 1 appeal withdrawn before the IESG decided 6 appeals accepted 6 appeals denied. So the small minority are actually the repeat appealers. Yeah, you are right. I was simply looking at the list of repeats. Of the rest, over half I would instantly recognize as well-known and long-time participants, and (without naming names) half of *those* folks were denied and half were accepted. So appeals that get to the level of the IESG from the group of 11 are accepted half of the time. That means that these folks are bringing issues to the IESG that, after having gone through the WG, the chairs, and the cognizant AD, half the time are still accepted by the IESG. That is, there's a 50/50 shot they've found a serious problem that the IESG agrees the rest of us in the IETF have missed. I'd be part of that club. Yup, fair 'nuff -- as would I. I am honored to be a member of that club. Remembering that appeals, as others have pointed out, a mechanism for requesting a second look at some issue, they are an important, perhaps vital, part of our process. We probably don't have enough of them. Effectively telling people to not appeal because they will be identified as kooks hurts the process model by suppressing what might be legitimate concerns. Agreed. In any dispute process, there will be some folks who are outliers that make up an awful lot of the total load. But that shouldn't take away from those who are using it for its designed purpose. Agreed. The dispute / appeals process is important, and needed -- it has served, and I'm sure will continue to serve, a useful purpose. But, before filing an appeal I think one should take a step back, wait a day or three to calm down and ask oneself: A: is this really worthy of an appeal? B: how / why did we end up here? C: does my appeal look more like the club of 3, or the club of 11? D: have I tried to resolve this without resorting to appeals? really? E: do I actually understand how this IETF thingie works? F: was there any sort of process violation or am I simply annoyed that no-one likes / listens to me? G: have I filed more appeals than actual contributions? H: does my appeal text Contain Randomly capitalized Text or excessive exclamation marks? Have I made up words? I: am I grandstanding? J: am I simply on the rough side of consensus? K: is this really worthy of an appeal? W In addition, it is important to note that the page does _not_ list every appeal since 2002. If one reads Section 6.5 of RFC 2026, it describes a multi-step process for appears in each of a collection of categories. The web page lists only those that were escalated to full IESG review. Interestingly, 2026 6.5 only refers to things that get to the IESG, IAB, or ISOC BoT as appeals. The rest of the discussions are simply part of dispute or disagreement resolution. But John's central point still stands: Most of the dispute resolution takes place before it ever gets to the IESG, IAB, or ISOC BoT as a formal appeal. p.s. to any IESG members who are reading this: community understanding of the process might be enhanced by putting a note on the appeals page that is explicit about what that list represents, i.e., only appeals that reached full IESG review and not all appeals. Good idea
Re: [IETF] submission tool not sending confirmations ?
On Jul 2, 2013, at 10:43 PM, John Levine jo...@taugh.com wrote: I'm trying to submit and I-D, and I'm not getting the usual confirmation mail. My mail logs show nothing, no attempts, no failures. It worked the last time I tried it on Sunday. (Yes, I gave it a working address.) Anyone else seeing this? Happened to me recently -- I ended up opening a ticket.. Then I discovered the issue -- I was adding myself as a co-author on an existing draft -- in order to prevent shenanigans, an *existing* author has to submit it. Perhaps this is your issue? Anyway, Henrik / the tools folk are planning on adding a descriptive error message for the above. W R's, John -- I think perhaps the most important problem is that we are trying to understand the fundamental workings of the universe via a language devised for telling one another when the best fruit is. --Terry Prachett
Re: [IETF] Re: IETF, ICANN and non-standards
On Jun 19, 2013, at 3:43 PM, John Levine jo...@taugh.com wrote: I think this is the correct strategy, BUT, I see as a very active participant in ICANN (chair of SSAC) that work in ICANN could be easier if some more technical standards where developed in IETF, and moved forward along standards track, that ICANN can reference. As a concrete example, the EPP systems used in production by TLD registries use extensions that are documented only in I-Ds, often expired I-Ds, or in dusty I-D like web documents. If you look at the applications for new TLDs on the ICANN web site at https://gtldresult.icann.org/application-result/applicationstatus you will find that nearly all of them plan to use EPP extensions not described in an RFC. Most of these extensions should be utterly uncontroversial, e.g., one to synchronize renewal dates among multiple domains, or another to tell a client that its credit balance has dropped below a threshold. Assuming we care about stability and interoperability, wouldn't it make sense for the IETF to spin up a WG, collect these drafts, clean up the language, make sure they agree with the widely implemented reality, and publish them? I realize you were asking a larger question, but.. If we do, I volunteer to help collect, review, clean up, check and push them along. W R's, John -- Working the ICANN process is like being nibbled to death by ducks, it takes forever, it doesn't make sense, and in the end we're still dead in the water. -- Tom Galvin, VeriSign's vice president for government relations.
Re: [IETF] Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
On Jun 19, 2013, at 4:29 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 19/06/2013 18:25, Patrik Fältström wrote: On 18 jun 2013, at 18:54, Jari Arkko jari.ar...@piuha.net wrote: As for the rest of the discussion - I'm sure there are things to be improved in ICANN. I'd suggest though that some of the feedback might be better placed in an ICANN discussion than on IETF list. And is not like there'd be nothing to improve on our side :-) Lets focus on IETF aspects here. I think this is the correct strategy, BUT, I see as a very active participant in ICANN (chair of SSAC) that work in ICANN could be easier if some more technical standards where developed in IETF, + lots. If these are not developed in the IETF, we run the risk of ICANN doing technical stuff. As someone whose time is now[0] split between ICANN and IETF, I can tell you something -- you[1] *really* don't want ICANN developing technical standard. A pre-condition for that is that technical and operational problem statements are formulated, which could be sent to appropriate WGs or used to justify a BOF. If ICANN could focus on that instead of solutionism or committeeism, progress should be possible. Yup. This message needs to be properly communicated though -- Suzanne Woolf has been attempting (and being fairly effective) to do so. W [0]: I, along with some other IETF folk, serve on the SSAC under Patrik. [1]: You in the general sense, not you as in Brian or Patrik -- although I'm guessing you don't either. Are you confused yet with which you you are? Brian and moved forward along standards track, that ICANN can reference. Same with some epp-related issues, and also DNS-related, which I must admit I think has stalled in the IETF. When that happens, ICANN start to invent or at least discuss IETF related issues -- which I think is non optimal. But on the other hand, if IETF do not move forward, then what should ICANN do? I will btw be the first few days (until including Tuesday or so) at IETF in Berlin and am happy to discuss this issue with anyone interested. Patrik Fältström Chair SSAC, ICANN . -- She'd even given herself a middle initial - X - which stood for someone who has a cool and exciting middle name. -- (Terry Pratchett, Maskerade)
Re: [IETF] Re: IETF Diversity
On Jun 19, 2013, at 2:35 PM, Dave Crocker d...@dcrocker.net wrote: On 6/19/2013 11:31 AM, Melinda Shore wrote: Even in fields in which the overwhelming majority of practitioners, the majority of people in leadership or management positions are men. Everybody's got good intentions indeed, almost everyone claims that they are a better than average driver. Nah, I'm better than everyone else, because I don't suffer from the Dunning–Kruger effect. individual self-assessment tends to be a very unreliable mechanism upon which to base efforts at social change. Indeed. W d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Never criticize a man till you've walked a mile in his shoes. Then if he didn't like what you've said, he's a mile away and barefoot.
Re: [IETF] Content-free Last Call comments
[ Not sure if this is adding to the Signal or the Noise on the Discuss list, but it *will* help bump up my ranking on the Weekly posting summary, which I use to justify my participation to my management. That's what it's for, isn't it?!* ] On Jun 10, 2013, at 4:37 PM, Pete Resnick presn...@qti.qualcomm.com wrote: Russ, our IAB chair and former IETF chair, just sent a message to the IETF list regarding a Last Call on draft-ietf-pkix-est. Here is the entire contents of his message, save quoting the whole Last Call request: On 6/10/13 1:45 PM, Russ Housley wrote: I have read the document, I a support publication on the standards track. Russ A month ago, we had another very senior member of the community post just such a message (in that case directly to the IESG) in response to a different Last Call. I took that senior member of the community to task for it. But apparently Russ either disagrees with my complaint or didn't notice that discussion on the IESG list, so I think it's worth airing here in public: A statement such as the above is almost entirely useless to me as an IESG member trying to determine consensus. It is content-free. I disagree. We don't vote in the IETF, so a statement of support without a reason is meaningless. We should not be encouraging folks to send such things, and having the IAB chair do so is encouraging bad behavior. Had I not known Russ and his particular expertise, I would have no reason to take it into consideration *at all*. We should not have to determine the reputation of the poster to determine the weight of the message. Even given my background knowledge of who Russ is, I cannot tell from that message which one of the following Russ is saying: - This document precisely describes a protocol of which I have been an implementer, and I was able to independently develop an interoperable implementation from the document. - This document is about a technology with which I have familiarity and I have reviewed the technical details. It's fine. - I've seen objection X to the document and I think the objection is incorrect for such-and-so reasons. - My company has a vested interest in this technology becoming a standard, and even though I know nothing about it, I support it becoming a standards track document. - My Aunt Gertrude is the document editor and she said that she needs statements of support, so here I am. - I have a running wager on when we're going to reach RFC 7000 and I want to increase my odds of winning. I take it I am supposed to presume from my friendship and knowledge of Russ that one of the first three is true and that the last three are not. (Well, maybe the last one might be true.) But if instead of from Russ Housely, the message was from Foo Bar, I would have absolutely no way to distinguish among the above. Actually, yes. Russ has been participating in the IETF (and specifically in the area where he posted the above email) for a long time -- you know this, because you've also been participating. In *my opinion* he has shown himself to be diligent and sane. This means that *I* would give his comment and support great weight -- I'd *assume* he has read and understood the document, and is supporting it because #1, 2, 3 and / or 6. If Foo Bar had posted the comment, and in *my* opinion Foo Bar is a total nutter, I would give his comment less, or possibly negative, weight. Obviously your opinions of Russ and Foo may be opposite to mine -- you apply your own weighting to each comment -- that's why we pay you the big bucks… If Foo Bar is new enough to the IETF and cannot reasonably expect everyone on the IESG (or in a WG or wherever) to know and have formed an opinion of him, then it is *Foo Bar's* responsibility to more fully support his comments. Do folk who actually *participate* actively and sanely get to assume that they have earned some standing and credibility? Yup. I view this as a feature, not a bug. If I go to my doctor and he tells me that I simply have a cold (and not, like I'm convinced, the plague), I should presumably weight his comments higher than those of my crazy next door neighbor (who, apparently, routinely communicates with beings from another dimension), yes? We want to reward merit and participation, not make the process so annoying that those who participate get annoyed and wander off. If anyone *opposes* a draft, I think that it behooves them to explain what the issue is, regardless of who they are. This is similar to at a restaurant -- when the waiter asks if you are enjoying your [steak|tofu] it's fine to say Yes thanks, great, but if express displeasure you should be ready to explain what you didn't like. I think we should stop with these one-line statements of support. They don't add anything to the consensus call. I'm disappointed that Russ contributed to this pattern. Other opinions? My opinion is that the
Re: [IETF] Re: Not Listening to the Ops Customer
Warren Kumari -- Please excuse typing, etc -- This was sent from a device with a tiny keyboard. On Jun 1, 2013, at 5:51 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Doug Barton wrote: Not picking on you here, in fact I'm agreeing with you regarding the early days. In '94 SLAAC/RA was a good idea, and remains a good idea for dumb devices that only need to know their network and gateway to be happy. Wrong. Thank you for so eloquently proving Doug's point. W Even at that time and even on small end user LANs, it is better to let the gateway manage the address configuration state in centralized fashion than to have, so called, SLAAC, which is full of address configuration state, which is maintained in fully distributed manner involving all the nodes. Masataka Ohta
Re: [IETF] Not Listening to the Ops Customer
On Jun 1, 2013, at 12:35 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 01/06/2013 15:00, John C Klensin wrote: --On Friday, May 31, 2013 17:23 -0700 Randy Bush ra...@psg.com wrote: rant the sad fact is that the ietf culture is often not very good at listening to the (ops) customer. look at the cf we have made out of ipv6. the end user, and the op, want the absolute minimal change and cost, let me get an ipv6 allocation from the integer rental monopoly, flip a switch or two, and get 96 more bits no magic. 15 years later, dhcp is still a cf, i have to run a second server (why the hell does isc not merge them?), i can not use it for finding my gateway or vrrp exit, ... at least we got rid of the tla/nla classful insanity. but u/g? puhleeze. Randy, I suggest that characterizing that set of issues as IETF versus Ops is probably not completely right either. It was more complicated. I was actually running a team that ran site network ops at the time, and (since DHCP was not yet deployable), IPv4 was then a serious nuisance to manage, compared say to Novell Netware and, even, Appletalk. There were good reasons we wanted stateless auto-configuration and unlimited subnet size, to mention two IPv6 bells and whistles. If DHCP had already been deployed, our opinion might have been different. Yes, it was more complicated, but the sad part is that DHCP was widely deployed in V4 long before V6 was a viable transport for real work on the Internet. Operators kept asking for DHCP and kept being slapped down by zealots who refused to listen to / consider why the Ops were asking for this. I *really* want to make sure that my CEO always gets the same address, and want him to be assigned specific DNS servers and use a certain gateway. The folk who manage the DHCP are the Internal Services Infrastructure Group (aka The windows monkeys) and I'm sure as heck not giving them access to my router to twiddle knobs on it. For example, with IPv6, the IETF has proposed multiple transition solutions with no roadmap as to which one to apply under what circumstances and growing evidence that some of those solutions are unworkable in practice and others are incompatible with what are claimed to be fundamental and important features of the Internet. It turns out that as soon as you envisage a network in which some nodes only support 32 bit addresses and other nodes can't get a globally unique 32 bit address, you are forced into a world of hurt that requires some combination of NAT, tunnels and dual-stack. That is completely independent of the design of IPng, and we knew it 1994. Yes, hindsight always makes things *much* clearer. It also provides a nice sandbox to stand on…. Anyway, I think that going down the path of There are warts in V6, I want a refund! is not helpful. What I hope we can try and focus on is how we can improve understanding of what the customer (operators, users) actually wants, how and where the protocols of the future will be used, how we can incorporate changes as we get feedback and understand new requirements, etc. I was not intending to point fingers (although I realize I did), but rather to try show places where the protocol could have improved with a better understanding of what folk were looking for / with more operator input... So while your criticism is valid that we collectively came up with too many such combinations, that collective mistake was (IMHO) not a result of the design of IPv6 as such. It was more caused by the design of human beings. I'd go further -- some of the issue is (IMO) caused by the consensus driven nature of how we do things. We all have different sets of interests and different priorities. Because of a need to achieve consensus, we end in something kind of like horse-trading. We add features to appease some set of folk, and compromise on other bits to appease others. I suspect that if one or two folk had designed this, soup-to-nuts, we'd have ended up with something cleaner. It doesn't take a skilled operations person to understand that is a problem; someone with a pointy head and barely enough clue to figure out what a bit is much less how many of them are in various addresses can derive a don't be the first person on the block or don't migrate if you can figure out an alternative lesson from that. Similarly, various applications folks within the IETF have pointed out repeatedly that any approach that assigns multiple addresses, associated with different networks and different policies and properties, either requires the applications to understand those policies, properties, and associated routing (and blows up all of the historical application-layer APIs in the process) or requires request/response negotiation that TCP doesn't allow for (and blows up most of the historical application-layer APIs). It's true, but to avoid that, I think we'd
Re: [IETF] RE: Time in the Air
On May 31, 2013, at 10:03 AM, l.w...@surrey.ac.uk wrote: clearly, all IETF meetings should be in Cape Town, Wellington, or Perth, because more time in the air means more time without interruption where drafts can be read before the meeting. quiet time on a plane can be productive time. Until more airlines start offering in-flight Internets… I treasure my time on a plane, as it mean I can actually write some draft, etc. Once there is Internet -- yes, I *could* always just turn off my Wifi / not sign up for the in-flight bits, but I'm not disciplined enough. I end up deciding I quickly need to look up some reference and then: http://xkcd.com/214/ W Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Mark Nottingham [m...@mnot.net] Sent: 31 May 2013 10:59 To: ietf Discussion Subject: [IETF] Time in the Air In an attempt to inject some data into the discussion, I wrote a bit of code that figures out how much time, given your home city, you would have spent in the air if you'd attended all IETF meetings since IETF74 (i.e., from 2009 onwards). The first column is the home airport. The second column is the great circle time between the home airport and the nearest large airport to the IETF meeting, hhh:mm. This doesn't count things like transit time, taxiing, takeoff and landing overhead, indirect routing, etc. As such, this is an ideal number; the only way to achieve anything close to it is to have a private jet (with exceptional range). The third column is the time (hhh:mm) using the shortest-time routing on a travel booking engine. This is first-takeoff-to-last-landing time. Both numbers assume round trip between home and the IETF airports. SFO 204:10 282:04 // San Francisco BOS 197:42 297:38 // Boston ATL 205:44 297:28 // Atlanta ANC 197:12 345:54 // Anchorage LHR 198:02 249:44 // London FRA 202:10 255:22 // Frankfurt FCO 223:52 283:04 // Rome SVO 211:28 287:14 // Moscow TLV 264:12 334:22 // Israel DXB 293:26 344:34 // Dubai NRT 259:00 314:38 // Tokyo HKG 296:38 359:22 // Hong Kong BLR 332:28 448:24 // Bangalore MEL 450:28 556:04 // Melbourne AKL 442:24 569:04 // Auckland JNB 414:30 498:22 // Johannesburg EZE 411:10 522:56 // Buenos Aires GIG 381:56 488:32 // Rio de Janeiro Draw your own conclusions, of course. One observation is that there's a 3+ days-in-the-air per year variance if you're a full-time participant, depending on where you live. I.e., more than one day-per-meeting difference, on average. In the air alone. Another is that, perhaps surprisingly, the closest homes to all meetings are in Europe, not the US (at least by shortest-time routing). I can run other airports upon request, as well as make source available, but will do so conservatively, so as not to incur the ire of the services I'm (ab)using. Regards, P.S. The IETF airports chosen were: IETF_airports: [ ORL, ATL, YVR, CDG, TPE, YQB, PRG, PEK, AMS, LAX, HIJ, ARN, SFO ], -- Mark Nottingham http://www.mnot.net/ -- Do not meddle in the affairs of wizards, for they are subtle and quick to anger. -- J.R.R. Tolkien
Re: [IETF] Re: Issues in wider geographic participation
On May 30, 2013, at 8:37 PM, John C Klensin john-i...@jck.com wrote: --On Thursday, May 30, 2013 15:31 -0400 Warren Kumari war...@kumari.net wrote: The below is not a direct response to John, it is more my general views on IETF interaction with operators. So, I've been a long time participant in some NOG's and still (perhaps incorrectly) view myself as an operator. I've spent significant time thinking about / discussing the issue of insufficient operator involvement in the IETF, trying to understand some of the causes. I've tried to summarize some of the operators' views below, and also some thoughts on how we might be able to work better / get more operator input. I think that at the root of much of the problem is cultural differences -- if we want more operator involvement / feedback there needs to be some attention paid (by both the operators and the IETF folk) to understanding these differences, and taking care to respect / accommodate the other side's culture. ... Warren, I think these notes are very helpful, at least insofar as I have enough knowledge to evaluate. Some of your comments, including... This is somewhat of a vicious cycle -- operators participate less, and so the IETF understands less about how their networks run. This leads to solutions that don't understand the real world, and so operators lose faith/interest in IETF, and participate even less. ultimately call the IETF's legitimacy and long-term future into question. As you suggest, we may have good vendor participation but the operators are ultimately the folks who pay the vendor's bills. ... As I told someone in another thread, I threw the NOG idea out as an example without thinking through all of the possible dynamics. It may be a terrible idea... or even a good idea that won't work usefully. Part of that discussion included an observation that is probably a corollary to one of yours. Many operators, either individually or in groups, don't perceive that they have much incentive to review IETF documents, much less get dragged into the document development and consensus-forming process. Yup. And some operators have decided that the IETF document development and consensus-forming process is sufficiently annoying that they are standing up their own forum for Best Common Practice docs: http://www.ipbcop.org/ -- Documented best practices for Engineers by Engineers Some more info: http://www.internetsociety.org/deploy360/wp-content/uploads/2012/09/Hughes-BCOP.pdf There are BCOPs groups forming / within RIPE, NANOG, etc. This is still early days, but there have been discussions on how these should actually be published, etc. Various ideas have been floated, including bringing them to the IETF once baked, but the IETF stamp, a separate rfc-editor stream, simply publishing them under their own banner, etc. There is a NANOG meeting in New Orleans next week, where more discussions about this will be happening. If I make it to the session I'll try provide some feedback… Out of interest, who all from here will be attending NANOG? Who all attended RIPE in Dublin a few weeks ago? One (IMO) good idea that was mentioned recently (sorry, I cannot remember by whom, may have been Jim Martin) was for someone from the IETF to present a short summary of interesting work at NOG meetings. Someone from the IETF could collect short summaries from various WG's and present them at the various NOGs -- these should (IMO) be teaser style summaries, with the most interesting / dynamic bits highlighted. Ideally each WGs would provide a short, concise summary, and then the WG chairs (and folk who wear the smily faced dots on badges) could be designated as contact points, to help take input from operators, provide more detail, info on how you join the WG and participate, etc.. W Certainly, we are unlikely to get very many people who are not active IETF participants to do work for the good of the IETF. From that perspective, the very best incentive for reviewing a document pre-standardization is the perceived risk that it will make one's life worse if it goes through without input from your perspective. If we throw documents over the wall without clear motivation as to why people on the other side of the wall should care,... well, that is as much a setup for failure as the model in some other Internet bodies of soliciting input and then not paying any attention to it. (In the latter case, there may be organizational advantages to being able to say we received NN comments, but that does not apply to the IETF.) More generally, and borrowing (but altered somewhat) from another thread: The real point I'm trying to make is that, if our goal is really to do outreach to other communities to get better input or reviews with broader perspective, then we better start thinking more creatively than trying to persuade people (and their organizations
Re: [IETF] Not Listening to the Ops Customer (was Re: Issues in wider geographic participation)
On May 31, 2013, at 8:23 PM, Randy Bush ra...@psg.com wrote: rant the sad fact is that the ietf culture is often not very good at listening to the (ops) customer. look at the cf we have made out of ipv6. the end user, and the op, want the absolute minimal change and cost, let me get an ipv6 allocation from the integer rental monopoly, flip a switch or two, and get 96 more bits no magic. Unfortunatly Yup, the issue with v4 was simply a lack of addresses -- more address bits was what ops wanted, this probably needed a new protocol number, but that's about all. Unfortunately the was a bad case of creeping featuritis and we got: A new, and unfortunately very complex way of resolving L2 addresses. Magic IPSec, which then went away again. Extension headers that make it so you cannot actually forward packets in modern hardware ( http://tools.ietf.org/html/draft-wkumari-long-headers-00) SLAAC, which then required privacy addressing and then fun that that entails / the DHCP debacle. RA instead of VRRP Countless transition strategies. The list goes on and on, but gets depressing really fast. Operators learnt a number of lessons (the hard way) while operating IPv4 networks that reoccured in new ways in IPv6. For example, operators learnt that having a large subnet behind a router makes the router fall over (doing all the ARP processing) during an IP scan. This is almost identical to the issue described in RFC 6583 (Operational Neighbor Discovery Problems) Operators learnt (a long time back) that allowing source-routing is a really bad idea, and so a: devices disable it by default and / or b: the standard templates all have no ip source-route (or equivalent). This is almost identical to the Routing Header issues in V6 (see RFC 5095 - Deprecation of Type 0 Routing Headers in IPv6 ) Most operators address ptp Ethernet links with a /30 or /31 in V4. Took a long time to get this in V6 (RFC 6164 - Using 127-Bit IPv6 Prefixes on Inter-Router Link) and it is still controversial. We ended up in a space where perceived elegance and shiny features overshadowed what folk actually wanted -- 96 more bits, no magic. 15 years later, dhcp is still a cf, i have to run a second server (why the hell does isc not merge them?), i can not use it for finding my gateway or vrrp exit, ... at least we got rid of the tla/nla classful insanity. but u/g? puhleeze. Yup at ripe/dublin, olaf gave a really nice but somewhat glib talk about technology adoption, using dnssec and ipv6 as the positive examples. Yes, this was a great talk -- I think that it was somewhat glib for the audience, but having a longer, more in depth version of it at an IETF would (IMO) be valuable. I think that Olaf has a few versions of that talk…. For folk who'd like to see the RIPE version - https://ripe66.ripe.net/archives/video/7/ - Innovation at the Waist as some curmudgeonly schmuck pointed out at the mic, dnssec is forward compatible and there are no alternatives, so it is being adopted despite its complexity and warts. ipv6 is not forward compatible, we put unnecessary obstacles in the deployment path, and there are alternatives. d o o m. if we had wanted ipng deployed, we would have done everything we could to make it simple and easy for net-ops and end users to turn it on. instead, we made it complex and hard and then blame everyone else for not instantly adopting it en masse. the ietf did not listen to or consider the customer. this is fatal. and the arrogance is taking what is left of the e2e internet down the drain with it. +1. w randy -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman.
Re: [IETF] Re: Issues in wider geographic participation
On May 31, 2013, at 3:56 PM, Randy Bush ra...@psg.com wrote: Yup. And some operators have decided that the IETF document development and consensus-forming process is sufficiently annoying that they are standing up their own forum for Best Common Practice docs: http://www.ipbcop.org/ -- Documented best practices for Engineers by Engineers Some more info: http://www.internetsociety.org/deploy360/wp-content/uploads/2012/09/Hughes-BCOP.pdf actually, that is not operators acting for operators at all. Yup, Randy is 100% correct, this was started, and has gotten much thrust, from non-ops / policy folk. But, the fact that it has gotten some traction / the comments that one hears from ops folk re: how hard it would be to do this in the IETF context is (IMO) telling. it is yet another non-ops group trying to colonize ops. documentd best practices for engineers by policy folk. mission creep on their part, imiho. it would be amusing if they did not already have a mission that is critical for all of us. There are BCOPs groups forming / within RIPE, NANOG, etc. ripe has published ops practice and even protocol docs for a many years. as one example, route flap damping came from the ripe doc series. nanog may get serious, time will tell. Out of interest, who all from here will be attending NANOG? i will be. and saw you at ripe. will you be in lusaka in a week? Unfortunately not -- I had some conflict thing... One (IMO) good idea that was mentioned recently (sorry, I cannot remember by whom, may have been Jim Martin) was for someone from the IETF to present a short summary of interesting work at NOG meetings. this has been done many times. imiho, it has not stirred up much useful interaction unless the ietfer says something really st00pid. Yes, I may be tilting at windmills, but I think that, if it were done right (short summaries, just enough to pique interest, and then These are the bits we'd like feedback on, and here is how you can provide it (without joining yet another navel-having mailing list) it could be really useful. But, doing it right would be the key... then it gets amusing. Yes. Maybe it should be designed to present the contentious bits? W randy -- Militant Agnostic -- I don't know and you don't either...
Re: [IETF] Re: Issues in wider geographic participation
On May 30, 2013, at 1:24 PM, John C Klensin john-i...@jck.com wrote: Forwarding a discussion that started offlist for operational reasons with permission. I've tried to elide some irrelevant material; I hope that, if Eliot thinks it was relevant after all, he will add it back in once he gets to an appropriate machine. --On Thursday, May 30, 2013 09:20 -0400 John C Klensin john-i...@jck.com wrote: --On Thursday, May 30, 2013 08:03 + Eliot Lear (elear) el...@cisco.com wrote: If we subscribe wholly to this then to borrow from Darth Vader, our failure is complete. As you and I have discussed and debated, our engineering choices make certain assumptions about what problems are high order and which ones we can safely ignore. An example is bandwidth. Eliot, I think --or at least hope-- that either you have misunderstood me or that I have misunderstood your response. I'm not talking about bandwidth. I'm talking about protocols that don't work well under less than optimal circumstances. And I'm arguing for awareness and case-by-case understanding of tradeoffs, not somehow designing for the bottom. We've seen implementations that appear to be in full conformance to IETF specifications that simply die with packet timeouts and retransmissions. Perhaps that is just failure to document the use cases and limitations, perhaps it is failure to describe the edge cases and what to do about them. I'm disinclined to entirely blame implementers who make a good-faith effort to follow IETF specs carefully: if our documents don't permit them to get things right, I think at least part of the failure is ours for failure to cover those cases in specifications. We have recognized the issues with some specs and work areas, including trying to promote delay-tolerant efforts -- whether the environments be Mars or reindeer-based mobile stations in areas considerably north of Jari. In others, we have waved them off. The IETF was formed in part to have rapid impact, and by necessity that required operators and even some users who we later decided to call application developers. Sure. I'm not suggesting pushing either out. I am suggesting that more diversity in those groups would be of benefit. I'm also suggesting that, while including people and review processes who can speak with good experience from operator perspectives would be of huge benefit, that we don't want to expand into an operator forum. That means that the operational folks we want are operational folks who can also speak usefully to protocol issues. As what I think is a corollary, I think that beating the bushes in developing countries to try to get more operators and end users to attend the IETF as an end in itself is not a productive activity from an IETF standpoint. And, yes, I think we should be seeking reviewer partnerships with the NOGs (and maybe others) for certain classes of protocol specifications rather than expecting people who frequent those groups to participate actively in the IETF... and excluding whatever valuable input they might have if they don't. We have tried the latter model and, IMO, failed. The below is not a direct response to John, it is more my general views on IETF interaction with operators. So, I've been a long time participant in some NOG's and still (perhaps incorrectly) view myself as an operator. I've spent significant time thinking about / discussing the issue of insufficient operator involvement in the IETF, trying to understand some of the causes. I've tried to summarize some of the operators' views below, and also some thoughts on how we might be able to work better / get more operator input. I think that at the root of much of the problem is cultural differences -- if we want more operator involvement / feedback there needs to be some attention paid (by both the operators and the IETF folk) to understanding these differences, and taking care to respect / accommodate the other side's culture. Please note: I am discussing the operator and IETF participant as stereotypes, obviously the reality is much more nuanced than I'm presenting. These stereotypes probably don't include you -- they are simply generalizations to try and present the different sides of the issue. These are some of the concerns I have heard from operators: 1: The work in the IETF simply takes too long. I actually operate a network, and so I need results *soon*. I really don't want to spend months debating if requiring foo is a 'should' or a 'SHOULD', I just want my feature NOW. I give $vendor large amounts of money each year -- if I actually want a feature I just wave cash at them / threaten to move to $other_vendor and they'll add it for me. I saw this for myself in DANE. During the time it took us to get chartered, write a use case document, have endless navel-gazing exercises, meet a few times, and then finally publish a document, a set of folk
Re: [IETF] Re: Balancing the Process (Was: Obsoleting SPF RRTYPE)
On May 2, 2013, at 9:56 PM, Mark Andrews ma...@isc.org wrote: In message 5182828c.3040...@isdg.net, Hector Santos writes: Mr. Resnick, for the record, I wasn't upset. Believe it or not, I was actually applying an suggestion posted last month or so here with the IETF diversity talks to help get a major WG issue resolved, one with a near surety of an appeal, resolved and addressed much faster and hence avoid a waste of time on the behalf of all. How appropo, that a topic of balancing of process as being considered. It is one thing I believe the IETF needs and can be actually apply today. Yes, I don't agree with the negative tone taken in SPFBIS where in effect, an attempt to shut down communications and indirectly personally attack posters occurred and the advocates of the SPF RRTYPE removal (incidentally, a SPEC change which I believe was prohibited by the charter), basically blowing off advocates of a RFC4408 status quo. If you believe that was proper, I think we have a WG problem. Overall, I believe this (keep the migration path) is the proper compromise to resolve the issue, and I believe that this particular issue is industry-wide important to resolve with across the board engineering input. It *SHOULD NOT* be reserved only to the applications SPFBIS group especially when we know what the DNS community will say about this and has said so since MARID 2003 and again last year in IETF and DNSOPs. I was simply hoping to help Balance the process then as I was attempted to do again. If I was in error for trying to get a serious issue resolve, then please accept my apology. Sincerely, Hector Santos One of the questions is how to deal with vendors that claim to ship a product which is in compliance with the protcol when they are not. The DNS protocol has a error code for when you do not understand a query, FORMERR. It also has a error code for when you do not implement part of the protocol, NOTIMP. With RFC 103[45] you have three choices as a developer when you get a query type you don't know about. 1. Treat it as a FORMERR. 2. Treat it as a NOTIMP. 3. Treat it as a opaque data. Now in my book it isn't a FORMERR as you can understand the question even if you can't deal with it. NOTIMP is a reasonable response though I believe the intent in RFC 103[45] was to treat it as opaque data query which is what RFC 3597 says to do. Nowhere in RFC 103[45] does it say DO NOT RESPOND to the query yet we have DNS vendors that ship products that do just that and are claiming that they conform to the protocol. For a example of a set of servers that does this see earthlink.net's servers. Query for HINFO/earthlink.net at the authoritative servers for earthlink.net (itchy.earthlink.net and scratchy.earthlink.net) and you will not get a response. A RFC 103[45] compliant server should know about HINFO. It should also be capable of returning a NOERROR NODATA response for that query and it fact will if you ask for a non-existent TXT record at a name it serves. How do we deal with sites? How do we deal with vendors that ship such product? Unless the caffeine just hasn't sunk in yet, it works for me: wmbt-macbookair:Preferences wkumari$ dig HINFO earthlink.net @scratchy.earthlink.net ; DiG 9.8.3-P1 HINFO earthlink.net @scratchy.earthlink.net ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 1906 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;earthlink.net. IN HINFO ;; AUTHORITY SECTION: earthlink.net. 1800IN SOA itchy.earthlink.net. hostmaster.earthlink.net. 2013042602 3600 300 2592000 1800 ;; Query time: 51 msec ;; SERVER: 207.69.188.197#53(207.69.188.197) ;; WHEN: Fri May 3 12:59:50 2013 ;; MSG SIZE rcvd: 84 So, maybe the way you fix such sites / deal with vendors that ship such products is you post to ietf@ietf.org and cc hostmaster@site? :-P W Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Hope is not a strategy. -- Ben Treynor, Google
Re: [IETF] Re: IETF Diversity Question on Berlin Registration?
On Apr 29, 2013, at 4:55 PM, Joe Abley jab...@hopcount.ca wrote: On 2013-04-29, at 16:49, Sam Hartman hartmans-i...@mit.edu wrote: Stewart == Stewart Bryant stbry...@cisco.com writes: Stewart Why would you disregard a statistical analysis? That seems Stewart akin to disregarding the fundamentals of science and Statistical analysis is only useful if it's going to tell you something that matters for your decision criteria. http://i.imgur.com/47D7zGq.png Wow, that *was* useful, and has helped reinforce my belief that I chose the right browser -- Think of the children, don't use IE. Couldn't resist: http://xkcd.com/552/ W Joe -- There were such things as dwarf gods. Dwarfs were not a naturally religious species, but in a world where pit props could crack without warning and pockets of fire damp could suddenly explode they'd seen the need for gods as the sort of supernatural equivalent of a hard hat. Besides, when you hit your thumb with an eight-pound hammer it's nice to be able to blaspheme. It takes a very special and straong-minded kind of atheist to jump up and down with their hand clasped under their other armpit and shout, Oh, random-fluctuations-in-the-space-time-continuum! or Aaargh, primitive-and-outmoded-concept on a crutch! -- Terry Pratchett
Re: [IETF] Comments for Humorous RFCs or uncategorised RFCs or dated April the first
On Apr 6, 2013, at 9:03 AM, Abdussalam Baryun abdussalambar...@gmail.com wrote: Unclassified Message, but not Humorous Some participants like to send messages/documents as categoried or classified, and may include in others uncategorised or unclassified. That is a reasonable approach in reasonable organisations. I see some RFCs as mentioned in [1], that they are humorous that reflect a historic culture or a behavior that some may like to do in a certain date (others may not like to do or be part of). If the date is special then thoes RFCs SHOULD be *historical*. I suggest/request that the IETF stops this humorous RFC publication or try to categories them or distinguish them from our logical work/efforts. I request if they are categorised as informational or experimental then to be obsoleted. I recommend for future RFCs of that type categories to be as *historical* not others (i.e. informational). -very, very, very lots. I understand you may have missed the fact that an RFC was an April 1st, and are grumpy now, but that's no reason to ruin things for the rest of us... Try hacking protocol, not policy -- then folk may listen more to your proposals on things. W If those RFCs are not categorising/distinguished as unclassified or humorous, then all RFC may be affected. The reader may not be able to distinguish thoes published documents by IETF (does an organisation care about readers or users of its publications!). You may think to create a new category name for such publication published on April for that interested culture behavior. [1] http://en.wikipedia.org/wiki/April_Fools%27_Day_RFC Regards AB
Re: [IETF] Re: It's a personal statement (Re: On the tradition of I-D Acknowledgements sections)
On Mar 25, 2013, at 6:50 PM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: Hi Lloyd, On 03/25/2013 10:03 PM, l.w...@surrey.ac.uk wrote: (i'm just commenting on this thread so that when it results in an I-D recommending how to write acks, I get acked…) +1 W P.S: :-P Thanks! Yours is the first useful thing anyone's said in this thread that I recall. (Most previous mails made me groan with embarrassment that we wrap ourselves around axles like this so easily, but yours gave me a chuckle, and is hence far more useful:-) S. -- For every complex problem, there is a solution that is simple, neat, and wrong. -- H. L. Mencken
Re: [IETF] Getting rid of the dot (was: Mentoring)
On Mar 19, 2013, at 11:19 AM, Carsten Bormann c...@tzi.org wrote: On Mar 19, 2013, at 13:22, Michael Richardson m...@sandelman.ca wrote: Instead of getting a new badge every meeting, maybe we should just get an IETF86 dot on a badge we keep from meeting to meeting. I want my badge on a shiny embossed metal plate with the words protocol police on it. Where do I have to apply? Will increase your meeting fee by ~$45, but here you go… http://www.visualbadge.com/BuildBadge_ViewPic2.aspx?badge=FB46base=silvertextfont=blocktextcolor=blacktext1=I.E.T.Ftext2=PROTOCOLtext3=text4=POLICEtext5=BCP38text6=seal=C998Mtextsep=NONEaff=A128back=finish=NICKEL+ELECTROPLATEqtyb=1etype=SOFT+(REGULAR)att=BADGE+ONLY+(PIN+BACK)sh=CURVEDspecins=price=39.50l=pricel=qtyl=0textsep=NONEbsize=Dimensions+(w+x+h)%3a+1.25''+X+1.75''limpr=-LEAVE+BLANK-centertype=MULTI+COLOR W Grüße, Carsten -- Go on, prove me wrong. Destroy the fabric of the universe. See if I care. -- Terry Prachett
Re: [IETF] Re: Welcome to IETF-86!
On Mar 10, 2013, at 3:04 PM, Alexa Morris amor...@amsl.com wrote: The IETF 86 agenda was loaded last week, however you do need to update the app in order to see the current meeting. And you need to tell it that you are interested in the current meeting -- click Meetings in the bottom right, and then make sure IETF 86 - Orlando is chosen ;-) W Alexa On Mar 9, 2013, at 8:16 PM, Warren Kumari wrote: On Mar 8, 2013, at 5:33 PM, Paul Wouters p...@nohats.ca wrote: On Fri, 8 Mar 2013, Jari Arkko wrote: The IETF meeting is beginning on Sunday. I'd like to welcome everyone to the meeting! This blog highlights some of topics that I find most interesting in the meeting: http://www.ietf.org/blog/2013/03/welcome-to-ietf-86/ Is someone going to update the IETFers iphone app? It still does not have the sculed in it :/ I have no idea, but this reminds me…. A huge, heartfelt thanks to whoever wrote it -- it makes life much much easier… W Paul -- Some people are like Slinkies..Not really good for anything but they still bring a smile to your face when you push them down the stairs. -- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amor...@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com http://www.amsl.com/ -- What our ancestors would really be thinking, if they were alive today, is: Why is it so dark in here? -- (Terry Pratchett, Pyramids)
Re: [IETF] Re: Welcome to IETF-86!
On Mar 8, 2013, at 5:33 PM, Paul Wouters p...@nohats.ca wrote: On Fri, 8 Mar 2013, Jari Arkko wrote: The IETF meeting is beginning on Sunday. I'd like to welcome everyone to the meeting! This blog highlights some of topics that I find most interesting in the meeting: http://www.ietf.org/blog/2013/03/welcome-to-ietf-86/ Is someone going to update the IETFers iphone app? It still does not have the sculed in it :/ I have no idea, but this reminds me…. A huge, heartfelt thanks to whoever wrote it -- it makes life much much easier… W Paul -- Some people are like Slinkies..Not really good for anything but they still bring a smile to your face when you push them down the stairs.
Re: [IETF] Petition for We the People US Federal Government petition process: Create a Request for Comment (RFC) process similar to the IETF's for taking in suggestions for innovation from public.
'm assuming this is a joke… but my subtlety filters are turned down, so who knows... The Internet Draft process of the IETF works so effectively at filtering out Internet trolls because of the rigor and structure required for a proposal to be submitted. W On Mar 5, 2013, at 9:55 PM, Sam Crooks sam.a.cro...@gmail.com wrote: Hi all: If you agree, please sign this petition. I'd appreciate your help in crossing the thresholds required for consideration. Regards, Sam Text of the Petition: Create a Request for Comment (RFC) process similar to the IETF's for taking in suggestions for innovation from public. I believe that the We the People initiative is a good idea, grassroots-level suggestions, but a less than ideal implementation for collection of innovation suggestions. I propose that the Federal Government implement a process and structure similar to the Internet Engineering Task Force (IETF) Internet Draft and Request For Comment (RFC) processes and organization, which has proven to be *extremely* effective at filtering the Internet trolls, which have hijacked the We the People website and at collecting and acting on valid innovation proposals from anyone with an idea. The Internet Draft process of the IETF works so effectively at filtering out Internet trolls because of the rigor and structure required for a proposal to be submitted. http://www.ietf.org; http://wh.gov/G29p https://petitions.whitehouse.gov/petition/create-request-comment-rfc-process-similar-ietfs-taking-suggestions-innovation-public/CqHFnjJc -- Working the ICANN process is like being nibbled to death by ducks, it takes forever, it doesn't make sense, and in the end we're still dead in the water. -- Tom Galvin, VeriSign's vice president for government relations.
Re: [IETF] Re: Internet Draft Final Submission Cut-Off Today
On Feb 26, 2013, at 5:54 PM, Roberto Peon grm...@gmail.com wrote: I'm not sure that the deadline serves any positive purpose so long as we keep all of the versions anyway. It certainly is annoying the way it is now and is disruptive to the development process rather than helpful for it. Um, maybe. Another way to look at it is that a deadline, any deadline, helps stop folk procrastinating and actually *submit*. Have a look at the number of submissions just before the cutoffs… W -=R On Tue, Feb 26, 2013 at 2:50 PM, Melinda Shore melinda.sh...@gmail.com wrote: On 2/26/13 1:45 PM, Paul E. Jones wrote: On the one hand, having a cut-off time could help WG chairs make a decision as to whether to entertain a discussion on a draft. On the other hand, having no cut-off date might mean that drafts are submitted extremely late and it makes it more challenging or impossible to prepare an agenda. Well, for one thing the IETF does its work on mailing lists, and meetings support that rather than the other way 'round. For another, I'm not sure this deadline makes any difference in practice (other than introducing an inconvenience). We're going to be giving meeting time to a draft for which there's no revision, because it needs meeting time. It's on the agenda whether there's a revision or not. I understand the deadline was introduced to provide incentives for people to get their stuff in in advance of a meeting. But. Melinda -- I had no shoes and wept. Then I met a man who had no feet. So I said, Hey man, got any shoes you're not using?
Re: [IETF] Showing support during IETF LC...
On Feb 25, 2013, at 2:16 PM, Mary Barnes mary.ietf.bar...@gmail.com wrote: On Mon, Feb 25, 2013 at 1:03 PM, Jari Arkko jari.ar...@piuha.net wrote: Agree with what John, Brian, and others have said. FWIW, at times - particularly with documents having some controversy - the ADs are left wondering what the silent majority is thinking. So in some cases the private messages to the AD in question or to the IESG are helpful. And while +1 is usually bad form, indicating that you've done a thorough review and found no issues is appreciated. (Or better yet, that you intend to put this technology into your own use.) [MB] It's not clear to me why you think +1 is bad form. I interpret +1 to mean that an individual agrees with the assessment/input/comments of the email to which they +1. Rather than regurgitate the information, it seems expedient to me to use +1 in those cases.Certainly, if no substantive comments are made or no statement such as you indicate appears in the thread, then certainly +1 isn't useful. [/MB] I suspect it is because it is very hard to know if someone replying with '+1' has actually read / has a useful opinion on whatever they are replying to, or is just going alone with the herd… Then again, which is more useful / less annoying?: Version 1: I also do not understand why +1 is bad form. Instead of simply restating in other words that which was said previously, I could simply reply with +1 to show that I agree with a particular stance. Obviously, if there are no comments of substance in the discussion then simply replying with +1 is not contributing anything or, Version 2: +1 :-P W Finally, John Leslie wrote: In theory, an individual raising an issue on the ietf list has the same weight as a directorate review, but in practice each AD takes a directorate review more seriously unless he/she knows the commentor well. I hope that is not the case. It should not be. The concerns raised in a comment to the list, from an individual or directorate, should be weighed on how reasoned messages they are. How they are justified. And your own understanding of the issue and its seriousness, now that it has been explained. Of course, we are all humans, so there can be natural bias to trusting people you know more than others. But we are _trying_ to do it differently. Naturally, an opinion from, say, a working group chair in the same area tends to be well-reasoned, because he or she has a lot of experience in the matter. But just because he or she might be a directorate member should not result in the opinion being weighed any more than someone else's. Jari -- The duke had a mind that ticked like a clock and, like a clock, it regularly went cuckoo. -- (Terry Pratchett, Wyrd Sisters)
Showing support during IETF LC...
Hi there, So, I have an etiquette question[0]. When a draft comes up for IETF LC, you get the standard: The IESG has received a request from the Funny Orange Orangutang WG (foo) to consider the following document: 'Orangutans Considered Harmful draft-ietf-foo-dangerous-orangutangs-04.txt The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 1970-01-01. So, if I have issues with the draft, I know to send them to the list -- but what if I simply want to show support? Normally I figure that if the draft is the product of a WG there is already demonstrated support, and so I don't bother cluttering up the list with +1, me too, FTW!, etc. but is this actually the right thing to do? What if I really think the draft is important / useful; is it appropriate then? Or, if I think that the draft may not pass otherwise? Is there any difference if it is not a WG product? What would Miss Manners say? W [0]: Asking etiquette questions on -discuss seems only marginally saner than asking dining or travel questions on -attendees , but… :-P -- Let's just say that if complete and utter chaos was lightning, he'd be the sort to stand on a hilltop in a thunderstorm wearing wet copper armour and shouting 'All gods are bastards'. -- Rincewind discussing Twoflower (Terry Pratchett, The Colour of Magic)
Re: [IETF] back by popular demand - a DNS calculator
Sent from my iPad On Feb 16, 2013, at 2:02 AM, Patrik Fältström p...@frobbit.se wrote: On 15 feb 2013, at 23:45, Warren Kumari war...@kumari.net wrote: Sure -- the DNS protocol *cannot* handle any value in the octets -- in fact, there are an *infinite* number of values it cannot handle *in the octets*. For example, it cannot handle 257. It also cannot handle 321, nor 19.3... Ok, it is obvious Friday...somewhere... Once when being on IESG way back when I was tasked to write the response to the letter we got with a suggestion on an alternative solution for the running out of IPv4 addresses problem. The proposal was to not stop counting at 255 in each of the four numbers separated by periods, but continue to (at least) 999. That's also a solved problem -- there is even a draft about it : http://tools.ietf.org/html/draft-terrell-math-quant-ternary-logic-of-binary-sys-01 You just use ternary logic instead of binary and all your problems are solved... or something...I get a little lost during the proof of Fermat's... W Patrik
Re: [IETF] Re: back by popular demand - a DNS calculator
On Feb 15, 2013, at 5:06 PM, Patrik Fältström p...@frobbit.se wrote: On 15 feb 2013, at 18:19, Joe Touch to...@isi.edu wrote: - the Bert version uses DNS strings that aren't valid (*, +, ',', ++) Are we going to open again the question whether the DNS protocol can handle any value in the octets, as compared to the hostname definition that says something more limited? ;-) Sure -- the DNS protocol *cannot* handle any value in the octets -- in fact, there are an *infinite* number of values it cannot handle *in the octets*. For example, it cannot handle 257. It also cannot handle 321, nor 19.3... :-P W Patrik -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman.
Re: [IETF] A modest proposal
On Jan 22, 2013, at 11:45 PM, Melinda Shore melinda.sh...@gmail.com wrote: On 1/22/13 7:16 PM, Dean Willis wrote: Microsoft-OS text editors. Seriously. People wanted to be able to write correct SIP messages using text editors, and there were more Microsoft users than Linux users on the list. Oh, c'mon. MS products and MacOS at the time used CRLF for newlines generally, not just in Word. The fact that it was specified that way in HTTP, SMTP, FTP, and others matters a bit, as well. Yup, and Unix users have the ability to choose line endings: Emacs - M-x set-buffer-file-coding-system RET undecided-dos VI - : Set fileformat = dos : W If you are using anything else, a: don't or b: tr -d '\r' input.file output.file or perl -pi -e 's/\r\n/\n/g' input.file or sed 's/$'/`echo \\\r`/ input.txt output.txt or…. W Melinda -- The duke had a mind that ticked like a clock and, like a clock, it regularly went cuckoo. -- (Terry Pratchett, Wyrd Sisters)
Re: [IETF] WCIT outcome?
On Jan 2, 2013, at 5:07 PM, Dave Crocker d...@dcrocker.net wrote: On 1/2/2013 1:34 PM, ned+i...@mauve.mrochek.com wrote: Now, your point about rewiring the jack may in fact be the reason for _post-Carterphone_ acoustic couplers, but it was indeed at one time illegal to connect directly (other than AT+T/WE supplied equipment). I'm skeptical about this last part. Prior to the advent of RJ-11 Bell System line cords used a large polarized four pin jack. After Carterphone all sorts of stuff started to appear to accomodate these, including extension cords, plug-jack passthroughs, and even cube taps. Acoustic couplers date back farther than the 4-pin plugs. As I understood the ATT claim, they asserted a need to protect their network from misbehaving electronics and so required all interfacing to be through the handset that they provided. Hence the overlay hack of an acoustic coupler. Not unlike MIME... At one point there was something that said one phone in each home had to be directly wired without a plug. I don't know if this was a regulation, a phone company rule, or just a suggestion, but it also fell by the wayside after Carterphone. It was usually enforced rigorously. A given field tech might choose to overlook a local mod, but they were authorized to remove such things. So in my apartment, I installed a shutoff switch to the line, to be able to sleep through attempts by my boss to call me in to work an additional shift as a computer operator, at UCLA, around 1970 -- if I answered, I was required to come in. Remember there was no caller ID in those days. The tech who needed to work on my phone service was very clear that he was supposed to remove it. After checking that I had handled the wiring acceptably, he looked at me and said so if I remove this, you'll probably just reinstall it, right? He then left it in place. I grew up in South Africa, with Telkom, the state run monopoly. Connecting anything other than a telephone was illegal, with (IIRC) the possibility of jail time. You would have to rent the phone unit itself from Telkom by going to the post-office and filling in a form, then waiting few a few weeks to months. If yo unmoved you had to return the unit and rent a new one… South Africa used weird jacks, shared with Benin, Burundi, Cameroon, Central African Republic, Cook Islands, Liberia, Namibia and Serbia. (some pictures here: http://www.networkmuseum.net/2011/06/phone-plugs.html). The pins were made of some very soft metal (possibly high in lead, based upon the speed at with they would tarnish and appearance of the oxidation) and the wipers in the socket from a dissimilar metal. This would result in very poor / flaky connections, and kicking the jack to wiggle / reseat it was a common practice. Fun times... W d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Eagles soar but a weasel will never get sucked into a jet engine
Re: [IETF] Re: mailing list memberships reminder - passwords in the clear
On Nov 2, 2012, at 3:56 PM, John R Levine jo...@taugh.com wrote: Why does the mailing list memberships reminder send passwords in the clear? Because that's what Mailman does. Send code. And that's acceptable to the IETF? You're kidding me, right? I can't speak for the IETF, but I do note that the same password notices have been going out on the first of every month for years. You just noticed iit now? The mailman webUI (e.g: https://www.ietf.org/mailman/listinfo/ietf ) says: You may enter a privacy password below. This provides only mild security, but should prevent others from messing with your subscription. Do not use a valuable password as it will occasionally be emailed back to you in cleartext. If you choose not to enter a password, one will be automatically generated for you, and it will be sent to you once you've confirmed your subscription. You can always request a mail-back of your password when you edit your personal options. Once a month, your password will be emailed to you as a reminder. W And once again, if you think it should do something else, send code. We're volunteers here. Assertions that it is very important for someone else to do work that you're not prepared to do are rarely effective. R's, John -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman.
Re: [IETF] Re: [IETF] Re: Recall petition for Mr. Marshall Eubanks
On Nov 1, 2012, at 6:57 PM, John R Levine jo...@taugh.com wrote: As a small point of procedures, no one is sending an actual signature. It therefore would provide a modicum of better assurance for signatories to send the email that declares their signature directly to the ISOC President rather than to the person initiating the recall. If you're concerned that some of the 20 people who Olafur says signed his petition did not actually do so, please say that. If there's some other problem, what is it? Or if you're worried about unsigned or forged mail, why are you assuming that any of the messages on this list are real? The list software uses only the easily faked From: line to verify senders. R's, John -- Some people are like Slinkies..Not really good for anything but they still bring a smile to your face when you push them down the stairs.
Re: [IETF] Re: Recall petition for Mr. Marshall Eubanks
Warren Kumari -- Please excuse typing, etc -- This was sent from a device with a tiny keyboard. On Oct 31, 2012, at 9:15 PM, Melinda Shore melinda.sh...@gmail.com wrote: On 10/31/12 1:21 PM, Olafur Gudmundsson wrote: Fellow IETF'rs below is a recall petition that I plan on submitting soon if there is enough support. I regret having to do it this way, +1 but since it seems to be necessary and there is no agreed-upon alternative, I support this. As do I. :-( W Melinda
Re: [IETF] Exceptional cases
On Oct 26, 2012, at 8:16 AM, Eliot Lear l...@cisco.com wrote: Andrew, On 10/25/12 9:52 PM, Andrew Sullivan wrote: Oh, for heaven's sake. This is nothing to do with punishment. This is a straightforward administrative problem. Turning this into an opportunity to exercise a heavyweight and in fact punitive process would be an injustice. If the IETF has wound itself into such bureaucratic knots that we can't just make an exceptional decision in exceptional circumstances, we are in much worse trouble than I thought. A And as of yet nobody has challenged the need to remove Marshall. We've just gone off the deep end on process. What?! You are trying to say that the IETF ratholed on process? Never… http://www.cafepress.com/mf/33235226/ietf-process-organic-cotton-tee_tshirt W Yes, let's close the process problem as Brian said in due course. Let's also not rush through the changes for all the reasons that John Klensin wrote, plus another: I don't like the proposed approach, but that's for another message. Eliot -- When it comes to glittering objects, wizards have all the taste and self-control of a deranged magpie. -- Terry Pratchett
Re: [IETF] I-D Action: draft-jaeggli-interim-observations-00.txt
On Oct 15, 2012, at 5:53 PM, Adrian Farrel adr...@olddog.co.uk wrote: ok, i am lost. the draft is only an outline and has zero content? is it a quiz? Treat it like that and see if you can give Joel the right answers. For me: Did it make any difference to you that it was a LIM rather than simply a SIDR interim? Yes -- because it was LIM multiple WGs met at the same time. This meant that OpSec and V6Ops conflicted with SIDR, and so I missed the SIDR meeting. Were logistics and resources worth the fee? Personally I think so -- I have been involved in multiple interims, and the quality of the remote participation was (IMO) much better at the LIM. Having someone else (Meetecho) handle the audio / video was great… We (OpSec) were hoping to get more of the RIPE attendees (aka, operators) to show up and participate, but: A: there was a gap between RIPE and the LIM, B: the existence of the LIM was not announced far enough in advance for most RIPE attendees to change their plans C: we (OpSec) did a poor job of announcing the fact that we would be meeting, and asking for operators to come participate. Should we hold future LIMs, or do the scheduling and other issues mean that normal interims are the way forward? Sorry, but figuring this sort of thing out is what we pay *you* for… (aka, I don't know, to close to call). W cheers, Adrian -- What our ancestors would really be thinking, if they were alive today, is: Why is it so dark in here? -- (Terry Pratchett, Pyramids)
Re: [IETF] Re: I-D Action: draft-jaeggli-interim-observations-00.txt
On Oct 15, 2012, at 5:49 PM, Randy Bush ra...@psg.com wrote: ok, i am lost. the draft is only an outline and has zero content? is it a quiz? No, I believe that it is very subtle satire, reflecting Joel's view on the utility of the meeting :-P imiho, the sidr meeting was useful and got work done which probably would have taken a lot more time online and would have had the wonderful email misunderstanding amplification. +lots. Sad as it is, getting folk together in a room helps focus the discussion and provides many fewer opportunities for misunderstanding… randy -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf Warren Kumari war...@kumari.net
Re: [IETF] Large-scale measurement effort (re)started
On Sep 24, 2012, at 4:17 AM, Henning Schulzrinne henning.schulzri...@fcc.gov wrote: We just published an initial architecture and requirements draft on large-scale performance measurement architectures at http://datatracker.ietf.org/doc/draft-schulzrinne-lmap-requirements/ This is motivated by the FCC Measuring Broadband America effort [see http://www.fcc.gov/measuring-broadband-america/2012/july] and related efforts elsewhere. Comments on this new effort are appreciated on the LMAP mailing list [https://www.ietf.org/mailman/listinfo/lmap] Just to confirm, this is the same list that was created on 13th April, with I will be providing more details and background shortly,… and Please join the discussion on the list if you're interested in this topic.. And an (unanswered) question from Stephane on the same day? And then, Fri, 15 Jun 2012 a (unanswered) request from Matthew Ford for more details and background? And then (also unanswered) the same from me on Wed, 11 Jul 2012 Same list, yes? W Henning
Re: [IETF] Last Call: draft-vegoda-cotton-rfc5735bis-02.txt (Special Use IPv4 Addresses) to Best Current Practice
On Jul 14, 2012, at 3:18 PM, Christian Huitema wrote: Very useful document, certainly worth publishing. +1 It is one of those documents that needs frequent updates. +1 RFC 6052, IPv6 Addressing of IPv4/IPv6 Translators, makes reference to a predecessor of this document, stating in section 3.1 that The Well-Known Prefix MUST NOT be used to represent non-global IPv4 addresses, such as those defined in [RFC1918] or listed in Section 3 of [RFC5735]. I assume that implementers will automatically upgrade their code to reference the new version. -1 -- I would not assume any such thing. I *might* guess that implementors will include the new version in new / updated code, but the not necessarily the automatically bit :-P W -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Randy Bush Sent: Friday, July 13, 2012 4:21 PM To: IETF Disgust; The IESG Subject: [IETF] Re: Last Call: draft-vegoda-cotton-rfc5735bis-02.txt (Special Use IPv4 Addresses) to Best Current Practice The IESG has received a request from an individual submitter to consider the following document: - 'Special Use IPv4 Addresses' draft-vegoda-cotton-rfc5735bis-02.txt as Best Current Practice read and support randy -- Working the ICANN process is like being nibbled to death by ducks, it takes forever, it doesn't make sense, and in the end we're still dead in the water. -- Tom Galvin, VeriSign's vice president for government relations.
Re: Feedback Requested on Draft Fees Policy
On Jul 20, 2012, at 9:07 AM, IETF Administrative Director wrote: The IAOC is seeking community feedback on a proposed policy by the IAOC to impose fees to produce information and authenticate documents in response to subpoenas and other legal requests. The IETF receives requests for information, documentation, authentication or other matters through subpoenas and less formal means that require manpower and materials to be expended. These requests are on the rise. During the period 2005 to 2010 the IETF responded to nine subpoenas. Since 2011 the IETF has received five subpoenas and three other legal requests for authenticated documents. Each such request is time sensitive and involves the IETF Counsel, the IAD, and members of the IAOC, who together form the Legal Management Committee, to rapidly analyze and identify the means for satisfying the request. Often there is a need to retain outside counsel, especially in cases that might lead to depositions or court testimony. The IAOC believes a Schedule of Fees is an appropriate and reasonable means to recover costs associated with such efforts. The draft policy entitled Draft Fee Policy for Legal Requests can be found at: http://iaoc.ietf.org/policyandprocedures.html Before adopting a policy the IAOC would like feedback on this before making a decision. Comments appreciated to ietf@ietf.org by 6 August 2012. Ray Pelletier IETF Administrative Director LGTM++. Seems like a grand idea -- who knows, may even help avoid nuisance suits (although the fees are so small (compared to all the other costs) that I don't hold much hope of this…). W -- For every complex problem, there is a solution that is simple, neat, and wrong. -- H. L. Mencken
Re: [IETF] Re: New Non-WG Mailing List: IETF-822
On Jun 14, 2012, at 5:44 PM, Peter Saint-Andre wrote: On 6/14/12 3:37 PM, IETF Secretariat wrote: List address: ietf-...@ietf.org Is no one thinking ahead to the 822nd meeting of the IETF in the year 2258?!? Who cares about that? I think that it is *vital* that we discuss RFC 85 and fully explore all of the implications therein. For example, *where* at the Illini Union will it be? What do we do if Phyllis doesn't reply in time? Who will bring the bluesheets? How do I get from the airport to the Illini Union? And who fixes the clock in my room if the chambermaid doesn't? I therefore propose that we create a ietf-...@ietf.org list to fully (and finally) get to the bottom of these important questions, once and for all…. W /psa --- Schizophrenia beats being alone.
Re: [IETF] Re: [IETF] Re: New Non-WG Mailing List: IETF-822
On Jun 14, 2012, at 5:55 PM, Warren Kumari wrote: On Jun 14, 2012, at 5:44 PM, Peter Saint-Andre wrote: On 6/14/12 3:37 PM, IETF Secretariat wrote: List address: ietf-...@ietf.org Is no one thinking ahead to the 822nd meeting of the IETF in the year 2258?!? Who cares about that? I think that it is *vital* that we discuss RFC 85 and fully explore all of the implications therein. For example, *where* at the Illini Union will it be? What do we do if Phyllis doesn't reply in time? Who will bring the bluesheets? How do I get from the airport to the Illini Union? And who fixes the clock in my room if the chambermaid doesn't? I therefore propose that we create a ietf-...@ietf.org list to fully (and finally) get to the bottom of these important questions, once and for all…. …. and wouldn't this have been awesome if I actually had ietf...@ietf.org in my paste buffer (like I thought I did) and not ietf-...@ietf.org. That way I would have sounded super-awesomely funny and not like I had miscalculated my meds…. W W /psa --- Schizophrenia beats being alone. -- It is impossible to sharpen a pencil with a blunt axe. It is equally vain to try to do it with ten blunt axes instead -- E.W Dijkstra, 1930-2002
Re: [IETF] Re: Last Call: draft-ietf-intarea-ipv4-id-update-05.txt (Updated Specification of the IPv4 ID Field) to Proposed Standard
-- No man is an island, But if you take a bunch of dead guys and tie them together, they make a pretty good raft. --Anon. On Jun 3, 2012, at 12:34 AM, C. M. Heard wrote: On Sat, 2 Jun 2012, Masataka Ohta wrote: Existing routers, which was relying on ID uniqueness of atomic packets, are now broken when they fragment the atomic packets. Such routers were always broken. An atomic packet has DF=0 and any router fragmenting such a packet was and is non-compliant with the relevant specifications (RFCs 791, 1122, 1812). Sorry, but no…. Not following the RFC != broken. Not following the RFC == non-compliant. There are numerous places where implementations do not follow the specs for various reasons, ranging from simply not bothering, through philosophical differences to customers paying for non-compliant feature X. Sorry, I'm in a somewhat pedantic mood, and I saw a soapbox, so I climbed up on it… W //cmh
Re: [IETF] RE: RFC 2119 terms, ALL CAPS vs lower case
On May 16, 2012, at 4:10 PM, Worley, Dale R (Dale) wrote: From: John C Klensin [john-i...@jck.com] Remind me: Is bold must more or less compelling that underlined must. And where does uppercase MUST fit in? I fear the slightly richer publication format will give rise to a slightly more complex revision of RFC 2119. Let's try to remember that many of the comments/ requests for alternate publication formats have been to make display more a function of the devices being used. Depending on type style variations (style, size, font variations, underlining, etc.) would pretty much defeat that particular claimed requirement. As I take Sam's note to sort of point out, even the use of uppercase to imply specific semantics can be problematic; we should at least strive to not make things worse, IMO. I'm looking forward to the normative use of BLINK.../BLINK. Errr… would that be more or less strong then the non-BLINK version of a word? Initially I'd think more, but on reflection it only visible for half the time, so I guess it is half as strong?! ;-) W Dale
Re: [IETF] Re: Future Handling of Blue Sheets
On May 10, 2012, at 1:42 PM, Melinda Shore wrote: On 5/10/12 9:32 AM, Martin Rex wrote: There has never been a need to actively broadcast these massive amounts of personally identifiable information (PII), and I haven't seen any convincing rationale for doing it now. To be honest, I don't want to receive more spam and My boss might find out I skipped a session are not reasons not to be open about who's participating in sessions, particularly as we drift towards a meetings/voting model. I understand sensitivity about broadcasting travel plans but in general some of the arguments being offered for being a less open organization with a less open process are drifting into The FBI implanted a radio transmitter in my teeth territory, and it seems to me that making blue sheets available after meetings does not reveal much PII beyond what's already available on the mailing lists. Oh dear, oh dear oh dear…. I've been trying hard to stay out of this discussion, but finally cannot anymore… I fully agree with Melinda here -- if you are active in the IETF (or even if you aren't), you email address is already known to the spammers. Our lists, and list archives are all public -- if you think that you are important enough that spammers would download and OCR blue sheets to get your address, you are A: out of touch with the current spam model and / or b: believe that you are much more important than you really are... If you are concerned that your bossman might figure out that you skipped a session -- well, here's an idea, actually two: 1: work somewhere where you manager trusts you enough to do what's in the best interests of the organization (and then do so) and / or 2: attend the friggin' sessions. Presumably you flew half way round the world to participate, not to drink espressos in some new and exotic city. For the record: 1: My email addresses are war...@kumari.net, wkum...@google.com, wkum...@gmail.com, war...@snozzages.com and ... 2: I was sitting in seat 3A in room 243 at 15:25 on TUESDAY, March 27, 2012. I cannot remember what I was wearing, but it probably involved a t-shirt, sandals and some kind of hat. When you invent a time machines and travel back, you should be able to find me there.. 3: I didn't attend a single session on Afternoon Session I, WEDNESDAY, March 28, 2012 (I feel that I have gotten much much rantier than intended, but, oh well…) W [0]: and mailman's super secure s/war...@kumari.net/warren at kumari.net/ was figured out a long time ago! There's a serious question here about tradeoffs between privacy and openness. Openness is not just a core institutional value (although it is one - do not forget that), but it's also a defense against charges of collusion, which, unfortunately, we've been seeing. Melinda
Re: [IETF] Re: IETF posting delays
On May 7, 2012, at 6:18 PM, Hector Santos wrote: Hi, I think what has been lost here is that the delays were not just with my non-member submission, but also my member address as well. The fact that it is intermittent makes it all very odd. I still have yet to receive a May 6 8:49PM reply post using my member address and its been nearly 22 hours. The odd thing is that someone indicated offlist they received a copy of it. But its not on the IETF list archive and my servers show no evidence of any attempt. Maybe you have not metoo (Receive your own posts to the list?) set on your mailman entry? Actually, if you login to mailman for the discuss list does it show anything interesting about your address? W My MTA machine use SPF with hard fail policies (no softfail or neutral results) and all my mail is signed, that doesn't seem to have any weight. Whats odd is if this is indeed of case of specific individuals moderation, its filtered on domains only and not the person because I have no problem with gmail.com postings. Thanks -- Hector Santos http://www.santronics.com http://hector.wildcatblog.com jabber: hec...@jabber.isdg.net Mary Barnes wrote: I agree with you John. I know that I have had messages discarded on several occasions. As a moderator, I look at the legitimacy of the posting and if it is a member of the community (it's generally very easy to tell), then I add them as being able to post even though they aren't subscribed. This can be very helpful as many of us use multiple addresses. Mary. On Mon, May 7, 2012 at 10:03 AM, John C Klensin john-i...@jck.com wrote: --On Monday, May 07, 2012 14:18 + John Levine jo...@iecc.com wrote: the question seems to be we used to reply to the sender with a notification that their message was blocked due to not being a list member, with options to wait or cancel; did we disable those notifications? I sure hope so. These days about 99.9% of spam from unknown senders is spam with forged addresses, so responses are just more spam aka blowback. At the same time, the IETF has considerable obligations about openness. From that point of view, silently discarding messages from someone who thought they had properly subscribed could be rather bad news. Fortunately, if I correctly understand the thread, we aren't doing that, we are moderating instead. If that is correct, it seems to me that it might be appropriate to send a message to the submitter of a moderated message explaining that moderation leads to both delays and extra work so that, if they intend to submit further messages from the address, they should subscribe properly. That approach would seem to serve both efficiency (fewer messages to moderate because people would be warned to subscribe) and anti-blowback efforts (the only messages that would generate responses to a supposed submission addresses are those that had already been found sufficiently valid/relevant to post to the list). It also seems to me that our subscription and archive pages might well be modified to be explicit about what our procedures actually are. Doing so would improve openness, help some contributors, and not help any spammers who are indifferent to whether their messages go (anyone wanting to specifically spam IETF lists can figure out how to subscribe, even with our verification process). If an active contributor like Hector is posting one message after another, seeing delays, and not noticing that he is not properly subscribed at that address, it seems to me that we could, and should, be doing better rather than blaming the victim. john
Re: [IETF] Re: 'Geek' image scares women away from tech industry ? The Register
On Apr 30, 2012, at 5:31 PM, Janet P Gunn wrote: My own anecdotes. Yes, it starts early. When I was 3 I announced that I was going to be a physicist when I grew up. WHY? 1 - a physicist has a chair that is on WHEELS, and spins ROUND and ROUND 2 - a physicist has a blackboard with COLORED CHALK 3 (and MOST important) a physicist has a CANDY machine in the hall outside his office. Hmmm... when I was young I wanted to be a garbage man... then one day I realized I didn't own the correct gloves, so I decided I would a doctor instead... Apparently that fact that I would A: be able to buy garbage man gloves (or get some provided) and B: doctors also need gloves completely didn't occur to me... :-P W Well, I didn't become a physicist, but those features certainly put technology in a good light from an early age.!! Second, while the statistics may say something else, I find MORE WOMEN, in MORE RESPECTED positions, at IETF than in my work environment. Janet ietf-boun...@ietf.org wrote on 04/30/2012 10:13:50 AM: Mary Barnes mary.ietf.bar...@gmail.com Sent by: ietf-boun...@ietf.org 04/30/2012 10:13 AM To Riccardo Bernardini framefri...@gmail.com cc IETF discussion list ietf@ietf.org Subject Re: 'Geek' image scares women away from tech industry ? The Register Yes, the article is far from complete. But, your antecdote only goes to show your own bias towards women in science and engineering in general. By the time most females reach high school they have already been conditioned that girls aren't as good as boys in math and science. There's a far amount of studies showing this - at least in the US. As Monique said it is a very complex issue. Some of it starts at home and it starts extremely early. It's far more common for girls to be told they are pretty rather than smart. They have found some physiologic reasons that do influence math abilities - those with math brains tend to have higher levels of testosterone. That all said, it still doesn't explain why the percentage of women active in the IETF is less than the percentage of women that are in the field. But it might have something to do with IETFers sharing your perspective that women just aren't interested. Regards, Mary.
Re: [IETF] Re: shared address space... a reality!
On Mar 14, 2012, at 8:36 AM, Christopher Morrow wrote: 2012/3/14 Roger Jørgensen rog...@gmail.com: This is really good news for some people, that already have address conflict within RFC1918 and don't want to get public address space :p you mean every enterprise on the planet? (or probably 99.999%) Don't forget consumers -- I have renumbered some of my home network to use this… It just solved a problem that I didn't have… W -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman.
Re: [IETF] Add a link to the HTML version in i-d-announce mails ?
On Mar 6, 2012, at 8:41 AM, Xavier Marjou wrote: As a subscriber of the i-d-annou...@ietf.org list, I generally prefer reading the HTML version of the draft rather than the TXT version. I thus often need to manually rewrite the TXT link to fetch the HTML version of the draft. I can not believe I'm the only one. Yup, you are not the only one -- this annoyed me sufficiently that I finally gave in and wrote a Chrome extension to do this for me. Basically it watches the address bard and looks for www.ietf.org/id/foo and, depending on the setting in the options page, will redirect to the Tools or Datatracker. So, if I follow a link like http://www.ietf.org/id/draft-ietf-idr-as0-03.txt the extension will notice and rewrite it to http://tools.ietf.org/html/draft-ietf-idr-as0-03 (or https://datatracker.ietf.org/doc/draft-ietf-idr-as0/ ). This is my first extension/ javascript, and it's not particularity polished, etc but if folk are interested it is on the tools page ( http://tools.ietf.org/ ) or, direct: https://chrome.google.com/webstore/detail/aiccdpabeagpjcebilebhlifplfkinao Share and enjoy. W Hence, would it be possible to also include a link like http://tools.ietf.org/html/draft-name in the mail of the announced draft? Cheers, Xavier ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IETF] Add a link to the HTML version in i-d-announce mails ?
On Mar 6, 2012, at 7:43 PM, Barry Leiba wrote:
Yup, you are not the only one -- this annoyed me sufficiently that I finally
gave
in and wrote a Chrome extension to do this for me.
Basically it watches the address bard and looks for www.ietf.org/id/foo
and,
depending on the setting in the options page, will redirect to the Tools or
Datatracker.
Inspired by that, I wrote a completely trivial (one-line) Greasemonkey
script this afternoon, to do it for Firefox. It's so short that I'll
just paste it below. Works nicely.
Oooh, very cool….
W
Barry
--
// ==UserScript==
// @name IETF draft html
// @namespace ...whatever...
// @descriptionRedirect txt drafts to html
// @includehttp://www.ietf.org/id/*
// @includehttps://www.ietf.org/id/*
// ==/UserScript==
(function () {
window.location = new
String(window.location).replace(www.ietf.org/id,
tools.ietf.org/html).replace(.txt, );
})();
--
--
Don't be impressed with unintelligible stuff said condescendingly.
-- Radia Perlman.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: [IETF] Re: ITC copped out on UTC again
On Jan 20, 2012, at 1:04 PM, Ofer Inbar wrote: If the main problem with leap seconds is their future unpredictability, isn't there a compromise option between the status quo and no more leap seconds? Couldn't they come up with a fixed schedule for leap seconds for many centuries at a time, based on current predictions of approximately how many will be needed each century? That should be good enough to prevent real human-noticeable drift between UTC and perceived day/night time. If a correction is needed because current predictions turn out to be wrong, it seems that could be done very rarely, with centuries of lead time in changes to the schedule. Was anything like this considered at the international level? [ I know this is not something the IETF can decide, of course ] So, many of these discussions and suggestions seem to be at best addressing a symptom (time is diverging) versus the actual issue (the planet is slowing down) -- this feels to me like a bandaid over a gaping wound. So, my proposal is that, at the next meeting, we all face counter to the rotation and blow really hard -- Lord knows that we generate enough hot air, maybe we can finally put some of it to good use. I'm considering proposing a bar BOF so that we can determine just how long we would need to blow for. Obviously different folk generate vastly different amounts of hot air, and so factors like this would need to be taken into consideration, etc. W -- Cos ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IETF] Re: Last Call: draft-ietf-sidr-rpki-rtr-19.txt (The RPKI/Router Protocol) to Proposed Standard
On Dec 20, 2011, at 6:00 PM, Danny McPherson wrote: I'm kinda surprised the security ADs are OK with this in a brand new connection-oriented protocol meant to increase security of the network: S.7: Caches and routers MUST implement unprotected transport over TCP using a port, rpki-rtr, to be assigned, see Section 12. Operators SHOULD use procedural means, ACLs, ... to reduce the exposure to authentication issues. Yup. Just below the text that you included there is: If available to the operator, caches and routers SHOULD use one of the following more protected protocols. and a list of things including AO, SSH, TCP MD5, IPSEC, TLS. Sections 7.1. (SSH Transport), 7.2. (TLS Transport), 7.3. (TCP MD5 Transport) and 7.4. (TCP-AO Transport) provide more information on using these. The Security Considerations section also say: ... So the strength of the trust relationship and the transport between the router(s) and the cache(s) are critical. You're betting your routing on this. … Transports which can not provide the necessary authentication and integrity (see Section 7) must rely on network design and operational controls to provide protection against spoofing/ corruption attacks. I'm sure that the authors would have preferred to simply say Use TCP-AO, and saved themselves a bunch of typing (and Security warnings, etc) -- it is obvious that they are not tying to gloss over the concerns. Unfortunately not all OSs support TCP-AO…. Well then, it seems that, as routers already support SSH it should be simple to wrap a TCP stream, yes? Unfortunately no -- not all implementations have a simple library type model. Same things for IPSec / TLS, etc. In an ideal world there would be ubiquitous, secure, fast, cheap, reliable, unencumbered transport security -- unfortunately we are not there (yet). Folk who have support for secure transports available should use them, but if I don't, I'd still like to have the option to deploy this. The perfect is the enemy of the good. -danny Warren. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-sidr-rpki-rtr-19.txt (The RPKI/Router Protocol) to Proposed Standard
On Nov 29, 2011, at 5:51 PM, The IESG wrote: The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'The RPKI/Router Protocol' draft-ietf-sidr-rpki-rtr-19.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-12-13. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Support. I have (carefully) read and reviewed this document and support publication…. W Abstract In order to formally validate the origin ASs of BGP announcements, routers need a simple but reliable mechanism to receive RPKI [I-D.ietf-sidr-arch] prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IETF] Re: [IETF] Travel/Attendees list FAQ
On Dec 8, 2011, at 11:00 AM, Paul Hoffman wrote: On Dec 7, 2011, at 6:49 PM, Dave CROCKER wrote: Actually, I meant wiki according to its classic, collaborative meaning: http://en.wikipedia.org/wiki/Wiki What you folks are describing is a web page, not really a wiki. Exactly, and that is appropriate for something whose primary target is organizations that are giving large amounts of money and time to the IETF. A collaborative page can easily go sideways with contributors who don't understand the parameters of what is meant to be there. Yes, and who have very little incentive to add stuff -- for example, look at the WG Chairs wiki ( http://wiki.tools.ietf.org/group/wgchairs/ )-- the subtitle is: Everything a WG Chair Needs to Know but Was Afraid to Ask . This site is far from useful[0], and hasn't been kept up to date (mnot made some changes ~ 6months ago, 22months ago Marc changed some email addresses, 2 years ago Tony changed a URL or two, most of the content is 5 years old). It is *far* from everything a WG Chair needs to Know -- something like this aimed at the event folk / organizers at a sponsor is not going to reflect well on the IETF and is not going to help lead to a successful meeting. If we ended up with the opposite problem (everyone editing), things would be much much worse -- anyone reading this would assume that we are a bunch of childish, blithering idiots -- go read some previous Attendees lists and sample random threads (the Hilton clock thread: http://www.ietf.org/mail-archive/web/80attendees/current/msg00271.html , the CD is a chocolate? thread, the infamous Maastricht train threads) -- these are the sorts of things that folk might add the the Wiki -- it this really the image we want to be projecting? Wiki's are a great idea, *for some things*, but (IMO) this is not one of them. W [0]: Yes, I *know* it's a wiki and I can / should go edit it myself, but, well In many cases such as WGs, such sideways motion is fine; for a page whose audience are often people who don't know about the IETF but are tasked with deciding whether or not to give us significant financial support. --Paul Hoffman ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IETF] Re: Travel/Attendees list FAQ
On Dec 7, 2011, at 2:33 PM, Ole Jacobsen wrote: The flip side of this argument is that it could be viewed as a helpful guide for the hosts/sponsors at any given venue. (This is the kind of information you should provide.) + lots... I work for a company that is sponsoring an upcoming meeting. Most of the organization is being done by folk who have never attended an IETF meeting (but some of them will be coming to Paris to get a feel for things). This document has been hugely useful (oddly enough we were talking about just how useful today) to help them understand the general feel, the sorts of things to pay attention to, what information is needed, the pain associated with trains (:-P), food considerations, etc. At APRICOT, we've developed an Ops Manual[1] that covers everything from room setup to no kareoke at the social event. I am not saying that our document needs to be an RFC, but we don't have a lot of alternative ways to publish things that can be quickly retrieved, printed off and so on. [1] http://www.apricot.net/docs/APRICOT-Op-Man.pdf Something like this tailored to the IETF would be awesome. The organizers at many of the sponsors are not IETF participant / attendees and having useful reference / background material would we really good for them -- a single document like the APRICOT-Op-Man or an RFC, self contained (and printable), in a single voice will be much better understood than a whole collections of pages with various voices I often (usually?) disagree with Wes, but think that this draft is *really* useful and is worth publishing... W Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj Skype: organdemo On Wed, 7 Dec 2011, Bob Hinden wrote: While I agree that the questions won't change as often as the answers, it will likely change. We have come a long way from just asking how many cookies there will be. Also, if it gets published as an RFC, it is going to be viewed as a specification. I think it's best to avoid that and just have a wiki. I would be surprised if this topic continues to be as active area of discussion in the future, making it unlikely that there would be new RFCs published. Further, is this something we really want in the historical record. Bob ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IETF] Re: Consensus Call: draft-weil-shared-transition-space-request
On Dec 2, 2011, at 1:51 PM, Joel jaeggli wrote: On 12/2/11 09:59 , Michael Richardson wrote: Ted, your response does not address what I said at all. Not one bit. Let's assume that *every* enterprise used every last address of 172.16/12 (and, for that matter ever bit of 1918 space). That's irrelevant and still does not address my question. The question is whether these addresses are used BY EQUIPMENT THAT CAN'T NAT TO IDENTICAL ADDRESSES ON THE EXTERIOR INTERFACE. I am happy to accept an answer of, Yes, all 1918 address space is used by such equipment, but nobody, including you, has actually said that. one reason enterprises use 172.16/12 for stuff is because that way, when their VPNs come up with people's residents, they do not immediately conflict with the LAN at the home/coffee shop, etc. realistically a sufficiently large enterprise uses all of rfc 1918 in one form or another... But (also realistically) a sufficiently large enterprise that uses all of RFC1918 is not going to be sitting behind a CGN... W you're counting on to some extent the more specific route associated with the subnet leaving the covering vpn route unclobbered. sometimes however heroic work-arounds are required. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IETF] Re: Consensus Call: draft-weil-shared-transition-space-request
On Nov 30, 2011, at 1:40 AM, Bob Hinden wrote: On Nov 29, 2011, at 10:16 PM, Christian Huitema huit...@microsoft.com wrote: I did share what I was smoking - it's called 'reality' :). Which reality? I think Randy is much more realistic! +1 +lots. You are telling us that you want a /10 of private address space set aside because you cannot use the current allocation of private address space in RFC 1918. You tell us that the effect you want to achieve cannot be attained if the address that you use are also used by customer networks. But then, there is no mechanism whatsoever that would prevent customer networks from using the new /10 as soon as it would be allocated. Sure, you may put text in a RFC somewhere, but that is not a mechanism. Ergo, if we were to make that allocation, it will become unusable for your stated purpose in a very short time. I think that's not a very good idea. I would rather not see that allocation being made. That is my view as well. I think this is a bad idea for the reasons stated. sob I was *really* trying to stay out of this (both because I made my position clear at the beginning of this effort, and because it has turned into a political pissing match). While Ron had made it clear that this was not intended to be another last call, it seems to have morphed into one, so... I too believe that this is a bad idea for the reasons already stated (and restated, and then restated again and then discussed and restated and then churned around and restated...). W Bob ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IETF] Re: Plagued by PPTX again
On Nov 15, 2011, at 5:55 PM, Ray Bellis wrote: On 15 Nov 2011, at 16:26, Bob Hinden wrote: +1 The Datatracker does officially support PPTX, so I don't believe it's unreasonable to use it. If you don't like that policy, I'm not sure where you would take that up. It also hadn't occurred to me that people might actually prefer PPT over the more open PPTX format. I've also noticed that you can get problems when exporting to PDF using Office for Mac 2008. It mangles ligatures when you copypaste the PDF contents into something else. Yes… This part is REALLY annoying… Wanting to be a good jabber scribe, I try insert the slide titles into the jabber room so that folk can follow along at home…. Cutting and pasting from PDFs exported by Office (including on Windows) gives me things like: Algorithm*MigraFon*Documents* Sure, I can type / retype the slide tutles, but I tpye raelly pooorly... W Ray ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IETF] Re: watersprings.org archive of expired Internet Drafts
On Oct 7, 2011, at 5:36 AM, t.petch daedu...@btconnect.com wrote: I had been waiting a while for a quiet moment on the list to express my regret at the passing of Watersprings - R.I.P. Well, you will probably be glad to hear that it is in the process of being resurrected. It was down to save power after the tragic tsunami in Japan. Noritoshi is updating scripts to run under Linux, so it is not fully up / up to date... W Apart from I-D announcements that made to a WG list I track, then watersprings was my primary source for all I-D, simply because the web site was so good, probably as close to perfection as I will ever see. No thousands of .gif to spend ages downloading, no Megabytes of XML that take half an hour to process, no https that locks up the workstation more often than not, no need for a user manual to explain how to do what; just a simple, self-evident interface, as simple as it could be but no simpler (a paragon of engineering design) taking me to exactly what I needed, almost every time (no irtf, but I learnt to live with that). watersprings, you are sorely missed. Tom Petch - Original Message - From: Dan Wing dw...@cisco.com To: 'Tony Finch' d...@dotat.at; ietf@ietf.org Sent: Friday, September 30, 2011 6:58 PM Subject: [IETF] RE: watersprings.org archive of expired Internet Drafts -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Tony Finch Sent: Friday, September 30, 2011 7:34 AM To: ietf@ietf.org Subject: watersprings.org archive of expired Internet Drafts I have been using the watersprings.org archive of internet drafts http://www.watersprings.org/pub/id/ to obtain copies of drafts that are no longer available from http://www.ietf.org/internet-drafts/ However the domain watersprings.org has disappeared. Does anyone know what has happened to it and/or if it is likely to come back, or if there are alternative archives elsewhere? http://tools.ietf.org/html/DRAFTNAME works very well, and has everything near as I can tell. It also does partial matches on DRAFTNAME, so you can do http://tools.ietf.org/id/draft-*behave* to see everything with behave in the name. The HTML-ized version shows the history, provides clickable diff's, shows if it turned into an RFC, clickable Errata, Obsoleted By:, and so on. -d ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IETF] Re: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
While it is not perfect, I too support publication... W On Oct 5, 2011, at 7:11 PM, David Sinicrope wrote: I concur with Dave's comment and support publication of the draft. Dave On Oct 5, 2011, at 7:06 PM, David Allan I david.i.al...@ericsson.com wrote: I think it is unfortunate that we are in a situation where such a document has utility. But ultimately it does. Therefore I support the publication of draft-sprecher... D MPLS Working Group, Please be aware of the IETF last call as shown below. The document was presented for publication as an individual RFC with IETF consensus and AD sponsorship. This draft is clearly close and relevant to the work you do, but after discussing with the chairs I came to the conclusion that it does not comment on the technical or process decisions of the MPLS working groups, and it does not attempt to make any technical evaluations or definitions within the scope of the MPLS working group. It is more of a philosophical analysis of the way the IETF approaches the two solutions problem with special reference to MPLS-TP OAM. Thus, I am accepting the document as AD Sponsored rather than running it through the MPLS working group. My reasoning is that the working group has got plenty to do working on technical issues without being diverted into wider IETF philosophy. As an AD Sponsored I-D it is subject to a four week IETF last call. That is plenty of opportunity for everyone to comment and express their views. Please send your comments to the IETF mailing list as described below, or (in exceptional circumstances) direct to the IESG. Thanks, Adrian ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IETF] Re: Another reason not to return :-)
On Oct 2, 2011, at 9:07 AM, Ole Jacobsen wrote: On Sun, 2 Oct 2011, Huub van Helvoort wrote: Hej Ole, Do you mean that the majority of IETF is cannabis user? In that case the IETF should cancel the Taipe meeting because cannabis is a schedule 2 narcotic in the ROC, and possession can result in up to 3 years imprisonment. BR, Huub. Well, no, obviously not (there is a smiley), I dunno... Some of the working groups I have sat in on would make me wonder... :-P W but your note is another good reminder to check local laws and regulations. Of more pressing interest to IETFers (while I have your attention) might be that the host pages have recently been updated to include cellphone and cell data information, see: http://ietf82.tw/info.html ... and note that http://g.co/maps/8bbd lists a number of points of interest including hotels, metro stations and shops of various kinds. Ole ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IETF] RE: possibly entertaining statistics
On Sep 7, 2011, at 6:42 PM, Thomson, Martin wrote: On 2011-09-07 at 20:13:34, Jari Arkko wrote: RFC publication speed (time from draft-smith-00 to RFC, measured in millibits/s): http://www.arkko.com/tools/lifecycle/sizematters.html This isn't particularly empirical, but it would seem that of the faster drafts, having the three characters 'bis' in the title helps. Ah! As a firm believer in cargo cult practices I am now going to include the string -bis- somewhere in the title of all new drafts… :-P W ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IETF] Re: Hyatt Taipei cancellation policy?
On Aug 24, 2011, at 5:28 PM, Thomas Narten wrote: Geoff Mulligan geoff.i...@mulligan.com writes: Maybe the majority doesn't care one way or the other - they will just go wherever the meetings are held in which case: let's make them easy to get to cheap decent food one roof (with other hotels near-by) cheap and easy to get to Having watched this debate play out in multiple venues (ICANN goes all around the world 3x a year as well) over multiple years, I've come to the following main conclusion: 1) you can't please all the people all the time, and there will be griping no matter what we do. We've got 1200 attendees. That's a lot of folk who have differing ideas of what is important. +lots And the folk who are happy with the status quo / apathetic / just glad that they don't have to choose locations are likely to be silent, so the tone of the conversation is very negative. I probably fall into the apathetic / glad it's not me category -- I care about: 1: Being able to meet and get work done. 2: Having a hotel really close / attached to the venue (so I can drop my bag off between sessions and dinner). 3: Having sort of food somewhere nearby. I view the meeting as work time, not vacation time -- if we meet in a resort in the Alps or a hotel in New Jersey, it's all the same to me (and, I suspect, to many) and so I haven't been very vocal on this thread... 2) There is no perfect solution. There are too many variables, not all of which are known in advance. And, everyone weighs various factors differently. Convenience of travel, for instance, is very different for US-based folk vs. Chinese and Australians. 3) The absolutely most important thing to get right is a meeting venue that works for getting work done. In my mind, the really key things here are: a) everyone can (easily) walk to the meeting site (this facilitates mingling, including at the bar) b) there is ample local food within walking distance (again for mingling/meetings) c) proper facilities (adequate meeting room, wireless, range of room rate options, and yes, I suppose cookies, etc.) If you get the above right, the other inconveniences don't matter (except maybe visa hassles). Or more precisely, folk can (and just should) deal with it. 100% agree. Seriously, taking one extra plane hop (or gasp! riding a train!) is just noise, when talking about a meeting that lasts 5+ solid days. I'd much rather take an extra hop to get to a meeting venue that works well, then save a few hours travel time to reach a venue that doesn't have places to eat. Etc. Hub cities are no panacea. I too like Minneapolis. As a venue, it meets the key IETF needs as better than most places we've visited. It has good airline connectivity (not perfect, but good). It meets the key criteria above. You can also walk everywhere underground in the winter, so the argument that it's too cold seems specious. Etc. But does everyone like Minneapolis? Apparently not. I'm told that the IAOC has stopped going there because they were getting too many complaints. People do get tired of going to the same places, even if a location works. I've concluded that going to new places is better than hubs. Even though I rarely take vacation in conjunction with meetings, getting 1/2 a day to sight see or even being able to walk into town for dinner in a new location is a positive thing over being at the same places too often. And I've concluded that the IAOC have a crappy job to do and that folk like to kvetch. If they found a private Caribbean island with free flights and a 5 star resort for $10USD per night, *someone* would complain that the sand was too hot and the falling coconuts were a hazard... W Thomas ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IETF] Re: Experiment for different schedule for Friday
On Aug 22, 2011, at 7:28 PM, Randall Gellens wrote: At 5:24 PM -0400 8/22/11, IETF Chair wrote: The IESG is considering a different schedule for the Friday of IETF 82. The IESG is seeking your input on these potential changes. The IESG would like to try a schedule experiment on Friday, using this schedule: 9:00 AM - 11:00 AM - Session I 11:00 AM - 11:20 AM - Room Change and Cookie Break 11:20 AM - 12:20 PM - Session II 12:10 PM - 12:30 PM - Room Change Break 12:30 PM - 13:30 PM - Session III I'd suggest shortening the first session and eliminating the cookie break, so: 9:00 AM - 10:30 AM: Session I 10:30 AM - 10:40 AM: room change 10:40 AM - 11:40 AM: Session II 11:40 AM - 11:50 AM: room change 11:50 AM - 12:50 PM: Session III I don't think 20 minutes is sufficient for a cookie break and room change, and think we can go without in order to be done sooner. However, if people really want cookies, perhaps they could be in the meeting rooms during Session II instead of centrally? Or perhaps they could plan ahead a little and grab a cookie or two (and some coffee) before the meeting…. W -- Randall Gellens Opinions are personal;facts are suspect;I speak for myself only -- Randomly selected tag: --- If you can't annoy somebody there's little point in writing --Kingsley Amis ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: subject_prefix on IETF Discuss?
On Aug 3, 2011, at 7:21 PM, Richard Kulawiec wrote: -1. This list complies with RFC 2919, which alleviates the need for the horrible, unscalable, obsolete, ugly kludge of Subject-line tags. I suggest that anyone who really, *really* wants them on their copies of messages arrange to have them added locally (perhaps by procmail or similar) and not force them on those of us who have chosen mail processing software that correctly uses List-Id. Still a little confused how this morphed into a religious war on RFC 2919 / List-Id. I *did* mention in the original post that I had been using List-Id to organize mail -- which would lead to folders with a few thousands of unread mails, which I would then unceremoniously dump, because it was just too much to deal with.. Subject-line tags allow me to just drop everything in the inbox and then, at a glance figure out what to read, and in what order. I then move the read stuff (and that that I don't care about) into separate mailboxes. For those who want to do the same (regardless of whether your religious views), this little bit of procmail woks for me, ymmv: # Add an [IETF] to messages to the IETF list. :0 fw * ^List-Id:[ ].*\ietf\.ietf\.org\ |/bin/sed -e 's/^Subject:[ ]*/Subject: [IETF] /' ---rsk ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
subject_prefix on IETF Discuss?
Hi all, I seem to remember discussions about this a long time ago, but searching through archives gets no love... How do folk feel about having asking for subject_prefix to be set on the IETF Discussion List (AKA this one!) - this will prefix mail sent to this list with something like [Discussion] or [IETF] or something [0]. Background: I used to just filter this list into a mailbox / folder (based upon List-Id:), but then I would forget to read it, so I have removed that procmail rule. Having a prefix would make it easier to tell at a glance what list the mail is associated with, what it might be about, etc. Yes, I *could* just make a procmail rule to munge the subject myself, but that seems icky, and solving it for the general case (and making Discussions more like the other IETF lists feels better). W [0]: Let the bike-shedding on actual prefix used begin... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Why the IESG needs to review everything...
[ Top posting - meta comment ] Every now and then I get a bee in my bonnet and decide to carefully review each and every draft in LC. I hate to break it to y'all, but many drafts really poorly written, and, even if you have very broad interests, many of them are going to be really boring to you… While not all ADs read all drafts, most read a large fraction of them (and read them carefully and thoughtfully enough to catch a number of large issues (and nits) *that were not caught in LC*) -- I think that they deserve recognition for performing a valuable and un-fun function... Climbing off soapbox, W On Jul 27, 2011, at 6:12 PM, Brian E Carpenter wrote: Responding to Glen Zorn's question in plenary: Firstly, not all ADs review all drafts - that's why you will see numerous no objection or missing ballot responses. Secondly, the drafts are de facto reviewed by review teams these days (gen-art, security area, etc.). This serves to alert the ADs if a draft really needs careful review. The workload is more reasonable than it used to be. Thirdly, when I was in the IESG, I was surprised quite often by *glaring* errors that had not been picked up before. Somebody has to be responsible for catching these, and today it's the IESG. Fourthly, because of the exact same discussion that Glen raised in plenary, the IESG defined and published its criteria for DISCUSS several years ago. Sometimes there are inappropriate DISCUSSes and those need to be pointed out when they happen. I hear the IESG members responding exactly right to this question. -- Regards Brian Carpenter ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-v6ops-6to4-to-historic (yet again)
Support, A+++, would by from again, etc. On Jul 26, 2011, at 7:54 PM, Randy Bush wrote: i do not care what the draft is called. i do not care whether it is info, experimental, or an IEN i do care that is says 6to4 MUST be off by default Arguing about the label feels like rearranging deckchairs, but if having tidy deckchairs is what's needed get 6to4 off by default, so be it… W randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Operations Directorate Review of draft-ietf-soc-overload-design
I reviewed the document draft-ietf-soc-overload-design in general and for its operational impact. Do not be alarmed -- Operations directorate reviews are solicited primarily to help the Area Directors improve their efficiency, particularly when preparing for IESG telechats, and allowing them to focus on documents requiring their attention and spend less time on the trouble-free ones. Improving the documents is important, but clearly a secondary purpose. A third purpose is to broaden the OpsDir reviewers' exposure to work going on in other parts of the IETF. Reviews from OpsDir members do not in and of themselves cause the IESG to raise issue with a document. The reviews may, however, convince individual IESG members to raise concern over a particular document requiring further discussion. The reviews, particularly those conducted in last call and earlier, may also help the document editors improve their documents. -- Review Summary: Intended status: Informational This document discusses models and design considerations for a SIP overload control mechanism. As such it doesn't document in much detail exactly how the mechanisms will be implemented, and so many of the standard Ops Directorate questions are not hugely relevant. Is the document readable? Yes. Is the document class appropriate? Yes. Is the problem well stated? Yes. Are there nits? No: No issues found here. Summary: 0 errors (**), 0 warnings (==), 1 comment (--). (comment is because of date!) Is the problem really a problem? Yes. (Taken as a given that devices can become overloaded, solving this is necessary). Does the document consider existing solutions? Yes (I am not a SIP geek and there may be other solutions that were not discussed). Does the solution break existing technology? No -- well, not to the best of my knowledge. SIP is Dark Magic to me, and I don't know many of the existing technologies, but it all sounds benign! Does the solution preclude future activity? No. Is the solution sufficiently configurable? Yes. Can performance be measured? How? Yes -- integral to the design of the system is monitoring for overload. The document could possibly have better explained that this information should be exposed for monitoring purposes, but the other docs are probably a better place for this. Does the solution scale well? Dealing with overload is very much required for scaling (basically the point of the doc!). Is Security Management discussed? Yes, very well -- the Security Considerations is long, clear and well thought out By dealing with / responding to overload, DoS situation can be avoided. More specific information will be discussed in documents specific to the overload feedback mechanisms. -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
