Re: Gen-ART LC review of draft-ietf-mpls-tp-rosetta-stone-12
The draft does not list ITU in abbreviation, there are many terminology not clear but more general definition. I prefer specific defining. Also many times refers to references to define without mentioning what was that definition, is that defined only in ITU and IETF cannot define its technology, or is it agreeing on a joint definition so IETF is just following ITU in some terms. AB On Sunday, October 13, 2013, Roni Even wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-mpls-tp-rosetta-stone-12 Reviewer: Roni Even Review Date:2013–10–12 IETF LC End Date: 2013-10–16 IESG Telechat date: ** ** Summary: This draft is ready for publication as an Informational RFC. ** ** ** ** Major issues: Minor issues: ** ** Nits/editorial comments: ** ** ** **
Re: Gen-ART LC review of draft-ietf-mpls-tp-rosetta-stone-12
Yes, my comment meant that it is a reply to the review message that there may be not clear definition from other participant point of view. Sorry my review is still not complete, I will send it. Do you mean my reply is not right, if I like to give a short comment before my full review. AB On Sunday, October 13, 2013, Adrian Farrel wrote: Hi, I am having sever difficulty parsing all of the information from your comment. And currently cannot see anything actionable by the authors. The draft does not list ITU in abbreviation, Loa has answered why this is not necessary. You mean that IETF agrees to do that as per a RFC passed or community awareness. there are many terminology not clear but more general definition. I prefer specific defining. This comment gives us nothing to go on! Which terminology do you find not clear but is a more general definition? And why is this a problem? You cannot expect the authors to fix or even discuss something if you do not show them what you are talking about. I am talking about the draft in overall, I will do my review if time is available. Also many times refers to references to define without mentioning what was that definition, What do you mean? Can you give an example and say how you think it should be? Will be shown in a full review message, this was a comment message, but thanks for your advise is that defined only in ITU and IETF cannot define its technology, or is it agreeing on a joint definition so IETF is just following ITU in some terms. *This* document is seeking IETF consensus. If that consensus is reached all definitions will be IETF definitions. If those definitions originate in ITU-T documents, they are also ITU-T definitions. If ITU-T documents make normative reference to IETF documents that contain definitions, those definitions are ITU-T definitions. Maybe I have missed the point of your comment. The point is why do we need other organisation definitions, or why did the author use those definitions, my point is any definition should relate to internet technology not references of other org, we may use other definitions for ours. Adrian
Re: Improving the ISOC Fellowship programme to attract people from under-represented regions into the IETF
The DT I am discussing has no clear problem to solve, the appointment is
not clear, I have been asking for a WG but only DT was done. The DT has no
milestones and no clear objectives, is it a DT or a WG. We don't need the
DT to adopt or agree on any real draft effort submitted, it is the
community that adopt or disagrees the output of any DT.
AB
On Saturday, October 12, 2013, Melinda Shore wrote:
On Oct 12, 2013 6:51 AM, Adrian Farrel
adr...@olddog.co.ukjavascript:_e({}, 'cvml', 'adr...@olddog.co.uk');
wrote:
I don't understand your assertion that there is no procedure in the IETF
to
support the existence of a Design Team.
I'd be sorry to see this discussion dragged down a procedural rathole.
Melinda
Gen-ART LC review of draft-ietf-mpls-tp-rosetta-stone-12
A comment can be a discussion/opinion for the draft that is at the IETF level, I did review but not completed writing the output. However, my comment may influenced comments today at WG level (usually the draft passed such review of WG LC) which did not send there comments to the IETF list, but the authors are gaining so far. I prefer that all comments should be at the IETF list after the IETF LC to give chance for discussion if needed (as a community DISCUSS position). AB On Sunday, October 13, 2013, joel jaeggli wrote: On Oct 13, 2013, at 7:32 AM, Abdussalam Baryun abdussalambar...@gmail.com wrote: Yes, my comment meant that it is a reply to the review message that there may be not clear definition from other participant point of view. Sorry my review is still not complete, I will send it. Do you mean my reply is not right, if I like to give a short comment before my full review. AB On Sunday, October 13, 2013, Adrian Farrel wrote: Hi, I am having sever difficulty parsing all of the information from your comment. And currently cannot see anything actionable by the authors. The draft does not list ITU in abbreviation, Loa has answered why this is not necessary. You mean that IETF agrees to do that as per a RFC passed or community awareness. there are many terminology not clear but more general definition. I prefer specific defining. This comment gives us nothing to go on! Which terminology do you find not clear but is a more general definition? And why is this a problem? You cannot expect the authors to fix or even discuss something if you do not show them what you are talking about. I am talking about the draft in overall, I will do my review if time is available. Insubstantial comments during the last call by someone who claims to have not reviewed the document are rather condescending. If you were the author what would you do with this feedback? Expectations of collegiality require a certain respect for common purpose, and the purpose of the last call is to surface remaining issues of substance, test for consensus and move on. (2418 section 8) Also many times refers to references to define without mentioning what was that definition, What do you mean? Can you give an example and say how you think it should be? Will be shown in a full review message, this was a comment message, but thanks for your advise is that defined only in ITU and IETF cannot define its technology, or is it agreeing on a joint definition so IETF is just following ITU in some terms. *This* document is seeking IETF consensus. If that consensus is reached all definitions will be IETF definitions. If those definitions originate in ITU-T documents, they are also ITU-T definitions. If ITU-T documents make normative reference to IETF documents that contain definitions, those definitions are ITU-T definitions. Maybe I have missed the point of your comment. The point is why do we need other organisation definitions, or why did the author use those definitions, my point is any definition should relate to internet technology not references of other org, we may use other definitions for ours. Adrian
Re: Improving the ISOC Fellowship programme to attract people from under-represented regions into the IETF
I am part of the community design team as well because I participate with community more than the private hidden groups. I think that the draft is a true work open to IETF. I still did not get a reply to my request to know what is the DT authority, very strange name without any procedure in IETF, please explain, AB On Fri, Oct 11, 2013 at 8:40 AM, Eggert, Lars l...@netapp.com wrote: Hi, I'm part of the design team. SM has written this document to begin a discussion with the broader IETF. The document does not have the consensus of the design team, and it is therefore obviously not a recommendation by the design team. Lars On Oct 10, 2013, at 20:10, S Moonesamy sm+i...@elandsys.com wrote: Hi Jari, Here's is a draft about improving the ISOC Fellowship programme to attract people from under-represented regions into the IETF. The draft builds upon the ISOC work, proposing adjustments and additional efforts, with the goal of enabling more sustained and active participation by contributors from under-represented regions. In a blog article ( http://www.ietf.org/blog/2013/04/diversity/ ), it is mentioned that: The design team will present their recommendations to the community, and engage in the discussion. Recommendations with community support will be taken forward. The draft only makes suggestions instead of recommendations. I am copying this message to ietf@ietf.org so that the community can comment about the draft. Regards, S. Moonesamydraft-ddt-fellowship-03.txt
Re: Last calling draft-resnick-on-consensus
Hi Pete, I object if the draft excludes remote participants opinions/feedbacks, the IETF WG list is the main place for measuring consensus not a physical limited room located in a region. Some WGs' Chair just follow room's consensus, or f2f participants arguments, which is not best practice relating to IETF procedures. The most important facility of IETF is that it works/decides remotely with individuals signatures/confirmations. AB On Fri, Oct 11, 2013 at 4:02 AM, Pete Resnick presn...@qti.qualcomm.comwrote: On 10/8/13 8:56 AM, t.p. wrote: 1) It does not state its target audience until, perhaps, the reference in the Conclusions, to WG Chairs. [...] Are ADs assumed to be above and beyond the considerations in this I-D:-( An excellent point. No, *every* consensus caller in the IETF should in my view be taking these points into consideration, ADs and chairs alike. The examples are full of WG/chair stories, but exactly the same kinds of things should happen, IMO, when ADs make consensus calls. As I said elsewhere, my primary (though not sole) audience is IETF leadership (ADs, chairs, editors, secretaries, etc.) and experienced IETFers who already understand the basics of our process and/or might some day wish to be in such roles. Hopefully the document is somewhat accessible to newer or once-in-a-blue-moon participants, but I hope the main consumers of this document are folks who need to make consensus calls or might some day. 2) There is an extensive discussion on the show of hands and the hum. What technology allows you to conduct those on a mailing list? I don't really talk about mailing lists, and I think you're right that it's worth spending at least a bit of time on in the document. In fact, neither a hum or a show of hands (messages?) on a mailing list makes a bunch of sense. Methodologically, I think the best way for chairs (or ADs) to deal with a mailing list is to checkpoint every so often, summarizing issues and perhaps even keeping an issues list, and then explicitly calling the consensus: I hear that people are in favor of X and I haven't heard strong objections. Unless there's anyone who can't live with X, I am going to say that we have consensus for it. It's the same sort of thing I describe for f2f conclusions of consensus. I think that's worth pointing out. 3) References to working groups with 100 active participants sound like a chimera. The only place where there's mention of large groups is in the last two sections, which are specifically the extreme examples. They are illustrative examples of the worst case scenario, not meant to be representational of the common case. 4) Five people for and one hundred people against might still be rough consensus. Can you see the presumption in that? Read on and the following text makes it clear that five are 'right' and one hundred 'wrong', but you are presuming that for is the right answer. Yes, that's the example I've used. In this example, the five people have made their case for a technical solution, one person has made an objection, the five people fully address the objection, and therefore there is rough consensus. So in this case consensus was for. The example is meant to show that 100 people blindly piling on the against side does not make them right and does not change the consensus. The right answer to a consensus call is a consensus,which can be against, as much as for, something that does not seem to be contemplated here. Sure. But that would be a different example. I don't understand your concern here. 5) Good WG chairs, and happily there are plenty of them, make their presumptions plain, as in asking for information about implementations at or around judging consensus. The views of someone who has independently produced rough code is then likely to outweigh those of a dozen people who have not, so three such expressing a view in one direction will prevail over several dozen who have not in the opposite direction. (This is all right as far as it goes, but I would like the views of users and operators to count for even more, since it is they who have the most to gain or lose; but sadly, their representation here is small and often not apparent). You quote Dave Clark's aphorism but then ignore half of it. Two things about this: 1. This document is about how we can come to consensus, not about the criteria around which we get that consensus (of which running code is one). And interesting document could be written about how we do (and sometimes don't) take running code into account, but it's not this document. 2. I take issue with one thing you do say above: The views of someone who has independently produced rough code is then likely to outweigh those of a dozen people who have not. I think this is actually wrong: It is not that the implementer's view is given more weight *because it came from the implementer*; that
Re: Last calling draft-resnick-on-consensus
Reviewer: Abdussalam Baryun Date: 11.10.2013 Last Call For the General Area I-D reviewed: draft-resnick-on-consensus-05 ++ Hi Pete and Jari, The documents provide important examples which are real within IETF, and needs to be studied/analysed more as case studies. Such real examples should be documented by historical documents which will help future work like this to refer to as real incidents. However, I support the idea of the draft subject to the below five requirements (the sixth is recommendation): 1) The draft should include remote participants input to the consensus process or path. The mailing list should be the main place for consensus measuring its roughness in the Internet community (not in only rooms or in hidden design teams). 2) The document does not mention the editor's task and how to work with discussions or chairs. If the editors are 5 most active participants in the WG then they are ruling the WG, and they can even discourage inputs by just disagreeing. I in MANET WG experienced many examples mentioned in your document, which I think will help future new participants to make better impacts on ietf WGs. I request explaining editors input and Chair's in such examples/situations. Editors and Chair are the ones facilitating on the path (i.e. consensus, as mentioned in draft). 3) The document does not mention the destinations of *consensus paths* within IETF. What you mean by destination? For me the destination is to submit the best document to IESG, or to Adopt an interesting document as WG document. Many individuals may not get to thoes destinations because of IETF WG Chair's methods. I recommend as you solve the *path* as it is consensus, but also correcting the path to get to correct destination only if we identify the destination. I request to define the destination and to define what is engineering reasons in agreeing and disagreeing (in IETF some times discussions are only politics not engineering, which makes problems in document qualities). 4) In the abstract you use *WE*, I object to use that word only if defined; do you mean all community or you mean majority, or minority, or management, or f2f participants or remote participants, or WG chairs, or ADs, etc. In my thoughts the meeting humming majority are the North America participants (i.e. check ietf statistics), but if you include remote participants of IETF in the draft then becomes diversified majority. Humming is used only in meetings not on lists, you may think of another way to do it on the list. Suggest/request to add in the abstract that this document should be as information to the training of WG Chairs. Also the abstract should include what is mentioned in the conclusion of *the way of thinking to get to participation decisions*. Please amend the abstract: draft-05Abstract: The IETF has had a long tradition of doing its technical work through a consensus process, taking into account the different views among IETF participants and coming to (at least rough) consensus on technical matters. In particular, the IETF is supposed not to be run by a majority rule philosophy. This is why we engage in rituals like humming instead of voting. However, more and more of our actions are now indistinguishable from voting, and quite often we are letting the majority win the day, without consideration of minority concerns. This document is a collection of thoughts on what rough consensus is, how we have gotten away from it, and the things we can do in order to really achieve rough consensus. Note (to be removed before publication): This document is quite consciously being put forward as Informational. It does not propose to change any IETF processes and is therefore not a BCP. It is simply a collection of principles, hopefully around which the IETF can come to (at least rough) consensus. ABamend The IETF has had a long tradition of doing its technical work through a WG consensus process [reference], taking into account the different views among IETF participants and coming to better (at least rough) consensus on technical and procedural matters. In particular, the IETF is supposed not to be run by a majority rule philosophy but an engineering community rule philosophy. This is why particpants engage in rituals like humming instead of voting within meetings. The results of consensus should have good engineering reasons. However, more and more of the IETF discussions/actions are now indistinguishable from voting, and quite often Chairs are letting the majority win the day, without much consideration of minority concerns. This document is a collection of thoughts on what a fair rough consensus is like, how IETF participants have gotten away from it, and the things they should do in order to really friendly guide for rough consensus achievement. The point of this document is to get all community to think about how IETF community is coming to better decisions in the IETF, to make sure participants avoid
Re: Improving the ISOC Fellowship programme to attract people from under-represented regions into the IETF
I did not like the change of the title which was suggested in diversity list. the first title was related to IETF, because we need to attract more other regions in IETF or to facilitate the improve of other region's participation. The draft's solution was to recommend fellowship (should not be the only marketing way), which made it distract its real value. I suggest to see how this fellowship is coordinated with IETF and how much it attracts (real results needed), this will help the program managers to know how IETF sees the program from the community point of view (not management of ietf or management of the program). AB On Friday, October 11, 2013, Jari Arkko wrote: we need to keep the flexibility of bringing in someone new agree But my main issue is that the draft sounds like its trying to take over and redefine an ISOC program, which I don't think the IETF can or should do. The ISOC program has a purpose, a history and at least from my perspective is working pretty well with the budget it has available. I'm not sure we can actually improve it much. agree, of course. at best we can provide input. but it really is an ISOC program. Jari
Re: Montevideo statement
I like your approach and comments, and I think that our ietf leaders are not always leaders but in IESG they are the managers. Mostly ietf ruled by community consensus not presidents, so we have many leaders including you and some others may be additional leaders for the community. The ietf wants feedback because there are not less than 50 leaders in ietf that lead the Internet community or leaders that make/discover things for the community when they participate. I really want to say the important thing about leaders that they have followers (not statements). Managers have workers and they may represent organisation decisions and statements. The body that is managing the decisions of ietf can make representation statements, but leader statements has no value if there is no followers. Therefore, IMO, if there is no time for asking feedback of community then the IETF chair can ask the IESG, to support such represent statement. Otherwise we wait to review the community feedback for two weeks. AB On Thursday, October 10, 2013, Dave Crocker wrote: Folks, There are a few things that we should consider rather more carefully than we've been doing, beyond a few of the postings. (I'd especially like to suggest that there be more careful review of Andrew Sullivan's postings on the thread, since he raises essential point, in my view.) In any event: 1. In spite of calling itself a press release (at the bottom) and having gone through an ISOC media person, what was released was not a press release. Neither in form nor substance. Its title says statement, and the bottom list of people is in the style of a signature list, rather than merely listing attendees -- and note that Jari does characterize this as being signed. Hence what was released was in the style of a formal statement, issued under the control of its signatories. 2. The statement does not merely say that these folk met and discussed stuff. It says they agreed to stuff, or at leased called for stuff. 3. These people were acting as representatives of their organizations; hence the use of their titles. And the statement does not explicitly say they were speaking only for themselves. So their agreement to the Statement needs to be taken as their speaking for their organizations. 4. Having both IETF Chair and IAB Chair makes it look like there were two organizations being represented, but in practical terms there really weren't. 5. It has been noted that the IAB is largely autonomous for something like this; hence the IAB Chair formally only has to answer to the IAB itself, and we are told he was in this case. What this begs is a question about the IAB acting independently of the IETF community... My initial reading of the Statement was that it was quite benign, so that any concern about it's speaking for the IETF was purely a matter of principle. In that regard, I considered it a nice test case for some basic IETF discussion of the authority of our 'leaders' to make statements on our behalf but without our review or approval. Then I re-read the statement more carefully and landed on: They called for accelerating the globalization of ICANN and IANA functions, towards an environment in which all stakeholders, including all governments, participate on an equal footing. 5. It's not at all clear what accelerating the globalization means here, since the statement offers no context for whatever 'globalization' efforts with ICANN and IANA are happening. Worse, this item is entirely political, involving organizations with which the IETF has on-going agreements and reliance. Further, I believe there is no IETF context -- nevermind consensus -- for the topic. As far as I know the IETF has no basic discomfort with its relationship with IANA, for example. We might individually make guesses about what this item in the Statement means, but my point is that a) we shouldn't have to, and b) it has no context within the IETF community. For any of our 'leaders' to make agreements on our behalf, about political issues of organizations with which we have formal arrangements -- and probably any other organizations -- is significantly problematic. As has been noted, there are practical and formal limits to requirements for getting IETF rough consensus. Any constraints on public statements by IETF leaders needs to balance against those limits, if we are to allow folk to speak publicly at all. 6. The realities of trying to get IETF community rough consensus means that anything requiring timely action cannot seek formal consensus. To that end, we need to distinguish between 'review' and 'approval'. IETF community review can be very quick indeed, though probably not less than 24 hours, if the range of review comments is to be a good sampling of the community. In the current example, community review quickly noted the erroneous phrasing that confuses
Re: Montevideo statement
I agree to appoint leader under clear procedures, so I am not sure of representing without procedure is authorised in ietf, but I trust that ietf leaders do practice procedure, but not sure if discussion meant that there was something missing in this statement practice. AB On Wednesday, October 9, 2013, Arturo Servin wrote: We appointed our leaders, we have to trust them. They had to do a call, an important one and they made it. I support what they did, that is what we chose them for, to represent us and be our voice. We cannot expect that they ask our opinion for every decision they made, that is not practical or possible in today's world. Sometimes like in this statement, we need to trust in their good judgment. My 20 cents, as On 10/9/13 12:00 PM, John C Klensin wrote: --On Wednesday, October 09, 2013 02:44 -0400 Andrew Sullivan a...@anvilwalrusden.com javascript:; wrote: ... That does not say that the IAB has issued a statement. On the contrary, the IAB did not issue a statement. I think the difference between some individuals issuing a statement in their capacity as chairs and CEOs and so on, and the body for which they are chair or CEO or so on issuing a similar statement, is an important one. We ought to attend to it. Please note that this message is not in any way a comment on such leadership meetings. In addition, for the purposes of this discussion I refuse either to affirm or deny concurrence in the IAB chair's statement. I merely request that we, all of us, attend to the difference between the IAB Chair says and the IAB says. Andrew, While I agree that the difference is important for us to note, this is a press release. It would be naive at best to assume that its intended audience would look at it and say Ah. A bunch of people with leadership roles in important Internet organizations happened to be in the same place and decided to make a statement in their individual capacities. Not only does it not read that way, but there are conventions for delivering the individual capacity message, including prominent use of phrases like for identification only. Independent of how I feel about the content of this particular statement, if the community either doesn't like the message or doesn't like this style of doing things, I think that needs to be discussed and made clear. That includes not only at the level of preferences about community consultation but about whether, in in the judgment of the relevant people, there is insufficient time to consult the community, no statement should be made at all. Especially from the perspective of having been in the sometimes-uncomfortable position of IAB Chair, I don't think IAB members can disclaim responsibility in a situation like this. Unlike the Nomcom-appointed IETF Chair, the IAB Chair serves at the pleasure and convenience of the IAB. If you and your colleagues are not prepared to share responsibility for statements (or other actions) the IAB Chair makes that involve that affiliation, then you are responsible for taking whatever actions are required to be sure that only those actions are taken for which you are willing to share responsibility. Just as you have done, I want to stress that I'm not recommending any action here, only that IAB members don't get to disclaim responsibility made by people whose relationship with the IAB is the reason why that are, e.g., part of a particular letter or statement. john
Re: leader statements
There should be known limits for chairs, leaders, only if the procedures have mentioned no limits of representation. Trust is there but still there is also levels and limits for trust and representation. AB On Wednesday, October 9, 2013, Brian E Carpenter wrote: On 10/10/2013 08:27, Andrew Sullivan wrote: ... What I am not sure about is whether people are willing to accept the chairs acting in that sort of leader of organization role. If we do accept it, then I think as a consequence some communications will happen without consultation. For a CEO is not going to agree to issue a joint communiqué with someone who has to go negotiate the contents of that communiqué (and negotiate those contents in public). If we do not accept it, then we must face the fact that there will be meetings where the IETF or IAB just isn't in the room, because we'll have instructed the chairs not to act in that capacity. I've been there in the past, as IAB Chair, ISOC Board Chairman, and IETF Chair. Either we trust our current and future chairs, on certain occasions, to speak in our name without there being a discursive debate in advance, or we will have no voice on those occasions. If there was a pattern of I* chairs subscribing to statements that the relevant community clearly found quite outrageous, there might be an argument for having no voice. I suggest that there is no such pattern. There may be quibbles over wording sometimes, but that is inevitable when several different stakeholder organisations have to agree on wording. The wording is inevitably a compromise; it can't be otherwise. It's perfectly reasonable to ask our chairs to invite debate in advance when that is possible; but in many of these cases, it simply isn't. It's also perfectly reasonable that people should comment on the wording even after it's set in stone; that helps us to do better next time. If we nominate good candidates for our leadership positions, and send thoughtful comments to the NomCom (and the IESG and IAB for their nominating duties), we won't get leaders who put their names to anything outrageous. We should trust our chairs to act as figureheads and leaders towards the outside world. Brian Carpenter
Re: Last calling draft-resnick-on-consensus
I agree with Melinda, IETF WG Chair is the key to practice guiding the group to clear consensus, otherwise guide them to best/productive discussions related to improvements in the work or in the consensus. AB On Sun, Oct 6, 2013 at 10:14 PM, Melinda Shore melinda.sh...@gmail.comwrote: On 10/6/13 1:03 PM, Jari Arkko wrote: My goal is to publish it as an Informational RFC. It is an explanation of principles and how they can be applied to productively move IETF discussions forward. While there is no change to IETF processes or any presumption that guidance from this document must be followed, I have found the document very useful. It has been referred to numerous times in IETF and IESG discussions. Consensus is hard and many WG discussions have complex trade-offs and differing opinions. I believe having this document become an RFC would help us apply the useful principles even more widely than we are doing today. Glad to hear it - I think this is an enormously useful document. I'm wondering if wg chair training at an upcoming meeting can't be spent on it. Vancouver's too soon, but what about London? Melinda
Re: [Tools-discuss] independant submissions that update standards track, and datatracker
Hi Michael, I agree that it should appear in related WG's field or area. I see in IETF we have WGs documents list but not areas' documents list, so the individual document may not be found or discovered. I think any document of IETF should be listed in its field area or related charter, but it seems like the culture of IETF focusing on groups work not on the IETF documents. For example, when I first joined MANET WG I thought that RFC3753 is related because it is IETF, but in one discussion one participant did not accept to use that document even though it was related. Fuethermore, some WGs don't comment on related documents to their WG, which I think this should change in future IETF culture (e.g. there was one individual doc that was requested by AD to comment on by the WG but no respond). Therefore, IMHO, the IETF is divided by groups with different point of views/documents and they force their WG Adopted-Work to list documents (not all related to Group-Charters), but it seems that managemnet does not see that there is a division in knowledge or in outputs of the IETF, which a new comer may see it clearly. I recommend to focus/list documents related to Charter, not related to WG adoptions, because all IETF document are examined by IESG. AB On Tue, Oct 1, 2013 at 7:29 PM, Michael Richardson mcr+i...@sandelman.cawrote: This morning I had reason to re-read parts of RFC3777, and anything that updated it. I find the datatracker WG interface to really be useful, and so I visited http://datatracker.ietf.org/wg/nomcom/ first. I guess I could have instead gone to: http://www.rfc-editor.org/info/rfc3777 but frankly, I'm often bad with numbers, especially when they repeat... (3777? 3737? 3733?) While http://datatracker.ietf.org/wg/nomcom/ lists RFC3777, and in that line, it lists the things that update it, it doesn't actually list the other documents. Thinking this was an error, I asked, and Cindy kindly explained: http://datatracker.ietf.org/wg/nomcom/ lists the documents that were published by the NOMCOM Working Group. The NOMCOM Working Group was open from 2002-2004, and only produced one RFC, which is RFC 3777. The RFCs that update 3777 were all produced by individuals (that is, outside of the NOMCOM Working Group), and so aren't listed individually on the NOMCOM Working Group documents page. I wonder about this as a policy. Seeing the titles of those documents would have helped me find what I wanted quickly (RFC5680 it was)... While I think that individual submissions that are not the result of consensus do not belong on a WG page. But, if the document was the result of consensus, but did not occur in a WG because the WG had closed, I think that perhaps it should appear there anyway. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works ___ Tools-discuss mailing list tools-disc...@ietf.org https://www.ietf.org/mailman/listinfo/tools-discuss
RE: [Tools-discuss] independant submissions that update standards track, and datatracker
While I think that individual submissions that are not the result of consensus do not belong on a WG page. Where do they belong? I prefer that they belong under the Area page, but is there an area page, not sure why was that not a good idea. But, if the document was the result of consensus, but did not occur in a WG because the WG had closed, I think that perhaps it should appear there anyway. I agree, but still I think an area page is required, some day in the future may be the Area will expire or be changed by the community, so don't we should think where is the history of these areas. Also our procedural RFCs and BCPs are not related to General Area, I prefer to see them all under an area related, some day this general area may change as well (may be called Procedural Area). I agree that the way documents are related to IETF-fields or IETF-areas is not an easy way for tracking information, also the documents are not much connected but more separated (IETF is divided in WGs which creates division/differences in documents of the same field). As once one AD proposed Cross-Areas in IETF, I want to add proposing Cross-WGs, all are responsible for related issues in IETF (i.e. Areas and Groups). AB
Re: ORCID - unique identifiers for contributors
I agree with both, but maybe the problem is that people from academia are not participating enough to report to ADs their concerns (e.g. what is bad in ietf, or lack of diversity), on the other hand, people from industry are more organised and don't need/want the academians ideas/participations :-) AB On Wed, Sep 18, 2013 at 6:46 AM, Riccardo Bernardini framefri...@gmail.comwrote: On Wed, Sep 18, 2013 at 3:14 AM, George Michaelson g...@algebras.org wrote: Currently, IETF standards activity carries little or no weight for an academic career profile. It doesn't appear to have a weighting compared to peer review publication. I think this is a shame, because the contribution is as substantive, if not more so. And, since time is limited and choices have to be made, I believe good students/postdocs don't come into our space because the payback isn't there compared to submission into the peer-review process. (happy to be corrected. this is a belief, not a proven theory) I can confirm your theory, at least regarding me. I come from academia. I came with some enthusiasm, happy to try to get involved in IETF activities; I subscribed to few WG mailing list, but after some time I discovered that (unfortunately) the payback for unit of work was much less than just publishing scientific paper. So, I unhappily unsubscribed from most of the ML and I stay here, lurking in the background, waiting for some interesting subject... Too bad.
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On 9/9/13, Owen DeLong o...@delong.com wrote: I have to agree with Lorenzo here again. This document seems to me to be: 1. Out of scope for the IETF. Please define what is the IETF scope? IMHO, IETF is scoped to do with IPv6 devices requirements and implementations. Do you think there is a RFC that considers thoes requirements? 2. So watered down in its language as to use many words to say nearly nothing. No, the draft says things, I think if you read nothing that you did not read then. If you read, then what is your definition of saying nothing? 3. Claims to be informational, but with so many caveats about the nature of that information that it's hard to imagine what meaningful information an independent reader could glean from the document. I think this was mentioned clearly in the draft, which readers can understand. Finally, given the spirited debate that has extended into this last call (which I honestly wonder how this ever saw last call over the sustained objections) definitely does not appear to have even rough consensus, nor does it appear to have running code. IMHO, the LC is not for consensus, but it is for us to send the IESG our comments, and then they decide what is the IETF decision. Why is there such a push to do this? Why is there a push to water-down it? I still was not convinced by your argument. However, Lorenzo comments should be considered by the draft as the authors are working on. AB
Re: Equably when it comes to privacy
I agree with you SM, politics and considering countries names in that way, that is out of scope of IETF. Comments below, AB On 9/8/13, SM s...@resistor.net wrote: At 07:07 08-09-2013, Jorge Amodio wrote: You mean like Pakistan, Iran, Libya, Syria, Saudi Arabia There were people from Pakistan who participated in the IETF. I recall an email exchange where a person from that country received an unpleasant comment from someone who is part of the IETF leadership. That is rude behavior, which I may experienced in IETF. In my opinion a discussion about Country X or Country Y would take the thread downhill. It can also have a chilling effect. I totally agree, by having more participants from all world's countries, makes the IETF more diverse, and by silence to such rude behavior means we are welcoming less diversity. At 05:14 08-09-2013, Phillip Hallam-Baker wrote: Another worrying aspect of [censored] is that it is named after[censored]. They seem to be looking to make [censored] out of us. They certainly seem to be endorsing [censored]. What should we think if the [censored] had a similar program codenamed [censored]? It would not look good. It is not good behavior if IETF just watches lists and does not make mentoring to its participants old/new comers. AB Regards, -sm
Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
On 9/6/13, Brian E Carpenter brian.e.carpen...@gmail.com wrote: Tell me what the IETF could be doing that it isn't already doing. I'm not talking about what implementors and operators and users should be doing; still less about what legislators should or shouldn't be doing. I care about all those things, but the question here is what standards or informational outputs from the IETF are needed, in addition to what's already done or in the works. I think we need to rethink the way we do protocols or the way security WGs do standards. It will be easy to blame/ask the Security Area participants/experts of what was not done or what should been done, however, this area seems more as a cross-area, and I suggest that the IETF re-thinks or re-structures the Security area and/or its WGs' Charteres. AB
Re: New Mailing List: Internet governance and IETF technical work
On 9/4/13, IAB Chair iab-ch...@ietf.org wrote: As requested by the community, the IAB has decided to open a mailing list to discuss topics regarding the intersection of Internet governance and IETF technical work. In particular, this list will focus on issues relating to Internet governance and regulation, including the 2014 ITU Plenipotentiary Conference, and their potential to impact the future of the Internet architecture. In that regard, the community is invited to participate in this mailing list with an eye toward both receiving more information about these events and advising the IAB by identifying key issues for which the board may wish to provide technical clarifications on how certain policy outcomes could impact the Internet architecture. - Because Internet governance is often a sensitive topic and passions often run high, while anyone from the IETF community is welcome, those who join the list will be expected to stay within the parameters above (e.g., receiving information and providing constructive advice to the IAB) and to comport themselves in a respectful way toward all. To encourage inclusion, we are asking that individuals avoid repetitive or excessive posting. The IAB's ITU-T Coordination Program Leads (currently Ross Callon and Joel Halpern) may, at their sole discretion, remove or moderate individuals whose posting is not of assistance to the IAB or, in the opinion of the Program Leads, of benefit to the IETF community. I am confused of what is asked to an individual in ietf community, first I understand you want invite me to discuss a topic on a list but in the same time you don't want excessive posting (while agreeing that all don't want repetition). Discussions may need many postings related to our interests. People have different ways of measuring posts/discussions, Do you mean the definition of excessive is 5 posts per week? However, I am sorry that it seems that I will not join that list as long I don't understand the value of these discussion conditions, and don't need excessive conditions managing my volunteering participation rights. AB
Re: REVISED Last Call: draft-ietf-pwe3-vccv-impl-survey-results-02.txt (The Pseudowire (PW) Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results) to Informational RFC
Thanks Andrew, I am happy to see a survey draft, I never seen one before in IETF, however, if there was a survey done before in IETF, it will be interesting to mention that if you think necessary related. On 9/5/13, Andrew G. Malis agma...@gmail.com wrote: Abdussalam, Many thanks for your review and comments on the draft. I have some answers inline. On Wed, Sep 4, 2013 at 10:24 PM, Abdussalam Baryun abdussalambar...@gmail.com wrote: The Reviewer: Abdussalam Baryun Date: 05.09.2013 I-D name: draft-ietf-pwe3-vccv-impl-survey-results Received your Request dated 04.09.2013 ++ The reviewer supports the draft subject to amendments. Overall the survey is not easy to be used as source of information related to such technology users, but easier as source of information related to respondings of companies. AB I prefer the title to start as: A Survey of .. Andy The draft is reporting the results of the survey, rather than being the survey, so the title couldn't start as you suggested. A possibility could be The Results of a Survey on Pseudowire (PW) Virtual Circuit Connectivity Verification (VCCV) Implementations, but I think the existing title is more concise. Yes that was my aim, thanks, Abstract This survey of the PW/VCCV user community was conducted to determine implementation trends. The survey and results is presented herein. AB How did the survey determine implementations related to users (are they general known or uknown or chosen by authors...etc). What kind of results? Andy The survey was of service providers deploying pseudowires and VCCV. The users, in this case, are service providers. ok, if described in the document, and how were they selected, is it on there work volume basis, or etc. AB the abstract starts interesting but ends making the results not clear what it was (good, reasonable, expected, positive, had conclusions..etc)? AB The draft states that it has no conclusion, because it is not intended for that but to help in knowing results to help in other future drafts. However, the abstract mentions that the survey conducted to determine (not understood how to determine without conclusions or analysis). Andy It wasn't the job of the people conducting the survey to draw conclusions from the results, it was for them to report the results so that the working group could collectively draw conclusions in their ongoing work. At the time, the WG needed information on which combinations of PW and VCCV options were actually in use, and the survey was used to collect that information. Ok, the WG needs information, but if I still remember, the document does not state/define such need to match the survey. Introduction In order to assess the best approach to address the observed interoperability issues, the PWE3 working group decided to solicit feedback from the PW and VCCV user community regarding implementation. This document presents the survey and the information returned by the user community who participated. AB the introduction needs to show the importance of the survey, or what makes such decision from the WG (i.e. seems like the WG has not cover all types of community, not sure)? AB Why did the WG decide the survey by using questionnair? Andy The part of the Introduction on page 3 provides the background, rationale, and importance of the survey. We used a questionnaire as that form of survey is easiest for the respondents and allowed us to use SurveyMonkey to conduct the survey. The questionnaire method has advantages and disadvantages, so if on section mentions the result validity in linked to method, I think the reader will know how much he can depend on such results. AB suggest amending the document presents the questionnair form questions and information returned .. Andy We could change the sentence to say This document presents the survey questionnaire and the information returned by the user community who participated. my language may not be perfect, but I agree that amending it to show survey method and method of result collection. Sections 1.1 1.2 and 1.3 ..questions based on direction of the WG chairs.. There were seventeen responses to the survey that met the validity requirements in Section 3. The responding companies are listed below in Section 2.1. AB Why were thoes methodologies and why that way of quetions chosen for this survey? The answer to this is important for the document (informational) and future drafts. Andy While the survey questions were originally suggested by the WG chairs, they were written by the survey authors and reviewed by the WG prior to the collection of results. We could add that if you like. I think that is an important information, because the WG is part of the community, not sure if you have service providers respondent which are joined in the WG, if so then that information is important also, even
Unbearable related to misspellings ideas (was Re: draft-moonesamy-ietf-conduct-3184bis)
On 9/1/13, Eduardo A. Suárez esua...@fcaglp.fcaglp.unlp.edu.ar wrote: What is unbearable to me is that in more than one discussion in a mailing list someone's opinion is censored because misspell their ideas or opinions. I don't think that is unbearable, usually in communications between IP devices/machines it happens that words or digits are missed or changed but because the receiver is able to detect the error and find out the mistake by the context of the message, so it corrects the words/digits. Therefore, I recommend all (poster and reader, native and non-native English speakers) to try to detect errors and correct them to make ideas or opinion clear at receiver. We always get misspellings in I-Ds, and even RFCs (some even not made errata because understood/detected-and-corrected), therefore, we are use to it, so we can do same in our discussions. AB
Re: REVISED Last Call: draft-ietf-pwe3-vccv-impl-survey-results-02.txt (The Pseudowire (PW) Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results) to Informational RFC
The Reviewer: Abdussalam Baryun Date: 05.09.2013 I-D name: draft-ietf-pwe3-vccv-impl-survey-results Received your Request dated 04.09.2013 ++ The reviewer supports the draft subject to amendments. Overall the survey is not easy to be used as source of information related to such technology users, but easier as source of information related to respondings of companies. AB I prefer the title to start as: A Survey of .. Abstract This survey of the PW/VCCV user community was conducted to determine implementation trends. The survey and results is presented herein. AB How did the survey determine implementations related to users (are they general known or uknown or chosen by authors...etc). What kind of results? AB the abstract starts interesting but ends making the results not clear what it was (good, reasonable, expected, positive, had conclusions..etc)? AB The draft states that it has no conclusion, because it is not intended for that but to help in knowing results to help in other future drafts. However, the abstract mentions that the survey conducted to determine (not understood how to determine without conclusions or analysis). Introduction In order to assess the best approach to address the observed interoperability issues, the PWE3 working group decided to solicit feedback from the PW and VCCV user community regarding implementation. This document presents the survey and the information returned by the user community who participated. AB the introduction needs to show the importance of the survey, or what makes such decision from the WG (i.e. seems like the WG has not cover all types of community, not sure)? AB Why did the WG decide the survey by using questionnair? AB suggest amending the document presents the questionnair form questions and information returned .. Sections 1.1 1.2 and 1.3 ..questions based on direction of the WG chairs.. There were seventeen responses to the survey that met the validity requirements in Section 3. The responding companies are listed below in Section 2.1. AB Why were thoes methodologies and why that way of quetions chosen for this survey? The answer to this is important for the document (informational) and future drafts. AB The reason of the survey's methodology should be mentioned in clear section, as the athors' opinion. Section 1.2 Form Why the form did not make security consideration related to implementations in the form questions? which then may be used in security section. Results section 2 AB are difficult to read or find related to section 1.2. AB Usually the section mixes between what was returned and what was given. It is prefered to have two separate sections as 1 (what was given including the form), and what was returned as results. Regards AB On 9/4/13, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'The Pseudowire (PW) Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results' draft-ietf-pwe3-vccv-impl-survey-results-02.txt as Informational RFC 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-09-23. 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 Most pseudowire Emulation Edge-to-Edge (PWE3) encapsulations mandate the use of the Control Word (CW) to carry information essential to the emulation, to inhibit Equal-Cost Multipath (ECMP) behavior, and to discriminate Operations, Administration, and Maintenance (OAM) from Pseudowire (PW) packets. However, some encapsulations treat the Control Word as optional. As a result, implementations of the CW, for encapsulations for which it is optional, vary by equipment manufacturer, equipment model and service provider network. Similarly, Virtual Circuit Connectivity Verification (VCCV) supports three Control Channel (CC) types and multiple Connectivity Verification (CV) Types. This flexibility has led to reports of interoperability issues within deployed networks and associated drafts to attempt to remedy the situation. This survey of the PW/ VCCV user community was conducted to determine implementation trends. The survey and results is presented herein. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pwe3-vccv-impl-survey-results/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pwe3-vccv-impl-survey-results/ballot/ No IPR declarations have been submitted directly on this I-D.
Re: draft-moonesamy-ietf-conduct-3184bis
On 9/1/13, S Moonesamy sm+i...@elandsys.com wrote: Hi Eduardo, At 23:19 31-08-2013, Eduardo A. Suarez wrote: I think both parties have to try to express clearly. Those who do not have the English as their native language should also try to do so. Agreed. What is unbearable to me is that in more than one discussion in a mailing list someone's opinion is censored because misspell their ideas or opinions. I'll try and rephrase the above. In some mailing list discussions a person's ideas or opinions are ignored because the ideas or opinions are either not expressed clearly or the ideas or opinions are not understood. I always think the problem of not understanding a message in IETF is not the fault of the transmitter, but it is the receiver's fault. The receiver SHOULD make more efforts to understand, or send a reply to request clarifications (specially in IETF WGs when discussing technical issues). The fault cannot be the used-language or the way the language is used, but the fault can be low performance of communication or low purpose of such work at receiver end. AB
Re: Rude responses
On Mon, Aug 26, 2013 at 5:36 PM, l.w...@surrey.ac.uk wrote: I experienced rude respondings in IETF list That would be when you tried to get April 1 RFCs discontinued. No, I experienced rude response from some participants including you, and regarding yours I received a private email from one director that he ask me not to reply to you because he wants to handle it with you privately. I request that the IETF Chair to stop you from sending me any further emails, because you are changing the subject to personal issues. AB From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Abdussalam Baryun [abdussalambar...@gmail.com] Sent: 25 August 2013 12:27 To: Pete Resnick Cc: dcroc...@bbiw.net; ietf@ietf.org Subject: Re: Rude responses (Was: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard) I experienced rude respondings in IETF list and in one WG list, I don't beleive that it is culture of IETF participants, but it seems that some people should understand to be polite and reasonable in such organisation business. Finally, the rude responding is not controled by the chair of thoes lists, therefore, thoes lists can be rude lists from time to time. AB
Re: Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
Reviewer: Abdussalam Baryun Date: 26.08.2013 As per the IESG request for review dated 19.08.2013 I support the draft, thanks, below are my comments, Overall The draft is about 3GPP Mobile Devices but the draft has no normative reference to such device. The title of the draft SHOULD mention that it is general profile or a proposal, where the abstract says *specifies an IPv6 profile* which means not general, so the title SHOULD say *An IPv6 profile*. Also the draft does not consider Mobile IP issues nor RFC5213 into requirements. From the doc the reviewer is not sure does the draft consider MANET issues or not needed for such devices or such connections? Abstract This document specifies an IPv6 profile for 3GPP mobile devices. AB suggest this document defines an IPv6 profile The document is missing an applicability statement section, which may be found in one paragraph in section 1.1, but the reviewer would like more details because the document is some how saying it is general requirements. AB On Mon, Aug 19, 2013 at 11:52 PM, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices' draft-ietf-v6ops-mobile-device-profile-04.txt as Informational RFC 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-09-02. 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 specifies an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). This document defines a different profile than the one for general connection to IPv6 cellular networks defined in [I-D.ietf-v6ops-rfc3316bis]. In particular, this document identifies also features to deliver IPv4 connectivity service over an IPv6-only transport. Both hosts and devices with capability to share their WAN (Wide Area Network) connectivity are in scope. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ballot/ No IPR declarations have been submitted directly on this I-D.
Re: Rude responses (Was: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard)
I experienced rude respondings in IETF list and in one WG list, I don't beleive that it is culture of IETF participants, but it seems that some people should understand to be polite and reasonable in such organisation business. Finally, the rude responding is not controled by the chair of thoes lists, therefore, thoes lists can be rude lists from time to time. AB On Thu, Aug 22, 2013 at 5:46 AM, Pete Resnick presn...@qti.qualcomm.comwrote: On 8/21/13 2:17 PM, Dave Crocker wrote: On 8/21/2013 11:58 AM, Pete Resnick wrote: AD hat squarely on my head. On 8/21/13 1:29 PM, Dave Crocker wrote: Oh. Now I understand. You are trying to impose new requirements on the original work, many years after the IETF approved it. Thanks. Very helpful. That's not an appropriate response. It is certainly not helpful to me as the consensus caller. And it is rude. Since you've made this a formal process point, I'll ask you to substantiate it carefully and also formally. The implication of your assessment is that IETF participants must not comment on the utility of comments by others. That's not what I said, and in fact if you look at the line immediately following what you quoted, you will see that I said: It's perfectly reasonable to say, This would constitute a new requirement and I don't think there is a good justification to pursue that line. It is not your complaint about the imposition of new requirements that is problematic, or your point that it is not useful to continue that line of discussion. Talk about the utility of a comment all that you want. It is the sarcasm and the rudeness that I am saying is unreasonable. Especially coming from a senior member of the community, the only purpose it seems to serve is to bully others into not participating in the conversation. If you think that the conversation has gone on too long, you're perfectly within rights to ask the manager of the thread (in this case, myself or the chairs), in public if you like, to make a call and say that the issue is closed. But again, the tactics displayed above are not professional and not reasonable rhetorical mode. I don't recall that being a proscribed behavior, since it has nothing to do with personalities. So, please explain this in a way that does not sound like Procrustean political correctness. I am not sure what the first sentence means. And I'm sorry that you believe that my stance on this is Procrustean. But the fact is that rude comments of this sort do not contribute to consensus-building in the least. For the record, I entirely acknowledge that my note has an edge to it and yes, of course alternate wording was possible. However the thread is attempting to reverse extensive and careful working group effort and to ignore widely deployed and essential operational realities, including published research data. I appreciate your input that you believe that some or all of the objectors are ignoring operational realities. Perhaps they are. But the fact is that Last Call is a time for the community to take a last look at WG output. If senior members of the community (among which there are several in this thread) are suspicious of the output, it *is* important to make sure that their concerns are addressed. Maybe they simply don't have all of the information. But maybe the WG has missed something essential in all that careful work. Both have historically happened many times. A bit of edge is warranted for such wasteful, distracting and destabilizing consumption of IETF resources. In fact an important problem with the alternate wording, such as you offered, is that it implies a possible utility in the thread that does not exist. It is far more distracting and destabilizing for the IETF to come out of a Last Call with experienced members of the community suspicious that a bad result has occurred, especially if the tactic used to end the discussion was sarcasm to chase people away from the discussion. You are looking at only the little picture. The consensus might end up on the rough side, but having the conversation has utility in and of itself. I find your edge much more disruptive to the conversation, making it much more adversarial than explanatory, and damaging the consensus that might be built. I think that lowers the utility of the output tremendously. pr -- Pete Resnickhttp://www.qualcomm.**com/~presnick/http://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478
Re: Rude responses (Was: Last Call: draft-ietf-spfbis-4408bis-19.txt
Hi Aaron, I will add that it depends on that is there some one stopping rude actions in IETF, or is it just free to post any respond. I know that the procedure of IETF does mention such actions, but I don't see practicings so far, AB On Fri, Aug 23, 2013 at 2:20 AM, Aaron Yi DING aaron.d...@cl.cam.ac.ukwrote: The line between being Rude and being Upfront is tricky and highly context dependent. Aaron Thomas
Re: Charging remote participants
Hi Hadriel, I agree that charging IETF participants with any money is not a good idea, but charging participants with some effort/work/contribution to do is needed. For example, participants SHOULD do some work in IETF, either review, authoring, attending-meetings, commenting on lists, etc. Otherwise the IETF will not develop. If someone just subscribe to the list with no contribution, that I will not call a participant. The reward/motivation from IETF to participants is to acknowledge in writting their efforts, which I think still the IETF management still does not motivate/encourage. IETF Remote Participants (IETFRP) SHOULD charge the IETF not the other way, because still the IETF ignores some IETFRP efforts (or even hides information that should be provided to the diverse community). AB On Fri, Aug 16, 2013 at 11:10 PM, Hadriel Kaplan hadriel.kap...@oracle.comwrote: Since the topic keeps getting raised... I think that charging remote participants any fee is a really terrible idea. One of the really great things about the IETF is its open and free (as in beer) participation policy. The real work is supposed to be done on mailing lists, and there's no charge or restriction on who can send emails. That policy is actually quite rare for standards bodies, and makes our output better not worse. Obviously we discuss things and do real work at physical meetings too, and they're not simply social occasions. At the end of the day we actually want people to come to the physical meetings, but the realities of life make that impossible for many. But charging remote participants for better tools/experience isn't the answer. At least for me, whenever I'm discussing a draft mechanism I actually *want* input from remote participants. I don't want it to be only from folks who can afford to provide input. I want it from people who can't get approval for even a $100 expense, from people who are between jobs, people from academia, and even from just plain ordinary users rather than just vendors or big corps. At one time we worried that free remote participation would lead to too many random participants to get work done, but that hasn't become a problem afaict. Please don't whittle it down further to only those who can afford it. I would do anything whatsoever to avoid charging remote participants, even if it means raising the fee for f2f attendees to subsidize remote-participant tooling costs. In that vein, I think a lot of the f2f attendees get our reg-fee paid by our employer and another $50 or even $100 isn't going to make a bit of difference for us - for those whom it would make a difference, I'd create another category of f2f registration fee like 'Self-paying Attendee' or some such. Selecting the new category would drop your fee by the $50 or $100, but wouldn't change what gets displayed on your badge or anything. It would be purely optional, with no guilt attached for not paying it and no visible difference to anyone else. Just put some words on the registration form page saying something like If you cannot expense your registration fee, please select the 'Self-paying Attendee' category or something like that. Or make it some checkbox thingy. I believe the majority of folks who can expense it will not have difficulty expensing a 'Regular Attendee' charge so long as it doesn't say we opted to pay more. -hadriel p.s. Even from a purely practical standpoint, charging remote participants raises a lot of issues - we debate incessantly just about the f2f day-pass, and that's nothing compared to this. For example: if things break during the meeting session, do we re-imburse them? Do we pro-rate the re-imbursement based on how many of their meetings had technical issues with audio or video? Do we charge a flat fee for the whole week of meetings, or just charge per meeting session, or depending on how long the session is? Do we charge students a different rate, like we do f2f reg-fees? Do we need to provide tech support with a specific SLA? This while thing is a can of worms. It's not worth it.
Re: The Friday Report (was Re: Weekly posting summary for ietf@ietf.org)
I agree with you John, I also not objecting it but wanted more meaning into the report when I receive it, as I suggested before for clarifications. I don't think majority in IETF think it is meaningless so that is why I want to clarify the meaning and discuss what most may not want to discuss. If this was already discussed could some one point me to a discussion about a weekly post that is done for long and which it may be meaningless by some and understoond the meaning by others. I will add that the report can be misleading, and that I have no intention to write a code for something that is not IETF procedure, but I have intention to clarify such message received each week in IETF that has a lack of information or meaning agreed on. AB On Sun, Aug 4, 2013 at 9:55 PM, John C Klensin john-i...@jck.com wrote: --On Sunday, August 04, 2013 19:53 + John Levine jo...@taugh.com wrote: If there is a serious drive to discontinue the weekly posting summary - I strongly object. As far as I can tell, one person objects, everyone else thinks it's fine. I do not want to be recorded as thinking it is fine. If nothing else, I think was is being reported is meaningless statistically (which doesn't mean people can't find value in it). However, I do not object to its being posted as long as it isn't used to justify personal attacks on individuals for their ranking. It seems to me that isn't quite what you said, rough consensus or not. best, john
Re: Anonymity versus Pseudonymity (was Re: [87attendees] procedural question with remote participation)
Hi Adam, I don't agree with you. I am a remote participant (2 years and never attended meetings) in the IETF organisation, do you think that IETF is fare in treating remote participants? I think the current IETF direction is in favor of attended-meeting participants, so IMHO one reason of some hidding their name is because the IETF still is not yet able to control wrong behaviour of participants who think they are well known. Thoes wrong behavior abuse peoples rights in IETF. If some are well known, the reason is because they got better opportunity in going to meetings, or that majority of participants are from two regions (North America+Europe). For me the IETF reputation is about 40% (evaluated by asking close friends that did not participate and including the way I was treated within 2 years), still needs more work to build its reputation (e.g. I think some old participants need guidance to IETF visions). For me participants' good reputation depend on their reactions: if I get a nice reply from them, or if they don't only respond to known people, or if they acknowledge efforts, or if they encourage other into IETF visions, or if they provide good ideas/inputs, or if they manage work/WG/IETF well, etc. In IETF volunteers' reputations SHOULD always be high and respected, but seems like the IETF give chance for abuse so its reputation makes some people prefer to be anonymous so they try to save their self reputation. We in IETF SHOULD not focus on people's reputation, we SHOULD focus on ideas, reasons, work-quality, documents/RFCs reputations and process-procedures reputations. We are here to document IETF reputation but not to document a person reputation or even his/her name. A person's name for me is only important when I want to refer to his/her review, draft, idea, etc. Don't forget that in procedure; any input into IETF is own also by IETF no matter what was the name given, so bad behaviour makes IETF reputation bad and then some people leave, or make anonymous names, or don't participate just listen. IMO, the majority of subscribers (in WGs) are listeners with zero participation. AB On 8/2/13, Adam Roach a...@nostrum.com wrote: Moving to ietf@ietf.org, since I think this is not in any way specific to Berlin. On 8/2/13 12:24, Olle E. Johansson wrote: In rtcweb we have remote participants that prefer anonymity for a number of reasons. I'm going to make a broad assumption that the number of reasons all relate to privacy. If that is incorrect, please weigh in. The question is how this is handled in regards to note well, when they want jabber scribes to relay opinions or proposals to the meeting. Just a note for the future. I think we should allow anonymous listeners, but should they really be allowed to participate? We had a previous conversation around pseudonyms, which I think concluded that pseudonyms are pretty much okay (and impossible to reliably detect anyway). Given this fact, someone can protect their identity through use of a consistent pseudonym. This has the property of developing a persona behind that pseudonym that the working group members can reasonably interact with. By contrast, attempting to participate in a truly anonymous fashion rather than participating with a pseudonym seems to have very little justification, with significant potential drawback for the working group. The privacy implications are pretty much identical, but it provides the illusion that one can act in a way that has no impact on a persona's reputation. IMHO, this is ripe for bad behavior, bad faith participation, and other abuses. Given the availability of pseudonymous participation, I don't think we need to tolerate anonymous participation. /a
Re: Weekly posting summary for ietf@ietf.org
Hi Thomas, Please note that the week did not end yet (IMO ends on Saturday night) but your week is starting from Friday and end on Thursday night. If we follow your week then I prefer if you post at end of Friday (as in the end of working days of 5 in each week). However, in my comment below I will follow the week as done in world calender, start from Sunday (mornings) and ends on Saturday (nights). In the last previous weeks IETF got 135, 140, and 109 messages, for weeks 28, 29, and 30 respectively. The week 31 as below got 222 messages because it is the IETF meeting week in Berline. I expected to get lower input from attendees and higher from remote, because attendees are available at meetings. My input increased as you reported (but percentage per total is still similar), because of the meeting and I am remote, to communicate with attended participants. However, I will try to check my input per month not per week so I can adjust my particpation volume on the list, because on week 30 I had no input. Please note that this respond is related to you reporting my and others participation activity, which I will do frequently to comment/discuss on such report. AB + 2013 WEEK 28 +++ http://www.ietf.org/mail-archive/web/ietf/current/msg80637.html + 2013 WEEK 29 +++ http://www.ietf.org/mail-archive/web/ietf/current/msg80774.html + 2013 WEEK 30 +++ http://www.ietf.org/mail-archive/web/ietf/current/msg80883.html + 2013 WEEK 31 +++ On 8/2/13, Thomas Narten nar...@us.ibm.com wrote: Total of 222 messages in the last 7 days. script run at: Fri Aug 2 00:53:02 EDT 2013 Messages | Bytes| Who +--++--+ 4.95% | 11 | 7.45% | 129461 | abdussalambar...@gmail.com 5.41% | 12 | 6.26% | 108812 | mo...@network-heretics.com 4.95% | 11 | 4.51% |78362 | s...@resistor.net 4.50% | 10 | 4.72% |82029 | brian.e.carpen...@gmail.com 3.60% |8 | 5.15% |89569 | hal...@gmail.com 4.05% |9 | 3.58% |62145 | john-i...@jck.com 4.05% |9 | 3.54% |61529 | arturo.ser...@gmail.com 4.05% |9 | 3.39% |58959 | melinda.sh...@gmail.com 3.60% |8 | 2.83% |49207 | jari.ar...@piuha.net 1.80% |4 | 3.79% |65923 | leaf.yeh@gmail.com 3.15% |7 | 2.10% |36449 | j...@mercury.lcs.mit.edu 2.70% |6 | 2.50% |43444 | y...@checkpoint.com 2.70% |6 | 2.05% |35661 | stpe...@stpeter.im 2.25% |5 | 2.01% |34917 | d...@dcrocker.net 2.25% |5 | 1.87% |32418 | barryle...@computer.org 1.80% |4 | 2.25% |39049 | t...@ecs.soton.ac.uk 1.35% |3 | 2.36% |41081 | sprom...@unina.it 1.80% |4 | 1.87% |32564 | a...@yumaworks.com 1.80% |4 | 1.65% |28732 | ted.le...@nominum.com 1.80% |4 | 1.50% |26028 | mcr+i...@sandelman.ca 1.80% |4 | 1.45% |25184 | aaron.d...@cl.cam.ac.uk 1.35% |3 | 1.38% |24049 | ch...@ietf.org 1.35% |3 | 1.34% |23348 | rdroms.i...@gmail.com 1.35% |3 | 1.16% |20126 | roland.bl...@kit.edu 1.35% |3 | 1.15% |19939 | kathleen.moria...@emc.com 1.35% |3 | 1.12% |19406 | joe...@bogus.com 1.35% |3 | 1.09% |19009 | hartmans-i...@mit.edu 1.35% |3 | 0.96% |16709 | to...@isi.edu 0.90% |2 | 0.99% |17194 | d3e...@gmail.com 0.90% |2 | 0.93% |16233 | petit...@acm.org 0.90% |2 | 0.85% |14812 | amor...@amsl.com 0.90% |2 | 0.82% |14280 | jcur...@istaff.org 0.90% |2 | 0.80% |13957 | yd...@cs.helsinki.fi 0.90% |2 | 0.77% |13418 | da...@tcb.net 0.90% |2 | 0.71% |12262 | josh.howl...@ja.net 0.90% |2 | 0.66% |11396 | scott.b...@gmail.com 0.90% |2 | 0.64% |11075 | ned+i...@mauve.mrochek.com 0.90% |2 | 0.59% |10336 | ra...@psg.com 0.90% |2 | 0.56% | 9647 | i...@meetecho.com 0.45% |1 | 0.93% |16123 | nkuk...@verilan.com 0.45% |1 | 0.85% |14714 | jsalo...@cisco.com 0.45% |1 | 0.81% |14144 | andrewm...@google.com 0.45% |1 | 0.66% |11498 | amanda.ba...@icann.org 0.45% |1 | 0.62% |10744 | mary.h.bar...@gmail.com 0.45% |1 | 0.59% |10318 | daedu...@btconnect.com 0.45% |1 | 0.55% | 9616 | d...@cridland.net 0.45% |1 | 0.54% | 9392 | david.bl...@emc.com 0.45% |1 | 0.50% | 8729 | a...@anvilwalrusden.com 0.45% |1 | 0.50% | 8686 | nar...@us.ibm.com 0.45% |1 | 0.47% | 8238 | ted.i...@gmail.com 0.45% |1 | 0.46% | 7965 | br...@innovationslab.net 0.45% |1 | 0.46% | 7918 | kvi...@broadcom.com 0.45% |1 | 0.45% | 7905 | simon.lei...@switch.ch 0.45% |1 |
The Friday Report (was Re: Weekly posting summary for ietf@ietf.org)
On 8/3/13, Patrik Fältström p...@frobbit.se wrote: On 3 aug 2013, at 08:46, Abdussalam Baryun abdussalambar...@gmail.com wrote: I prefer if you post at end of Friday (as in the end of working days of 5 in each week). However, in my comment below I will follow the week as done in world calender, start from Sunday (mornings) and ends on Saturday (nights). The day a week starts, and what days are working days in a week, differs between cultures. Many have Sunday-Thursday as working days. Many have Monday as the first day of the week. I suggested to Thomas to submit report in end of Friday (read what i prefered done above) to include both Sun-Thur and Mon-Fri working days, so all can see the result of working days in IETF. There is not *one* definition of when a week start and end. I have worked both (Sun-Thur) and (Mon-Fri), my definition never matters, it is the definition of the organisation we work for that matters. So is there a definition in IETF or does Thomas have a definition or it was selected randomly morning of Friday. AB Patrik
Re: making our meetings more worth the time/expense (was: Re: setting a goal for an inclusive IETF)
I agree with some of your points, thanks, comments below, On Tue, Jul 30, 2013 at 4:54 PM, Keith Moore mo...@network-heretics.comwrote: http://www.ietf.org/blog/2013/07/a-diverse-ietf/ Also, I wanted to let everyone know that tomorrow in the Administrative Plenary, Kathleen Moriarty and Suresh Krishnan will be talking about what they have uncovered so far in their efforts in the diversity design team. I'm looking very much forward to their report. Their efforts will help us understand where we have room to improve - often by much :-) - and what kinds of actions we can take to improve our inclusiveness. This is something that I've struggled with for years. A big part of the problem (from one point-of-view) is that we've become so geographically diverse in our choice of meeting sites that we've drastically raised the cost of attending meetings on a regular basis - everyone has to travel a lot to so (though people in North America still have an easier time of it). And while there are clearly things that could be done to reduce meeting costs, we'd be doing very well to reduce total trip cost by more than say 15%. But earlier today I realized that the problem isn't just the cost of attending meetings - it's the value that we get in return for those meetings. I've been taking notes about how ineffectively we use our meeting time. Most of what I've observed won't surprise anybody, but here's a summary: WG meeting sessions aren't scheduled to encourage discussion, but to discourage it. At meeting after meeting, in several different areas, I see the lion's share of the time devoted to presentations rather than discussion. Similarly, WG meetings generally aren't run in such a way to facilitate discussion, but to discourage it. It's only Tuesday afternoon and I've already lost count of how many times I've heard a meeting chair tell people that they have to stop discussing things because there are more * presentations* to do. I think I was told that IESG is in charge of management of the meeting, so we should ask it to clarify its position, WHY it was done that way? However, I mentioned that time management was not done well in MANET WG in previous meetings but no one cares of my comments. I hope your will get through to IESG. Rooms are set up not to facilitate discussion, but to discourage it. The lights are dim, the chairs are facing forward rather than other participants, the projector screen (not the person facilitating a discussion, even if someone is trying to facilitate a discussion) is the center of attention.The chairs are set so close together and with so few aisles that it's hard for most of the attendees to get to the mics. The microphone discipline which was intended to facilitate remote participation ends up making discussion more difficult for everybody who has paid to be on site. I mentioned before that I was discouraged while I was remote participant, but seems like even some f2f participants get that feelings from time to time. The management of meetings should respond to your comments (not a person but the body, which I expect IESG). In the vast majority of WG sessions, everyone has his nose in a laptop. (me included). This is because the information being presented at the moment is generally not valuable enough to occupy the attendees' attention. The attendees are there for one of two reasons - either they're just trying to absorb some low-value information while still doing something else that is more useful, or they're waiting for some opportunity to actually interact - either within the context of that WG meeting or afterward (perhaps because the best way to catch a particular person is often to show up at a WG meeting that that person is attending.) I usually will blame the IETF chairs to do better attraction to participants including remote ones on jabber. All of these things have been standard practice, in IETF and elsewhere, for so long, that hardly anyone questions them. They have to be that way because they're habit, and even if one or two people try to change things (and I realize some ADs are trying), they have to contend with the mindless habit-driven decisions of everyone else involved. We can change meetings management, and I don't think there is a standard practice for management of this meeting and others. We need an RFC for how to best manage the meeting, which can update from time to time, however, I mentioned to the venue selectors to be involved because selecting venue affects the meeting management capacity. Well, please excuse my candor, but f*ck habit. We can't be effective engineers if we let bad habits continue to dictate how we work. You keep repeating habit as it is not good, but I think we need it, but we need management to make people's habit in the direction of the IETF habits :-) AB -- My expenses for this meeting are around USD 2.500. Some are paying
Re: making our meetings more worth the time/expense (was: Re: setting a goal for an inclusive IETF)
IMHO, The presenters are MUST, but the time channel for presenting is the problem or boring factor. I mentioned before that we need short presentations 5 minutes, and more discussions. AB On Tue, Jul 30, 2013 at 9:30 PM, Keith Moore mo...@network-heretics.comwrote: On Jul 30, 2013, at 7:47 PM, Bob Braden wrote: On 7/30/2013 9:35 AM, Noel Chiappa wrote: Easy fix: 'slide' (well, nobody uses real slides anymore :-) rationing. E.g. if a presenter has a 10 minute slot, maximum of 3 'slides' (approximately; maybe less). That will force the slides to be 'discussion frameworks', rather than 'detailed overview of the design'. Noel Noel, I tried the 3 slide limit in the End2end Research Group some years ago, and it did not work very well. Presenters just can't discipline themselves that much, no matter how hard you beat on them. Maybe the first step is to stop having presenters. Keith
Re: making our meetings more worth the time/expense (was: Re: setting a goal for an inclusive IETF)
I think *side meetings* are killing IETF, I call it *hidden meetings*, there is no input for IETF when we have side meetings. The input to IETF in through meeting sessions and discussion lists. So I agree with Keith that meeting sessions have low discussions, and may discourage remote participants to discuss as well. I think why you feel that side meetings are valuable, is because it has short presenting, each person talks for less than 5 minutes and discussion time is interesting. So you and Keith seem to be having same aim to exclude long presentations of issues. Furthermore, I will add that we need not to only ask questions and discuss with the authors/presenters, we should be discussing to the IETF WG with the meeting. This way the habit will be not boring and ALL will be attracted. AB On Wed, Jul 31, 2013 at 9:30 AM, Donald Eastlake d3e...@gmail.com wrote: The most valuable part of IETF meeting is and has always been the hall conversations and side meetings Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Tue, Jul 30, 2013 at 12:10 PM, Michael Richardson mcr+i...@sandelman.ca wrote: Keith Moore mo...@network-heretics.com wrote: But earlier today I realized that the problem isn't just the cost of attending meetings - it's the value that we get in return for those meetings. I've been taking notes about how ineffectively we use our meeting time. Most of what I've observed won't surprise anybody, but here's a summary: Thanks for this. Rooms are set up not to facilitate discussion, but to discourage it. The lights are dim, the chairs are facing forward rather than other participants, the projector screen (not the person facilitating a discussion, even if someone is trying to facilitate a discussion) is the center of attention. The chairs are set so close together and with so few aisles that it's hard for most of the attendees to get to the mics. The microphone discipline which was intended to facilitate remote participation ends up making discussion more difficult for everybody who has paid to be on site. I think that these physical things are something that we can do some experiments about. Well, please excuse my candor, but f*ck habit. We can't be effective engineers if we let bad habits continue to dictate how we work. I agree. For 80% of most WG meetings, the lights should be bright, the participants should face each other. If there's a person facilitating the discussion that person should be the center of attention.If we're going to use microphones, the rooms should be set up to allow everyone in the room to have easy access to them. We should have several microphones, again facing each other, so that several people can have a conversation without everyone having to queue up. Can we please try this in Vancouver? This would work especially well for BOFs. Maybe we can start there. Chairs will need training as *facilitators* And maybe, in addition, we need to provide better places for people to hang out and work while trying to get an opportunity to interact with specific people. The terminal rooms are generally placed in out-of-the-way corners, but the most effective places to interact with people are in the hallways. I agree. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works
Re: making our meetings more worth the time/expense
comments below On Wed, Jul 31, 2013 at 3:23 AM, Andrew Sullivan a...@anvilwalrusden.comwrote: On Wed, Jul 31, 2013 at 08:38:26AM +1200, Brian E Carpenter wrote: It's been pointed out before that in a group with very diverse languages, written words are usually better understood than speech. It's a fact of life that you can't have a full-speed cut-and-thrust discussion in a group of 100 people, half of whom are speaking a foreign language. Sitting in a circle does not fix this. While that is true, I think it misses the point of the objections to the sit-and-watch-PowerPointTV. First, I observe that we already _have_ a great deal of written words: the drafts. I continue to believe that altogether too much time in WG meetings is spent introducing, presenting, or otherwise showing off ideas in an existing draft to participants in the WG. I acknowledge that (particularly in early stages of WG life, in topics with a lot of different work, and in cross-WG presentations) these intro presentations are a fact of life. But I think we are extremely bad at holding the reigns on them. The presenter SHOULD focus on taking WG feedback by asking WG Questions like : do you think explaining in a section XXX will be good? then the WG hummms, In a WG meeting, I think such intro presentations about drafts really can be kept to three pieces of information: the name of the draft, a slogan describing the problem it is supposed to solve, and a pointer to the beginning(s) of discussion thread(s) on the draft. If the person promoting the draft can't give the elevator pitch, they don't know their own draft well enough to summarize it and shouldn't be presenting it. Any additional discussion in the presentation ought to be exploring, as much as possible, one or more of the following topics: - a particular issue - is $issue a real problem - alternatives for solving $issue - motivation for $issue solution choices Each such slide, it seems to me, ought to encourage at most a couple minutes of exposition and then some discussion. The _reason_ to get together in a big room with other people is to use the high-bandwidth opportunity to hash out the extent of a problem. The back and forth of you forgot this, no that won't work because it explodes foo, and so on, is the value here. Please note that we SHOULD not only blame the presenter/author for this problem of boring and presentation format, but I also blame the WG participants, why the don't READ, READ, READ, the DRAFTS under AGENDA. If they do READ then they can input please take my questions, 1, 2, 3 and please take my recommendations 1, 2,3, and please take my requests/comments, 1,2,3. Notice that none of that includes complicated flow-chart diagrams that explain in detail a proposal. There _is_ a place for those, however: an actual presentation that gets made after significant discussion on the list has made it clear that nobody understands the proposal. At that point, those 10-15 minute presentations of some proposed mechanism are important, if only to inspire commenters to go back to the list and say, Ok, _now_ I get what you were trying to say, and your text needs to be improved along the following lines. But these full explanation presentations happen too often when there has not been such confusion. I agree with this above point. Of course, all of the above depends on us going back to the list and working out the details there, and it depends on people having read the drafts and having a list of questions themselves that have been deferred from the list for the face to face discussion. I agree with you, I believe presentations in meetings are also sometimed useful if they are exploring a problem space. In that case, I believe what one needs is _short_ presentations of the sort, Here's what I think the problems are, and then a lot of well-moderated discussion. I agree as if you ment short as less/equal than 5 minutes. The IETF Chair and WG Chairs SHOULD consider these issues you raised. Unfortunately, actually running meetings this way is a lot of work, requires fairly careful planning, and requires an indifference to nasty remarks on the part of presenters who would much rather listen to themselves for 20 minutes than to others. But I think it'd make for better meetings. (Yes, along with room layouts that were more suited to getting people to the mic.) I will add that We need with the author/presenter, to know the reviewers of the draft, and get their short comments, so that will help the WG to decide when asked for their opinion. So the reviewers are as a supervisor to the WG, and the WG Chair is arranging their input in the session to make the meeting valuable. The old days are gone. Yes, and we need to figure out how to use meeting time effectively here in the new days. That effective use does not, I think, involve expanding to fill all the time
Re: setting a goal for an inclusive IETF
Hi Jari, I have gave many feedback on the diversity issue, and I thank you for the article, I agree with iot totally. I will repeat my comment, that the design team of diversity SHOULD make clear what is its goals and milestones, therefore, we can give better feedback, but leaving that hidden to management, then only the special people listed in your article, I would prefer that the design team are selected by diversity parameters ( gender, region, age, necomer-oldcomer, etc). Thanks again, AB On Tue, Jul 30, 2013 at 2:53 PM, Jari Arkko jari.ar...@piuha.net wrote: We have discussed diversity at the IETF at length. Yesterday, Pete Resnick and I wrote an article about what we think the goal for the IETF should be, as well as listing some of the early activities that we have taken at the IETF. Our goal is making the IETF more inclusive for everyone who needs to be working on Internet standards. We are at the beginning, however, and a lot of work remains ahead. Here's the article: http://www.ietf.org/blog/2013/07/a-diverse-ietf/ Also, I wanted to let everyone know that tomorrow in the Administrative Plenary, Kathleen Moriarty and Suresh Krishnan will be talking about what they have uncovered so far in their efforts in the diversity design team. I'm looking very much forward to their report. Their efforts will help us understand where we have room to improve - often by much :-) - and what kinds of actions we can take to improve our inclusiveness. Jari
Re: making our meetings more worth the time/expense (was: Re: setting a goal for an inclusive IETF)
Hi Barry, Sorry for long meesage, I will give you a real example which I experienced that includes my request regarding a WG ietf draft that has no presenter but two people in the WG that want discuss it in meetings as below real story. I want to confirm my statement of hidden discuss/information related to IETF work, because there are intentions/encourages by some to do hidden meetings, and hidden reviews (they are acknowledged in draft with reviews that are not listed or hidden, on the other hand, once I have not been acknowledged-listed when I published my review even), however, I think it can be fixed in future. I am not against the side meeting but against not documenting information (excluding side info, and reviews, and comments, that change the work we are doing). A live WG example in IETF is for this Berline-meeting: A request for discussion was raised [1] by a participant that will attend, and I (as remote-meeter) support for that request that I did raise [2]. The author suggested that he has no presentation and would like time within the week (i.e. I understand it was side meeting) to discuss with that attended participant [3] (as hidden meeting, but still no reply to the remote requester, was that remote participant discouraged, maybe). However, it was nice that the first discuss-requester has added request to only do discussions in WG meeting (not side meetings) [4]. [1] http://www.ietf.org/mail-archive/web/manet/current/msg15521.html [2] http://www.ietf.org/mail-archive/web/manet/current/msg15523.html [3] http://www.ietf.org/mail-archive/web/manet/current/msg15534.html [4] http://www.ietf.org/mail-archive/web/manet/current/msg15535.html My comment we need to encourage the discussions to be done in the IETF, and even if we done a discussion in a side meeting as per your examples, we SHOULD quickly write it down into the IETF lists (as some participants do, e.g. the chair's article of diversity done this month). My addition comments below, AB On Wed, Jul 31, 2013 at 3:00 PM, Barry Leiba barryle...@computer.orgwrote: The most valuable part of IETF meeting is and has always been the hall conversations and side meetings I think *side meetings* are killing IETF, I call it *hidden meetings*, there is no input for IETF when we have side meetings. The input to IETF in through meeting sessions and discussion lists. I have no argument with your last sentence; it's absolutely correct. But I think you misunderstand the point Donald is making about things such as small hallway conversations. Example: A few people get together in a corner and one says, About that point I made on the list that you brushed off... here's what I'm talking about:, and five or ten minutes of discussion ensues. At the end, either the guy with the point now understands why he's wrong (or why his point isn't practical), or the document editor says, OK, I get your point now. Let me work up some proposed text and post it to the list. In this example, they (discussion team) should add the result of discussion into the IETF WG lists, they should document it Example: A few people get together during a session time they have free, and they bash out some text to resolve an issue that came up. They come to the working group meeting session with an explanation of their conversation and the proposed text, and it's discussed in the meeting session (and posted to the list afterward). In this example, they should document the result of discussion and the event into the IETF WG lists (if they think useful). Example: Someone has an idea for a new document or other new work, so he gathers some people to have breakfast one morning, explains his idea, bashes it around with his colleagues, and as a result of that breakfast chat he goes home after the IETF meeting and writes up an Internet Draft. So the result is already an input draft, IMHO, that side meeting is respected by IETF because it is a usual birth of any draft/idea. That side meeting is not hidden, but also not related to any IETF document. I was arguing discuss that are related to IETF document which has a value that will direct the IETF draft. None of this is hidden; none of this is secret. It's all the way work gets done efficiently: a small group of people crack some tough nuts, and present the results to a wider audience. When the discussion is done or encouraged by human habit to make it in a special TEAM, I will say it is SECRET, as long as it ended there. I hope our diversity team is not secret because still I seem not to know what is happening there, nothing is announced on their lists regarding targets. Furthermore, please see my point above of my real example on one WG, it happends in IETF that they discuss issues out side the lists/meetings and then the results of such TEAM/SIDE/HIDDEN meeting is not given (can be forgotten, because most are bussy, which is always the excuse that can be used) to the community,
Re: Oh look! [Re: Remote participants, newcomers, and tutorials]
On 7/27/13, John C Klensin john-i...@jck.com wrote: one locates it (IETF Home Page - IESG - Members) one even gets contact information as a bonus. And the listing of AD names is pretty useless without contact info. As from my remote participant experience in IETF Routing Area (rtg), I was very happy/encouraged to be able to speak directly (issue related to MANET WG) to the AD of rtg at his open-office session at a previous IETF meeting (even 2 minutes makes big differences). Giving a chance to remote participants to speak to WG chairs or ADs is good to encourage remote-participants/new-interested-people to start thinking to join the meetings. I suggest that all ADs for other areas do the same if available (I am not sure if they do that, but if they do, that is great). Furthermore, if mentoring is available for remote participants then the mentor may book a time if needed with WG chair or AD, otherwise an agreed time communication can continue directly between mentor and participant. Booking a 2 minute remote speach at IETF-meetings from remote-community to an IETF AD or WG-Chair can be a new opportunity that IETF/IESG can think about to schedule in future. AB
Re: Remote participants access to Meeting Mailing Lists was Re: BOF posters in the welcome reception
I agree with your suggestion Christer. Remote-participants have right to register their attendance because they do attend remotely and IETF SHOULD register their information if available. Last meetings I did not like that I was not registered because I am remote, but now I feel more welcomed. I think the location of remote participant at the meeting time can be variable per participant (so can be distracting). Even participants that attend some meeting sessions may be remote in others or attend both ways at same time, so I think it is better to know/register how many are only-remote and at which group-sessions and for how long, and how many remote inputs per session. Then the registered info are useful for IETF to improve it participation per meetings or meeting-locations. AB On 7/25/13, Christer Holmberg christer.holmb...@ericsson.com wrote: Hi, Whatever the information is used for, or not used for, I think it would be useful to know the number of remote participants, and where they are located. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -Original Message- From: SM [s...@resistor.net] To: Christer Holmberg [christer.holmb...@ericsson.com] CC: John C Klensin [john-i...@jck.com]; ietf@ietf.org [ietf@ietf.org] Subject: Re: Remote participants access to Meeting Mailing Lists was Re: BOF posters in the welcome reception Hi Christer, At 13:54 24-07-2013, Christer Holmberg wrote: Why couldn't remote participants register to the meeting like all other participants? Remote participation would of course still be free, but it would allow remote participants to subscribe to the attendee list in the same way as other participants. A quick scan of that list shows the following topics: - coffee, sims - mailing list for IETF women and the following comment: I'm not sure why I should be required to give my contact information to get a document prepared by the Brussels airport for Brussels passengers. In addition, it would provide better knowledge to IETF about the number of remote participants, where they are physically located (which might be useful input when planning future meeting locations) etc. I doubt that the IETF chooses its meeting location based on where the remote participants are located. I'll go off-topic first. Mr Reschke once asked I was just trying to understand *why* the archive can't be at http://www.ietf.org/tao/archive. Mr Housley replied that I was told that we cannot have http://www.ietf.org/tao directed to the document and also be the directory containing the archive directory. Mr Hansen provided some technical details about how that can be done. The point here is it might be better to have a good answer as some IETF participant might deconstruct the answer and find the flaw in it. Mr Klensin's message was about how to find out about the 87all mailing list. Participants within the inner circle know how to find it. The rest of the participants will not be able to find that information as it is not easily accessible through the www.ietf.orghttp://www.ietf.org web site. There is probably a lack of information about what information is provided through the ietf-announce@ mailing list. Regards, -sm
Re: BOF posters in the welcome reception
On 7/24/13, John C Klensin john-i...@jck.com wrote: --On Wednesday, July 24, 2013 09:22 +0300 IETF Chair ch...@ietf.org wrote: I wanted to let you know about an experiment we are trying out in Berlin. ... But we want as many people as possible to become involved in these efforts, or at least provide their feedback during the week. So we have given an opportunity for the BOFs to display a poster in the Welcome Reception (Sunday 5pm to 7pm). If you are attending the reception, take a look at the posters and look for topics that interest you. What about each poster state which WG/RFCs it is mostly depending-on/related (if applicable), this can make an easier way to know if I am interested or should be interested. Someone running the BOF is also likely standing by, so you can also get directly involved in discussions, sign up to help, etc. We hope that this helps you all network with others even more :-) How can I access the live discuss while remote? The remote live networking with BOF is still not-clear/difficult. I as remote would like to know how many attended and interested per BOF. In the interest of encouraging remote participation and involvement in those BOFs, could these posters be made available online before the reception? Will they eventually be incorporated into the minutes? Agree, and I will be more encouraged to participate if I know an estimate community rank (not sure how to evaluate may be from IESG), a similar way of poster presentation format per all BOFs (helps to read through, save time, and get more involve in more BOFs), how much work was done so far. And, incidentally, is there a way for remote participants to sign up for one or both meeting-related mailing lists without registering (or using a remote participation registration mechanism, which would be my preference for other reasons)? Agree, but to clarify; if not registered then the remote participant is still not sure to be involved, but if registered then means he/she is interested. AB
Re: Remote participants, newcomers, and tutorials (was: IETF87 Audio Streaming Info)
On 7/26/13, SM s...@resistor.net wrote: The consensus of the IETF is that: newcomers who attend Working Group meetings are encouraged to observe and absorb whatever material they can, but should not interfere with the ongoing process of the group This is bad for IETF, why no interfer from new experience, does IETF want to only be guided by longer-working people? It was also mentioned that: Working group meetings are not intended for the education of individuals I think few ietf-WGs need to be educated or need mentoring, so newcomers are recommended to help. I will add that it will be nice to know the newcomers opinion about such consensus, and make an IETF newcomer-WG consensus. The problem is that our IETF General Area (GA) is still not covering all important issues and left to the IESG to control thoes issues not the community. I requested before and still want to do now, to suggest WGs in the GA, therefore, we avoid discouraging reactions/decisions. The first quote might discourage newcomers from participating. I suggest discussing about the two quotes during the orientation as they could be misunderstood. Yes it does for me. I support your suggestion, because I don't think I misunderstood, they seem clear to exclude newcomers and only include groupings not individuals. AB
Re: Remote participants, newcomers, and tutorials (was: IETF87 Audio Streaming Info)
Thanks, I agree with your points/suggestions. I want to add; a) Work/Participation in IETF is remotely to run its daily business. b) Newcomers (how many we have per meeting); are always welcomed, no one in IETF have been participating for longer than 30 years, so some how could we say participants are mostly all new (remotely+newBody). It will be nice to have a presenter (one year ietf participant) in session related to new comers so he/she can present their live experience. IMHO, the IETF is always new not old, so we need newcomers (let them speak and present in their session) to make IETF newer, otherwise IETF will become old-oriented :-) I define a new comer as one that have been participating for less than 5 years or never attended more than 2 meetings. It will be nice if all newcomers with this definition gather together and discuss interested issues. c) Overall, all IETF participants including IESG members are mostly serving IETF as Remote participants (new and old comers), but at meeting days some are present at the venues and not remote. We need both participation methods, and it is better to encourage both at all times with equal access for diversity purposes. AB On 7/26/13, John C Klensin john-i...@jck.com wrote: Hi. For a newcomer or someone expecting to write I-Ds, some of the most important sessions at the IETF are the various Sunday afternoon tutorials and introductions. Many of them are (or should be) of as much interest to remote participants as to f2f attendees. Until and unless a newcomer's tutorial can be prepared that is focused on remote participants, even that session should be of interest. For this particular meeting all of the following seem relevant to at least some remote participants: Newcomers' Orientation Tools for Creating I-Ds and RFCs IAOC Overview Session Multipath TCP Applying IP Flow Information Export (IPFIX) to Network Measurement and Management So... (1) The note below strongly implies that none of those sessions are being audiocast.Why not and can that be fixed? (2) There is no hint on the agenda or tools agenda about availability of presentation and related materials (slides, etc.) for those sessions. Do those materials not exist? I know, but a newcomer or remote participant might not, that I can find some tutorials by going to the IETF main page and going to Tutorial under Resources, but I have no idea which of those links actually reflects what will be presented on Sunday. Assuming the presentation materials do exist for at least several of the sessions, finding them is much like the situation with subscribing to the 87all list. It should no involve a treasure hunt at which only very experienced IETF participants can be expected to succeed. Specific suggestions: (i) Let's get these open Sunday sessions audiocast and/or available over Meetecho or WebEx. If that is impossible for IETF 87, it should be a priority for IETF 88 and later. (ii) If there are presentation materials available, links from the tools agenda and an announcement to IETF-Announce as to where to find them would be desirable. (iii) If presentation materials are not available, why not? And, more important, can this be made a requirement for IETF 88 and beyond? thanks, john --On Friday, July 26, 2013 12:00 +0200 Nick Kukich nkuk...@verilan.com wrote: Greetings, For those interested in monitoring sessions or participating remotely the following information may prove useful. ... All 8 parallel tracks at the IETF 87 meeting will be broadcast starting with the commencement of working group sessions on Monday, July 29, 2013 at 0900 CEST (UTC+2) and continue until the close of sessions on Friday, August 2nd. ...
Re: Sunday IAOC Overview Session at the Berlin IETF
Hi Pat, Thanks. My concerns is that do we have a plan for disaster recovery/management in IETF or IEEE802. Including meetings which is the important time we come together for. Usually now organisations are looking into defining plans so the staff/participants are aware of procedures. I was thinking if I was to go to any organisation these days I will ask is there a plan and alternatives. Usually communication and information is the key to a better solution per person or per organisation. As IETF and IEEE802 standard communication technology then it is good if we have the best practice in the world. AB On Tue, Jul 16, 2013 at 9:33 AM, Pat Thaler ptha...@broadcom.com wrote: One can't 100% protect against disruption from emergency situations. I'm Vice Chair of IEEE 802 and there was a case where a venue became unavailable due to a disaster. In that case it was enough before the meeting that it worked as Bob described - the hotel chain worked with us to identify and contract an acceptable alternative. On the other hand, the tsunami hit Japan just before the IEEE 802 Singapore meeting - close enough to it that some folks were in the air on the way to the meeting when it hit. Many attendees had travel disrupted and arrived late. Some even were unable to attend due to problems getting an alternative routing. Fortunately, enough were able to arrive so that we had an effective meeting, but it was difficult. There are also cases where a wide spread weather disruption has caused problems for meeting effectiveness - e.g. a blizzard on the east coast of the USA. Pat -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Bob Hinden Sent: Monday, July 15, 2013 12:56 PM To: Abdussalam Baryun Cc: Bob Hinden; ietf@ietf.org Subject: Re: Sunday IAOC Overview Session at the Berlin IETF AB, snip - Is there an alternative venue if the venue was closed for any emergency reason at any time? or only one plan so if the plan changes there can be problems with the communities expected plan because they were not aware of the needed information per time. No, there is not an alternative venue under contract. It isn't practical to have two venues under contract, build two networks, etc. It is technically feasable, but would cause the registration fee to go up significantly to cover the extra costs. If there was, for example, a fire at a venue months before the the meeting we would look for an alternate, but what happens would depend on availability of alternative venues. We have good relationships with the hotel chains we use and they would work very hard to find an alternative venue, as would the effected venue.
Re: Sunday IAOC Overview Session at the Berlin IETF
Hi Bob, thanks and respond below, On Mon, Jul 15, 2013 at 8:55 PM, Bob Hinden bob.hin...@gmail.com wrote: AB, IMO the questions/comments that may be ok to see added to discuss are: 1) Venue selection and operation of the IETF meetings - Selection of the current venue and was there difficulties until getting to this meeting session time. From the managing meeting (providing services) and the community use of the meeting. (10 minute discuss if needed). I don't understand your question, please clarify. sorry, I ment meetings in the past were they all using the selected venue successfully, if there was difficulty (in attending, in using the avenue, in venue resources). Note that the IAOC selects the venue, provides the network, contracts with the hotel, etc., it is the IESG who is responsible for the agenda for the meeting, agenda planning, etc. - Is there an alternative venue if the venue was closed for any emergency reason at any time? or only one plan so if the plan changes there can be problems with the communities expected plan because they were not aware of the needed information per time. No, there is not an alternative venue under contract. It isn't practical to have two venues under contract, build two networks, etc. It is technically feasable, but would cause the registration fee to go up significantly to cover the extra costs. I ment that does the contract mention if there was difficulty in using the venue then an alternative may be an option. Does the finance of the venue contract is non-refundable ( a plan for service and maintenance). If there was, for example, a fire at a venue months before the the meeting we would look for an alternate, but what happens would depend on availability of alternative venues. We have good relationships with the hotel chains we use and they would work very hard to find an alternative venue, as would the effected venue. So I understand there is no plan, we only think about alternative when a problem appears. I wanted if possible a discuss on this issue. - Is there an historic/informational RFC issued by IAOC of difficulties or important comments in past of venues attended? No. There is an extensive record of comments about venue on the attendees list for individual meetings and the IAOC reports to the community. Also, meeting surveys with community feedback: http://iaoc.ietf.org/surveys.html Ok - Regarding advice within emergency situations (in or out the meeting venue), is it considered within chosing the managing meeting plan/venue, and is the emergency solution an available information for attended participants and who will attend within a meeting day. Assuming you mean while the meeting is taking place, the secretariat and venue have emergency plans in place. The secretariat discuses safety and emergency medial procedures with the venue to be prepared if anything should happen. Ok, so I understand that the safety procedure is discussed but not emailed/sended to registered participants. - Someone may like to know if is going to attend at a meeting, how is the meeting venue managed per time slots, is there a way of quick feedback/communication of registered-community for meetings (you may say IETF list but are they connected). The information availability can be used for others not attended and whom may attend at any time. (the venue ran out of coffee/water, so I may buy one while going to venue, or any other issue which can happen out of expected/plan). The IETF meeting agenda is managed by the IESG. Problems with the meeting venue can be reported to the Meeting Trouble Desk at m...@ietf.org. Problems with the network can be reported to the NOC at n...@ietf.org. ok thanks, 2) Other issue: + -Is there a future work plan milestones discussed? can be added to [*] Not sure what your are asking about, but future meetings are posted on the IETF web site and the process and timeline for meeting planning is part of the IAOC overview presentation. sorry, I ment what to discuss, is the community work plan of discuss, so IAOC knows what it is discussing each time, but does the community just follow presented issues, or we can come together and plan how we discuss/influence with IAOC. (this point was trigered when I read your call to community to suggest what to discuss). Each WG in IETF has milestones, but I not sure of the general area milestones related to meetings selections. -I am not sure if was discussed before and answered (I am sorry if repeated), where do I go to find important past/current QA for IAOC (to avoid efforts to be wasted, and unite best answers)? if not available it can be good to find it at [*]. Recent plenaries reports and the last IAOC overview session have been recored by Meetecho. The last IAOC overview is on the main page at http://iaoc.ietf.org. Also, plenary
Re: Sunday IAOC Overview Session at the Berlin IETF
Hi Bob, IMO the questions/comments that may be ok to see added to discuss are: 1) Venue selection and operation of the IETF meetings - Selection of the current venue and was there difficulties until getting to this meeting session time. From the managing meeting (providing services) and the community use of the meeting. (10 minute discuss if needed). - Is there an alternative venue if the venue was closed for any emergency reason at any time? or only one plan so if the plan changes there can be problems with the communities expected plan because they were not aware of the needed information per time. - Is there an historic/informational RFC issued by IAOC of difficulties or important comments in past of venues attended? - Regarding advice within emergency situations (in or out the meeting venue), is it considered within chosing the managing meeting plan/venue, and is the emergency solution an available information for attended participants and who will attend within a meeting day. - Someone may like to know if is going to attend at a meeting, how is the meeting venue managed per time slots, is there a way of quick feedback/communication of registered-community for meetings (you may say IETF list but are they connected). The information availability can be used for others not attended and whom may attend at any time. (the venue ran out of coffee/water, so I may buy one while going to venue, or any other issue which can happen out of expected/plan). 2) Other issue: + -Is there a future work plan milestones discussed? can be added to [*] -I am not sure if was discussed before and answered (I am sorry if repeated), where do I go to find important past/current QA for IAOC (to avoid efforts to be wasted, and unite best answers)? if not available it can be good to find it at [*]. [*] http://iaoc.ietf.org/ AB On 7/12/13, The IAOC bob.hin...@gmail.com wrote: The IETF Administrative Oversight Committee (IAOC) will hold a session from 1500-1650 in Potsdam 1 at the Berlin IETF on Sunday July 28, 2013. The purpose is to provide an overview of the IAOC to allow the community to better understand what the IAOC does, how the finances work, venue selection, and provide the IAOC feedback on the job they are doing. Remote participation support for this session will be provided by Meetecho. This will be similar to the session held at IETF86 in Orlando. The IAOC's responsibilities include: - Managing the IETF finances - Oversight of the IETF Administrative Director (IAD) - Selection and oversight of contracted services - Venue selection and operation of the IETF meetings - Support for the IETF's IT services (data tracker, web sites, tools, etc.) The topics that will be discussed include: - BCP101 - Structure of the IETF Administrative Support Activity (IASA) - Operation of the IAOC - Financial model and relationship with ISOC - Venue selection - Q A We hope this will improve the community understanding of how the IAOC works and provide the community an opportunity to provide feedback to the IAOC. Please let us know ahead of time if you have specific questions you would like to see discussed. Bob Hinden IAOC Chair
comment for draft-deng-call-chinese-names-00 (was Re: Regarding call Chinese names)
Hi Hui Deng, My comment for the draft is that I want to relate it to IETF as below, which I see that already some on IETF addressed by draft already call names including regional calling culture, which is excellent. The document will increase awareness and make the IETF culture more diversive. Comments: - The draft mentions word *speak*, is their formal and informal speaking difference in calling names ( you mentioned Mr/Mrs, but I was not sure it that compulsory formal way. Also what about how they *write* formally or informally. The word *call* in the title do you mean only in speaking or calling also in writing. - I am interested to know more why/how IETF participants (in past) had difficulty to communicate the names not how western people? So it may be good to know the history how IETF did call chinese names, or how they introduced their names in registrations. Secondly, not sure how the Chinese write and speak the names (is there difference way), as formal and informal, so I would like to know is there differences in writing documents, and does authors from this language like to translate there name to English without changing the tradition ways. So if you write in chinese do you prefer to write in your English-document, as author: Hui Deng or Deng Hui? - Does the draft want to give information to IETF to consider *call* when speaking or also when writing/reading documents? and if you write your formal name as your speak names tradition, do you suggest a method to have in writting names translated to English in IETF doc (optional for authors) without ignoring the authors' regional culture. So you may write for this draft: Author- Deng Hui (mandarin) in the last page of IETF doc and in front page the same formal English semantic way, as Hui Deng. Please advise, Thanks, AB On 7/11/13, Hui Deng denghu...@gmail.com wrote: Hello all We submitted two drafts to help people here to correctly call chinese people names: http://tools.ietf.org/html/draft-deng-call-chinese-names-00 http://tools.ietf.org/html/draft-zcao-chinese-pronounce-00 Feel free to let us know if you have any other issues? Best regards, -Hui Deng
Re: IETF registration fee?
Hi Paul, I agree with you if someone attends without presenting work, but I think the fees is reasonable if we compare with other conferences fees per day (don't forget your free to presentations of your docs and get feedback from many sessions, this may change in future if higher load). If the IETF considers your request, I think it will increase participation maybe about 5% globaly and 20% locally, so mostly encourages regional participations. I will also add that if the IETF can consider newcomers to get discount for one day, because newcomers may want to get a feeling of the meeting. AB On 7/10/13, Paul Aitken pait...@cisco.com wrote: Can you help me understand why the One Day Pass rate ($350) is so high compared with the full week rate ($650 / $800)? Registering for two days could cost more than a week! Surely the day rate should be a little more than (week/5), eg about $175 - $200, to encourage those who only want/need to contribute on particular days? Thanks, P.
Re: Call for Comment on draft-iab-anycast-arch-implications-09 on Architectural Considerations of IP Anycast
The informational-draft does not define IP anycast or does not refer to a document that defines the IP anycast (anycast was defined as refer to rfc1546). However, I think it is a draft for anycast services/methods in IP protocols (Internet Anycast), not only IP anycast. AB On 7/3/13, IAB Chair iab-ch...@iab.org wrote: This is an announcement of an IETF-wide Call for Comment on Architectural Considerations of IP Anycast (draft-iab-anycast-arch-implications-09). The document is being considered for publication as an Informational RFC within the IAB stream, and is available for inspection here: https://datatracker.ietf.org/doc/draft-iab-anycast-arch-implications/ The Call for Comment will last until August 1, 2013. Please send comments to i...@iab.org or submit them via TRAC (see below). Russ Housley IAB Chair = = = = = = = = = = Submitting Comments via TRAC 1. To submit an issue in TRAC, you first need to login to the IAB site on the tools server: http://tools.ietf.org/wg/iab/trac/login 2. If you don't already have a login ID, you can obtain one by navigating to this site: http://trac.tools.ietf.org/newlogin 3. Once you have obtained an account, and have logged in, you can file an issue by navigating to the ticket entry form: http://trac.tools.ietf.org/wg/iab/trac/newticket 4. When opening an issue: a. The Type: field should be set to defect for an issue with the current document text, or enhancement for a proposed addition of functionality (such as an additional requirement). b. The Priority: field is set based on the severity of the Issue. For example, editorial issues are typically minor or trivial. c. The Milestone: field should be set to milestone1 (useless, I know). d. The Component: field should be set to the document you are filing the issue on. e. The Version: field should be set to 1.0. f. The Severity: field should be set to based on the status of the document (e.g. In WG Last Call for a document in IAB last call) g. The Keywords: and CC: fields can be left blank unless inspiration seizes you. h. The Assign To: field is generally filled in with the email address of the editor. 5. Typically it won't be necessary to enclose a file with the ticket, but if you need to, select I have files to attach to this ticket. 6. If you want to preview your Issue, click on the Preview button. When you're ready to submit the issue, click on the Create Ticket button. 7. If you want to update an issue, go to the View Tickets page: http://trac.tools.ietf.org/wg/iab/trac/report/1 Click on the ticket number you want to update, and then modify the ticket fields as required.
Comments For I-D: draft-moonesamy-nomcom-eligibility-00 (was Re: The Nominating Committee Process: Eligibility)
This message is reply to an author of a new draft under ietf discussion. If this list is not the correct place to discuss such matter, then the list's responsible Chair is required to give details of where to discuss such new work. + Hi Moonesamy, (the Author of draft-moonesamy-nomcom-eligibility-00) I think the draft still needs more details, for example, the Abstract says to give remote contributors eligible to serve but how many remote, it is not-reasonable/not-practical to have most remote, and it is not fare/diverse to have all not remote. Furthermore, you did not mention diversity in the draft related to members selected. AB I prefer if you refer me, or the discussion list chair can refer me to somewhere we can discuss this new draft. Please note that I was told not to post more discuss messages on this list, so the chair or you are required to respond on this issue related to discussing the draft, because this may be my last post regarding this I-D. AB the update may need an informational draft (or better introduction) like what [1] is doing, so if we know the information on process challenges we will know the best practice. I like the [1] draft I think it needs to be renewed including remote members possibilities. [1] http://tools.ietf.org/id/draft-crocker-nomcom-process-00.txt AB you need to define *remote contributor* in the draft. When the authors define it then I can amend or edit. You need to mention that most of meeting of IETF per year are in one region which makes some from other regions to contribute remotely. Section 2 The section is not reasonable because you changed with no strong reasons. Why you want to change totally, I recommend to add idea not change. As to give opportunity to additional memebrs that are remote. These additional memebrs will have a special condition. This way you don't change the conditions for the current procedure of selecting f2f memebrs, and you may limit the number of remote contributors maybe 10 % of the total memebrs. AB suggest in Section 2 I suggest not to update the text of the RFC but to add new rule for selecting few remote participants. AB you need to add what are the remote memebrs responsibilities, because they may be similar or different than the other memebrs. my answers to your questions below, On Fri, Jun 28, 2013 at 1:50 AM, S Moonesamy sm+i...@elandsys.com wrote: Hi Abdussalam, Thanks for explaining why you support the draft. I am going to list some questions. Please read them as points to consider. There isn't any obligation to provide comments. You mean the draft should consider, - What is your opinion about helping the pie get larger? No we don't want things to get larger for others to eat, we want things to get smarter for others to use, share, and develop equally. - What would be an acceptable way of determining whether someone has been contributing to the IETF over a period of five meetings? Where are the five meetings (is it a f2f meeting?)and what kind of contributing you are asking? - Dave Cridland suggested that working groups provide a smallish set of volunteers each for the selection process. Is it okay to leave it to the working group chair to make the decision? I will send you discusses/answers offline I really want to focus questions related to the new draft not other issues. Therefore, I think the draft needs to involve what was discussed on the list (feedback). Updating this RFC procedure may need more reasons than what was presented in the draft, I think it is nice if you add more and change info to renew this draft for more further discusses. Thanks. AB
Re: The Nominating Committee Process: Eligibility
Thanks Moonesamy, I support the draft, it will give all participants from all the world equal opputunity. I made input related to this on the list because I found that I am remote participant and there was limits and conditions which I don't want. However, there may be some reasons that IETF done it that way which the draft may need to clarify and solve, AB On Thu, Jun 27, 2013 at 10:50 AM, S Moonesamy sm+i...@elandsys.com wrote: Hello, RFC 3777 specifies the process by which members of the Internet Architecture Board, Internet Engineering Steering Group and IETF Administrative Oversight Committee are selected, confirmed, and recalled. draft-moonesamy-nomcom-**eligibility proposes an update RFC 3777 to allow remote contributors to the IETF Standards Process to be eligible to serve on NomCom and sign a Recall petition ( http://tools.ietf.org/html/** draft-moonesamy-nomcom-**eligibility-00http://tools.ietf.org/html/draft-moonesamy-nomcom-eligibility-00). Could you please read the draft and comment? Regards, S. Moonesamy
Re: Accessibility of IETF Remote Participation Services
As per a request I received from you Dear Bernard, Chair, IETF Remote Participation Services Committee Thanks for your message. I am a remote participant that never ever came to the IETF meetings and not sure if I would. I think my experience may help your committee and it will help my investigation as well about the IETF performance. I hope that your committee has some people that are remote to IETF, so they have the feeling of our feelings. My feedback (as you request it) can be as below: The below observation is owned by the sender to be used in future I-draft 1- I don't feel that some WG chairs give importance to remote participants, maybe even presenters in IETF may not even know who is in remote. This needs to be improved. 2- I rememebr that once while my participation, I asked about how many f2f participants in the room agree or disagree, and I was noticed, but it will be helpful if WG chairs are using Jabber while checking the consensus, and say what is the situation, because I felt that the remote participants were not checked if they agree or disagree only f2f participants. 3- I as remote participant when I enter a room I want to know how many attending the room from both (f2f and remote), I only know how many are remote, and I seen some f2f participants are also in remote so they can see both sessions in the room. 4- We need more interaction from remote people than from f2f participants, I have feeling that the attended f2f are driving the meeting, no equal opportunity between participants 5- Some use the excuse of time limits, so remote people can easily be excluded from time used because maybe not important in the room discussions. Why do you get that feeling, IMHO all are equal and important, otherwise the IETF should give all regions equal meeting times. 6- I got once an I-D and wanted to present it while I was remote, but the IETF did not provide a way to enable me to present that I-D. I tried even to find a person to present but no one done for me. I was excluded even when I already done some efforts, does that mean that people who cannot attend cannot get their I-D adopted? 7- I have many other points but would like to leave them to my future I-Ds that when I get better time will share, but above are the main ones. Best Regards AB On Thu, Jun 27, 2013 at 8:06 PM, IETF Administrative Director i...@ietf.orgwrote: From: iaoc-...@ietf.org Subject: Accessibility of IETF Remote Participation Services For more than a decade, the IETF has tried to make it easier for remote attendees to participate in regular and interim face-to-face meetings. The current tools that the IETF has been using, as well as the state of remote participation services in the IETF was summarized by the IETF Chair in a message to the IETF-Announce list on 5 February 2013: http://www.ietf.org/mail-archive/web/ietf/current/msg77020.html Section 1 summarizes the current remote participation system: The IETF's current remote participation system (RPS) consists of a outbound real-time audio stream for each session carried to remote attendees over HTTP, textual multi-user chat carried over XMPP (commonly called Jabber), and posting of slides prior to the WG session so that they can be downloaded from the IETF web site. WebEx and Meetecho are experimentally supported, offering outbound real-time audio stream synchronized to the slides for the remote participant. Meetecho displays the Jabber Room on the screen with slides, and it can also be used to replay the audio and slides from a recording. As noted in Section 4 of the IETF Chair message, the IETF is currently soliciting suggestions for improvements in its RPS capabilities. As part of that, the IETF would like to solicit feedback on the accessibility and usability of remote participation services by IETF participants with disabilities. If you would like to comment on the accessibility and usability of IETF RPS services, please send email by July 26, 2013 to iaoc-rps at ietf.org, Subject: RPS Accessibility, and CC: ietf@ietf.org. Bernard Aboba Chair, IETF Remote Participation Services Committee
Re: documenting feedback of meeting venues
Hi Bob Hinden, and IETF management I attended a presentation of IAOC in IETF last-meeting. I have send you the below message which you did not reply so far (was waiting for three months). Please note that this is my last reminder (will wait only two weeks). I was remotely attending your talk in the last IETF meeting, and I asked a question but you or someone refered me to post on the list and that I will get reply. Please note I still did not get a reply and that I think was ignored by the presenters of such work. I don't think the community can be ignored. AB I usually give a communication delay tolerance time for about three months because people may be busy, but don't forget my requests :-) On 3/10/13, Abdussalam Baryun abdussalambar...@gmail.com wrote: To: Bob Hinden, (presented at IAOC overview) My question to Bob; why not document the feedback (of meeting venues) of community of past for the future? I recommend to change the IAOC procedure, to allow documentation? AB
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
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 Diversity
Commenting is already an action taken, so we thank who made effort to bring the points forward. I always add my comments even though I had given no title. However, thoes folks that have been given titles by the IETF I think they should do actions more regarding this diversity issue as Mr.Hallam-baker requesting. I never give excuses to managers, but appreciate all their efforts and patients for the community :-) AB On Wed, Jun 19, 2013 at 4:08 PM, Peter Saint-Andre stpe...@stpeter.imwrote: On 6/19/13 8:32 AM, Dave Crocker wrote: On 6/19/2013 5:35 AM, Dave Cridland wrote: Phillip Hallam-Baker wrote: There is a real problem with accountability and transparency in the IETF constitution which was designed by a bunch of old boys to maintain control in their own hands. Peter is a member of the IETF establishment so of course he sees no structural problem. PSA's been an AD, yes, but: Forgive me, but you just responded to a rather unpleasant ad hominem. We should not sustain such threads. My point, poorly expressed though it was, is that it's not productive for us all to wait from word on high before taking positive action. Members of the IESG, IAB, IOAC, or any other official body are just folks who are temporarily serving the community in a defined role. If we want to change the culture of our community with respect to diversity, it's better for us to work to encourage, nurture, and mentor particular individuals. My apologies for the extremely egregious manner in which I stated the point. It was not directed personally at Mr. Hallam-Baker, but at all of us who talk and don't take action -- myself very much included. Peter -- Peter Saint-Andre https://stpeter.im/
Re: IETF Diversity
I think all need mentoring. It is a both way learning for top and down levels. So maybe newcomer can be mentoring to management of what is a newcomer like these days :-) AB
Re: IETF Diversity
On 6/18/13, Phillip Hallam-Baker hal...@gmail.com wrote: I am rather disappointed that there hasn't been any followup to the diversity discussion that took place at the plenary. I thought there are some people following/working this up, and made some progress. However, I agree that I seen no progress written/reported to us, I do applications and I do security and so having a diverse range of input is critical if the final product is going to be useful. There are no gender or cultural issues in packet routing that I am aware of. But once we get to the application layer they become central. I agree that at that layer you will face the community. It does not take 100 people to write a specification but it does take a large number of people to adequately gather requirements. Taking requirements from 100 people from almost the same background and perspective is not very productive. I am aware that I have a limited personal perspective which is why I actively seek out other perspectives. I mentioned similar idea of that before, and I agree IETF needs diversity to progress. At the plenary I pointed out that there have been women involved in IETF ever since I started in IETF over 20 years ago now. Yet we have an IAB and an IESG with only one female member who is not ex-officio (according to their Web sites) That situation should be something that has the IETF management worried but I can't see much sign of that. I suggested also that we need more women in management, so I support that, however, majority men may not want that, so what can we do The IETF is unlikely to die but it can lose influence beyond the IP and DNS core. Sooner or later someone is going to work out how to establish an applications standards process that is gender and culture inclusive. And we know from experience that in our environment there can be a remarkably small time between the idea and establishing an institution. It is good if IETF realise that it can loose, so it will work harder. The IETF is mostly doing its meetings in North America so its culture is closer to North America culture. Minecraft was launched in 2011 and they had 4,500 people at their first international conference that year, they are now about to have their third. So they went from having nothing to having a larger participant community than the IETF in a matter of months. I think that is good news, and that IETF should realise how did that happen, and realise what is wrong in IETF. I suggested before that IETF encourages participants, and gave many responses but still I was feeling ignored. The IETF is a community known for valuing consensus rather than seeking diverse views. I see a real risk that the consensus being built here is a false consensus built by excluding opposing views rather than a real consensus built on reconciling them. I already mentioned that before, I found out that many say we want consensus when they don't have good engineering reason, and when there is no consensus they go back to technical reasons. Bringing opposing views to this forum is invariably a thankless task. The assumption is that if you can't hack it here well that is your fault and your problem. Case in point, each time I get something wrong in RFC2HTML and I get the error message 'You Lose', my natural response is 'why the heck am I bothering wasting my time here'. We waste time only if management don't listen to the minorities/diversed of the community. I do not think that gender is the only diversity problem in IETF but it is one that can be measured and the IETF is conspicuously failing. We also have a rather severe age problem, twenty years ago EKR and myself were among the youngest participants in most discussions and setting aside the grad students the same is usually true today. I agree, The perspective is going to need to change. Rather than looking for ways to encourage a few token women to work their way up through the existing selection regime we need to look at what sort of selection and participation and representation structures will encourage diversity. I think it is very easy to encourage people, and very easy to discourage people, the difficult part is to maintain people encouraged and liking to continue participating in the IETF. Many people in life hate CHANGE, so that is another difficulty, the IETF should get use to CHANGE. Thanks for your input it makes a greater impact than my inputs maybe because my english. AB
Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
The IETF Last Call has finished after 06.06.13 and now you request discussions. I think only IESG can call for discussions not editors. On 6/10/13, Ulrich Herberg ulr...@herberg.name wrote: We have submitted a new revision of the draft, addressing one comment from Adrian during IETF LC (which we wanted to address in the previous revision, but forgot about it). We added a new section that can trigger future work, as requested by Adrian. I don't see that Adrian requested a future work section, could you refer to his input for that or was that private request. May be comments in last call made you think to add missing information as future. What is the reason for future work in this informational draft? To the WG: Obviously, the new text is up for discussion if anyone has any issues with it. Is that a new text or new idea? if I don't know what the Editors discussed privately (outside IETF) how can I discuss inside IETF? However, I will not review any more for this draft because it has special policy for refering to contributions. AB Best regards Ulrich On Thu, May 23, 2013 at 3:22 PM, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'Security Threats for NHDP' draft-ietf-manet-nhdp-sec-threats-03.txt as Informational RFC 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-06-06. 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 analyses common security threats of the Neighborhood Discovery Protocol (NHDP), and describes their potential impacts on MANET routing protocols using NHDP. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats/ballot/ No IPR declarations have been submitted directly on this I-D. ___ manet mailing list ma...@ietf.org https://www.ietf.org/mailman/listinfo/manet ___ manet mailing list ma...@ietf.org https://www.ietf.org/mailman/listinfo/manet
Re: Content-free Last Call comments
A comment is a comment (important for discussing) which I want to see, no matter if content-free or not, the origin requester (IETF Last Call/WGLC) of such comments SHOULD specify which type of comment they want if necessary. As long as it is a comment-on-discuss-lists any can ask questions to the commentor to know the comment-reason if necessary. IMO, we don't want no-comment, ignorance, or no answers if requested, which will mean no discussions. AB
Re: Last Call: draft-ietf-ospf-manet-single-hop-mdr-03.txt (Use of OSPF-MDR in Single-Hop Broadcast Networks) to Experimental RFC
Hi Richard, I send to the author of an IETF document a message but it was not answered. I beleive that the question from the community was ignored, I hope you understand the importance of community questions. Why does the IETF name its documents RFCs, any one from the community can ask questions even after the RFC is produced, so we SHOULD NOT be stoped to comment on any document and the IETF SHOULD try to answer communities questions, otherwise IETF SHOULD NOT request comments. comments below, On 6/7/13, Richard Ogier og...@earthlink.net wrote: AB, As Joel pointed out, your questions should have been raised during the OSPF WG Last Call, which you did not participate in. You (inappropriately) posted questions on the MANET WG list after the OSPF WGLC was complete, and several people responded, most of them stating that RFC 5444 is not required for this document: Please note that I got a message from IETF post or an AD post in MANET WG, so I responded, and asked the author by their address (it was appropriate/reasonable reaction). I may agree that I should send to the origin WG, which I learn now, but only if that WG is open to questions. I know I don't work in OPSF WG, but that does not mean any one can stop me from commenting or asking questions outside that blocked-WG. My questions were before the IETF last call (which is enough). http://www.ietf.org/mail-archive/web/manet/current/msg15403.html http://www.ietf.org/mail-archive/web/manet/current/msg15406.html http://www.ietf.org/mail-archive/web/manet/current/msg15407.html http://www.ietf.org/mail-archive/web/manet/current/msg15408.html Although I should not be required to respond to your questions at this point, I thought that within the IETF last call of the I-D, all the community questions and comments are answered as long as the last call did not end. Furthermore, the OPSF WG is blocking me (so no one unsubscribed from the community can comment on the document) from sending my thoughts yesterday even after I subscribed. Thanks for your respond below, AB I will provide a few additional reasons why RFC 5444 and DLEP are not relevant for this document. (These reasons also apply to the parallel document draft-ietf-ospf-manet-single-hop-or-02.) 1. This draft does not propose a new interface, it only describes how the interface previously specified in RFC 5614 (and RFC 5820 for the other draft) can be configured in the special case of a single-hop MANET. Therefore, your comments should have been directed to RFC 5614 (and RFC 5820). 2. RFCs 5614 and 5820 describe MANET extensions to OSPF, and one of the goals was to minimize changes to OSPF, so we decided to use OSPF packet formats (with minimal changes), rather than MANET packet formats that were designed without OSPF in mind. (This point is also made in the last message listed above.) On the other hand, these are experimental documents, so your questions about using RFC 5444 and DLEP may be valid for future modifications to the proposed MANET extensions of OSPF (both RFCs 5614 and 5820). But they are not valid for draft-ietf-ospf-manet-single-hop-mdr or draft-ietf-ospf-manet-single-hop-or, not only because these two drafts have already completed WG Last Call, but also because they only describe how to configure RFCs 5614 and 5820 for the special case of a single-hop network. Richard On 6/6/13 3:15 AM, Abdussalam Baryun wrote: I send my request to the editors including questions but no reply from them to me. The thread [1] raised some issues, which is not mentioned in the I-D. The message [2] was ignored not answered (this is last reminder). The message [3] proposes using RFC5444 into this I-D, or raise the question of why not using MANET packet format within MANET domains (I need an answer). [1] http://www.ietf.org/mail-archive/web/manet/current/msg15400.html [2] http://www.ietf.org/mail-archive/web/manet/current/msg15412.html [3] http://www.ietf.org/mail-archive/web/manet/current/msg15418.html The I-D SHOULD not go forward if it still ignores the IETF community questions. Regards AB On 6/5/13, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Open Shortest Path First IGP WG (ospf) to consider the following document: - 'Use of OSPF-MDR in Single-Hop Broadcast Networks' draft-ietf-ospf-manet-single-hop-mdr-03.txt as Experimental RFC 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-06-19. 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 RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks (MANETs) by specifying its operation on the new OSPF interface of type MANET
Re: Weekly posting summary for ietf@ietf.org
Hi thomas, AB Comment on the summary report I recommend to add a column for subjects (number of subjects), because the number of subject participated in is very important is such summary. I think the pupose of this summary should be added as well in each post, I don't know why, only I expect the purpose is that it informs of work volume or overhead in such list. AB On 6/7/13, Thomas Narten nar...@us.ibm.com wrote: Total of 146 messages in the last 7 days. script run at: Fri Jun 7 00:53:03 EDT 2013 Messages | Bytes| Who +--++--+ 10.27% | 15 | 9.96% | 125797 | abdussalambar...@gmail.com 4.11% |6 | 6.44% |81389 | adr...@olddog.co.uk 5.48% |8 | 3.76% |47556 | mo...@necom830.hpcl.titech.ac.jp 4.11% |6 | 4.30% |54259 | war...@kumari.net 3.42% |5 | 3.58% |45181 | john-i...@jck.com 3.42% |5 | 3.28% |41450 | l.w...@surrey.ac.uk 3.42% |5 | 3.16% |39894 | d...@dcrocker.net 3.42% |5 | 2.36% |29749 | ra...@psg.com 2.74% |4 | 2.53% |31911 | carlosm3...@gmail.com 2.74% |4 | 2.18% |27483 | arturo.ser...@gmail.com 1.37% |2 | 3.38% |42690 | ron.even@gmail.com 2.74% |4 | 1.86% |23539 | m...@mnot.net 1.37% |2 | 3.15% |39833 | simo.veikkolai...@nokia.com 2.05% |3 | 1.88% |23809 | scott.b...@gmail.com 2.05% |3 | 1.68% |21225 | s...@resistor.net 2.05% |3 | 1.62% |20488 | ted.le...@nominum.com 1.37% |2 | 2.29% |28971 | doug.mtv...@gmail.com 2.05% |3 | 1.54% |19411 | jmamo...@gmail.com 0.68% |1 | 2.80% |35397 | elw...@folly.org.uk 2.05% |3 | 1.37% |17285 | iab-ch...@iab.org 0.68% |1 | 2.66% |33542 | cb.li...@gmail.com 1.37% |2 | 1.73% |21883 | barryle...@computer.org 1.37% |2 | 1.64% |20761 | jcur...@istaff.org 1.37% |2 | 1.50% |18953 | brian.e.carpen...@gmail.com 1.37% |2 | 1.44% |18207 | ulr...@herberg.name 1.37% |2 | 1.37% |17302 | hartmans-i...@mit.edu 1.37% |2 | 1.35% |17078 | aeop...@gmail.com 1.37% |2 | 1.27% |16048 | m...@blackops.org 1.37% |2 | 1.10% |13834 | spencerdawkins.i...@gmail.com 1.37% |2 | 1.09% |13711 | chris.dearl...@baesystems.com 1.37% |2 | 1.06% |13376 | joe...@bogus.com 1.37% |2 | 0.94% |11882 | c...@tzi.org 1.37% |2 | 0.92% |11641 | to...@isi.edu 0.68% |1 | 1.60% |20151 | rjspa...@nostrum.com 1.37% |2 | 0.88% |11081 | jari.ar...@piuha.net 1.37% |2 | 0.87% |10956 | fg...@si6networks.com 0.68% |1 | 0.95% |12013 | ke-oog...@kddi.com 0.68% |1 | 0.88% |11066 | nar...@us.ibm.com 0.68% |1 | 0.73% | 9244 | og...@earthlink.net 0.68% |1 | 0.67% | 8504 | framefri...@gmail.com 0.68% |1 | 0.66% | 8340 | d3e...@gmail.com 0.68% |1 | 0.63% | 7996 | david.bl...@emc.com 0.68% |1 | 0.63% | 7948 | yb...@panix.com 0.68% |1 | 0.62% | 7882 | daedu...@btconnect.com 0.68% |1 | 0.61% | 7654 | i...@cdl.asgaard.org 0.68% |1 | 0.61% | 7651 | yi.ji...@gmail.com 0.68% |1 | 0.60% | 7579 | elw...@dial.pipex.com 0.68% |1 | 0.59% | 7486 | ma...@isc.org 0.68% |1 | 0.55% | 6960 | d...@cridland.net 0.68% |1 | 0.55% | 6886 | aman...@verisign.com 0.68% |1 | 0.53% | 6748 | rwfra...@gmail.com 0.68% |1 | 0.52% | 6615 | bmann...@isi.edu 0.68% |1 | 0.52% | 6609 | j...@mercury.lcs.mit.edu 0.68% |1 | 0.51% | 6418 | stephen.farr...@cs.tcd.ie 0.68% |1 | 0.50% | 6367 | do...@dougbarton.us 0.68% |1 | 0.50% | 6353 | p...@cypherpunks.ca 0.68% |1 | 0.50% | 6328 | f...@cisco.com 0.68% |1 | 0.49% | 6164 | p...@frobbit.se 0.68% |1 | 0.45% | 5654 | y...@checkpoint.com 0.68% |1 | 0.44% | 5502 | nscl...@gmx.de 0.68% |1 | 0.41% | 5235 | c...@a.org 0.68% |1 | 0.41% | 5212 | pe...@akayla.com 0.68% |1 | 0.40% | 5074 | wjh...@hardakers.net +--++--+ 100.00% | 146 |100.00% | 1263211 | Total
Re: Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
don't like to show that non-popular found their mistakes, but Why thoes experts came to use IETF service which calls-reviews to all levels of experties to contribute to the document they author under IETF ownership? Normal IETF business is to discuss not seek acknowledgement. Ideas, Comments and reviews are included in the discuss for drafts progress. Seeking acknowledgement is not wrong within IETF, but please consider *not acknowledging reviews* within IETF documents is not IETF culture (we are not paid so why you thinking much of the business, the IETF business will only progress with acknowledging the volunteers). If you want to change the way that the IETF participants (and document authors/editors in particular) acknowledge reviews of their documents, then please start a separate thread or, better still, write an I-D and see whether you can gain consensus. I know that, but your advise comes back to you also, if you want to change the community expectations close to your opinions, I advise you to write an I-D that shows where to exclude participants to IETF documents. The last time you brought this topic up on this list, I do not recall seeing support. Few did not support which were less than 15 persons, because IMO, there was no evidance of editors seeking to ignore reviewers contributions. Also, change is difficult any where in any organisation, so it will take time, IMO, people realise that participating-experts of IETF are the minority comapared to the community. I decided to complain any procedure error first and then write about what happend, so I will wait to see what is the IESG decision regarding the acknowledgement request. Please note that I have many procedural I-D in mind but it depends on the right time to submit it and get support. The only reason I can find for someone being able to demand that they are named in an Acknowledgements Section is for conformance to the IETF's Rights policies. My reason is that the truth SHOULD be reflected on the document. If you are editor I recommend you may say in the section thanks to x for his minor contribution if that satisfies your WG you work with, but not to ignore the truth. The truth is that IETF is calling for reviews from the community mostly not only from companies, and that your document changed an idea, so you ack. I do not propose to do an explicit consensus call on whether Abdussalam should be named in this draft. IMO, it should have been done in the WG. Thank you for your opinion. Are you asserting that consensus on the readiness of this document for a publication request was incorrectly called by the working group chairs. This would be a serious allegation against the chairs and I would require evidence that there had been no consensus or that they had made an incorrect assessment of the consensus. No, I accepted that the I-D goes to IESG only the complaint request of acknowledgement and the community reviews in IETF-LC. The wg chair mentioned my complaint in his report. I wait for the IESG decisions related to this I-D. Best Regards Abdussalam Baryun A Participant working in IETF (subscribed) A Memebr of Internet Society (registered)
Re: Last Call: draft-ietf-ospf-manet-single-hop-mdr-03.txt (Use of OSPF-MDR in Single-Hop Broadcast Networks) to Experimental RFC
I send my request to the editors including questions but no reply from them to me. The thread [1] raised some issues, which is not mentioned in the I-D. The message [2] was ignored not answered (this is last reminder). The message [3] proposes using RFC5444 into this I-D, or raise the question of why not using MANET packet format within MANET domains (I need an answer). [1] http://www.ietf.org/mail-archive/web/manet/current/msg15400.html [2] http://www.ietf.org/mail-archive/web/manet/current/msg15412.html [3] http://www.ietf.org/mail-archive/web/manet/current/msg15418.html The I-D SHOULD not go forward if it still ignores the IETF community questions. Regards AB On 6/5/13, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Open Shortest Path First IGP WG (ospf) to consider the following document: - 'Use of OSPF-MDR in Single-Hop Broadcast Networks' draft-ietf-ospf-manet-single-hop-mdr-03.txt as Experimental RFC 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-06-19. 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 RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks (MANETs) by specifying its operation on the new OSPF interface of type MANET. This document describes the use of OSPF-MDR in a single-hop broadcast network, which is a special case of a MANET in which each router is a (one-hop) neighbor of each other router. Unlike an OSPF broadcast interface, such an interface can have a different cost associated with each neighbor. The document includes configuration recommendations and simplified mechanisms that can be used in single-hop broadcast networks. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/ballot/ No IPR declarations have been submitted directly on this I-D.
Re: Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
On 6/6/13, Adrian Farrel adr...@olddog.co.uk wrote: Hi, It falls to me to make a call on this issue before the document moves on. Abdussalam has complained that he has not been acknowledged and has objected to the current text in section 8. The authors have responded on the MANET list We believe that only comments that lead to significant improvements of the draft deserve a listing in the acknowledgment section, and we have therefore not modified the section. What was the WG decision? Why any contribution that influnces the I-D ideas is not acknowledged? IMO, if a technical-idea within the I-D was discovered wrong by a participant, or a new technical-idea added to I-D from an input, then the I-D should be acknowledged. I have reviewed the email threads on the MANET mailing list and do not consider that Abdussalam made contributions to the text of the document. Didn't that person make review and discovered errors? Why don't you consider discovering an error as a contribution? Why don't you consider providing new ideas a contribution? What is your definition to contribution? I also believe that the comments he made did not advance the content of the document. So I understand that you need to have advance the content then you acknowledge. Furthermore, per multiple references (such as RFC 2026) the Acknowledgements section is used to properly acknowledge major contributors. I am trying to find that condition of *major contribution*, Normal IETF business is to discuss not seek acknowledgement. Ideas, Comments and reviews are included in the discuss for drafts progress. Seeking acknowledgement is not wrong within IETF, but please consider *not acknowledging reviews* within IETF documents is not IETF culture (we are not paid so why you thinking much of the business, the IETF business will only progress with acknowledging the volunteers). I do not propose to do an explicit consensus call on whether Abdussalam should be named in this draft. IMO, it should have been done in the WG. AB From: Abdussalam Baryun [mailto:abdussalambar...@gmail.com] Sent: 03 June 2013 17:10 To: ietf Cc: adr...@olddog.co.uk; i...@ietf.org Subject: Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC I would hope that IETF add my name in the acknowledgement section of the I-D. I complained to AD about that my efforts in WGLC was not acknowledged by editors even after my request, however, I did not stop reviewing (trying not be discouraged) which I will complete on 6 June with the final comments. Therefore, this message (can be added as a comment on the I-D) is an objection to section 8 that ignores acknowledge input/review effort related to the I-D. AB
Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
Reply to your request dated 24/05/2013 I-D: draft-ietf-manet-nhdp-sec-threats-03 Draft Reviewed By: Abdussalam Baryun (AB)Dated:06/06/2013 Reviewer Comment A3: Use Cases not considered and the Information Bases Threats. +++ *Use-cases threats* Reading the RFC6130 applicability section 3, the I-D does not consider all the use-cases included in the that section 3. AB Does the use-case of NHDP [RFC6130] add any value to the threats, or the I-D assumes only one use case which is OLSRv2 network. The NHDP uses RFC5444 packets and RFC5444 messages, so what are the threats to NHDP use for each? not mentioned in I-D. RFC6130 NHDP Can use relevant link-layer information if it is available. AB is there any threat from that use-case? not mentioned in the I-D. *Information bases threats* RFC6130 Appendix F This appendix illustrates various examples of physical topologies, as well as how these are logically recorded by NHDP from the point of view of the router A. This representation is a composite of information that would be contained within A’s various Information Bases after NHDP has been running for sufficiently long time for the state to converge. AB Why the logically recording of the NHDP for all the examples not mentioned in the I-D and were not threat analysed? If there is similar level of threats related to all exampels in RFC6130, then please mention that. This is my last message, thanks. Regards AB
Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
I received an IESG message asking my comments so I gave it, regard to your comments below, the reply is that I refer to missing information needed in the I-D, so the reveiw suggests that there is something missing. Did not suggested text because I know that it most probably not be considered. The Last call ends by 06.06.2013 so I still am in this date, not sure why you close, AB On 6/6/13, Adrian Farrel adr...@olddog.co.uk wrote: I find it somewhat disruptive that this email raises new questions on a draft authored in a working group in which you participate, and that it has arrived after the end of IETF last call. I see a series of questions in this message, but no suggested textual changes. I therefore conclude that you are requesting no changes and none shall be made. Thank you. Adrian Reply to your request dated 24/05/2013 I-D: draft-ietf-manet-nhdp-sec-threats-03 Draft Reviewed By: Abdussalam Baryun (AB)Dated:06/06/2013 Reviewer Comment A3: Use Cases not considered and the Information Bases Threats. +++ *Use-cases threats*
Re: Forwarding AODV messages over a tunnel
On 6/5/13, Thomas Meier nscl...@gmx.de wrote: Hello, I want to forward AODV messages over a tunnel (don't worry, it's not for a wormhole attack). its ok, but if it was my AODV network I will be worried. Tunneling is not understood only if I know what network are you tunneling through!! In the RFC3561 I can't find information about how to deal with the packet at the tunnel endpoint. IMHO, normal ways of packet tunnel Should I increment the hopcount of a RREQ by one or by the number of hops the tunnel has? RREQ is not a packet, your question was on packets, that increment of RREQ is done by AODV node received. So I think only once, because one tunnel and between two aodv-nodes only. Furthermore I'm wondering about which address to use for the previous node at the tunnel endpoint. Should this be the entrance of the tunnel or the real previous node? nothing is real when you are tunneling, so use the node address of tunnel start. Overall I think the routing performance will not be good only if the network elements of the tunnel is not mobile. If the tunnel entrance is used as previous node and the hopcount is only incremented by one, the tunnel would be prefered compared to a connection without a tunnel (like in wormhole attacks). Not correct, you don't say your reason, so I don't know how to respond. Is there some information on how to deal with a tunnel? In MANET documents I don't think there is importance of using tunneling, I think it is not prefered. If used it will be an attack so I am worried about what are you doing :-) AB
Re: Call for Review of draft-iab-rfc4441rev-04.txt, The IEEE 802 / IETF Relationship
Reply to your request dated 05.06.2013 Reviewer: Abdussalam Baryun Dated 06.06.2013 The I-D: draft-iab-rfc4441rev-04 A1 Comments: Overall Overall, why does the document start with IEEE before IETF. If this is a document produced by us as IETF, we need to focus on the relationship of OUR organisation first with others. So IMHO, it should say in the title: The IETF/ IEEE 802 Relationship. Within all the document I recommend we follow that focus on the relationship between the IETF and IEEE 802. In the sections I recommend to start with IETF not IEEE802. Furthermore, the title just says relationship, it is not enough title, what kind of relationship you are doing? The word relationship is not mentioned in the Abstract at all which I expected that. ABchange please amend the title to : The IETF and IEEE 802 Collaboration Relationship. Why the I-D does not reference a normative reference from IEEE that also states the relationship between IEEE802 / IETF, or is there no document procedure for the other party? Each IETF and IEEE802 should have their own terminology in this I-D, there is some mixing which confuses, example ballot used in IEEE802 but the I-D uses it for IETF as well (please change). Are we ignoring our other terminologies of IETF procedure. Section 3.1.4 Cultural differences AB there is missing culture issue which is the opennes, is the IEEE 802 open for access. Culture does not mean only how and when making decisions, the culture is about interacting with the COMMUNITY. I am not sure about the domain of the IEEE802 community, but know the IETF community. AB ADD please describe in this section the communities and access policy to each organisation body (WG, Working task, etc). Best Regards AB + On 6/5/13, IAB Chair iab-ch...@iab.org wrote: This is a call for review of The IEEE 802 / IETF Relationship prior to potential approval as an IAB stream RFC. The document is available for inspection here: https://datatracker.ietf.org/doc/draft-iab-rfc4441rev/ The Call for Review will last until 20 June 2013. Please send comments to i...@iab.org. On behalf of the IAB, Russ Housley IAB Chair
Re: Call for Review of draft-iab-rfc4441rev-04.txt, The IEEE 802 / IETF Relationship
I want to discuss this issue of collaboration if I get a response/permission. How can the IETF participant collaborate with IEEE 802 memebr/participant? From the I-D I see that the IETF participant NEEDs the IETF WG chair to do that, but the IEEE 802 participant does not need any chair. Are we collaborating at all levels as management and participants, or are we collaborating at management only from one organisation and at other levels at the other organisation (no equal opportunities)? I RECOMMEND that this I-D reconsiders the collaboration and leave it between managements of both organisations, as long as one of the organisation is collaborating mostly at management. If we don't discuss and only review, there may be a misunderstandning between community and the author. Regards AB On 6/5/13, IAB Chair iab-ch...@iab.org wrote: This is a call for review of The IEEE 802 / IETF Relationship prior to potential approval as an IAB stream RFC. The document is available for inspection here: https://datatracker.ietf.org/doc/draft-iab-rfc4441rev/ The Call for Review will last until 20 June 2013. Please send comments to i...@iab.org. On behalf of the IAB, Russ Housley IAB Chair
Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
I would hope that IETF add my name in the acknowledgement section of the I-D. I complained to AD about that my efforts in WGLC was not acknowledged by editors even after my request, however, I did not stop reviewing (trying not be discouraged) which I will complete on 6 June with the final comments. Therefore, this message (can be added as a comment on the I-D) is an objection to section 8 that ignores acknowledge input/review effort related to the I-D. AB On Mon, Jun 3, 2013 at 6:35 AM, Ulrich Herberg ulr...@herberg.name wrote: Hi Adrian, I personally agree that adding an informational ref to draft-ietf-manet-nhdp-olsrv2-sec is a good idea. I will discuss with my co-authors. Thanks Ulrich On Sunday, June 2, 2013, Adrian Farrel wrote: Hi Abdussalam, I think it is a reasonable suggestion for this I-D to make a forward reference to draft-ietf-manet-nhdp-olsrv2-sec Although this work is clearly scoped to NHDP (RFC 6130) as currently specified, it is worth an informational reference to note that there is work in progress that seeks to update NHDP to counter a number of security threats described in this document. I do not think, however, that this I-D should attempt to describe the situation with NHDP after the inclusion of protocol work that has not yet been completed. Contrary to your suggestion, I think this I-D motivates updates to 6130 and it would be wrong to review this document in the context of changes being made to address this document. Thanks, Adrian I think if we got an effort in IETF to update NHDP [RFC6130] as draft [1] does, why this reviewed I-D of threats does not include [1] in its references to be reviewed before reviewing this NHDP-threat I-D? I suggest to include draft [1] in References section, IMHO, any updates to RFC6130 should be considered by the community while reviewing this I-D. [1] draft-ietf-manet-nhdp-olsrv2-sec-02
Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
Hi Adrian My comments below, On 6/2/13, Adrian Farrel adr...@olddog.co.uk wrote: Hi Abdussalam, I think it is a reasonable suggestion for this I-D to make a forward reference to draft-ietf-manet-nhdp-olsrv2-sec Although this work is clearly scoped to NHDP (RFC 6130) as currently specified, it is worth an informational reference to note that there is work in progress that seeks to update NHDP to counter a number of security threats described in this document. So I understand you agree with my suggestion on this I-D to referencing/refering to that draft [1]. I do not think, however, that this I-D should attempt to describe the situation with NHDP after the inclusion of protocol work that has not yet been completed. I think the work completes when the WG submits to AD, but reviews not completed. IMHO, the draft/work [1] is completed from WGLC, and now is at AD review. Contrary to your suggestion, I think this I-D motivates updates to 6130 and it would be wrong to review this document in the context of changes being made to address this document. I suggest the I-D referencing. I do not think I suggested way of reviews, but that other satetment was my opinion/beleive or advise to community of such reveiw for output quality. I don't understand why you think it was wrong way of review, after you agreed to reference such document (usually my reviewing reviews all references as well). Regards AB I think if we got an effort in IETF to update NHDP [RFC6130] as draft [1] does, why this reviewed I-D of threats does not include [1] in its references to be reviewed before reviewing this NHDP-threat I-D? I suggest to include draft [1] in References section, IMHO, any updates to RFC6130 should be considered by the community while reviewing this I-D. [1] draft-ietf-manet-nhdp-olsrv2-sec-02
Re: Time in the Air
Thanks Mark, This is very interesting results, it is ok if not 100% correct which I think the error can be less than 10%, but I may have different analysis of results. You concluded that homes in Europe had better shortest distances to IETF meetings (assuming that thoes homes have full participation of all meeting from 2009). Always Europe gets better results because it is the favoriate meeting-location for ALL businesses, but hope that IETF changes most of its meetings in Europe which will serve all. I will post in future another message of my opinion of a best practice of meeting locations which may become a good I-D start (but need your assistance and your data results) My analysis will discover that the past locations of IETF meetings (from 2009 until now) does not serve-best the majority of full attendance-participants of IETF from all regions. Thoes past locations serve only regional-meeting-participants. My analysis discovers that there is not close air-time-results when comparing between homes/regions, the results variances between home cities are large. Overall, I suggest to consider the number of participants that are full time attendance in all most meetings 90% attendance (not 75%). Also to consider the number of past attendance of meetings in Europe and Asia (there are large differents I think). These two considerations will show that past locations of meetings did not serve better the IETF but served some regional-interests. IMHO, two meetings in Europe per year is a better practice for IETF activities. AB On 5/31/13, Mark Nottingham m...@mnot.net wrote: In an attempt to inject some data into the discussion, I wrote a bit of code that figures out how much time, given your home city, you would have spent in the air if you'd attended all IETF meetings since IETF74 (i.e., from 2009 onwards). The first column is the home airport. The second column is the great circle time between the home airport and the nearest large airport to the IETF meeting, hhh:mm. This doesn't count things like transit time, taxiing, takeoff and landing overhead, indirect routing, etc. As such, this is an ideal number; the only way to achieve anything close to it is to have a private jet (with exceptional range). The third column is the time (hhh:mm) using the shortest-time routing on a travel booking engine. This is first-takeoff-to-last-landing time. Both numbers assume round trip between home and the IETF airports. SFO 204:10 282:04 // San Francisco BOS 197:42 297:38 // Boston ATL 205:44 297:28 // Atlanta ANC 197:12 345:54 // Anchorage LHR 198:02 249:44 // London FRA 202:10 255:22 // Frankfurt FCO 223:52 283:04 // Rome SVO 211:28 287:14 // Moscow TLV 264:12 334:22 // Israel DXB 293:26 344:34 // Dubai NRT 259:00 314:38 // Tokyo HKG 296:38 359:22 // Hong Kong BLR 332:28 448:24 // Bangalore MEL 450:28 556:04 // Melbourne AKL 442:24 569:04 // Auckland JNB 414:30 498:22 // Johannesburg EZE 411:10 522:56 // Buenos Aires GIG 381:56 488:32 // Rio de Janeiro Draw your own conclusions, of course. One observation is that there's a 3+ days-in-the-air per year variance if you're a full-time participant, depending on where you live. I.e., more than one day-per-meeting difference, on average. In the air alone. Another is that, perhaps surprisingly, the closest homes to all meetings are in Europe, not the US (at least by shortest-time routing). I can run other airports upon request, as well as make source available, but will do so conservatively, so as not to incur the ire of the services I'm (ab)using. Regards, P.S. The IETF airports chosen were: IETF_airports: [ ORL, ATL, YVR, CDG, TPE, YQB, PRG, PEK, AMS, LAX, HIJ, ARN, SFO ], -- Mark Nottingham http://www.mnot.net/
Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
Continue Reply to your request dated 24/05/2013 Draft Reviewed By: Abdussalam Baryun (AB)Dated:02/06/2013 Reviewed I-D: draft-ietf-manet-nhdp-sec-threats-03 Reviewer Comment A2: Referencing the NHDP and related to RFC6130 ++ I think if we got an effort in IETF to update NHDP [RFC6130] as draft [1] does, why this reviewed I-D of threats does not include [1] in its references to be reviewed before reviewing this NHDP-threat I-D? I suggest to include draft [1] in References section, IMHO, any updates to RFC6130 should be considered by the community while reviewing this I-D. [1] draft-ietf-manet-nhdp-olsrv2-sec-02 AB On 5/24/13, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'Security Threats for NHDP' draft-ietf-manet-nhdp-sec-threats-03.txt as Informational RFC 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-06-06. 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 analyses common security threats of the Neighborhood Discovery Protocol (NHDP), and describes their potential impacts on MANET routing protocols using NHDP. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats/ballot/ No IPR declarations have been submitted directly on this I-D. ___ manet mailing list ma...@ietf.org https://www.ietf.org/mailman/listinfo/manet
Re: Issues in wider geographic participation
necessary. The process advisor could recommend that that author seek out other resources, including a mentor or editorial help, when necessary. The IETF's curmudgeon component, many of whom would make lousy mentors, might still be good document process advisors. Disagree, that is discriminating between participants, all participants should be equal don't you think, (iii) Allow new participants who intend to participate remotely and by mailing list to request and be assigned mentors, ideally mentors who speak the participant's primary language. Focusing our efforts only on people who show up at meetings means that we leave the folks who could be among our more productive participants in the cold and, for most regions where we have little penetration and resources are a problem, pretty much guarantees that it will stay that way. Again that is discrimination of focus-of-efforts, the IETF does not do that. However, if the some new-participant agrees with that, then it can be ok, otherwise, no. So it should be after the agreement of participant and with no excluding if disagreed. (iv) Encourage ISOC to redesign the IETF Fellows program so that people who were reasonable candidates for long-term participation were tracked differently from the observer-tourists. In the potential participant track, the assumption should be that Fellows might have participated remotely (including by mailing list) already, that such participation would give a candidate Fellow some extra priority or points in the selection process, and that activities during IETF should include explicit and focused discussions of optimal ways to participate without attending meetings. If we (or ISOC, or other organizations) later get the Fellows to more meetings, that would be great, but the goal should be to make a good remote participant, not people who can be effective only if they attend a lot of face to face meetings. I agree that IETF management discuss this point with ISOCs (or each region ISOC), and each ISOC feedback should be considered as well. The above would not be easy. Nothing is easy when it involves alot of people's lives/times/money. However, IMO, your proposal will not be encouraging all new-participants but maybe only yung-new-participants. It would require a large number of experienced members of the community to make a major commitment to working with new authors and non-attendee newcomers. I support this point as well, but without making new-participant feel that he/she discriminated from others. If it is only saying you are in level 1 of participating, fine but not saying; well you are in level 1 so please don't make noise (such behavior is not acceptable), or you are in level 1 so no one in the community wants to know your thoughts (such behavior is not acceptable), or you did not write an I-D so people will not listen to you until you do, etc. But it would help significantly to bridge the gap between interested in the IETF and its work and contributing participant. Only if there is mutual respect and equal opportunities, Flying a thousand person-weeks worth of folks into an area where we have little participation and attracting a few local tourists won't have the same effect --with or without a few hours of newcomer sessions-- and will still leave people with the need to make that transition if they are going to be effective. Regarding region attraction/effects, I may agree and disagree. Agreeing because I want to meet some authors of excellent RFCs, but I mostly disagree with the point for some reasons. Your point here is assuming many things which are not always true. You assume that majority of Internet-community are represented by current IETF participation, and that if new participating they mostly may not be affective. You assume that all IETF f2f participants are all affective and will continue that way. You assume that other regions that are not participating in IETF because they are not aware of the IETF. You assume that being effective mostly-means that you have to f2f attend meeting. You assume that new-comers will be encouraged by special-sessions, and assume that the thousand persons need to make transition to such region. IMHO, the IETF work and *business* is mostly done *remotely* on its lists not in f2f meetings, but community interconnections are done in *meetings*. Therefore recommend a Wider Geographic Participation Diversified and not discriminated. Please note that the above is my opinion and believe, but if the comments are wrong, feel free to comment on them. Regards Abdussalam Baryun University of Glamorgan, UK - I worked on four new I-Ds so far and doing my best to renew them shortly. - I never attended an IETF meeting so far, because not able to, but I will do in future, because want to meet most of the IETF ADs which are encouraging, and to meet some participants that done excellent RFCs. - I beleive that I am always affective and following
Re: Hands across the water/hands across the sky
Hi Spencer. I like your point. I think it is correct that collaboration is needed between all regions for many I-Ds or related I-Ds to the region participants interest. Cross-participation co-authoring between regions may make better results than co-authors from same region. Comments below, On 5/31/13, Spencer Dawkins spencerdawkins.i...@gmail.com wrote: For those of you looking at where I-D and RFC authors are from, I'd like to suggest one other thing to look at - the extent that participants are co-authoring with folks outside their region. There are some I-Ds like that which was a result of meetings of an author team of different regions and same interest. I will add another interesting point, IMO, each region has different interests, so if you ask in diff-region meetings of the community interest you mostly get different responds but not if the attendance are the same persons. It's pretty tempting for new participants to submit drafts that they like, and maybe reaching out to their office mates as co-authors, but to be effective in the IETF, participants have to learn how to collaborate with folks from other IETF sponsors (including other IETF sponsors who compete head-to-head with your IETF sponsor), other countries, and other regions. Collaboration covers many activities, but I'm curious what we might learn from looking at this specific kind of collaboration. I agree totaly, personal self-reveal I say this to a lot of people who don't believe me, but I have been shy for most of my life, and it's still not easy for me to have conversations with total strangers. That's not a cultural challenge, and it's not a language challenge, but it is a challenge I've faced in the IETF as *I* was learning to collaborate. For anyone who is also learning how to do this - for me, it's been worth it. I encourage you to continue your efforts for your progress (all have their special issues), which I think it is what IETF is about to make all learn for better Internet. I am experiencing a different situation while I am trying to have discussions with people I don't know in IETF, I get bad responses, and getting to know good people before I meet them. I am collaborating (in reviewing ideas not authoring, and a plan with one in future of authoring I-D) already with some that I never met but only remotely discussed in IETF. And anyone is welcome to join us for drumming at IETF meetings - I bring extra drums, and there's no telling who else you'll meet. /personal self-reveal I will join, we actually can plan to co-author an I-D while drumming so we don't waste time, thanks :-) AB
Re: Fixing: the standards track or RFC series (was: Re: What do we mean when we standardize something?)
On 5/30/13, John C Klensin john-i...@jck.com wrote: difficult problems arise when someone comes to us with a spec that might be ok but isn't how we would do it and tries to say you can have this and we will turn over change control as long as you don't really want to make any changes. When a statement equivalent to that is justified on the basis of either being in a hurry or not invalidating existing implementations, we find ourselves in the middle of the contradiction between consensus of industry practice and best engineering solution for standardization. If the standards proposed are reviewed well I don't think there will be contradiction, I don't recommending always sticking to best engineering solutions, because it is difficult to guarantee best solutions in present/future (best practices ok). For industry request work, IMO its better that our standards get into between *best engineering practices* and *good engineering practices*, that will not contradict with *consensus* and *industry practices*. AB
Re: IETF Meeting in South America
On 5/30/13, George Michaelson g...@algebras.org wrote: At risk of alienating my comrades from locations seeking to attract an IETF for local development/inclusiveness and the like reasons, I think John gets to the nub of the matter: the wider community cost, borne by all attendees as a 'silent tax' is really very high, for this outcome. We need to be explicit this is what we're doing. The ISOC grants are probably a more cost effective way of boosting participation from outlier economies right now. Yes, let's be explicit, what is the meeting values or goals? Why we are considering cost now when we are looking into the IETF future challenges, or when we are looking into developing IETF activities (i.e. better outcome change) So lets be explicit. This is a standards-setting body, which is discussing outreach, inclusiveness, wider participation outcomes, and the cost consequences on attendance where the core motivation is standards setting. Yes, let's be explicit, we need to discuss the IETF meeting not discuss the IETF business, IMHO, meetings are for establishing better connection between the IETF and the Internet-Community. IMHO, IETF is not just a standards-setting body, please read what it says about itself: IETF The mission of the IETF is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet. IETF The IETF is a Large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the and the smooth operation of the Internet. It is open to any interested individual. AB so interested individuals are welcomed in the IETF meetings and business. If the core motivations are changing, maybe that drives things in a different way? Don't forget that the Internet is changing and that the Internet Community is changing, the IETF SHOULD follow thoes changes :-) AB
Re: IETF Meeting in South America
Hello, Thanks alot, we need people like you that tell others about IETF and its real culture, or what they can do by using IETF. If people/community can know what they can do, they will participate. Are the IETF management contacting Internet Societies in South America about participation, and what was the response? That information is important to know if the meeting will make difference or not. The IETF management need to do effort as well to encourage people like you are doing. We need experts from South America to be involved and we hope that IETF management contact the region's experts to encourage participation. The experts then will reply to IETF management and tell them their needs and ask to solve their problems of using IETF or problems of participation. Most probably they have already tried but left as I was always thinking to do but did not. AB On 5/29/13, I rob sistopef...@gmail.com wrote: Hello, I agree with the Idea of a IETF meeting in South America. I think it is a way to let the people know about IETF (of course there are other ways, but this is a good one), to give the possibility to students/engineers with very good skills to get into the IETF, thinking that it is going to be published in universities in advance, to give time to students to enroll to a mailing list and read the drafts to be presented. Talking about my personal experience, I am pretty new in the IETF, but since I have been involved, I teach my students (from Argentina) about it, I tell them, that they can participate, that is open, and I realize that they didn't know it. I understand that usually the place is chosen based on the most of participant origin, but I think a meeting in Latin America is a good opportunity to give the possibility to people from that region to know about the IETF. Kind Regards, Ines Robles. -- I would like to follow up on this proposal. Having a meeting in South America scheduled two or three years in advance will let us engage local organisations and individuals on a project. We did several activities in the region trying to encourage IETF participation, but we're going to be much more effective if they're part of a plan with a strong commitment (and effort) from the IETF community. Since this opportunity was announced, there were several contacts and proposals from different groups asking for additional information, suggesting things to do, asking for details, etc. We now have a much more fertile ground to do multiple things. Going further will also enrich the IETF work and community (making it more international becomes a side effect). In this region there are many engineers, software developers, people at Universities, etc. that could provide new ideas and energy to the IETF. Christian
Re: More participation from under-represented regions (was: IETF Meeting in South America)
Hi SM my answer to your reply, On 5/27/13, SM s...@resistor.net wrote: Hi Abdussalam, At 16:38 26-05-2013, Abdussalam Baryun wrote: I think they SHOULD have, and all of us should do the same, because IETF will expand and become stronger by increasing participants from ALL Internet community regions. The answers also based on IETF vesion. The question was about what was done in the past. It is not about what the IESG or IAB is doing or could do in future. Any done in past may need to change in future to cope with Internet-world change. I can answer only for the present and future. At 16:51 26-05-2013, Abdussalam Baryun wrote: There are some from Africa trying to find the way in, but they may not mention it, however, training is not important much to make people participate but the type of training and its period inside organisation not outside. For example, I notice that there was one African participant (not me), trying to participate in writing one draft for the community, so was he/she encouraged by the WGs, Does that participant reside in Africa? Will that participant implement the draft by writing code? I think the draft was Informational, not for coding. The link below, but I hope you are not the same author because is similar S.M. :-) http://www.ietf.org/mail-archive/web/ietf/current/msg76741.html Regards AB
Re: IETF Meeting in South America
On 5/29/13, S Moonesamy sm+i...@elandsys.com wrote: I wasn't unable to attend an IETF meeting some time ago due to an administrative issue. The proposal I intended to discuss about (it was discussed during a session) was not adopted. With hindsight I'll say that the proposal would not have been adopted as I would have made the mistake of not following IETF culture. I don't think I should follow the IETF culture to make my I-D adopted by WG, but I may follow the good/technical reasons the WG provide. We need to follow the technology/region/users needs for the Internet purposes. The Internet is a global network that is present in all regions, each region may have different needs and similar needs. So if my document was not adopted by WGs, then there SHOULD be a good technical reason (not that I did not follow cultures). I think that IETF follows up with the Internet developers, users and participants (within South America and others). AB
Re: Participation per Region of Authoring IETF documents vs Marketing
Hi Lars, It was for Asia region, I thought its rate is between (5 - 50) rfc/year for last 3 years. Basing on; The first figure of RFCs is the Comparison of countries over the year [1], the second, is the Distribution of number of RFCs per continent [2], the third is publication rate per year [3]. For the I-Ds going in IETF is seen from the distribution of drafts according to the countries of their authors [4] and [5]. All figures make together the below conclusions, even though some of them need more details for readers to understand. As from Figure [1] always one region (North America) is doing about 200 rfc/year and the each of others may do between 5 - 50 rfc/year or 50-100, but all together other regions do 150 rfc/year, so total ietf-participation can be about 350 rfc/year. The Figure [2] is not reasonable, not showing of years or period of such numbers. So my understanding is that for Europe-region and Asia-region, the number of I-Ds rates are high compared to North America, but not the rate of RFCs. I see that the total RFCs ietf-output rate (RFC/year) as in Figure [3] for the last three years is about 350 rfc/year, so if North America is having 200, the all others only will have about 150 rfc/year. The total RFCs produced per countries is in Figure [6] is reasonable but if compared with Figure [2] I get lost. From Figure [5] (also [4]) the number of I-Ds (now currently 2013 outstanding) from Asia and Europe are about 600 and 1200 respectively (let us add them up so =1800 ids), which I think only about 150 will succeed (non-North America drafts). Furthermore, for North America the I-Ds are 1500 ids and only 200 ids will succeed to become RFCs. I think that Asia and Europe should have together about 250/year rfc not 150 rfc/year. If we do more MARKETING effort we can make that rfc-rate of other regions increase, but we already tried to increase North America rate but it is stable for about 200 rfc/years. [1] http://www.arkko.com/tools/rfcstats/countrydistrhist.html [2] http://www.arkko.com/tools/recrfcstats/d-contdistr.html [3] http://arkko.com/tools/rfcstats/pubdistr.html [4] http://www.arkko.com/tools/stats/d-countrydistr.html [5] http://www.arkko.com/tools/stats/d-countryeudistr.html [6] http://www.arkko.com/tools/rfcstats/d-countrydistr.html This lower participation from regions like Asia will continue because most meeting are in North America, or most participants from North America prefer to have face-face meeting locally, than to be remote to other regions (not reasonable because they are writers in English very well). Also other regions participants prefer to participate in meetings not remotely (but that is reasonable because they are not good in English Language Writting). It is also important that some IETF management visit the other region participants for the progress of their I-Ds. Please note that I don't claim that my analysis is all correct, but trying to discuss it and get others to analyse as well or comment on the figures/statistics. If you disagree or have any comment please reply/advise. Thanking you, AB On Wed, May 29, 2013 at 10:53 AM, Eggert, Lars l...@netapp.com wrote: Hi, On May 28, 2013, at 19:46, Abdussalam Baryun abdussalambar...@gmail.com wrote: by looking into the statistics of I-Ds and RFCs, it is strange that we get sometimes high rate in the I-D going in IETF from some regions but the success rate of I-Ds to become RFCs is very low (5- 50). which IDs and RFCs are you basing this statement on? Thanks, Lars
Re: Participation per Region of Authoring IETF documents vs Marketing
On 5/29/13, Jari Arkko jari.ar...@piuha.net wrote: by looking into the statistics of I-Ds and RFCs, it is strange that we get sometimes high rate in the I-D going in IETF from some regions but the success rate of I-Ds to become RFCs is very low (5- 50). There seems to be a general pattern where new participants first participate and/or produce IDs but it takes some time to produce RFCs. Yes that is right, so I think we can encourage thoes new participants to join and continue, of speed up by our guidance, and also the IETF may be guided by thoes new comers. It is a two way new-participation, and even IETF is new to participate in other new sub-regions or sub-communities. For instance, for a while it was the case that there was a growing number of proposals and participants from China, Yes IETF needs China's participation, so the question is why is China (as sub-region) having low rate of rfc/year? How can the IETF do marketing/help to improve that? but it is only more recently that the RFC statistics reflect this (see the bright green line in http://www.arkko.com/tools/rfcstats/countrydistrhist.html). The hypothesis is that first of all, it takes a while to produce RFCs :-) and that new participants take a while before they get up to speed on the process, find enough other parties that share similar needs for the specific technical work, etc. So if you agree that they need to find other parties to speed up or increase rate of rfc/year, that meens it will be a good idea to have one meeting of IETF per year in Asia region (IETF marketing in Asia for participation). Furthermore, IETF can have one meeting per year for each region equally (for equal marketing opportunities), because North America region's rate of rfc/year for many years shown to be stable not much improving (about 200 rfc/year), and all participants in North America have excellent English and writting skill to explain remotely in meetings. Some inputs on this IETF list (sub: IETF meeting in South America) say that IETF meeting in South America will not increase participation, as no result of such marketing (I disagree, their argument may be correct only if South America are well English writers that can easily remotely communicate). On the other hand, from their argument I understand that it means there is no affect of IETF meeting for all regions to increase or decrease participation including North America (no results of marketing or de-marketing). Therefore, if we reduce the number of meeting in North America (as not de-marketing because at least there is a meeting per year) we will not face any decrease of the 200 rfc/year (so we can give more space to other regions), because they are mostly not-new-participants (as compared to hypothesis you explain for China's rate and new-participate speed) and they are well english/known writers/remote-participants. AB My thoughts on the subject and on South America meeting subject.
Re: When to adopt a WG I-D
It is difficult to read, because I am expecting a process and find something else, I started to read, but got confused (stoped reading), why you are titling it as creating WG-draft and mentioning the adoption into the document. I understand that the creating first is *individual-draft* not *WG-draft*, the adoption happens after the creation of individual draft. If creating is WG creation, then it is already adopted as *idea* not *draft*, and then draft-00 is the WG-draft. I don't see the process clear at all, I maybe missing something, AB On Tue, May 28, 2013 at 10:32 AM, Adrian Farrel adr...@olddog.co.uk wrote: Hi, Dave Crocker and I have this little draft [1] discussing the process and considerations for creating formal working group drafts that are targeted for publication. We believe that this may help clarify some of the issues and concerns associated with this part of the process. We are targeting this as Informational (i.e. commentary on existing process, not new normative definition of process) and would like your input. What is not clear? What have we got wrong? How should we resolve the remaining editor notes? Thanks, Adrian (per pro Dave) [1] http://www.ietf.org/internet-drafts/draft-crocker-id-adoption-02.txt
Re: Participation per Region of Authoring IETF documents vs Marketing
by looking into the statistics of I-Ds and RFCs, it is strange that we get sometimes high rate in the I-D going in IETF from some regions but the success rate of I-Ds to become RFCs is very low (5- 50). So the only region that is producing RFCs with high rate (about 200 per year) is North America even though there is a high rate of I-Ds created. No sure Why is that result, or waste of efforts, or maybe I misunderstood the figures, How many I-Ds per year of Asia-region are adopted by IETF WGs? How many I-Ds per year of Europe-region are adopted by IETF WGs? AB On Mon, May 27, 2013 at 4:46 PM, Eggert, Lars l...@netapp.com wrote: On May 27, 2013, at 15:31, Abdussalam Baryun abdussalambar...@gmail.com wrote: On 5/27/13, Eggert, Lars l...@netapp.com wrote: On May 27, 2013, at 12:10, Abdussalam Baryun abdussalambar...@gmail.com wrote: Each IETF document mentions the authors place address (I may suggest adding region, as a categorised by IETF), but not sure of history statistics of how many IETF-documents produced by authors in South America, Africa, or Asia, or others. http://www.arkko.com/tools/stats/d-countrydistr.html and related pages I read that before, but does not show documents/RFCs per region. It shows drafts per countries. For example, does not show the drafts from South America. Does not show all regions in sequence of the most participated region. That's why I wrote *and related pages*. Clicking around Jari's pages, you will easily find http://www.arkko.com/tools/rfcstats/d-contdistr.html as well as many more stats. As for most participated region, look at the reports from the IAOC: http://iaoc.ietf.org/reports.html Lars
Participation per Region of Authoring IETF documents vs Marketing
Each IETF document mentions the authors place address (I may suggest adding region, as a categorised by IETF), but not sure of history statistics of how many IETF-documents produced by authors in South America, Africa, or Asia, or others. I think it is a good marketing start for IETF to get more Informational-RFCs input from regions by guiding their inputs. Furthermore, if IETF helds a meeting in one region with very low participation, then Why not that IETF encourages people to involve in joining authors of interested documents to that region and interested to IETF as well? AB
Re: Issues in wider geographic participation
Hi John, I agree and I will add, that What makes that participant continue to volunteer, or even witness/read the ietf work process? Making someone interested to do something freely is not an easy task. The difficulty is how to make that individual participate with value, he/she may need help to notice that *IETF needs* their regional-participation. Example, I got once a response that IETF or WG chair's jobs are not to educate others, but who said that IETF is better educated or that WG chairs are better educated than others. It always depends on the relativity of education with the region needs, not only eduaction related to the Internet technology. I think we *need* in IETF to gain all best educated people of world-regions into IETF (volunteering), so that we make the Internet better for the WORLD, because technology SHOULD follow the community-regional *needs*. Not that we need to gain best standard/technology experts to make all regions follow the technology-product requirements, because will may never be *used* that way :-) Comments below, AB On 5/27/13, John Levine jo...@taugh.com wrote: I think this is a summary of the issues people have mentioned that discourage participation from LDCs, in rough order of importance. * People aren't aware the IETF exists, or what it does, or that it has an open participation model Also IMHO, the IETF is not aware of existance of Internet community-regional *needs* for their better Internet technology future, * People don't read and write English well enough to be comfortable participating That is not an issue, well educated people around the world know english reasonably, but the problem is that many of current IETF participants like to read correct english, hope they change to adapt to the World's English. * People are unaccustomed to and perhaps uncomfortable expressing overt disagreement That is true, but mostly Chairs and editors are responsible to make that continue or stop. * People don't think they have anything to contribute to an organization that is mostly people from rich countries This point is important, please read my addition above. * People don't have adequate Internet access for mail, or to use the remote participation tools Yes that is true, but also we need people like old participants, or 98% of participants to get use to participating remotely at IETF meetings. I don't want to see complains on journey expenses of money but of spending-time is ok :Z I have to say that I don't see one or two meetings in South America addressing any of these. Given that the incremental cost to the participants, compared to meeting in North America, would likely be on the order of a million dollars, it seems to me very likely that there are better ways to spend the money. I don't care how much money spent, we SHOULD focus on how much time gained by IETF and how much volunteer-time spent for IETF. Attendance can spend the same time remotely, the World is well connected now, For example, if language and net access is a problem, it might be interesting to set up a remote participation center in B.A. during one of the North American meetings (it's one time zone off from Toronto) with screens and cameras, paid interpreters, and a few volunteers to help explain what's going on. I think the problem is contribution access to IETF. We need centers to increase access to documents-produced per regions, centers to increase participants per region, centers to increase remote users per regions, etc. R's, John
Re: Participation per Region of Authoring IETF documents vs Marketing
On 5/27/13, Eggert, Lars l...@netapp.com wrote: On May 27, 2013, at 12:10, Abdussalam Baryun abdussalambar...@gmail.com wrote: Each IETF document mentions the authors place address (I may suggest adding region, as a categorised by IETF), but not sure of history statistics of how many IETF-documents produced by authors in South America, Africa, or Asia, or others. http://www.arkko.com/tools/stats/d-countrydistr.html and related pages I read that before, but does not show documents/RFCs per region. It shows drafts per countries. For example, does not show the drafts from South America. Does not show all regions in sequence of the most participated region. AB
Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
Reply to your request dated 24/05/2013 Draft Reviewed By: Abdussalam Baryun (AB)Dated:27/05/2013 Reviewer Comment A1: Previous comments in WGLC +++ Related to your request below please read my previous review comments [1] and I will continue with additional messages/comments. [1] http://www.ietf.org/mail-archive/web/manet/current/msg15254.html Regards AB On 5/24/13, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'Security Threats for NHDP' draft-ietf-manet-nhdp-sec-threats-03.txt as Informational RFC 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-06-06. 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 analyses common security threats of the Neighborhood Discovery Protocol (NHDP), and describes their potential impacts on MANET routing protocols using NHDP. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats/ballot/ No IPR declarations have been submitted directly on this I-D. ___ manet mailing list ma...@ietf.org https://www.ietf.org/mailman/listinfo/manet
Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
Hi, Reviews at this stage don't need supports from WG when it is in the IETF Last Call, the comments are sent as per request of iesg. AB On 5/27/13, Jiazi YI yi.ji...@gmail.com wrote: Hi, I think those comments have been addressed/answered in my previous reply http://www.ietf.org/mail-archive/web/manet/current/msg15274.html I didn't see the support of your comments from other WG participants. best Jiazi 2013/5/27 Abdussalam Baryun abdussalambar...@gmail.com Reply to your request dated 24/05/2013 Draft Reviewed By: Abdussalam Baryun (AB)Dated:27/05/2013 Reviewer Comment A1: Previous comments in WGLC +++ Related to your request below please read my previous review comments [1] and I will continue with additional messages/comments. [1] http://www.ietf.org/mail-archive/web/manet/current/msg15254.html Regards AB On 5/24/13, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'Security Threats for NHDP' draft-ietf-manet-nhdp-sec-threats-03.txt as Informational RFC 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-06-06. 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 analyses common security threats of the Neighborhood Discovery Protocol (NHDP), and describes their potential impacts on MANET routing protocols using NHDP. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats/ballot/ No IPR declarations have been submitted directly on this I-D. ___ manet mailing list ma...@ietf.org https://www.ietf.org/mailman/listinfo/manet
Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
On 5/27/13, Jiazi YI yi.ji...@gmail.com wrote: Hi, I think those comments have been addressed/answered in my previous reply http://www.ietf.org/mail-archive/web/manet/current/msg15274.html I didn't see the support of your comments from other WG participants. I also didn't see objection of my comments from the WG. I also didn't see support of your reply from the WG. (WG decisions are WG-rough-consensus, not the editors opinion). If there was WG objection then I will report that in my reviews to IESG as information. AB
Re: More participation from under-represented regions (was: IETF Meeting in South America)
I support to add the new region, hoping in future Africa gets its chance. IMO, I thought about it from another point of view. After a long time of having IETF meetings mostly in one region (as history of North America region gaining most meetings), the result of that was that IETF participants are majority from North America, so I think it MAY be a result of meetings held in one region (some will argue it is because experts individual-participants/company-participants come from North America, while giving no value of IETF marketing), However, IETF claims it is for the WORLD as Internet is, not for only one region's Internet. So giving now chance for other regions (or diverse Internet communities) to gain meetings will help in the FUTURE more participants from other regions as it happend to North America. For IETF it already gained many from North america, and they don't increase so it SHOULD market elsewhere for future plans. My answers to your questions below, AB On 5/26/13, SM s...@resistor.net wrote: At 09:42 26-05-2013, Dave Crocker wrote: I like visiting South America. But IETF meetings do not have tourism as a goal. So yes, I'm sure those who go will enjoy the city; but again, that's not stated purpose of choosing venues. Over a year ago the IAOC [was] pleased to announce the Return of the Nerds to Paradise! If we are serious about wanting more participation from under-represented regions, then let's attack that issue seriously and substantively, rather than with an expensive marketing show. Yes. The meaning of the elephant in the room is an important and obvious topic, which everyone present is aware of, but which isn't discussed, as such discussion is considered to be uncomfortable. The elephant in the room is that there hasn't been any discussion about what has been done to get more participation from under-represented regions but nobody has mentioned that. (a) Was the IESG working on how to get more participation from under-represented regions? I think they SHOULD have, and all of us should do the same, because IETF will expand and become stronger by increasing participants from ALL Internet community regions. The answers also based on IETF vesion. (b) Was the IAB working on how to get more participation from under-represented regions? I think they SHOULD have, and all of us should do the same, because IETF will expand and become stronger by increasing participants from ALL Internet community regions. The answers also based on IETF vesion. I am asking the above questions as it is not clear who in the IETF was doing that. I am working on it my self, so I hope others think the same, I have asked many students about the IETF, they don't know about it a thing, so should n't we ask question why the community of Internet users in South America not participating? One answer can be that the reason is that IETF participants majority from North America and they don't want to spend money on long journies that include many competing regions (e.g. few regions or few long distance per year maybe fine). Regards, -sm
Re: More participation from under-represented regions
Hi SM, There are some from Africa trying to find the way in, but they may not mention it, however, training is not important much to make people participate but the type of training and its period inside organisation not outside. For example, I notice that there was one African participant (not me), trying to participate in writing one draft for the community, so was he/she encouraged by the WGs, Directors, or the Chairs, was the draft guided? was that participant asked to market that draft in his/her community region to make support. The IETF majority-culture may not be much welcoming from others point of view, I try to market IETF but need help of the responds others may get from discouragings. AB On 5/27/13, SM s...@resistor.net wrote: Hi Edwin, At 13:59 26-05-2013, Edwin A. Opare wrote: The awareness creation should start at the grassroots level : The Universities!. Train the soon-to-graduate Computer Scientist/Engineer on the values and essence of the IETF and it'll forever be with them even after graduation. To elicit participation from the under-represented regions, the universities are a sure starting point, then a lot more industry-focused awareness creation by the ISOC local Chapters. AfNOG has trained hundreds of people in Africa. Those people do not participate on the mailing list. There are some people from Africa who have attended IETF meetings. They don't participate in the IETF. Why is it that there are some participants from South America whereas there aren't any participants from Africa? Regards, -sm
Re: IETF Meeting in South America
I support the ietf-meeting in new regions, and reply as below, On 5/26/13, Dave Crocker d...@dcrocker.net wrote: The IAOC has put forward two reasons for having an IETF meeting in South America: Encouraging growing participation will help strengthen the Internet, further encourage participation from those areas that will see the most growth in the coming years, and will help advance the IETF in political and international circles which is becoming more of an imperative. Yes I agree, but think that managment SHOULD work with ALL participants (usually majority from North America) to make this successful. We will not do that only if we work together, otherwise not possible if only management work alone. That is: 1. Promoting regional participation from Latin America There certainly are under-represented constituencies that we should find ways to bring to the IETF in greater numbers. Residents of Latin America certainly qualify. However a number of comments on the ietf list have observed that our conducting a single meeting in South America is unlikely to effect greater Latin participation in the IETF. If you analyse results for short term, you are right, but these things are long term plans for future participants. We need to give South America more time to see the result, I agree, it won't, and frankly I think it shouldn't, because it's a expensive and possibly risky Grand Gesture rather than a substantive change. Not sure what is expensive, do you mean expensive for IETF or for the participants. If it is for regular participants, then they may become remote for some time, for the best of IETF, which they will gain as will. If we want great regional participation, let's look for ways to achieve that -- for /all/ under-represented constituencies. I suspect that what's needed will be similar for all of them. So you ask to other way other than reducing the majority of meetings in North America. Do you mean that if we go for the way you are disagreeing it will result to reduce number of majority participants? I don't think so, as long as ALL have the IETF vesion. 2. Counteracting some type of IETF 'deficiency' in political and international circles. As stated, that's a pretty vague concern, although yes, we sometimes hear criticisms around the IETF's regional choices. However the nature of exchanges like these are -- as correctly characterized by the IAOC -- political, and they are rarely assuaged by letting the critics dictate organizational decision-making, such as where to send 1200 participants for a mission-critical meeting. No one sending any participants, it is a volunteering meetings, and can be remotely attended. New communities are still need more face to face meetings than experts of IETF. Put simply: we shouldn't let political critics set the agenda for IETF strategic planning. They'll just find something else to hassle us about, since their political goal is criticizing the IETF, not improving it. Again as others have noted, one meeting in the region won't be enough, and then there are the other regions we don't go to, and there will be something else, and something more after that. Yes, that is the beauty of IETF, it always changes for the best, we need to get use to change, many organisations face their staff resistance of change. Usually memebrs of organisation like things to go the way it was before. But wait. There's a bigger issue being missed: The basis of the criticism is fundamentally specious! The /reality/ is that the IETF is dramatically /more/ open in its participation and its documents than nearly any other international standards group, most of whom have nation- or vendor-based membership fees and restrictions, with little or no participation via email or remote attendance. We will get more remote participants when the meetings are expensive for majority of participants. However, the number of attendance will increase, because we got remote attendance and face to face new attendance with lower costs per individuals :) Again, don't let political exercises determine the IETF's public message. The solid reality of extreme IETF global inclusiveness is real and basic. Those who want to hear that message will. Those who don't won't be quieted by a stray meeting in the southern half of South America. Of course we need to do more and better at being inclusive. The nascent diversity effort speaks to the IETF's own concern about that. As for some other points in the IAOC message... On 5/23/2013 9:07 AM, Bob Hinden wrote: There has been a consistent level of IETF participation from South and Central America, and it has been growing since IETF82. The data on this is posted at http://iaoc.ietf.org/documents/IETF-Regional-Attendance-00.pdf. From the cited table, we see that Latin American meeting attendance grew from 1% to 2%, over a bit more than one year. However
Re: WebRTC and emergency communications (Was: Re: IETF Meeting in South America)
I don't think there is any general solution to the early vs. complete tradeoff [1], IMHO, that general answer is; having good organisation or management from all parts participants, discussion chairs and from directors. nor, as long as we keep trying to deal with things as collections of disconnected pieces rather than systems, to the issues created by WGs with significant overlaps in either scope or technology. It is good to have systems that is why we need WGs with procedures, and it is good to have collections-of-ideas (can be disconnected) that is why we need diversed participants in each system/WG. I am against the disconnection idea of pieces/work, we need both connection and disconnection. The pieces SHOULD be always connected as long it serves the same subject/issue/scope, but can disconnected when we look into applications/projects. What I think we can do is to be particularly vigilant to be sure that the two WGs are tracking and frequently reviewing each other's work. At least RTCWEB and ECRIT are in the same area, which should make that coordination easier than it might be otherwise. From my new monitoring/experience of IETF, I don't think same area WGs are coordinated in working related to their pieces. Management SHOULD organise such coordination. AB +++ This message is not sent to private address, only sent to IETF. My thoughts are writen in a message for the IETF not for other party, if you want to comment on the thoughts, please comment on the message idea/content not on the author or his/her thoughts/methods. +++ [1] Watch for a note about this that I've been trying to organize for about two weeks and hope to finish and post this weekend.
General Comment on AD Review or IESG Review
Hi Just small comment on the AD review, and to show my expectation. I hope to know your expectations of reviews. If we know the expectations of the community we will progress better. I expect that the AD review overviews all I-D pieces and also all the WG participants input within the WGLC. IMHO, I don't expect that the AD just uses participants input without refering to such input/piece. We need connected pieces, not disconnected because the review is for one work I-D. I expect that IESG review overviews all I-D pieces and also the IETF participants input within the IETF Last Call. We need connected pieces, not disconnected because the review is for one work I-D. I like to make my review connected and disconnected to other people's ideas other pieces of work. AB + This message is not sent to private address, this is only sent to IETF. However, the author accepts private or public replies as long it is respectful. +
Re: General Comment on AD Review or IESG Review
Connecting ideas related to the same I-D is not an easy task, usually reviewers just do their own review without reading others. I try to read all reviews (if time is available) or input related to I-D to connect ideas to help in better my review results or quality. I recommend that such connection/coordination of reviews should be done in the IETF-Area level for WGLC-reviews and AD-review, and then done in the IESG level for ietf-reviews and editors-reply. This way the final review for the Area and for the IESG will get better results. When we work as a team we will be connecting good ideas (may include cross areas) to get to the best quality and final team work idea. AB
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
The problem is that WG participants SHOULD follow/update their milestones and take responsibility to progress work to thoes goals direction. The Chair SHOULD follow the WG requests, or the Chair SHOULD encourage discussing the milestones. I already requested before that all WGs SHOULD discuss their milestones and update it in each meeting or on the list. If no one cares then the result is WG failing some-goals which no one realise until long, but some people outside the IETF are watching such performance. AB On Fri, May 17, 2013 at 7:29 PM, Keith Moore moore at network-heretics.com wrote: I don't think milestones will be useful unless and until: (a) they're defined in terms of not only concrete but also meaningful goals (e.g. complete problem definition, identify affected parties and groups representing their interests, complete outline of initial design, but NOT revise document X); (b) we start automatically suspending the activities of groups that fail to meet them (no meetings, no new I-Ds accepted, mailing list traffic blocked), until such groups are formally rechartered; and (c) IESG is reluctant to recharter groups that have repeatedly failed to meet milestones, especially if those groups haven't produced evidence of significant progress.
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
Instead of a WG progress report, what I had in mind was a separate report for each work item. The report should briefly describe I agree with you totally, that work-item-report SHOULD be copied to AD and WG. That report is needed mostly when the work does not target its milestone, requesting new milestone with plans/reason. AB
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
On May 15, 2013, at 4:30 PM, Adrian Farrel adrian at olddog.co.uk wrote: The claim (or one of the claims) is that some ADs may place Discusses that are intended to raise a discussion with the authors/WG that could equally have been raised with a Comment or through direct email. This, it is claimed, may unnecessarily delay the document from completing the publication process. Discussions should have a time limit (can be one week), like we have in meetings (2hours), if there is time we can know when things are needed to respond to, I usually ignore when there is no milestones or planing-time. Does IESG have milestones for documents processing/discussions? Now the dangerous bit, Suppose the AD raised her concern by writing a Comment or sending an email and balloting No Objection. That would mean that the I-D would be approved for publication. At this point either: - the discussion goes on, but the document becomes an RFC anyway or - the responsible AD holds the document pending satisfactory completion of the discussion. That AD SHOULD not hold for unlimited time, also should discuss the issue with the WG related in limited time. I suggest that the former is a bad result. Not that the authors/WG will ignore the discussion, but if they disagree on something the AD considers very important, the authors/WG have no incentive to participate in the discussion. Only community rough concensus will decide the final result, Of course, all participants in this thread so far would never behave like that, but there is a possibility that this will happen for some authors. Yes only if there is no time limits for work that should be done, I also suggest that the latter introduces exactly the same amount of delay as the Discuss. There is always possibility of large delay in systems that have no time limits for processing or responds. Our time/work used is important for IETF, IMO, no one should hold work/time only if able to decide/notify/plan when/how to leave it go for all reaction possibilities. AB
