Re: The Purpose of WG participants Review (was Re: Purpose of IESG Review)
On Fri, Apr 12, 2013 at 8:24 PM, Abdussalam Baryun abdussalambar...@gmail.com wrote: How can a memebr of staff in a company argue with the manager about the manager's decisions or performance? Only Owners/shareholders can question managers and staff. IMO, the meeting/list discussions on any issue without an I-D written is the staff talking/working. ??? Not in the country I live in or the company I work for. It is IMO the *obligation* of a professional to call his manager on wrong decisions or performance. I think you have a strange view on IETF leadership, I for one, as a chair of a WG regard myself as the *servant* of the WG rather than the *boss*. We decide based on consensus, not on hierarchy. Klaas
Re: Internet Draft Final Submission Cut-Off Today
On Feb 27, 2013, at 9:52 AM, Glen Zorn glenz...@gmail.com wrote: On 02/27/2013 03:46 PM, Stefan Winter wrote: Hi, [...] ferkakte [...] As a German, I'm now torn apart between being flattered that we've successfully exported a German word to the U.S. and being speechlessly shocked by the way spelling was b0rked in the process. I believe that it's actually Yiddish. yup: http://www.yiddishdictionaryonline.com/dictionary/display.php?action=searchtype=romword=farkakt still my bet would be that this Yiddish word has Germanic origins…. Klaas
Re: 30th Anniversary of Transition to TCP/IP
Happy slow start of 2013! Sent from my iPad On 31 dec. 2012, at 18:21, IETF Chair ch...@ietf.orgmailto:ch...@ietf.org wrote: Happy New Year. It is already 2013 in some part of the world. The ARPANET transitioned to TCP/IP on 1 January 1983. That was 30 years ago, and it was a huge milestone in the journey toward the Internet as we know it. You can see the transition plan. Like so many other historic networking documents, it is an RFC. See http://www.rfc-editor.org/rfc/rfc801.txt Happy New Year, Russ
Re: In Memoriam IETF web page
Good plan! Sent from my iPad On 21 okt. 2012, at 18:32, Dave Crocker d...@dcrocker.net wrote: Folks, A thread on the nanog list, about abha ahuja, reminds me of a suggestion I made casually to a few folk after the last IETF meeting: We should consider having a persistent IETF page in memory of people who were part of our community. While the idea is simple, the comments I got back make clear that it needs to be pursued carefully. That requires some formality. There are two different lines of consideration. These are offered as a starting point for discussion: 1. Who should be listed? A number of different models make sense, but the challenge is something that is workable. For example, it does not seem like the sort of thing that would be appropriate for a consensus call to the community, for each entry. I think that means the rules should be entirely mechanical. Conceptually, the goal should be to include anyone who was part of the IETF community. I'll suggest that any of these would qualify: a. Held a formal position in the IETF (AD, WG Chair, IAOC/Trust, IAB, IRTF, Nomcom, ...are there others?) b. Held a position on an IETF committee (directorate, advisory, ...) c. Held a position on IETF staff (IAD, RFC Editor and, I think, this should include on-going contractors, including AMS and RFC document editors. d. RFC author 2. What should be the form of the page? I suggest we keep it extremely simple: an alphabetic listing by name, with a photo, if available, and a pointer to a page if they have one. In some cases, the IETF might formulate its own page for a person, but that's distinct from this basic listing. Thoughts? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Colloquial language [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
On 5/31/12 10:58 AM, Stephen Farrell wrote: I'm with Brian and Yoav on this. I don't see a need to change here. And I do think we might lose something if we become too PC. If a bunch of non-native speakers did say yes, I found that made the document less useful then I'd be more convinced that all these changes were worth it. As a non-native speaker I agree. I think colloquial is fine. The one thing causes me some trouble is all the references that Americans make to sports that nobody in the civilized world cares about ;-) (left field, Hail Mary passes etc.) But I think the Tao pretty much avoids those (perhaps Home base is the exception). Klaas On 05/31/2012 08:47 AM, Dave Crocker wrote: On 5/31/2012 9:24 AM, Brian E Carpenter wrote: I actually have no evidence either way; that's why I suggested asking some of them;-) 1. Reliance on self-reporting for such things is methodologically problematic. It presumes a degree of self-awareness that is often missing. For example a native speaker of a language that uses noun doubling -- saying the noun twice -- to indicate plurals was quite insistent with me that that wasn't the rule. 2. To claim a lack of evidence presumes some previous effort to acquire it. However a quick search discloses: http://journals.cambridge.org/action/displayAbstract;jsessionid=054711CCAB4AFB348F7E70C9079E7305.journals?fromPage=onlineaid=2546012 Paywalled. Abstract says comprehen-sibility of the non-native's interlanguage so is a worse sinner IMO:-) http://dc.library.okstate.edu/cdm/singleitem/collection/theses/id/1031/rec/9 Drives NoScript bonkers and needs some kind of FF plug in. http://www.google.com/url?sa=trct=jq=esrc=ssource=webcd=3ved=0CF0QFjACurl=http%3A%2F%2Fscholarcommons.usf.edu%2Fcgi%2Fviewcontent.cgi%3Farticle%3D1255%26context%3Detdei=iyDHT4eBB874sgaa-rGQDwusg=AFQjCNFnYm2MzlDnknB6AzfB0Oi4tUVyVg 289 pages, so only read abstract. That's about adolescents. My experience at IETF meetings is that more native English speakers seem to behave like adolescents, but maybe that's just me:-) It does make the point that there's a (presumably positive) correlation between understanding of idiom and academic achievement, I guess the argument could also be made that the Tao should be about as difficult to read as a typical IETF mailing list. S. among others. The mere existence of these ought to make clear that there is a significant issue in the use of colloquialisms with non-native listeners. d/
Re: Gen-ART Telechat Review of draft-ietf-kitten-sasl-saml-08
Hi Ben, On Jan 13, 2012, at 11:00 PM, Ben Campbell wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-kitten-sasl-saml-08 Reviewer: Ben Campbell Review Date: 2012-01-13 IESG Telechat date: 2012-01-19 Summary: This draft is almost ready for publication as a proposed standard. There are a few minor issues that should be considered first. Note: This is incremental to my review of version 06 at last call. Version 08 is considerably improved and resolved most of my comments. But a few still remain. Quoted text below is from that previous review. Yes, should have informed you about those changes before. I was going to wait until I had also incorporated Simon's additions, but I realize that may have been confusing. Major issues: None Minor issues: -- section 3.2, last paragraph: … needs to correlate the TCP session from the SASL client with the SAML authentication. Please elaborate on this correlation The author added text, but the new text is about correlating response with request. The text I mentioned was about correlating a TCP connection to a SAML authentication. ah ok, but the intention of the text really is to talk about correlating the session that the SASL client maintains with the SASL server and the SAML session that the SAML client has with the SAML server. Would you be ok with changing the wording to that extent? So: Also, the SASL server needs to correlate the session it has with the SASL client and the SAML authentication by comparing the ID of the SAML authentication request it has issued with the one it receives in the SAML authentication statement -- section 4, 3rd and 4th paragraph (paragraph a and b) These seem like protocol affecting differences. If so, they need elaboration, such as normative statements and formal definitions, or references to such. I did not see a response to this comment. see Simon's comments -- section 5, general: The section seems to need further elaboration or references I did not see a response to this comment. idem Also, this section compresses the interaction with the identity provider. Why not show the details for those steps like the others? (If you mean them to be out of scope, then why give as much detail as you do?) I did not see a response to this comment. I want to give enough details for implementers to understand the full flow, even though those steps are out-of-scope for this specification. I thought the [ ] brackets would convey that, do you think it is clearer to leave that part out altogether? Nits/editorial comments: -- Pagination is strange throughout the document. (Mostly blank pages, etc.) It's worse in the PDF version, but still not right in the text version. Pagination is still strange. I see a few mostly blank pages, diagrams split across page breaks, etc. hmm, strange, I removed some empty lines and in my version it nicely broke on session headings, but I'll double check all generated versions next iteration. -- section 3, 1st paragraph: Recall section 5 of [RFC4422] for what needs to be described here. That reads like an author's to do note to himself. Has the needed description been completed, or does it still need to be described? Partially fixed. I suggest s/needs to be/is ok, will do -- section 3.1, first paragraph: Is authorization identifier the same as IdP-Identifier? The paragraph has been updated, but I still have the question. It is not, I will add text on that -- section 3.3, 2nd paragraph: and SHALL be used to set state in the server accordingly, and it shall be used by the server Is this new normative language, or a repeat of language from the SAML spec? The author changed SHALL to MUST, which leads me to believe my comment was not clear. I did not object to SHALL. My concern was, with the reference to RFC4422, it was not clear if the text was introduction a new normative requirement, or just restating requirements from 4422. If the second, then it's important to make sure the reader knows which doc is authoritative. You can do that by keeping the language descriptive, or by explicitly (and strongly) attributing the language with something like 'RFC4433 says, …. SHALL….' If, on the other hand, this is truly a new normative statement, then no change is needed. right, now I get it. It is indeed intended in the 4422 sense, so I will take your suggestion -- section 4, 1st paragraph: I have difficulty parsing this. The text is updated, but I still have trouble parsing it. In particular, I'm not sure what you mean by the phrase ...and appropriate references of it not referenced elsewhere in this
Re: reading drafts on an ipad
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/6/11 5:38 PM, Cullen Jennings wrote: Has anyone found a particularly good solution to reading drafts on an ipad? What about markup and notes on drafts? I use GoodReader Klaas -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4UiikACgkQH2Wy/p4XeFJkDwCgo2qFiFt6g9Ot6RX/kxvKfavg 7nEAn0HF4Ip2vixeWmffRkM7lr7xEqM3 =HvYc -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: whine, whine, whine
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/21/11 3:28 PM, Ray Bellis wrote: On 21 Jun 2011, at 14:02, Simon Perreault wrote: Not going to argue about San Diego vs Québec, but just going to point out that multiple carriers do serve Québec. Among them are Air Canada, United, Continental, Delta, and US Airways. The only European operator into YBQ appears to be Air Transat (whoever the heck they are) and they only fly from Marseille and Paris. I'm flying BA to Montreal and taking the short city hopper flight to YBQ from there. otoh, not having to go through US immigrations saves you about as much time as you would have saved with a direct flight, not to mention the terrorist until proven innocent treatment. ;-) Klaas -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4AoCYACgkQH2Wy/p4XeFIWogCfW2dn+A+anCx0NIILJ6SPAqLx J9IAn30Txe/eoIzxaF87lgf/sYKFkeG7 =zVIP -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Google Scholar, was How to pay $47 for a copy of RFC 793
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/10/11 6:14 PM, Paul Hoffman wrote: On May 10, 2011, at 8:41 AM, Harald Alvestrand wrote: For some reason, scholar has indexed 151 docs from tools.ietf.org and then stopped. If only there was someone who worked at Google on this list who could send an internal message to get this rectified :-) wasn't there this Norwegian guy that worked there? Klaas -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3JZecACgkQH2Wy/p4XeFI1qACdEGmWlx6n1aguOZAYOIRbvgSo XTEAn0Oa3+ZgBTrw/xYMakPoyzWDyXK/ =TzHv -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Abfab@IETF80
Hi, At the risk of causing my mail box to be filled with flames... I want to draw your attention to the fact that the first of the 2 Abfab sessions (Monday 1510-1610 Abfab I, Karlin I) will be dedicated to the overall architecture, example use cases and current implementation status. So if you want to find out what this Abfab stuff is about this may serve as a gentle introduction... Klaas (Abfab co-chair) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
how eduroam works (was: Re: Admission Control to the IETF 78 and IETF 79 Networks)
Hi Phillip, You can find all you want to know at the website: http://www.eduroam.org, especially the Service Definition at: http://www.eduroam.org/downloads/docs/GN2-07-327v2-DS5_1_1-_eduroam_Service_Definition.pdf you may also want to watch the cartoon at: http://www.youtube.com/watch?v=TVCmcMZS3uA In short: There is a hierarchy of RADIUS proxy-servers (institution, country, European/APAC/Americas) that form a web of (transitive) trust. This RADIUS infrastructure is used to forward EAP requests from the visited institution to the home institution of the user, the home institution of the user verifies the credentials and sends back an ACK or NAK. When the visited institution receives an ACK from the home institution the user gets access. Users connect using 802.1X with WPA2/AES Hope this helps, Klaas Wierenga Any chance of a link to specs showing how it is done? Might be something that maybe deserves to see wider use. On Sat, Jul 24, 2010 at 9:19 AM, IETF Chair ch...@ietf.org wrote: eduroam (education roaming) is the secure, world-wide roaming access service developed for the international research and education community. eduroam allows students, researchers and staff from participating institutions to obtain Internet connectivity across campus and when visiting other participating institutions by simply opening their laptop. Since we expect a reasonable attendance at IETF from eduroam-connected sites, IETF participants with an eduroam account configured, should get connected to the wireless network right away with their usual credentials. Enjoy, Russ On 6/30/2010 5:55 PM, IETF Chair wrote: I am writing to let you know about a change in the IETF meeting network. At IETF 79 in Beijing, the IETF network will be connected to the open Internet with absolutely no filtering. However, we have agreed with our hosts that only IETF meeting participants will have access to the network. Following sound engineering practices, we will deploy admission control mechanisms as part of the IETF 78 meeting network in Maastricht to ensure that they are working properly before they are mission critical. I am writing to let you know what to expect in both Maastricht and Beijing. ADMISSION CONTROL CREDENTIALS To gain access to the IETF network, you will need to provide a credential. Your primary credential will be your registration ID. You can find your registration ID on the registration web page, in the response email confirmation you received from the Secretariat, on your payment receipt, and on the back of your IETF meeting badge. Your Registration ID will be your user name, and it will be used with a password that will be provided at a later date. This same password will be used by all attendees. We recognize that IETF 78 registration IDs are very easy to guess. We expect to use less easily guessed registration IDs for IETF 79. If for any reason you are uncomfortable using your Registration ID, there will be a supply of completely anonymous Registration ID/Password pairs on slips of paper available at the help desk and registration desk. You will be asked to show an IETF meeting badge to ensure that slips are only provided to registered meeting attendees. Each set of credentials will allow up to three separate MAC addresses on the network, allowing attendees to use the same credential for their laptop, phone, or other devices. The limit is to prevent the leak of a single credential from undermining the entire system. GAINING ACCESS TO THE NETWORK The primary mechanism to gain access to the wireless network will be either the ietf.1x or ietf-a.1x SSID. These will be configured with WPA1 and WPA2 Enterprise. You simply provide your credentials to your supplicant software for authentication to the network. I personally encourage you to use WPA2 over WPA1 if your software and hardware support both. If your software does not support WPA Enterprise, you can use the captive portal. To use this portal, associate with either the ietf-portal or ietf-a-portal SSID. Upon initial connection, Internet connectivity will be blocked. Simply open a browser and go to any web site, just like many hotel networks, and you will be redirected to a portal page where you can enter your credentials. Once the credentials are validated, your MAC address will have unrestricted access to the network for some period of time. The portal page will also have links to the internal wiki page with helpful information as well as a way to create trouble tickets prior to authentication. If your small devices does not support WPA Enterprise and does not have a browser, then you will be able to visit the help desk and register the device MAC address for access to the network. If you need to register your device, please know the MAC
