Weekly posting summary for ietf@ietf.org
Total of 164 messages in the last 7 days. script run at: Fri Jun 21 00:53:02 EDT 2013 Messages | Bytes| Who +--++--+ 7.93% | 13 | 6.46% |83622 | stpe...@stpeter.im 6.10% | 10 | 5.81% |75305 | do...@dougbarton.us 4.88% |8 | 3.91% |50591 | melinda.sh...@gmail.com 4.27% |7 | 4.48% |58056 | john-i...@jck.com 3.05% |5 | 4.91% |63546 | david.bl...@emc.com 3.05% |5 | 3.70% |47900 | hal...@gmail.com 3.05% |5 | 3.37% |43652 | yd...@cs.helsinki.fi 3.66% |6 | 2.68% |34743 | d...@dcrocker.net 2.44% |4 | 3.47% |44982 | jsalo...@cisco.com 2.44% |4 | 2.11% |27359 | s...@resistor.net 2.44% |4 | 2.03% |26268 | ted.le...@nominum.com 2.44% |4 | 2.01% |26016 | joe...@bogus.com 2.44% |4 | 1.95% |25313 | jari.ar...@piuha.net 1.83% |3 | 2.27% |29410 | morrowc.li...@gmail.com 1.83% |3 | 2.01% |25980 | abdussalambar...@gmail.com 1.83% |3 | 1.83% |23694 | p...@frobbit.se 1.83% |3 | 1.79% |23217 | b...@nostrum.com 1.83% |3 | 1.56% |20167 | y...@checkpoint.com 1.83% |3 | 1.49% |19314 | war...@kumari.net 1.22% |2 | 2.05% |26509 | ed.le...@neustar.biz 1.83% |3 | 1.42% |18361 | hartm...@painless-security.com 1.83% |3 | 1.24% |16039 | a...@anvilwalrusden.com 1.83% |3 | 1.23% |15972 | paul.hoff...@vpnc.org 0.61% |1 | 2.41% |31232 | rjspa...@nostrum.com 1.83% |3 | 1.14% |14763 | ra...@psg.com 1.22% |2 | 1.68% |21721 | suresh.krish...@ericsson.com 0.61% |1 | 2.27% |29379 | magnus.westerl...@ericsson.com 1.22% |2 | 1.42% |18391 | doug.mtv...@gmail.com 1.22% |2 | 1.40% |18104 | arturo.ser...@gmail.com 1.22% |2 | 1.36% |17556 | nar...@us.ibm.com 1.22% |2 | 1.35% |17460 | carlosm3...@gmail.com 1.22% |2 | 1.27% |16497 | kathleen.moria...@emc.com 1.22% |2 | 1.19% |15475 | f...@cisco.com 1.22% |2 | 1.02% |13166 | br...@innovationslab.net 1.22% |2 | 0.86% |11137 | aser...@lacnic.net 1.22% |2 | 0.70% | 9102 | j...@mercury.lcs.mit.edu 0.61% |1 | 1.10% |14193 | daedu...@btconnect.com 0.61% |1 | 0.85% |10959 | presn...@qti.qualcomm.com 0.61% |1 | 0.83% |10754 | d...@cridland.net 0.61% |1 | 0.81% |10541 | shollenb...@verisign.com 0.61% |1 | 0.78% |10037 | chris.dearl...@baesystems.com 0.61% |1 | 0.74% | 9635 | t...@ecs.soton.ac.uk 0.61% |1 | 0.73% | 9392 | mirja.kuehlew...@ikr.uni-stuttgart.de 0.61% |1 | 0.68% | 8857 | f...@isoc.org 0.61% |1 | 0.66% | 8528 | me...@globetel.com.ph 0.61% |1 | 0.61% | 7937 | barryle...@computer.org 0.61% |1 | 0.59% | 7633 | hsan...@isdg.net 0.61% |1 | 0.59% | 7614 | scott.b...@gmail.com 0.61% |1 | 0.57% | 7422 | droma...@avaya.com 0.61% |1 | 0.57% | 7367 | brian.e.carpen...@gmail.com 0.61% |1 | 0.55% | 7182 | hous...@vigilsec.com 0.61% |1 | 0.54% | 7035 | nomcom-chair-2...@ietf.org 0.61% |1 | 0.53% | 6804 | adr...@olddog.co.uk 0.61% |1 | 0.52% | 6786 | jab...@hopcount.ca 0.61% |1 | 0.51% | 6609 | ma...@isc.org 0.61% |1 | 0.51% | 6549 | jo...@taugh.com 0.61% |1 | 0.50% | 6442 | randy_pres...@mindspring.com 0.61% |1 | 0.48% | 6250 | mehmet.er...@nsn.com 0.61% |1 | 0.47% | 6147 | m...@mnot.net 0.61% |1 | 0.46% | 5925 | turn...@ieca.com 0.61% |1 | 0.45% | 5781 | jo...@iecc.com 0.61% |1 | 0.44% | 5733 | stephen.farr...@cs.tcd.ie 0.61% |1 | 0.44% | 5640 | o...@ogud.com 0.61% |1 | 0.43% | 5549 | c...@tzi.org 0.61% |1 | 0.41% | 5339 | d...@xpasc.com 0.61% |1 | 0.40% | 5241 | d...@virtualized.org 0.61% |1 | 0.40% | 5212 | i...@ietf.org +--++--+ 100.00% | 164 |100.00% | 1295092 | Total
Re: Policy makers
On 6/21/13 2:38 AM, SM wrote: At 11:00 20-06-2013, The IAOC wrote: series of events and programs in South America. This would include: - Increasing the IETF Fellows and policy makers from the region I don't see any policy makers reviewing Internet-Drafts. I don't see any policy makers writing IETF RFCs. Policy makers do not usually participate in IETF discussions. You haven't and probably won't. But they were invited (IMHO) not to participate in the IETF to review or write I+D but to know the IETF, what we do, how we work; and how governments and the IETF can collaborate. I think that ISOC should continue with that effort. Regards, as
Re: Weekly posting summary for ietf@ietf.org
* For Week 25 in 2013 About 17 subjects discussed, about 6 IETF LCs, about 3 Gen-Art Review. On Fri, Jun 21, 2013 at 5:53 AM, Thomas Narten nar...@us.ibm.com wrote: Messages | Bytes | Who +--++--+ 1.83% | 3 | 2.01% | 25980 | abdussalambar...@gmail.com 3 messages in same subject IETF Diversity - *For Week 24 in 2013 AB total number of discussed subjects/threads on the IETF list are about 20. AB total number of discussed IETF LCs in this week are about 7. On 6/14/13, Thomas Narten nar...@us.ibm.com wrote: Total of 158 messages in the last 7 days. script run at: Fri Jun 14 00:53:03 EDT 2013 Messages | Bytes| Who +--++--+ 3.16% |5 | 4.16% |52840 | abdussalambar...@gmail.com AB abdussalambar...@gmail.com contributed to 4 subjects on the IETF list, 2 IETF LC I-Ds and 2 general subjects. -- Please note that I consider mentioning my input number with email address in the list without number of subject as a comment on my input to IETF list, therefore, I will have to reply, only if you exclude my address from your report, or if you add the number of subjects at least. Please note that I have not given any one a permission/allowance to comment/count on my number of inputs, and that I requested that the subject number to be added. Overall, if you have a permission from the community for this report please provide me with a reference. Best Regards AB
Re: Weekly posting summary for ietf@ietf.org
AB Thomas started posting these weekly reports many years ago as a service to the community to remind us all that posting to ietf@ietf.org contributes to the information and work overload of the IETF community as a whole. The numbers are a reminder to think carefully about what you send to the list and to only send what you consider to be sufficiently important that the community as a whole needs to be aware of it. Most members of the IETF community try their best to minimize their so called Narten Number. Many regard these postings as a useful service, and I for one, thank him for doing it. - Stewart
Re: Weekly posting summary for ietf@ietf.org
+1 (and that will be my only posting on this subject, I suggest that if you don't get Stewart's drift you stop sending mails to the list until you do) /Loa On 2013-06-21 15:00, Stewart Bryant wrote: AB Thomas started posting these weekly reports many years ago as a service to the community to remind us all that posting to ietf@ietf.org contributes to the information and work overload of the IETF community as a whole. The numbers are a reminder to think carefully about what you send to the list and to only send what you consider to be sufficiently important that the community as a whole needs to be aware of it. Most members of the IETF community try their best to minimize their so called Narten Number. Many regard these postings as a useful service, and I for one, thank him for doing it. - Stewart -- Loa Anderssonemail: l...@mail01.huawei.com Senior MPLS Expert l...@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64
Re: Weekly posting summary for ietf@ietf.org
Hi Stewart, I don't have any problem with the report/reminder only that it has missing important information. The subjects of discussions are not counted, so I counted them. Also the report does not distinguish between general-posting and replying to IETF LCs. AB On Fri, Jun 21, 2013 at 2:00 PM, Stewart Bryant stbry...@cisco.com wrote: AB Thomas started posting these weekly reports many years ago as a service to the community to remind us all that posting to ietf@ietf.org contributes to the information and work overload of the IETF community as a whole. The numbers are a reminder to think carefully about what you send to the list and to only send what you consider to be sufficiently important that the community as a whole needs to be aware of it. Most members of the IETF community try their best to minimize their so called Narten Number. Many regard these postings as a useful service, and I for one, thank him for doing it. - Stewart
Re: [IETF] IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
On Jun 19, 2013, at 8:43 PM, John C Klensin john-i...@jck.com wrote: ... The point, Warren (and others) is that all of these are ICANN doing technical stuff and even technical standards in a broad sense of that term. Some of it is stuff that the IETF really should not want to do (I'm tempted to say avoid like the plague). Some of it probably should be here. As an outsider to both, there is a certain amount of stuff that has ended up in SSAC and even RSAC that might have been better located in SAAG or some IETF or NOG DNS operations group. I certainly won't argue that we've got the balance right. And I think it is unfortunate that the very early redesign of the original PSO had the side effect of making it hard or impossible to work out optimal boundaries and cross-review mechanisms with ICANN and that we are instead having a discussion more than a dozen years later about keeping ICANN from doing technical work or making standards. +1 (specifically - it is unfortunate that a more operational ICANN / IETF liaison did not emerge via the PSO structure) Let's not complicate things further by making the assumption that anything that reasonably looks like technical stuff belongs in the IETF and not in ICANN. It is likely to just make having the right conversations even harder. I believe that policy issues that are under active discussion in ICANN can also be discussed in the IETF, but there is recognition that ICANN is likely the more appropriate place to lead the process of consensus development and approval. I believe that protocol development that is under active discussion at the IETF can also discussed at ICANN, but there is recognition that the IETF is likely the appropriate place to lead the process of consensus development and approval. Note that there are lots of things that are neither policy nor protocols (e.g. operational best practices and guidelines) and while one can claim that either forum is valid, it really depends on the particular situation and where those folks who are closest to the problem actually choose to go with it (and depending on the protocol, that might not be either of the above...) /John Disclaimer: My views alone - YMMV.
Re: Weekly posting summary for ietf@ietf.org
These are valid points. For a long time, I used a public forum support reporter for our support process which categorized daily and hourly messaging patterns, hottest threads and topics and reply efficiency concepts. Basically to see how many messages were replied to in general and how many were replied by the technical support staff (measured against a list of certain responders) and how many were missed (ignored) which you strived to minimized. In the past, I considered using this reporter here just to see, but it already had a posting summary and it would be viewed more as an redundant annoyance. Plus, I certainly do no want to step on anyone shoes. In my view, it offers little other than as other stated to mind your number of post, but clearly that doesn't apply to all folks. If you have something to say, this is not going to deter you. Others may feel otherwise, but these folks don't care what you think and rightly so. Based on what I see, most messages are during weekdays and during the day, normal working hours I suppose. It does cut down by the weekend. While there is a high ignorance factor at the particular individual level, most messages have a high reply factor. IOW, most messages are not ignored. Of course, that may just mean when a message is not interesting, it gets ignored. There is also a Shutdown factor too - when a certain individual post, people tend to stop posting. But I think overall, the SUPPORT factor per se is pretty good here and in the most IETF forums I've participating in. However, it does depend on who is doing the postings and this fact shouldn't be a surprise. -- HLS On 6/21/2013 10:48 AM, Abdussalam Baryun wrote: Hi Stewart, I don't have any problem with the report/reminder only that it has missing important information. The subjects of discussions are not counted, so I counted them. Also the report does not distinguish between general-posting and replying to IETF LCs. AB On Fri, Jun 21, 2013 at 2:00 PM, Stewart Bryant stbry...@cisco.com wrote: AB Thomas started posting these weekly reports many years ago as a service to the community to remind us all that posting to ietf@ietf.org contributes to the information and work overload of the IETF community as a whole. The numbers are a reminder to think carefully about what you send to the list and to only send what you consider to be sufficiently important that the community as a whole needs to be aware of it. Most members of the IETF community try their best to minimize their so called Narten Number. Many regard these postings as a useful service, and I for one, thank him for doing it. - Stewart
Re: [IETF] IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
On 6/21/13 10:46 , John Curran wrote: I believe that policy issues that are under active discussion in ICANN can also be discussed in the IETF, but there is recognition that ICANN is likely the more appropriate place to lead the process of consensus development and approval. I believe that protocol development that is under active discussion at the IETF can also discussed at ICANN, but there is recognition that the IETF is likely the appropriate place to lead the process of consensus development and approval. Note that there are lots of things that are neither policy nor protocols (e.g. operational best practices and guidelines) and while one can claim that either forum is valid, it really depends on the particular situation and where those folks who are closest to the problem actually choose to go with it (and depending on the protocol, that might not be either of the above...) /John Disclaimer: My views alone - YMMV. A version of these three paragraphs would make an excellent executive summary for the 2050bis Draft itself. -- 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: Weekly posting summary for ietf@ietf.org
It seems to me that you have missed the fact that the IETF is a volunteer organization. The vast majority of us appreciate that Thomas creates this summary. If you feel different information would be useful, then create your own report and share the results, to at least to see if your version is desired. Thomas provided a link in the earlier discussion to his code so I imagine you could use that as a starting point. You might also find it helpful to review the terms of the IETF Note Well which you agreed to when you joined this list. You lose control of anything you contribute so making demands about how that information is used is pointless. On Fri, 21 Jun 2013, Abdussalam Baryun wrote: Hi Stewart, I don't have any problem with the report/reminder only that it has missing important information. The subjects of discussions are not counted, so I counted them. Also the report does not distinguish between general-posting and replying to IETF LCs. AB On Fri, Jun 21, 2013 at 2:00 PM, Stewart Bryant stbry...@cisco.com wrote: AB Thomas started posting these weekly reports many years ago as a service to the community to remind us all that posting to ietf@ietf.org contributes to the information and work overload of the IETF community as a whole. The numbers are a reminder to think carefully about what you send to the list and to only send what you consider to be sufficiently important that the community as a whole needs to be aware of it. Most members of the IETF community try their best to minimize their so called Narten Number. Many regard these postings as a useful service, and I for one, thank him for doing it. - Stewart
Re: [IETF] IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
--On Friday, June 21, 2013 11:46 -0400 John Curran jcur...@istaff.org wrote: ... Let's not complicate things further by making the assumption that anything that reasonably looks like technical stuff belongs in the IETF and not in ICANN. It is likely to just make having the right conversations even harder. I believe that policy issues that are under active discussion in ICANN can also be discussed in the IETF, but there is recognition that ICANN is likely the more appropriate place to lead the process of consensus development and approval. I believe that protocol development that is under active discussion at the IETF can also discussed at ICANN, but there is recognition that the IETF is likely the appropriate place to lead the process of consensus development and approval. ... John, While I agree with the above (and am still trying to avoid carrying this conversation very far on the IETF list), I think another part of the puzzle is that there are also situations in which technical considerations imply real constraints on policy alternatives. Some obvious examples include physical constants like the speed of light, others, only slightly less obvious, include things like the design of the DNS as a simply hierarchy that cannot support symmetric aliases (i.e., anything that would support an actual came from function or a list of all of the names that point to a given note). The policy folks ignore those constraints, or treat them as subject to policy-making decisions at the risk of being ridiculous and/or causing considerable harm to the Internet. While they are less obvious in this community, I suggest it works the other way too -- there are policy and economic decisions and realities that are as much constraints on the technical solution space as those technical constrains are on the policy ones, with just about the same risks of ridiculousness or damage if they are ignored. That is, again, why it is so unfortunate that the original model of the IAB/PSO as one of ICANN's three everyone has to work together pillars was abandoned... and more unfortunate that it was replaced on the ICANN side by approximately nothing other than some committees and other bodies that could easily be ignored and on the IETF side by depending on individuals with feet in both camps to speak up. john
RE: Gen-ART LC Review of draft-thornburgh-adobe-rtmfp-07
hi Ben. thanks for your review. comments/replies inline. From: Ben Campbell [mailto:b...@nostrum.com] Sent: Thursday, June 20, 2013 4:07 PM 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 resolve these comments along with any other Last Call comments you may receive. Document: draft-thornburgh-adobe-rtmfp-07 Reviewer: Ben Campbell Review Date: 2013-06-20 IETF LC End Date: 2013-06-25 Summary: This draft is almost ready for publication as an informational RFC. However, I have some concerns about the purpose and intended status of the document that I think should be considered prior to publication. Note: This is an informational draft that describes what I understand to be an existing protocol as implemented by commercial products. Therefore, this review does not attempt to evaluate the protocol itself. I assume the protocol is what it is, and it is not up to the IETF to agree or disagree with it. *** Major issues: -- Why does this need to be published as an IETF stream RFC? If I understand correctly, this documents an existing protocol as implemented by commercial products. I agree with Martin's comment that there is value in publishing this sort of thing, but I applaud the Adobe and the author for publishing it so other implementations can interoperate with their products. But that could have done that in an independent stream document, or even in an Adobe published document. (Perhaps even in a prettier format ;-) ) If we publish this as an IETF stream document, then I think it needs stronger clarification that it is not an IETF consensus doc than just its informational status. this memo documents an existing network transport protocol that is widely deployed and in widespread use in the Internet. we felt that the IETF community (and in particular the participants in the Transport and Services Area) is the most appropriate community with which to share this work: 1) members of this community have the necessary and relevant expertise not only to understand the protocol, but to make use of it potentially in new applications beyond Flash; 2) it is a transport protocol similar in many ways to TCP and SCTP and widely deployed and used; 3) Adobe is interested in pursuing standardization of this protocol (with all that entails) if there is community interest, and the IETF is definitely the right place for that. we are very grateful that Martin Stiemerling chose to sponsor this document. with regard to comments in later messages in this thread, i'd be happy to include some (IESG-supplied) boilerplate in the document to clarify that it is not the product of an IETF WG. however, note that both the title and first sentence of the Introduction indicate that this is Adobe's blahblahblah, consistent with other vendor-protocol RFCs and consistent with IESG editorial insistence (as told to me by a former TSV AD). see RFC 4332 and RFC 6802 for two examples of vendor-specific/supplied protocols. see also the IESG note in RFC 4332 as an example disclaimer that could be added. Along those lines: -- Is this document the authoritative specification? (I suspect not.) Who owns change control? I assume that to be Adobe and/or the authors. What expectation do readers of this draft have that it represents the current version of RTMFP at any point in time? this memo is the authoritative specification for Adobe's RTMFP. Adobe owns change control. i believe the second and third paragraphs of the Introduction indicate to a reader that this draft represents RTMFP as deployed in the named Adobe products at the time of writing. -- Under what circumstances would one desire to implement this? I can infer that from the introduction, but it would be nice to see some sort of applicability statement making it explicitly clear that this is not an IETF protocol, and that one would implement it in order to interoperate with certain Adobe products. I know that some of this may be implied by the fact that this is informational rather than standards track. But I don't expect readers who are not IETF insiders to understand that subtlety without some explicit words to that effect. In particular, it would be good to clarify the difference between this and the many not quite accepted as standards track by some working group nature of a number of our informational RFCs that describe protocols. i will expand on applicability beyond what i specify in the first paragraph of the Introduction, in general terms such as the kinds of functionality we use this protocol for in Flash. note that interoperation with certain Adobe products, such as Flash Player, requires additional information such as the Flash-specific Cryptography Profile and syntax/semantics of mapping Flash's Real Time Messaging
Re: [IETF] IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
On Jun 21, 2013, at 2:56 PM, John C Klensin john-i...@jck.com wrote: While I agree with the above (and am still trying to avoid carrying this conversation very far on the IETF list), I think another part of the puzzle is that there are also situations in which technical considerations imply real constraints on policy alternatives. Some obvious examples include physical constants like the speed of light, others, only slightly less obvious, include things like the design of the DNS as a simply hierarchy that cannot support symmetric aliases (i.e., anything that would support an actual came from function or a list of all of the names that point to a given note). The policy folks ignore those constraints, or treat them as subject to policy-making decisions at the risk of being ridiculous and/or causing considerable harm to the Internet. While they are less obvious in this community, I suggest it works the other way too -- there are policy and economic decisions and realities that are as much constraints on the technical solution space as those technical constrains are on the policy ones, with just about the same risks of ridiculousness or damage if they are ignored. Agreed. I believe that there is a better understanding of this situation now than in the earlier days (including among governments who are beginning to seriously engage with ICANN's GAC.) That is, again, why it is so unfortunate that the original model of the IAB/PSO as one of ICANN's three everyone has to work together pillars was abandoned... and more unfortunate that it was replaced on the ICANN side by approximately nothing other than some committees and other bodies that could easily be ignored and on the IETF side by depending on individuals with feet in both camps to speak up. It's difficult to lay blame anyone from walking away from the PSO approach; in ICANN's early years it always seemed to be a vestigial structure serving little purpose. The lack of apparent value was amplified when ICANN changed its proposed structure (from being oversight and coordination between true independent supporting organizations) into a heavily DNS-focused direction by opting to absorb the DNSO internally in the initial Singapore meeting. If ICANN were operating solely in a coordination and oversight role, with policy, process, and protocol development done in supporting organizations, then it would have been a lot easier to make the liaison and coordination function successful, both between pillars (DNSO, ASO, PSO) and to/from governmental types. For some reason, doing that in the margin of a 97% DNS-focused omnibus policy/oversight/coordination/operation organization doesn't provide the necessary level of attention. FYI, /John Disclaimers: My views alone. Apologies for length; I lacked the time to write a shorter reply.
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
On Jun 18, 2013, at 11:25 PM, Patrik Fältström p...@frobbit.se wrote: I think this is the correct strategy, BUT, I see as a very active participant in ICANN (chair of SSAC) that work in ICANN could be easier if some more technical standards where developed in IETF, and moved forward along standards track, that ICANN can reference. Same with some epp-related issues, and also DNS-related, which I must admit I think has stalled in the IETF. When that happens, ICANN start to invent or at least discuss IETF related issues -- which I think is non optimal. But on the other hand, if IETF do not move forward, then what should ICANN do? Something ICANN can do is ask the IETF for specifications. I can't promise instant delivery, but it will be slower if we don't know what they need.
