Re: I-D Action: draft-housley-rfc2050bis-00.txt
I think this draft is in a good state and says what needs to be said. One point is that, assuming we conclude that it should not be a BCP, this should probably be mentioned, for example in section 5. RFC 2050 contains an IESG note explaining why it was published as a BCP; it would be logical for the replacement to explain why it isn't. IMHO, it is RFC 2860 that makes BCP status inappropriate. Nit: there are numerous unused references (even RFC 2050 itself). Regards Brian Carpenter
Re: Last Call: draft-ietf-appsawg-webfinger-10.txt (WebFinger) to Proposed Standard
On Mon, Mar 04, 2013 at 12:24:24PM -0800, The IESG iesg-secret...@ietf.org wrote a message of 33 lines which said: - 'WebFinger' draft-ietf-appsawg-webfinger-10.txt as Proposed Standard This is a very important protocol (we need a standard way to get information about people and other entities, which do not rely on a central closed silo). I've read the draft carefully and I believe it is mostly OK. However, I reported two problems to the webfinger mailing list and I believe they require a new version of the I-D. One is the wrong tag for the default language (zero comments on the mailing list) and one is the lack of details on the matching of URIs (it seems there is a consensus on the mailing list to add a reference to a specific algorithm of RFC 3986). (A smaller problem is an imperfect example of language tags.)
meetecho praise
Hello. I would just like to say I'm very grateful for the WGs that used Meetecho to record their sessions. The HTML5 versions works out of the box with no plugins in Chrome both on my Ubuntu 12.04 machine and Chrome on my Windows7 machine. The sync of sound, slides, picture and jabber room is excellent and makes it very easy top follow what's going on. Some other recordings focus too much on the video of the speaker, where I'm of the opinion that it's the slides and the sound that is most important, and current incarnation of Meetecho solves this very nicely. I applaud these efforts and hope we can end up in a situation where all meetings at the IETF is recorded in this way. Thanks. -- Mikael Abrahamssonemail: swm...@swm.pp.se
RE: recognition
Perhaps there should be a gold dot for past service. Maybe a silver dot for ten years, a gold dot for twenty. (Slightly non-serious, but also slightly serious.) -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearl...@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England Wales No: 1996687 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Jari Arkko Sent: 15 March 2013 13:40 To: ietf@ietf.org list Cc: Ralph Droms (rdroms) Subject: recognition --! WARNING ! -- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. I wanted to give recognition to someone. As Ralph Droms stepped down from the IESG this week, he completed 24 continuous years of service in the leadership of the IETF, with a dot on his badge. The last four years he has been one of the INT ADs, and before that he chaired the DHC working group for 20 years (!). Thank you Ralph for everything you have done! If you see Ralph in the hallway, please stop and thank him for his service and contributions with DHCP and many, many other things. The proceedings of the first meeting of the DHC WG are here: http://www.ietf.org/proceedings/13.pdf (page 59). Jari Arkko IETF Chair This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person.
Re: meetecho praise
Hi all, I would like to join Mikael's words. I used to connect using a regular jabber client but the experience with meetecho is much better. Having audio, chat room and the slides is fantastic. I did not use the html5 version so my audio was using vlc, I had to modify our firewall rules becase the destionation port was blocked. Audio was very good (it can always be better of course). Thanks, Este mensaje ha sido enviado gracias al servicio BlackBerry de Movilnet -Original Message- From: Mikael Abrahamsson swm...@swm.pp.se Sender: ietf-boun...@ietf.org Date: Mon, 18 Mar 2013 11:04:06 To: ietf@ietf.org Subject: meetecho praise Hello. I would just like to say I'm very grateful for the WGs that used Meetecho to record their sessions. The HTML5 versions works out of the box with no plugins in Chrome both on my Ubuntu 12.04 machine and Chrome on my Windows7 machine. The sync of sound, slides, picture and jabber room is excellent and makes it very easy top follow what's going on. Some other recordings focus too much on the video of the speaker, where I'm of the opinion that it's the slides and the sound that is most important, and current incarnation of Meetecho solves this very nicely. I applaud these efforts and hope we can end up in a situation where all meetings at the IETF is recorded in this way. Thanks. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Mentoring
John, Fine plan if we can put a stop to having breakfast and lunch be the prime target for assorted management and coordination meetings. Yes. I would, however, favor conducting a lottery among, say, first-year attendees (but not first time unless they qualified by useful mailing list participation -- see my earlier comment and Spencer's response)-- and inviting the winners to sit in on IESG or IAB breakfast meeting, Not sure if that should be the winners or losers :-) Seriously though, I am roughly in the same camp as Seiichi. The real introduction of someone into the IETF is mostly about finding discussion partners around the reason why the person came to the IETF to begin with. Most of the time these would be peers within a working group. Like-minded vendors, customers or researchers. Not everyone who comes to the IETF for the first time is a beginner, they may for instance be established engineers on their fields, and just coming to the IETF to accomplish a goal. We discuss very interesting topics at the IESG and IAB, but I think the more direct way to introduce someone to the IETF network is to connect the person with others who work in the same topic. And maybe create some real co-operation between those people, building additional reasons for the person to continue to join our meetings. Anyway, this is a great thread. Plenty of ideas to consider. Sometime-later-than-Sunday sounds an interesting proposal, so do the WG breakfasts. In any case, scheduling is typically difficult with any approach we take. I also liked the beer motivator idea :-) and ideas about better ways to reach the newcomers. As an aside, from personal experience, small, targeted meetings with newcomers have tended to work better for me than otherwise. Jari
Re: Please review draft-housley-rfc2050bis-00.txt
I am wondering if the draft should mention that Local Internet Registries (LIRs) may sometimes take the form of National Internet Registries (NIRs) since this is now a reality in some places? The current text doesn't exclude such an arrangement, but given that this draft is an update to reflect current reality, it might make sense to include mention of NIRs explicitly, even if their mere existent may be considered controversial. Or is that just one can of worms you wish to leave unopened? 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
Re: Mentoring
Not answering any specific email, just establishing position: - I support a newcomers' list. However, I do believe that the definition of newcomer must be relaxed a bit. A newcomer is not a 'first time attendee'. Being a IETF youngster I would say that for the first three meetings you are a newcomer. This may vary, but if I had to draw a line somewhere, three would be my choice. - Breakfasts / lunch meetings are great, but they are not enough. These slots might need some augmentation. I don't have many ideas except dinners and parallel slots while the WGs sessions are in progress. - However tempting, I don't think ADs / WG chairs are ideal mentoring choices. During the IETF week they are drenched in work with their area directoring/ working group chairing duties and most of them won't have a lot of time for meeting newcomers and attending to their needs. - Mentors SHOULD be notified of their duties within reasonable time, and preferably be introduced to their 'pupils' via private email. I don't know how hard this would be to implement, but it would definitely help. Another thing to keep in mind: Do all newcomers want being mentored? I can think of one or two cases I know personally that probably wouldn't want a mentor. - Moving the newcomers reception to later in the week is a MUST. Mentors should obviously be also invited to this reception. Warm regards, ~Carlos On 3/14/13 9:30 AM, Adrian Farrel wrote: Mary, I need to check but... [MB] What I find interesting is that there was 200+ newcomers, but I certainly didn't find that many at the meet and greet. I have to wonder whether this doesn't have to do with the overlap between Sunday tutorials and this event. I think that needs to be fixed. Very right that it would need to be fixed, but I thought that it was avoided explicitly and deliberately. Anyone got a copy of the agenda in front of them? Maybe we could do a little research on why newcomers don't show at this meeting. Are they tired? Shy? Unaware? Not perceiving the value? Adrian
Re: Is there a Git repository of RFCs? Or of Internet-Drafts?
https://github.com/credil/ietf-drafts-sorted is the result of my draftmirror script which basically does s,-,/, in a selective way. Each author and group gets its own directory. Previously I have just run draftmirror on each of my devices, but now, I think I'll just use git pull, so I saved the world some bandwidth. https://github.com/credil/ietf-drafts is the unsorted rsync. I probably have to sort out what ssh key I use to push. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works pgp4bKX0sVf11.pgp Description: PGP signature
Re: [apps-discuss] Last Call: draft-ietf-appsawg-webfinger-10.txt (WebFinger) to Proposed Standard
Given how little control Internet users already have over which information about them appears in which context, I do not have a lot of confidence that the claimed discoverability benefits of WebFinger outweigh its potential to further degrade users' ability to keep particular information about themselves within specific silos. However, I'm coming quite late to this document, so perhaps that balancing has already been discussed, and it strikes me as unreasonable to try to stand in the way of publication at this point. Two suggestions in section 8: s/personal information/personal data/ (see http://tools.ietf.org/html/draft-iab-privacy-considerations-06#section-2.2 -- personal data is a more widely accepted term and covers a larger range of information about people) The normative prohibition against using WebFinger to publish personal data without authorization is good, but the notion of implicit authorization leaves much uncertainty about what I imagine will be a use case of interest: taking information out of a controlled context and making it more widely available. To make it obvious that this has been considered, I would suggest adding one more sentence to the end of the fourth paragraph: Publishing one's personal data within an access-controlled or otherwise limited environment on the Internet does not equate to providing implicit authorization of further publication of that data via WebFinger. Alissa On Mar 4, 2013, at 3:24 PM, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'WebFinger' draft-ietf-appsawg-webfinger-10.txt as 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 2013-03-18. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ballot/ No IPR declarations have been submitted directly on this I-D. ___ apps-discuss mailing list apps-disc...@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss
Re: meetecho praise
Hi, I want to support Mikael's comment. Meetecho worked really well, I used to connect using a regular jabber client however using Meetecho really enriches the experience, it was very nice to see the slides, to be in the jabber room, everything in the same screen. I also had audio (In a previous recording I also had video). I did not use html5 and my audio was using VLC. I got small two problems: my company's firewall blocked the output port to connect to, so I needed to create a special rule on it. Video was not available but I'm not sure because of the WG room or maybe another issue. Anyway audio was good (as usual it can always be better). Thanks, Alejandro, On 3/18/13, Mikael Abrahamsson swm...@swm.pp.se wrote: Hello. I would just like to say I'm very grateful for the WGs that used Meetecho to record their sessions. The HTML5 versions works out of the box with no plugins in Chrome both on my Ubuntu 12.04 machine and Chrome on my Windows7 machine. The sync of sound, slides, picture and jabber room is excellent and makes it very easy top follow what's going on. Some other recordings focus too much on the video of the speaker, where I'm of the opinion that it's the slides and the sound that is most important, and current incarnation of Meetecho solves this very nicely. I applaud these efforts and hope we can end up in a situation where all meetings at the IETF is recorded in this way. Thanks. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: meetecho praise
On Mon, Mar 18, 2013 at 5:04 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: Hello. I would just like to say I'm very grateful for the WGs that used Meetecho to record their sessions. The HTML5 versions works out of the box with no plugins in Chrome both on my Ubuntu 12.04 machine and Chrome on my Windows7 machine. The sync of sound, slides, picture and jabber room is excellent and makes it very easy top follow what's going on. Some other recordings focus too much on the video of the speaker, where I'm of the opinion that it's the slides and the sound that is most important, and current incarnation of Meetecho solves this very nicely. I applaud these efforts and hope we can end up in a situation where all meetings at the IETF is recorded in this way. [MB] That would be wonderful. I find Meetecho fantastic for going back and re-reviewing the meeting in cases where notes aren't complete. As a chair, it's really hard to take good notes and it's sometimes hard for participants as they are sometimes to engage in discussions. The Meetecho team works extremely hard during these meetings and definitely deserve applause for their work. [/MB] Thanks. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: meetecho praise
I agree whole heartedly as well, this was my first meeting with remote participation and the experience is definitely better compared to handling jabber / slides / voice streaming in three different applications. Bravo Meetecho team!! Dhruv On Mon, Mar 18, 2013 at 9:09 PM, Mary Barnes mary.ietf.bar...@gmail.comwrote: On Mon, Mar 18, 2013 at 5:04 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: Hello. I would just like to say I'm very grateful for the WGs that used Meetecho to record their sessions. The HTML5 versions works out of the box with no plugins in Chrome both on my Ubuntu 12.04 machine and Chrome on my Windows7 machine. The sync of sound, slides, picture and jabber room is excellent and makes it very easy top follow what's going on. Some other recordings focus too much on the video of the speaker, where I'm of the opinion that it's the slides and the sound that is most important, and current incarnation of Meetecho solves this very nicely. I applaud these efforts and hope we can end up in a situation where all meetings at the IETF is recorded in this way. [MB] That would be wonderful. I find Meetecho fantastic for going back and re-reviewing the meeting in cases where notes aren't complete. As a chair, it's really hard to take good notes and it's sometimes hard for participants as they are sometimes to engage in discussions. The Meetecho team works extremely hard during these meetings and definitely deserve applause for their work. [/MB] Thanks. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: meetecho praise
What Mary said, especially from a chair perspective. I stepped down as co-chair of three working groups just as the Meetecho team reached cruising speed, but they were very active in MediaCtrl and we benefited considerably from using an early version in Hiroshima. If I was co-chairing three working groups today, I would already have sent them my request for support in Berlin :-) Thanks, guys, for all that you do! Spencer On 3/18/2013 10:39 AM, Mary Barnes wrote: On Mon, Mar 18, 2013 at 5:04 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: Hello. I would just like to say I'm very grateful for the WGs that used Meetecho to record their sessions. The HTML5 versions works out of the box with no plugins in Chrome both on my Ubuntu 12.04 machine and Chrome on my Windows7 machine. The sync of sound, slides, picture and jabber room is excellent and makes it very easy top follow what's going on. Some other recordings focus too much on the video of the speaker, where I'm of the opinion that it's the slides and the sound that is most important, and current incarnation of Meetecho solves this very nicely. I applaud these efforts and hope we can end up in a situation where all meetings at the IETF is recorded in this way. [MB] That would be wonderful. I find Meetecho fantastic for going back and re-reviewing the meeting in cases where notes aren't complete. As a chair, it's really hard to take good notes and it's sometimes hard for participants as they are sometimes to engage in discussions. The Meetecho team works extremely hard during these meetings and definitely deserve applause for their work. [/MB] Thanks. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: meetecho praise
Hi, on behalf of the Meetecho team, let me just thank you all for your feedback and appreciation :-). We're glad you found Meetecho useful both during the meeting and for off-line access to the recorded sessions. Cheers, Simon Mary Barnes mary.ietf.bar...@gmail.com ha scritto: On Mon, Mar 18, 2013 at 5:04 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: Hello. I would just like to say I'm very grateful for the WGs that used Meetecho to record their sessions. The HTML5 versions works out of the box with no plugins in Chrome both on my Ubuntu 12.04 machine and Chrome on my Windows7 machine. The sync of sound, slides, picture and jabber room is excellent and makes it very easy top follow what's going on. Some other recordings focus too much on the video of the speaker, where I'm of the opinion that it's the slides and the sound that is most important, and current incarnation of Meetecho solves this very nicely. I applaud these efforts and hope we can end up in a situation where all meetings at the IETF is recorded in this way. [MB] That would be wonderful. I find Meetecho fantastic for going back and re-reviewing the meeting in cases where notes aren't complete. As a chair, it's really hard to take good notes and it's sometimes hard for participants as they are sometimes to engage in discussions. The Meetecho team works extremely hard during these meetings and definitely deserve applause for their work. [/MB] Thanks. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: meetecho praise
I looked at the WG's agendas of some meetings that I missed and none have a link to the meetecho's recording (they have the audio and jabber), which was odd to me (or I had very bad luck to miss the only non-meetcho meetings.) Then I found the recordings at: http://www.ietf.org/meeting/86/remote-participation.html#Meetecho I would suggest to add these links to the agenda's WG pages. Thanks! as On 3/18/13 1:09 PM, Simon Pietro Romano wrote: Hi, on behalf of the Meetecho team, let me just thank you all for your feedback and appreciation :-). We're glad you found Meetecho useful both during the meeting and for off-line access to the recorded sessions. Cheers, Simon Mary Barnes mary.ietf.bar...@gmail.com ha scritto: On Mon, Mar 18, 2013 at 5:04 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: Hello. I would just like to say I'm very grateful for the WGs that used Meetecho to record their sessions. The HTML5 versions works out of the box with no plugins in Chrome both on my Ubuntu 12.04 machine and Chrome on my Windows7 machine. The sync of sound, slides, picture and jabber room is excellent and makes it very easy top follow what's going on. Some other recordings focus too much on the video of the speaker, where I'm of the opinion that it's the slides and the sound that is most important, and current incarnation of Meetecho solves this very nicely. I applaud these efforts and hope we can end up in a si! tuation where all meetings at the IETF is recorded in this way. [MB] That would be wonderful. I find Meetecho fantastic for going back and re-reviewing the meeting in cases where notes aren't complete. As a chair, it's really hard to take good notes and it's sometimes hard for participants as they are sometimes to engage in discussions. The Meetecho team works extremely hard during these meetings and definitely deserve applause for their work. [/MB] Thanks. -- Mikael Abrahamsson email: swm...@swm.pp.se
Re: Please review draft-housley-rfc2050bis-00.txt
On 3/18/13 6:04 AM, Ole Jacobsen wrote: I am wondering if the draft should mention that Local Internet Registries (LIRs) may sometimes take the form of National Internet Registries (NIRs) since this is now a reality in some places? All of the NIRs I've encountered can be construed as LIRs under the terms of the definition of LIR in that region. apnic and lacnic I belive specifically recognize the term. The current text doesn't exclude such an arrangement, but given that this draft is an update to reflect current reality, it might make sense to include mention of NIRs explicitly, even if their mere existent may be considered controversial. Or is that just one can of worms you wish to leave unopened? 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
Re: meetecho praise
I've added the links to my WG meeting minutes. I think that's a better place to store these, although, unfortunately, it seems to take a long time for many to get their meeting minutes uploaded. My suggestion is for chairs to at least upload the raw minutes as drafts and include the Meetecho links. Certainly, you have to remember to finalize the minutes. But, something is much better than nothing for folks trying to work forward from the meeting. Regards, Mary CLUE and DISPATCH WG chair On Mon, Mar 18, 2013 at 11:19 AM, Arturo Servin arturo.ser...@gmail.com wrote: I looked at the WG's agendas of some meetings that I missed and none have a link to the meetecho's recording (they have the audio and jabber), which was odd to me (or I had very bad luck to miss the only non-meetcho meetings.) Then I found the recordings at: http://www.ietf.org/meeting/86/remote-participation.html#Meetecho I would suggest to add these links to the agenda's WG pages. Thanks! as On 3/18/13 1:09 PM, Simon Pietro Romano wrote: Hi, on behalf of the Meetecho team, let me just thank you all for your feedback and appreciation :-). We're glad you found Meetecho useful both during the meeting and for off-line access to the recorded sessions. Cheers, Simon Mary Barnes mary.ietf.bar...@gmail.com ha scritto: On Mon, Mar 18, 2013 at 5:04 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: Hello. I would just like to say I'm very grateful for the WGs that used Meetecho to record their sessions. The HTML5 versions works out of the box with no plugins in Chrome both on my Ubuntu 12.04 machine and Chrome on my Windows7 machine. The sync of sound, slides, picture and jabber room is excellent and makes it very easy top follow what's going on. Some other recordings focus too much on the video of the speaker, where I'm of the opinion that it's the slides and the sound that is most important, and current incarnation of Meetecho solves this very nicely. I applaud these efforts and hope we can end up in a si! tuation where all meetings at the IETF is recorded in this way. [MB] That would be wonderful. I find Meetecho fantastic for going back and re-reviewing the meeting in cases where notes aren't complete. As a chair, it's really hard to take good notes and it's sometimes hard for participants as they are sometimes to engage in discussions. The Meetecho team works extremely hard during these meetings and definitely deserve applause for their work. [/MB] Thanks. -- Mikael Abrahamsson email: swm...@swm.pp.se
raw meeting minutes (Re: meetecho praise)
On 3/18/2013 9:28 AM, Mary Barnes wrote: it seems to take a long time for many to get their meeting minutes uploaded. My suggestion is for chairs to at least upload the raw minutes as drafts If minutes takers used etherpad, the raw minutes would be available in real-time, rather than requiring everyone to wait for the polished version. It would also allow some crows-sourcing of corrections and additions to the raw minutes... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: raw meeting minutes (Re: meetecho praise)
Etherpad is an awesome tool and we've found out to be hugely useful over a number of IETFs, but be forewarned that on a couple of rare occasions the notes have disappeared. In the first case, it took a manual step for it to be restored. In the second we had a private copy... Lou On March 18, 2013 12:35:49 PM Dave Crocker d...@dcrocker.net wrote: On 3/18/2013 9:28 AM, Mary Barnes wrote: it seems to take a long time for many to get their meeting minutes uploaded. My suggestion is for chairs to at least upload the raw minutes as drafts If minutes takers used etherpad, the raw minutes would be available in real-time, rather than requiring everyone to wait for the polished version. It would also allow some crows-sourcing of corrections and additions to the raw minutes... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: raw meeting minutes (Re: meetecho praise)
Hi, Just my two cents: The very few times I've been minute taker it worked very well. Probably the problem might be when there is more than one minute taker using Etherpad at the same time. Alejandro, Este mensaje ha sido enviado gracias al servicio BlackBerry de Movilnet -Original Message- From: Lou Berger lber...@labn.net Sender: ietf-boun...@ietf.org Date: Mon, 18 Mar 2013 13:00:31 To: dcroc...@bbiw.net; Mary Barnesmary.ietf.bar...@gmail.com; Dave Crockerd...@dcrocker.net Cc: IETF-Discussion listietf@ietf.org Subject: Re: raw meeting minutes (Re: meetecho praise) Etherpad is an awesome tool and we've found out to be hugely useful over a number of IETFs, but be forewarned that on a couple of rare occasions the notes have disappeared. In the first case, it took a manual step for it to be restored. In the second we had a private copy... Lou On March 18, 2013 12:35:49 PM Dave Crocker d...@dcrocker.net wrote: On 3/18/2013 9:28 AM, Mary Barnes wrote: it seems to take a long time for many to get their meeting minutes uploaded. My suggestion is for chairs to at least upload the raw minutes as drafts If minutes takers used etherpad, the raw minutes would be available in real-time, rather than requiring everyone to wait for the polished version. It would also allow some crows-sourcing of corrections and additions to the raw minutes... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Please review draft-housley-rfc2050bis-00.txt
On Mon, Mar 18, 2013 at 5:20 PM, joel jaeggli joe...@bogus.com wrote: On 3/18/13 6:04 AM, Ole Jacobsen wrote: I am wondering if the draft should mention that Local Internet Registries (LIRs) may sometimes take the form of National Internet Registries (NIRs) since this is now a reality in some places? All of the NIRs I've encountered can be construed as LIRs under the terms of the definition of LIR in that region. apnic and lacnic I belive specifically recognize the term. As much as I dislike the entire term NIR I see it exist already on the top/root, to quote from http://www.iana.org/numbers Both IPv4 and IPv6 addresses are generally assigned in a hierarchical manner. Users are assigned IP addresses by Internet service providers (ISPs). ISPs obtain allocations of IP addresses from a local Internet registry (LIR) or National Internet Registry (NIR), or from their appropriate Regional Internet Registry (RIR): I see APNIC are using it (http://www.apnic.net/policy/operational-policies-nirs/text), are anyone else? All I see is just yet another level of administration/control? -- Roger Jorgensen | ROJO9-RIPE rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no
Re: raw meeting minutes (Re: meetecho praise)
It would also allow some crows-sourcing of corrections and additions to the raw minutes... CAW CAW CAW CAW !!!
Re: raw meeting minutes (Re: meetecho praise)
On Mon, Mar 18, 2013 at 09:35:49AM -0700, Dave Crocker wrote: If minutes takers used etherpad, the raw minutes would be available in real-time, rather than requiring everyone to wait for the polished version. When it's working, I prefer to use etherpad. It was down during the first SIDR session. Lest I seem like I'm griping about a single problem, it seems to be down at least once an IETF when I'm wanting to contribute notes. Great tool, but some issues seem to still be there. -- Jeff
Re: Please review draft-housley-rfc2050bis-00.txt
Policy Manual / v1.10 - 13/08/2012 1. Definitions http://www.lacnic.net/en/web/lacnic/manual-1 2. IPv4 Addresses http://www.lacnic.net/en/web/lacnic/manual-2 etc ... And it is not administration/control, it is also about service (language, timezones, etc.) /as On 3/18/13 2:44 PM, Roger Jørgensen wrote: snip I see APNIC are using it (http://www.apnic.net/policy/operational-policies-nirs/text), are anyone else? All I see is just yet another level of administration/control?
Re: Mentoring
At 06:44 18-03-2013, Carlos M. Martinez wrote: - I support a newcomers' list. However, I do believe that the definition of newcomer must be relaxed a bit. A newcomer is not a 'first time attendee'. Being a IETF youngster I would say that for the first three meetings you are a newcomer. This may vary, but if I had to draw a line somewhere, three would be my choice. I suggest calling the mailing list hall...@ietf.org or else use edu-t...@ietf.org. I don't see any reason why new has to be defined. - Breakfasts / lunch meetings are great, but they are not enough. These slots might need some augmentation. I don't have many ideas except dinners and parallel slots while the WGs sessions are in progress. I suggest increasing the duration of the breaks. If you formalize a lunch meeting, for example, it will be engineered for perfection. It will end up being uninteresting (see Meet-and-Greet thread). - However tempting, I don't think ADs / WG chairs are ideal mentoring choices. During the IETF week they are drenched in work with their area directoring/ working group chairing duties and most of them won't have a lot of time for meeting newcomers and attending to their needs. Yes. - Mentors SHOULD be notified of their duties within reasonable time, and preferably be introduced to their 'pupils' via private email. I don't know how hard this would be to implement, but it would definitely help. Another thing to keep in mind: Do all newcomers want being mentored? I can think of one or two cases I know personally that probably wouldn't want a mentor. Seiichi Kawamura mentioned that it is about peer environment. The idea of mentorship seems to be about having new people listening religiously to old people explaining how things should work. If the IETF thinks that it is a good idea I will opt out as I believe that I will be considering people are inferior if I do that. - Moving the newcomers reception to later in the week is a MUST. Mentors should obviously be also invited to this reception. Murray Kucherawy mentioned that newcomers reception is used to take care of business (the people who regularly attend meetings discuss about IETF work). At 05:42 18-03-2013, Jari Arkko wrote: Not sure if that should be the winners or losers :-) I don't like the idea of winners and losers. Seriously though, I am roughly in the same camp as Seiichi. The real introduction of someone into the IETF is mostly about finding discussion partners around the reason why the person came to the IETF to begin with. Most of the time these would be peers within a working group. Like-minded vendors, customers or researchers. Not everyone who comes to the IETF for the first time is a beginner, they may for instance be established engineers on their fields, and just coming to the IETF to accomplish a goal. We discuss very interesting topics at the IESG and IAB, but I think the more direct way to introduce someone to the IETF network is to connect the person with others who work in the same topic. And maybe create some real co-operation between those people, building additional reasons for the person to continue to join our meetings. Agreed. As an aside, from personal experience, small, targeted meetings with newcomers have tended to work better for me than otherwise. Yes. I would get rid of the dots. It seems that the IETF has been perpetuating rituals for no reason other than it is tradition (it is how things were done before). I would get rid of the new attendee tag as it creates different categories of individuals. Regards, -sm P.S. If your system of finding people to hire, speakers for your stage, or members for your board depends on having them step forward and ask, you've effectively institutionalized a bias.
Re: raw meeting minutes (Re: meetecho praise)
Hi, we have used an etherpad-enabled Meetecho room (https://twitter.com/spromano/status/311211960412807169/photo/1) during the History BoF at IETF86 and I have to say that the shared editor worked like a charm. In my personal view, this is an extremely useful tool for minute-taking. Simon Il giorno 18/mar/2013, alle ore 18:57, Jeffrey Haas ha scritto: On Mon, Mar 18, 2013 at 09:35:49AM -0700, Dave Crocker wrote: If minutes takers used etherpad, the raw minutes would be available in real-time, rather than requiring everyone to wait for the polished version. When it's working, I prefer to use etherpad. It was down during the first SIDR session. Lest I seem like I'm griping about a single problem, it seems to be down at least once an IETF when I'm wanting to contribute notes. Great tool, but some issues seem to still be there. -- Jeff _\\|//_ ( O-O ) ~~o00~~(_)~~00o Simon Pietro Romano Universita' di Napoli Federico II Computer Engineering Department Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: sprom...@unina.it Molti mi dicono che lo scoraggiamento Ë l'alibi degli idioti. Ci rifletto un istante; e mi scoraggio. Magritte. oooO ~~~( )~~~ Oooo~ \ (( ) \_) ) / (_/
Re: Mentoring
Yes and no. I would get rid of all the dots, possible yes. The new attendee tag, not sure. May change it for a dot. The tags is useful to identify new people and help. A mentor tag or dot would be useful to people for not thinking that you are a weirdo trying to make conversation. We need to get rid of old traditions if they do not longer apply, but also we need to subtle identify people willing to help and people that may need some help. Regards, as On 3/18/13 3:14 PM, SM wrote: I would get rid of the dots. It seems that the IETF has been perpetuating rituals for no reason other than it is tradition (it is how things were done before). I would get rid of the new attendee tag as it creates different categories of individuals.
Re: Mentoring
On 3/18/2013 2:34 PM, Arturo Servin wrote: Yes and no. I would get rid of all the dots, possible yes. In general, I like the scope of what's being questioned in the past week or so, even if the answer comes back we talked about this, and the other stuff we could think of was worse :-) On dots, specifically ... I'm guessing from context that you're thinking red/IAB, yellow/IESG, blue/WG chairs, and possibly pink (technically the IRSG, but almost all the IRSG members are also RG chairs, so in this case, pink is like yellow and blue, mixed together). There are dots, and then there are dots. The one I'd like to see continued the most is the orange dot, for Nomcom members. We choose the voting members at random out of a volunteer pool, with some qualifications but not a lot, for a specific duration. Perhaps there's value in helping the community identify Nomcom members quickly during breaks, etc. For several years, I've scheduled meetings with Nomcom during their office hours, but I'm usually providing input on 10-20 willing nominees. It might be helpful for someone to chat with a Nomcom member and give feedback on one or two willing nominees in just a few minutes - that's what I'm talking about. If the IAOC continues to hold open sessions at future IETF meetings, that's good; if not, perhaps there's value in helping the community identify IAOC members quickly, too. For extra credit, picking a color that's easier to identify distinctly would help (I can't consistently tell the difference between purple/IAOC member and blue/WG Chair unless someone is wearing both). IIRC, the green Local Host dots were intended to help people who weren't familiar with a meeting site find someone who was familiar with that site. Now that we have an IAOC, and attendees lists and meeting wikis, and a larger and more visible secretariat, green dots may have more value as recognition for meeting sponsors (and if giving out green dots matters to people who support the IETF financially, that's certainly sufficient as a reason to keep them!). Just keep thinking carefully, as people are doing, and developing a better understanding about what we are doing and why it might have been our practice in the past ... and whether it's still a good idea now. Thanks, Spencer The new attendee tag, not sure. May change it for a dot. The tags is useful to identify new people and help. A mentor tag or dot would be useful to people for not thinking that you are a weirdo trying to make conversation. We need to get rid of old traditions if they do not longer apply, but also we need to subtle identify people willing to help and people that may need some help. Regards, as On 3/18/13 3:14 PM, SM wrote: I would get rid of the dots. It seems that the IETF has been perpetuating rituals for no reason other than it is tradition (it is how things were done before). I would get rid of the new attendee tag as it creates different categories of individuals.
IETF 86 Admin Plenary Minutes
http://www.ietf.org/proceedings/86/minutes/minutes-86-iesg-opsplenary Please review and comment. Russ
Getting rid of the dot (was: Mentoring)
Hi Spencer, At 13:49 18-03-2013, Spencer Dawkins wrote: There are dots, and then there are dots. The one I'd like to see continued the most is the orange dot, for Nomcom members. We choose the voting members at random out of a volunteer pool, with some qualifications but not a lot, for a specific duration. Perhaps there's value in helping the community identify Nomcom members quickly during breaks, etc. Did you need to look for the NomCom dot to identify NomCom members? :-) If the IAOC continues to hold open sessions at future IETF meetings, that's good; if not, perhaps there's value in helping the community identify IAOC members quickly, too. If the community cannot identify these IAOC members quickly it can only mean that these members are unknown or known to a selected few who have been attending meetings since several years. attendees lists and meeting wikis, and a larger and more visible secretariat, green dots may have more value as recognition for meeting sponsors (and if giving out green dots matters to people who support the IETF financially, that's certainly sufficient as a reason to keep them!). Yes. Just keep thinking carefully, as people are doing, and developing a better understanding about what we are doing and why it might have been our practice in the past ... and whether it's still a good idea now. Agreed. Regards, -sm
Re: Getting rid of the dot (was: Mentoring)
I wouldn't mind replacing my blue dot with an indication *what* WG I chair, and in which area that is. Might be a bit more logistics when chairs change, but nothing that can't be solved with a DYMO labelmaker. Grüße, Carsten
Re: Getting rid of the dot
On 3/18/2013 5:04 PM, SM wrote: At 13:49 18-03-2013, Spencer Dawkins wrote: There are dots, and then there are dots. The one I'd like to see continued the most is the orange dot, for Nomcom members. We choose the voting members at random out of a volunteer pool, with some qualifications but not a lot, for a specific duration. Perhaps there's value in helping the community identify Nomcom members quickly during breaks, etc. Did you need to look for the NomCom dot to identify NomCom members? :-) Hi, SM, Not me, even when I don't recognize half the names of voting members, because I identify NomCom members by sending a request for an interview slot (and I'm remembering that these are 30 minutes long), so everyone in the room when I arrive is a NomCom member ;-) That's OK for people who can provide input on lots of people - I do - but doesn't scale for people who just want to provide input on a couple of people they've worked with, who are willing nominees for a NomCom-selected position. Grabbing someone who has to listen because they're chewing a cookie can be enough, sometimes! Spencer
Re: Getting rid of the dot (was: Mentoring)
On Mon, Mar 18, 2013 at 11:10:14PM +0100, Carsten Bormann wrote: I wouldn't mind replacing my blue dot with an indication *what* WG I chair, and in which area that is. Might be a bit more logistics when chairs change, but nothing that can't be solved with a DYMO labelmaker. Since I live with a graphic designer, I occasionally think about arranging for some stickers that convey what areas one follows. I suspect dinner conversation at some point will involve trying to figure out appropriate icons for the different areas. Routing is the only immediately obvious one to me. INT, TSV, OPS and APP may simply suffer from my poor imagination with some sort of ROYGBIV style 7-layer stack with those groups indicated by their appropriate place in the hierarchy. (Although OPS may object to my layer 6 thinking. :-) Such an exercise would probably generate a lot less controversy than my unsanctioned badge experiment. http://pfrc.org/~jhaas/pictures/badge.jpg -- Jeff
Re: Please review draft-housley-rfc2050bis-00.txt
1) In Section 1, goal #2, Hierarchical Allocation, I believe a reference the definition in RFC 5226 - Section 4.1. Well-Known IANA Policy Definitions, should be considered. 2) I also wonder if another appropriate goal would be explicitly defining the ASN and IP address registries using RFC 5226 language including the formal linkage to ICANN and the RIRs as the mechanism for IANA to implementing the Hierarchical Allocation of these registries. See: RFC 5226, section 4.3. Updating IANA Guidelines for Existing Registries The intention wouldn't be to override RFC 2860, ICANN Policy, or IR global policy, but to provide and explicit formal technical definition for these registries that really have only been implicitly defined to date as far as I can tell. There are any number of other registries that are far less important overall, that have excellent formal technical definitions that comply with RFC 5226 or its predecessors. However, these our most important registries have no such formal technical definitions, I think its really time to fix this situation. That said, to the greatest extent possible we need a formal technical definition compliant with RFC 5226 of the as-is-state, not of the want-it-to-be-state. Or, if I'm incorrect and there are formal technical definitions for these registries that comply with RFC 5226, or its predecessors, then they should be referenced in this document. 3) The last paragraph of Section 3, Internet Numbers Registry Technical Considerations Says; As the Internet and the Internet Numbers Registry System continue to evolve, it may be necessary for the Internet community to examine these and related technical and operational considerations and how best to meet them. I wonder if it wouldn't be appropriate to at least provide some suggestions for how this is to be accomplished. Maybe request that future RFCs related to these technical and operational considerations include an applicability statement as to the Internet Numbers Registry System, either in a separate section or maybe as a sub-section of the IANA Considerations. On 3/16/13 17:13 , Russ Housley wrote: A new, I-D, draft-housley-rfc2050bis-00.txt, has been posted. I am writing to ask for your review. Russ -- David Farmer Email: far...@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952
Re: IETF 86 Admin Plenary Minutes
http://www.ietf.org/proceedings/86/minutes/minutes-86-iesg-opsplenary Please review and comment. - Lorenzo Colitti was wondering what problem we are trying to solve: He looked at the IESG and they all look the same as the people in the audience. Is the problem that the people on the IESG don't represent the people in the audience? Or is the problem that the IETF participants are not diverse enough. These are two different problems, and they cannot both be solved with one solution. - I understood the beginning of Lorenzo's comment differently. I thought he said that when he looked at the stage he saw one version of (lack of) diversity, and when he looked at the audience he saw a different version. That, as I understood it, is what motivated his question about which of those problems we're aiming at solving. (In the version in the minutes, the question in the second sentence doesn't really make sense after the first sentence.) Barry
Re: [core] Last Call: draft-ietf-core-coap-14.txt (Constrained Application Protocol (CoAP)) to Proposed Standard
4.6. Message Size A CoAP message, appropriately encapsulated, SHOULD fit within a single IP packet (i.e., avoid IP fragmentation) and (by fitting into one UDP payload) obviously MUST fit within a single IP datagram. If the Path MTU is not known for a destination, an IP MTU of 1280 bytes SHOULD be assumed; if nothing is known about the size of the headers, good upper bounds are 1152 bytes for the message size and 1024 bytes for the payload size. this may motivate implementations to be frugal in their packet sizes and to move to block-wise transfers [I-D.ietf-core-block] when approaching three- digit message sizes. This draft says a coap message must fit within a single IP datagram. on the other hand, however, to avoid fragmentation, this draft may suggest to use the block-wise transfer, which is defined by another draft. If the payload size is more than the minimum MTU, the block-wise transfer works. If the total length of the options is bigger, the mechanism doesn't work. And, the length of URI is likely to be bigger than the MTU. Do you assume a use case in which the total length of options is going to be greater than the MTU ? One possible solution is that a fragment option is defined and is placed at the first than other options. And, However, the option number has a semantic, and the order of the options is settled. There is no room for the block options to be placed at the first. Shoichi
Re: [TLS] Last Call: draft-ietf-tls-multiple-cert-status-extension-04.txt (The TLS Multiple Certificate Status Request Extension) to Proposed Standard
On 15 Mar 2013, at 13:35, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'The TLS Multiple Certificate Status Request Extension' draft-ietf-tls-multiple-cert-status-extension-04.txt as 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 2013-03-29. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines the Transport Layer Security (TLS) Certificate Status Version 2 Extension to allow clients to specify and support multiple certificate status methods. Also defined is a new method based on the Online Certificate Status Protocol (OCSP) that servers can use to provide status information not just about the server's own certificate, but also the status of intermediate certificates in the chain. I read the document. I think it adds important functionality. It is clearly written, so I support its publication.
Re: Consensus on the responsibility for qualifications? (Was: Re: Nomcom is responsible for IESG qualifications)
Dave Crocker d...@dcrocker.net wrote: ... On 3/13/2013 9:07 PM, John Leslie wrote: I see several problems with this text: 1) It wanders from the current clear distinction between desired expertise, determined by the body where the nominee will serve, and IETF community's consensus of the qualifications required, determined by waving the right magic wand. ;^) Harumph! It doesn't wander. It moves with dedicated purpose... ;^) What text you are proposing as an alternative? I'll come back to that... it then advises each confirming body of its respective candidates; the nominating committee shall provide supporting materials that cover its selections, including the final version of requirements that the nominating committee used when making its selections; strikes me as too little, too late: the confirming body should learn of any relaxing (least of all changes!) to the desired expertise see above. There's a lot of above. Which in particular? these requirements shall be made public after nominees are confirmed. This seems too vague. I'd suggest we consider listing actual requirements in a formal report posted to ietf-announce. Again, there is a range range of important procedural detail that the existing does not provide. I'm in the camp that thinks that's appropriate. We haven't had a problem with the lack of formal specification for those details. Let's not fix something that's been working well. But it hasn't been working well! You have said yourself that some prior NomComs have felt prevented from changing anything of the desired expertise. Revised draft text: 2. The nominating committee determines the criteria for the job, synthesizing the desires expressed by the IAB, IESG or ^^^ should be desired expertise IAOC (as appropriate), desires express by the community, and ^^^ should be qualifications required the nominating committee's own assessment; it informs the community and candidates of these determined criteria; Informing the community is technically sufficient; but I still believe that the NomCom being chosen randomly is unlikely to have much expertise in judging community consensus: the confirming bodies are much more likely to have that expertise, and the confirming bodies may disagree with the NomCom's judgment of these criteria. Some formal consultation with the confirming bodies before publishing the criteria to the full community is likely to avoid a rash of troubles... Regardless of the text here, somebody who disagrees with the NomCom's judgment of consensus on these criteria will find a way to appeal. :^( it advises each confirming body of its respective candidates; the nominating committee shall provide the confirming body with supporting materials that cover its selections, including the final version of criteria that the nominating committee used when making its selections. There is a whole lot which needs to happen after publication of criteria and before informing confirming bodies of nominations. At the very least, there should be a paragraph break here... -- John Leslie j...@jlc.net
WG Action: Conclusion of Email Address Internationalization (eai)
The Email Address Internationalization (eai) Working Group in the Applications Area has concluded. The IESG contact persons are Barry Leiba and Pete Resnick. The mailing list will remain open.
WG Action: Conclusion of Kerberos (krb-wg)
The Kerberos (krb-wg) Working Group in the Security Area has concluded. The IESG contact persons are Stephen Farrell and Sean Turner. The work will continue in the Common Authentication Technology Next Generation (kitten) WG. The mailing list is external and will close, but users have already been migrated to the kitten list hosted by the IETF.
Last Call: draft-ietf-ipfix-flow-selection-tech-14.txt (Flow Selection Techniques) to Proposed Standard
The IESG has received a request from the IP Flow Information Export WG (ipfix) to consider the following document: - 'Flow Selection Techniques' draft-ietf-ipfix-flow-selection-tech-14.txt as 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 i...@ietf.org mailing lists by 2013-04-01. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Intermediate Flow Selection Process is the process of selecting a subset of Flows from all observed Flows. The Intermediate Flow Selection Process may be located at an IPFIX Exporter, Collector, or within an IPFIX Mediator. It reduces the effort of post-processing Flow data and transferring Flow Records. This document describes motivations for using the Intermediate Flow Selection process and presents Intermediate Flow Selection techniques. It provides an information model for configuring Intermediate Flow Selection Process techniques and discusses what information about an Intermediate Flow Selection Process should be exported. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1540/
