Re: ORCID - unique identifiers for contributors
On Sep 17, 2013, at 6:36 PM, Steve Crocker st...@shinkuro.com wrote: I'm in agreement. We have not had any standards so far regarding maintenance of the validity of contact information. For example, my contact information for the April 1, 1995 RFC 1776 is: Steve Crocker CyberCash, Inc. 2086 Hunters Crest Way Vienna, VA 22181 Phone: +1 703 620 1222 EMail: croc...@cybercash.com The email address, phone number and postal address became stale a long time ago. If ORCID is 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. Best regards Michael introduced, it's likely to be at least as good as email addresses, etc. Let's avoid or at least defer trying to endow them with additional properties such as permanence until there is some experience. Steve On Sep 17, 2013, at 12:16 PM, John C Klensin john-i...@jck.com wrote: --On Tuesday, September 17, 2013 11:20 -0400 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. 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. The more I think about it, the more I think that Andy or someone else who understands ORCIDs and the relevant organizations, etc., should be working on a URN embedding of the things. Since we already have provisions for URIs in contact information, an ORCID namespace would permit the above without additional tooling or special RFC Editor decision making. It would also avoid entanglement with and controversies about the rather long RFC Editor [re]tooling queue. Doing the write-up would require a bit of effort but, in principle, URN:ORICD: is pretty close to trivially obvious. Comments about dogfood-eating and not inventing new mechanisms when we have existing ones might be inserted by reference here. An interesting second (or third) conversation might be about how I could insert ORCIDs into the meta-data for already published documents. With a URN embedding that question would turn into the much more general one about how URIs in contact metadata could be retroactively inserted and updated. In some ways, that is actually an easier question. best, john
Re: ORCID - unique identifiers for contributors
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. The email address associated with the draft, for example draft-kutscher-icnrg-netinf-pr...@tools.ietf.org, apparently stays with the RFC. If you go to tracker for any RFC you can click email authors. I don't think there's a way to update the authors' current addresses. ... and that is my point. One level of indirection might be useful here. I would prefer to update only one mapping and not go through a list of RFCs and change the mapping for each document. Best regards Michael
Re: ORCID - unique identifiers for contributors
On Sep 17, 2013, at 8:19 PM, Melinda Shore melinda.sh...@gmail.com wrote: On 9/17/13 9:55 AM, Michael Tuexen wrote: ... and that is my point. One level of indirection might be useful here. I would prefer to update only one mapping and not go through a list of RFCs and change the mapping for each document. I really think that you all are completely over-engineering this. But that's what I think. What I *know* is that you're Really? Each RFC lists the addresses of the authors. My understanding is that this information might be used to contact the authors in case of questions, errata, ... At least this happened in the past. For example http://www.ietf.org/rfc/rfc3237.txt has 7 authors. I know that at least 4 affiliations have changed and at least you can't reach me anymore via the given e-mail address or telephone number. Best regards Michael looking at this from the perspective of IETF contributors. Librarians have a problem, too, and the ORCID stuff primarily addresses that problem, not ours. There's been a long history of difficulty in name usage on documents and that's confounded librarians, who for some reason (- sarcasm) feel the need to be able to group works by the same author. This has been dealt with through authority control mechanisms, where the cataloger tries to ascertain if a given Scott Smith is the same person as one of the many other Scott Smiths already in the catalog, and if not, creates a new authority record. Discrimination is encoded in the authority records in the form of middle names/initials, dates of birth and death, etc. Again, this is something the *cataloger* does, and it's actually rather difficult. So, in a cataloging record the contents of the author field are normalized under authority control and the author name as it appears on the title page is carried in the body of the cataloging record, and not indexed. There's a quite good discussion of this here: http://kcoyle.blogspot.com/2007/09/name-authority-control-aka-name.html What ORCID does is allow the author to help catalogers out by providing a unifying identifier. It's not intended to be authenticative or provide identity information - it just helps group documents (which is why I think it belongs in a separate piece of metadata). I don't think this is a huge deal and i don't think it requires community consensus. I imagine most IETF authors, who for the most part are not academics, will bother with it, and that's just fine. Melinda
Re: ORCID - unique identifiers for contributors
On Sep 17, 2013, at 9:24 PM, Melinda Shore melinda.sh...@gmail.com wrote: On 9/17/13 11:14 AM, Michael Tuexen wrote: For example http://www.ietf.org/rfc/rfc3237.txt has 7 authors. I know that at least 4 affiliations have changed and at least you can't reach me anymore via the given e-mail address or telephone number. This is not the problem ORCID addresses, except indirectly. It's a way to establish that the author Melinda Shore who worked at Cisco is the same author Melinda Shore who worked at the Center for Research Libraries. It is NOT a contact mechanism, a personal tracking mechanism, etc. Agreed. Maybe the wrong thread... I replied to a statement that the authors e-mail addresses went stale... Best regards Michael Melinda
Re: Experience with Online Protocol Testing
On Jun 28, 2013, at 6:54 PM, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 [I posted this question a little while ago to the WG chairs mailing list and got no response. Maybe my question is too trivial but I thought I should try it on the ietf@ietf.org list as well to get some feedback.] Hi all, when concerns about the lack of interoperability surfaced mid last year in the OAuth working group we (Derek, and myself) tried to figure out whether we should schedule a face-to-face interop and/or to develop an online test suite. We got in touch with Lucy Lynch (ISOC) and she helped us to find developers to work with us on the test software. Roland Hedberg, one of the guys working on the project for OAuth testing, presented his ongoing work in the OAuth working group, see http://www.ietf.org/proceedings/86/slides/slides-86-oauth-2.pdf OAuth is a bit more complex since it involves more than two parties and we were looking for a test framework that could be re-used to develop the desired results more quickly. To our surprise we couldn't find a test framework that we could easily re-use since most test frameworks really focus on different types of tests. Of course, we might have looked in the wrong direction. Here is how it works at the moment: * Imagine you have developed an OAuth-based identity management server (that contains an OAuth 2.0 authorization server) and it runs somewhere on the Internet (or in your lab). You don't need to have access to the source code to execute the tests. * You download the scripts that Roland Co had developed and configure them. Of course you will have to create an account at your IdP as well. * You run the test scripts against the authorization server and the script plays the other OAuth 2.0 parties in the exchange. The script contains a number of test cases (around 60+ at the moment) and determines whether the IdP responds correctly in the exchanges. I know that these ideas have come up in other working groups in the past already (such as in SCIM, which also has a test server up and running). It would be interesting to hear what others have been doing and what worked for you or what didn't. So it sounds like you are doing some sort of conformance testing... For SCTP we did a number of interoperability tests, which were face to face meetings and the people who were developing stacks we there. This events were always very helpful not only for improving the stacks but also for improving the IETF documents. I also developed a test tool for conformance testing based on some test descriptions provided by ETSI. However, it would have made sense to specify also some tests within the IETF. That can also help to clarify some protocol aspects and to focus on common mistakes. Providing tests is a very good thing in my experience. Unfortunately, at the point we did this for SCTP, the IETF position was that testing isn't an objective. Maybe it is time to change that... Best regards Michael Ciao Hannes -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJRzb+vAAoJEGhJURNOOiAtZBwIAISKHjD7gv8irkL4yaBR31K8 KLZCr/1n0n1OcXl3rE9MFOyA85hYNplZFd1giJLLgEX3UyofYXg/L2QOOLqtP0lT JgnW2CvR0WWKfIT1iKjAwAodCVLsHF8MdPE4tl0LBlCeqhA1waj/oCLkBzZrrhhq oWnZzP0I9nFdlSxV9EAHQ62RAxLUVQmBEqgMxl7A+iC9fGD8IhWSNSqqsaF0WOaB 6bHdwCFLYYAyqKhiuJAo/f6YFGEzIbPgpHPGjwBZzBIjwP/EGiFnAliyF8WATHzF RM+OWg6QASh1cNwzc0dbMcrcr1L1ve7amATMc4uPN7sRjhv0s62iguWfGRhQhHw= =YT5M -END PGP SIGNATURE-
Re: Experience with Online Protocol Testing
On Jun 28, 2013, at 7:14 PM, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 For SCTP we did a number of interoperability tests, which were face to face meetings and the people who were developing stacks we there. This events were always very helpful not only for improving the stacks but also for improving the IETF documents. I also developed a test tool for conformance testing based on some test descriptions provided by ETSI. However, it would have made sense to specify also some tests within the IETF. That can also help to clarify some protocol aspects and to focus on common mistakes. Providing tests is a very good thing in my experience. Unfortunately, at the point we did this for SCTP, the IETF position was that testing isn't an objective. Maybe it is time to change that... Best regards Michael I guess the code you wrote for your online test cases was your own work and you didn't re-use some else's test framework? Not a test framework, but a scheme interpreter (guile) was extended with the necessary stuff for sending/receiving packets, such that tests can be implemented as simple scheme functions. Doing a test is calling a scheme function which returns whether the corresponding test was passed or failed. Some shell scripts allows you running a test suite. The SCTP case is also a bit simpler than the OAuth scenario since in SCTP might have only tested client-server interactions (right?) Well, the testtool only deals with network layer events. Taking interactions with the application (API) into account is a different story. We also have an API tester, which is also self written. We currently don't have something which takes network and API events into account. Best regards Michael Ciao Hannes -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJRzcSCAAoJEGhJURNOOiAt064H/3iowM2lBBunk58jOq1/eAfK Cy+y+dpEqJoXeqMI7RLtTsXXDbblxI83cxO6OXol7HU37elmomdiD7qGg2KPeeOJ 1GyEWnXXJ1oaC9AcWAkPiRan2EhdXGxu6yWG1iuHniOSkC3WvU9nhVU8PLUkSPwB WSzh4hsj6tnTpR67oYoHkDwtQsFuvcvxiYkNV9rI3fy+FIXJ5ygf9UPmgVJpNqIx azmc8W9iWUUeGGnaU+/2APRybe8PpCZf6y+QKVFA/6Zkai86/HfTaDFdAnL/eOXV xhdXjHsn8Ci4CkCXJ7Pn2JRpIYX1y7ccMOvu8WHuvJnSQ2S091/EFHBY2w/Wydk= =vU1M -END PGP SIGNATURE-
Re: Internet Draft Final Submission Cut-Off Today
On Feb 26, 2013, at 8:01 PM, Dale R. Worley wrote: From: James Polk jmp...@cisco.com It used to be 5 PM Pacific, now it's 24:00 UTC. It's always been 2400 UTC, but with all the daylight savings time adjustments from country to country changing from year to year, I have talked to the Secretariat before (and recently), and verified this is indeed 8pm ET, at least for those in the US. Well, 2400 UTC is 8pm Eastern Daylight (i.e., summer) Time (GMT-4), but 7pm Eastern Standard Time (GMT-5). So I'd ask *when* did the Secretariat tell you that? Personally, I'd trust date -u much sooner than any random person. Even better: $ date --date='00:00 Feb 26, 2013 UTC' Mon Feb 25 19:00:00 EST 2013 $ Requires a Unix like system... Dale
Re: IETF chair's blog
On Feb 25, 2013, at 8:10 AM, Marc Petit-Huguenin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/24/2013 11:02 PM, Martin Sustrik wrote: On 25/02/13 07:56, Arturo Servin wrote: If it were to collaborate, an ietf application with open standards should be the way forward. Moreover, entities controlling these social platforms are, presumably, also participating in IETF. So, using these tools would give one party unfair advantage -- ability to promote or obscure individual discussions/threads/posts, ban users etc. Exactly. And it bothers me that we are not making much progress in having our own remote participant service and have to rely on Webex. Couldn't we use one based on RTCWeb (in the near future)? Best regards Michael - -- Marc Petit-Huguenin Email: m...@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRKw5bAAoJECnERZXWan7ESloQAIbg7xr93BwSjH8cNheN5zBg CVmoXV7ZqQdzQgZfHDjjwTBk3KSm6y99lzjyMQX3t/tqKWnqJH4jG7dVbtyGHAU8 +Q5j04tVaJ8S+fShS1SIJ5ySu+vjpTMF932++GkMWVsqklJw/hGDekH63dRdD7cK k2cQ4rcakHhx8n8rfA/JKRh+bwCN65GJH0+4E/SSf1RQmuYOhIp69lMeAJmb4t/d kT25XVkvuJlkqVfh3klZf+UwcV6sOnWaxYHsk+JA1K/dr3sAIFLAcju50AaRNgHa dchB1FvNMt373CBec5qk6qJ06qrKugq9KZsgnHxYR0YnyM6tVrcD1Mq/eHuVPlW9 SXAlqtEnVBAXoVvNdAMyccrv7i9L/HcHwrsYfUsUmOy3X/PWj1IfNRY6cqyvt6C8 p72KZTXeitg1pVKFd8PKVgmSPg1C2vO2uji7cpCqPY5JcwoVGOuEVNN4aoXkgvAT TsD5gm/uQCVI90/g/XGVeth6zGmShbXxsLHfZ4LCDdCEuc0NTOvB119tVw2kpSXT akmyi5Kl777BUz5x3WUoL4RlbeK6kpFaM7kAW7Uy3lzGnu2+IvwwJQqamhcqLQcv fngKTC2COHJo+6Wb19/Kpg6wlQG82NTBczlHlPyjeeyG3ZIVdrWs7UA/zX/E+vNc mziqVf91EVS9WzLE/nK+ =2NJB -END PGP SIGNATURE-
Re: Last Call: Modern Global Standards Paradigm
On Aug 11, 2012, at 8:10 PM, Paul Hoffman wrote: On Aug 11, 2012, at 5:05 AM, Randy Bush wrote: The IETF Chair and the IAB Chair intend to sign the Affirmation of the Modern Global Standards Paradigm, which can be found here: http://www.ietf.org/proceedings/84/slides/slides-84-iesg-opsplenary-15.pdf no brainer. Even with a brain, the document is obviously good. Please sign it. I agree. Best regards Michael --Paul Hoffman
Re: session layers, was Re: Renumbering ... Should we consider an association that spans transports?
Hi Lars, comment in-line. Best regards Michael On Sep 17, 2007, at 12:11 PM, Lars Eggert wrote: On 2007-9-17, at 12:13, ext Fred Baker wrote: Dumb question of the month. With the exception of the last claim (...can prioritize...), this could just as easily describe SCTP. What here is new? And define prioritize? For how this relates to SCTP, let me refer you to Section 6. (And yes, there are obvious similarities here to SCTP, but also RFC2140- like integrated congestion control, etc.) Prioritize meaning how a sender allocates the available path capacity for the SST bundle between connection instances. A demo that Bryan did that showed HTTP over SST dynamically adjusted priorities such that objects that were being rendered on the screen were transmitted at a higher priority, even while scrolling around a large page. The SCTP sender can handle multiple messages in different stream send queues in different ways. I call the selection function the stream scheduling function. Using different scheduling functions at the sender side you can get different fairness concepts. Message based round robin would get the fairness concept of having the same number of messages in each stream, doing a weighted fair queueing based scheduler you can share the bandwidth equally between the different streams and so on. Priorities are also simple to implement and have an analysed in http://www.cis.udel.edu/~amer/PEL/poc/pdf/sci2004-heinz-SCTP- Prioritized-Multistreaming.pdf The nice thing with the scheduling function is: it is a sender only thing. The receiver has to follow some simple rules, which almost all SCTP implementation do anyway. On Sep 17, 2007, at 2:02 AM, Lars Eggert wrote: You might be interested in Bryan Ford's SST paper from this year's SIGCOMM: Structured Streams: a New Transport Abstraction. Bryan Ford. ACM SIGCOMM 2007, August 27-31, 2007, Kyoto, Japan. http:// www.brynosaurus.com/pub/net/sst-abs.html ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Application knowledge of transport characteristics (was: Re: Domain Centric Administration)
On Jul 9, 2007, at 7:53 AM, Lars Eggert wrote: On 2007-7-5, at 19:07, ext Tom.Petch wrote: If we had a range of transports (perhaps like OSI offered), we could choose the one most suited. We don't, we only have two, so it may become a choice of one with a hack. But then that limited choice may be the reason why the Internet Protocol Suite has become the suite of choice for most:-) We have four standards-track transport protocols (UDP, TCP, DCCP and SCTP), and, FWIW, SCTP has a concept of record boundaries. Yes, has the concept of record boundaries: It transfers user messages, not bytes like TCP. But isn't the sane true for UDP and DCCP? Designers of applications and higher-layer protocols still have a tendency to ignore SCTP and DCCP and the particular features they can offer to applications. This can make applications more complex, because they need to re-invent mechanisms that a more appropriate transport protocol would have provided. Lars___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: www.ietf.org over IPv6
Result from a node in Germany: traceroute6 to www.ietf.org (2610:a0:c779:b::d1ad:35b4) from 2002:508f:ffec::217:f2ff:fec4:7979, 30 hops max, 12 byte packets 1 2002:508f:ffec::216:cbff:fec3:6b1a 0.804 ms 0.481 ms 0.432 ms 2 * 2002:5042:8003::1 70.834 ms * 3 2001:440::ffe4::2 249.506 ms 164.972 ms 162.975 ms 4 so-1-1-2.dus11.ip6.tiscali.net 164.79 ms 163.547 ms 164.418 ms 5 so-0-1-0.fra40.ip6.tiscali.net 165.011 ms 162.802 ms 162.836 ms 6 so-0-1-1.fra10.ip6.tiscali.net 162.973 ms 165.329 ms so-2-1-0.fra10.ip6.tiscali.net 162.993 ms 7 so-0-0-0.par77.ip6.tiscali.net 163.504 ms 164.756 ms 162.042 ms 8 so-4-0-0.par22.ip6.tiscali.net 164.441 ms 161.103 ms so-5-0-0.par22.ip6.tiscali.net 163.466 ms 9 so-2-0-0.was10.ip6.tiscali.net 164.578 ms 164.37 ms 164.715 ms 10 equi6ix-ash.ipv6.us.occaid.net 161.72 ms 172.445 ms 163.237 ms 11 unassigned.in6.twdx.net 172.994 ms 174.162 ms 173.657 ms 12 * * * 13 www.ietf.org 171.262 ms 172.037 ms 171.09 ms Best regards Michael On May 18, 2007, at 9:48 AM, Iljitsch van Beijnum wrote: Anyone else having problems reaching www.ietf.org over IPv6? For me, a traceroute dies in the Tiscali network, apparently around Washington. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Meeting Survey - Last Call
I tried, but got There is a problem with the page you are trying to reach and it cannot be displayed. Please try the following: Click the Refresh button, or try again later. Open the www.surveymonkey.com home page, and then look for links to the information you want. HTTP 500.100 - Internal Server Error - ASP error Internet Information Services Microsoft Support Best regards Michael On Apr 26, 2006, at 12:47 PM, Ray Pelletier wrote: All; More than 1,250 of you attended IETF 65 in Dallas and many others attended sessions remotely. Yet only 155 of you have responded to a survey intended to make future meeting experiences more successful. There are only 74 days left before IETF 66 in Montreal, only 74 days during which there may be the opportunity to effect improvements. Again, your participation is anonymous and your candor is most welcome. You can help by taking this short survey at: http://www.surveymonkey.com/s.asp?u=649182049947 At the end of the survey you will be able to see the survey results to date. I do appreciate the help. Thanks Ray Pelletier IETF Administrative Director [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
