Re: Radical Solution for remote participants
Hi, +1 On Fri, Aug 16, 2013 at 1:59 AM, Joel M. Halpern j...@joelhalpern.com wrote: Maybe I am missing something. The reason we have face-to-face meetings is because there is value in such meetings that can not reasonably be achieved in other ways. I would like remote participation to be as good as possible. But if would could achieve the same as being there then we should seriously consider not meeting face-to-face. Being at the IETF for a week is never going to be the same experience as participating remotely at a computer for a couple 2 hour meetings. A lot of work gets done outside the official WG meetings because the right people can all be in the same room at the same time. IMO we should be using more virtual interim meetings, not trying to turn our f2f meetings into remote meetings. WGs should meet virtually at least once a month for 2 - 4 hours to make progress on issues same as via the WG mailing list. Everybody is a remote participant in a virtual interim so the problems with interfacing to a live meeting go away. Conversely, until the technology gets that good, we must not penalize the face-to-face meeting for failures of the technology. Yours, Joel Andy On 8/15/13 9:48 PM, Mark Nottingham wrote: On 13/08/2013, at 11:00 AM, Douglas Otis doug.mtv...@gmail.com wrote: 1) Ensure exact digital interfaces driving projectors are fully available remotely. That would be fantastic, if feasible. Much simpler than sharing through software. 2) Ensure Audio access requires an identified request via XMPP prior to enabling either a remote or local audio feed. Hm. 3) RFI tags could facilitate enabling local audio feed instead of an identified request via XMPP. Could be quite interesting; many conferences now provide attendees with RFID tags... 4) In the event of the local venue loosing Internet access, the device regulating A/V presentations must be able to operate in a virtual mode where only remote participants are permitted to continue the meeting proceedings. That seems… extreme. 5) Important participants should plan for alternative modes of Internet access to remain part of the proceedings. Not exactly practical. 6) Develop a simple syntax used on XMPP sessions to: 1) signify a request to speak on X 2) withdraw a request to speak on X 3) signify support of Y 4) signify non-support of Y 5) signal when a request has been granted or revoked. For local participants this could be in the form of a red or green light at their microphone. The W3C does much of this already with IRC bots, e.g.: http://www.w3.org/2001/12/zakim-irc-bot.html (also can pick a scribe, track an agenda, etc.) 7) Develop a control panel managed by chairs or their proxies that consolidate and sequence requests and log support and nonsupport indications and the granting of requests. See above (I think). 8) Chairs should be able to act as proxies for local participants lacking access to XMPP. Not practical, unless they delegate. 9) Chairs should have alternative Internet access independent of that of the venue's. Seems extreme. 10) Establish a reasonable fee to facilitate remote participants who receive credit for their participation equal to that of being local. 11) The device regulating A/V presentations must drive both the video and audio portions of the presentations. A web camera in a room is a very poor replacement. 12) All video information in the form of slides and text must be available from the Internet prior to the beginning of the meeting. Cheers, -- Mark Nottingham http://www.mnot.net/
Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard
On Wed, Aug 14, 2013 at 12:31 AM, Yaron Sheffer yaronf.i...@gmail.com wrote: Hi Randy, I prefer to leave this question to people who know something about Netconf, i.e. not me. But let me just say that, based on my thoroughly extensive 5-min. research, YANG seems to be incompatible with CBOR. Can you be more specific? What is incompatible about YANG? Thanks, Yaron Andy On 2013-08-14 04:53, Randy Presuhn wrote: Hi - From: Yaron Sheffer yaronf.i...@gmail.com Sent: Aug 13, 2013 2:11 PM To: IETF Discussion Mailing List ietf@ietf.org Subject: re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard ... - The diagnostic notation can be used very effectively for things like configuration files, e.g. if an application already uses CBOR on the wire. Therefore I would suggest to formalize it a bit more, so that we also have interoperability at this level. Do you envision it as an encoding for Netconf? Randy
Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard
On Wed, Aug 14, 2013 at 6:07 AM, Carsten Bormann c...@tzi.org wrote: On Aug 14, 2013, at 13:40, Randy Bush ra...@psg.com wrote: YANG seems to be incompatible with CBOR. so what does that say about yang, yang's suitability for netconf, cbor, and cbor's suitability? Good question. I'm not sure the jury is even out on that yet. Yaron reminded me that netconf is using XPath for various purposes, so a CBOR rendition of netconf would need to do the same that you would need for doing netconf with JSON: either replace XPath with something else (indeed causing some incompatibility), or explain how to use XPath with the CBOR/JSON translation of the YANG model (which might be interesting). CBOR certainly has no trouble carrying around the data described by a YANG model. (Indeed, CBOR's decimal fractions were inspired by YANG's.) But then, I don't have an opinion whether adding a binary object representation to the netconf ecosystem is on the agenda. I am not sure this is an actual problem. NETCONF uses full XPath only if the :xpath capability is supported. The select expression represents the data to be returned from the conceptual datastore and possibly the state/statistics within the device. The select expression is not related to the message on the wire. There is also an error-path field that is returned in errors that contains the absolute path of the message or data node that caused the error. Neither of these message fields should cause an encoding problem. They are just strings at the message layer. Grüße, Carsten Andy
Re: Berlin was awesome, let's come again
On Tue, Aug 6, 2013 at 3:52 PM, Martin Rex m...@sap.com wrote: Ulrich Herberg wrote: I think that the heat was exceptional. I have grown up in Munich, and I have rarely ever seen it that hot (either in Munich or Berlin). Maybe it's global warming? ;-) Damn coincidences! IETF 39 was in Munich (August 1997) ArabellaSheraton @ Arabella Park, and it was HOT pretty much the whole week. Yes -- they said the same thing last time -- no need for ventilation since it never gets too hot here. I noticed the locals on the 200 bus to the beer festival were just as miserable as me. I stopped in a McDonalds for a diet coke, but the ice machine was broken. (I was told it was too hot for it to make ice. Since I was the only American in there, nobody noticed the ice machine didn't work but me ;-) I would still come back -- this was a great city for an IETF -- I just hope for once we get normal weather for July. -Martin Andy
Re: The Friday Report (was Re: Weekly posting summary for ietf@ietf.org)
Hi, I don't care if this report is published or not, but I will point out that the 1 week sample period is not that useful if the intent is to spot excessive posting. Somebody could be following up on 1 thread, and not post again for a year. Somebody could be participating in an IETF Last Call discussion, which should not even count as extra since that is a critical part of our review process. Andy On Sat, Aug 3, 2013 at 12:12 AM, Heasley h...@shrubbery.net wrote: Am Aug 3, 2013 um 9:05 schrieb Abdussalam Baryun abdussalambar...@gmail.com: 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 I suggest eliminating the report. As it doesn't measure content quality, one's contribution can't be measured by the email they produce. So, it is only a guage of the distraction they produce. The report itself is a distraction.
Re: 6tsch BoF
Hi, Isn't it obvious why humming is flawed and raising hands works? (Analog vs. digital). A hand is either raised or it isn't. The sum of all hands raised is comparable across tests. The sum of the amplitude of all hums is not. Andy On Thu, Aug 1, 2013 at 1:50 AM, Ralph Droms rdroms.i...@gmail.com wrote: I found the process in the 6tsch BoF (Tue 1520) for asking about taking on the work discussed in the BoF to be thought-provoking. Toward the end of the BoF, the chairs asked the question 1. Is this a topic that the IETF should address? First, the chairs asked for a hum. From my vantage point (middle of the room), the hum was pretty close to equal, for/against. I reviewed the audio (http://www.ietf.org/audio/ietf87/ietf87-bellevue-20130730-1520-pm2.mp3, starting about 1:22), and heard a slightly louder hum for. The BoF chairs decided they needed more information than they could extract from the hum, so they asked for a show of hands. From the audio record, there were a lot for (which matches my recollection) and a handful against (my memory is that no hands showed against). There was a request to ask for a show of hands for how many don't know. The question was asked, and the record shows a dozen. So, there was apparently a complete change in the answer to the question based on humming versus voting. There may also have been some effect from asking, after the fact, for a show of hands for don't know. I'm really curious about the results, which indicate that, at least in this case, the response to the question is heavily dependent on the on the mode used to obtain the answers to the question (which we all know is possible). In particular, the effect of humming versus show of hands was pretty obvious. draft-resnick-on-consensus gives several reasons why humming is preferred over a show of hands. From this example, it seems to me to be worth considering whether a more honest and accurate result is obtained through humming rather than a show of hands. The other question raised in my mind is why the initial result from the hum, which did not have a consensus either way, was not sufficient. Roughly the same response for/against the question would seem to me to be as valid a result as explicit consensus one way or the other, and the act of taking a show of hands to survey the appeared to treat the hum as irrelevant, rather than highly significant. - Ralph
Re: 6tsch BoF
On Thu, Aug 1, 2013 at 2:34 AM, Ralph Droms rdroms.i...@gmail.com wrote: On Aug 1, 2013, at 11:14 AM 8/1/13, Andy Bierman a...@yumaworks.com wrote: Hi, Isn't it obvious why humming is flawed and raising hands works? (Analog vs. digital). A hand is either raised or it isn't. The sum of all hands raised is comparable across tests. The repeatable test gives *an* answer, but is not necessarily the answer that best reflects the sentiment of those answering the question. A relatively imprecise thermometer that gives a reading close to the measured temperature is more useful than a digital thermometer that gives a precise but highly inaccurate reading. I disagree. Whether I raise my hand to ear level, 2 inches above my head, or as high as I can reach, the chair will still count my raised hand as 1. If I hum really load (and if everybody hums at a different volume) the chair cannot possibly know how to quantify that result. Quantifying the number of raised hands is not a judgement call, - Ralph Andy The sum of the amplitude of all hums is not. Andy On Thu, Aug 1, 2013 at 1:50 AM, Ralph Droms rdroms.i...@gmail.com wrote: I found the process in the 6tsch BoF (Tue 1520) for asking about taking on the work discussed in the BoF to be thought-provoking. Toward the end of the BoF, the chairs asked the question 1. Is this a topic that the IETF should address? First, the chairs asked for a hum. From my vantage point (middle of the room), the hum was pretty close to equal, for/against. I reviewed the audio (http://www.ietf.org/audio/ietf87/ietf87-bellevue-20130730-1520-pm2.mp3, starting about 1:22), and heard a slightly louder hum for. The BoF chairs decided they needed more information than they could extract from the hum, so they asked for a show of hands. From the audio record, there were a lot for (which matches my recollection) and a handful against (my memory is that no hands showed against). There was a request to ask for a show of hands for how many don't know. The question was asked, and the record shows a dozen. So, there was apparently a complete change in the answer to the question based on humming versus voting. There may also have been some effect from asking, after the fact, for a show of hands for don't know. I'm really curious about the results, which indicate that, at least in this case, the response to the question is heavily dependent on the on the mode used to obtain the answers to the question (which we all know is possible). In particular, the effect of humming versus show of hands was pretty obvious. draft-resnick-on-consensus gives several reasons why humming is preferred over a show of hands. From this example, it seems to me to be worth considering whether a more honest and accurate result is obtained through humming rather than a show of hands. The other question raised in my mind is why the initial result from the hum, which did not have a consensus either way, was not sufficient. Roughly the same response for/against the question would seem to me to be as valid a result as explicit consensus one way or the other, and the act of taking a show of hands to survey the appeared to treat the hum as irrelevant, rather than highly significant. - Ralph
Re: 6tsch BoF
On Thu, Aug 1, 2013 at 3:04 AM, manning bill bmann...@isi.edu wrote: we have never voted at IETFs. we believe in rough consensus and running code We are not voting. We are expressing agreement with a specific assertion. That is true whether the agreement is expressed via vocalization or motion of limbs. Humming allows the chairs to be totally biased and interpret the hum volume in a way that aligns with their preference for the outcome. However, I have seen many times where the chairs clearly miscounted the number of raised hands in order to make the outcome align with their preference. However this is much harder to pull off than comparing 2 similar hum volumes. The chairs can pick however they want to measure agreement. Many chairs ask for a show of hands. I prefer that method. There is still a judgement call when the numbers for and against are not significantly different. /bill Andy On 1August2013Thursday, at 2:14, A ndy Bierman wrote: Hi, Isn't it obvious why humming is flawed and raising hands works? (Analog vs. digital). A hand is either raised or it isn't. The sum of all hands raised is comparable across tests. The sum of the amplitude of all hums is not. Andy On Thu, Aug 1, 2013 at 1:50 AM, Ralph Droms rdroms.i...@gmail.com wrote: I found the process in the 6tsch BoF (Tue 1520) for asking about taking on the work discussed in the BoF to be thought-provoking. Toward the end of the BoF, the chairs asked the question 1. Is this a topic that the IETF should address? First, the chairs asked for a hum. From my vantage point (middle of the room), the hum was pretty close to equal, for/against. I reviewed the audio (http://www.ietf.org/audio/ietf87/ietf87-bellevue-20130730-1520-pm2.mp3, starting about 1:22), and heard a slightly louder hum for. The BoF chairs decided they needed more information than they could extract from the hum, so they asked for a show of hands. From the audio record, there were a lot for (which matches my recollection) and a handful against (my memory is that no hands showed against). There was a request to ask for a show of hands for how many don't know. The question was asked, and the record shows a dozen. So, there was apparently a complete change in the answer to the question based on humming versus voting. There may also have been some effect from asking, after the fact, for a show of hands for don't know. I'm really curious about the results, which indicate that, at least in this case, the response to the question is heavily dependent on the on the mode used to obtain the answers to the question (which we all know is possible). In particular, the effect of humming versus show of hands was pretty obvious. draft-resnick-on-consensus gives several reasons why humming is preferred over a show of hands. From this example, it seems to me to be worth considering whether a more honest and accurate result is obtained through humming rather than a show of hands. The other question raised in my mind is why the initial result from the hum, which did not have a consensus either way, was not sufficient. Roughly the same response for/against the question would seem to me to be as valid a result as explicit consensus one way or the other, and the act of taking a show of hands to survey the appeared to treat the hum as irrelevant, rather than highly significant. - Ralph
Re: 6tsch BoF
On Thu, Aug 1, 2013 at 4:24 AM, Yoav Nir y...@checkpoint.com wrote: On Aug 1, 2013, at 11:14 AM, Andy Bierman a...@yumaworks.com wrote: Hi, Isn't it obvious why humming is flawed and raising hands works? (Analog vs. digital). A hand is either raised or it isn't. The sum of all hands raised is comparable across tests. The sum of the amplitude of all hums is not. Hums are better as they give greater weight to people who are more vocally in support (or in opposition) to the assertion. Please provide some evidence that a loud hum means the person is more committed to work on an item. Favoring loud humming is subject to cultural bias. Some cultures are more inclined to raise their voice than others. Some people have naturally louder voices than others. Measuring volume may introduce bias in favor of loud men and against soft-spoken women, for example. This cultural bias is not compatible with increased inclusiveness. Andy Research shows([1]), that the one humming loudly for acceptance, will also volunteer to review and contribute code. The one humming loudly against is going to jump up to the mike in all future meetings and tell the group that they're doing the wrong thing. Those who hum softly will go back to reading their email. Yoav [1] citation needed
Re: I-D Action: draft-barnes-healthy-food-07.txt
Hi, On Tue, Jul 16, 2013 at 10:17 AM, Ted Lemon ted.le...@nominum.com wrote: ... given the number of graybeards who attend IETF, I think paying attention to the problem of excessive sugar in break foods is really important. I'm not supposed to have sugar, so the massive quantities of cookies, brownies, ice cream, etc. in the breaks are an unwanted distraction. But that doesn't mean I want celery and carrots instead. :-) I suggest more cheese and crackers, sandwiches, etc. and perhaps less cookies. Andy
Re: IETF registration fee?
On Wed, Jul 10, 2013 at 4:06 PM, Hector Santos hsan...@isdg.net wrote: On 7/10/2013 5:17 PM, Josh Howlett wrote: Day passes have nothing to do with it. I disagree. Day passes encourage the notion that it's normal to parachute into the IETF to attend a single session. I think that the IETF's strength is that we don't totally compartmentalise work items. I am perplexed that there is, on the one hand, a (valid, IMHO) concern about increasing IETF diversity participation, when there appears to be an active policy of discouraging potential participants who simply wish to get work done in some specific sessions. Superficially, it would seem that making participation more flexible and affordable might help to improve diversity participation. Josh. +1 Thank you. Well said. I had very little limited time but I wanted to blast by Orlando from Miami (by car) and attend just one day, just to meet the folks I often have electronic battles with over the years. But the daily cost was a little too much and I certainly didn't want (nor ready) to stay an entire week to make it cost effective. Perhaps it is a minor issue to attract local area interest, since that would be the only advantage for a daily attendance cost. It seems to be too much contradictory discussion about diversity. I don't have too much confidence anything will be improved. +1 Just because I want to attend all week doesn't mean everybody else should also want to do the same, or can afford the time and expense. Back when I was RMONMIB WG Chair, it was difficult to get developers to attend the IETF. They were too busy implementing the RFCs to spend an entire week at the IETF. They really didn't want to expand their horizons and attend extra meetings for WGs they didn't follow. I think a 1-day pass would have helped a little, since one still has to make travel plans in advance of the final agenda. It seems to me that a cheap 1 day pass and ultra-cheap 1 day student pass would encourage local people to attend their first IETF. -- HLS Andy
Re: The Nominating Committee Process: Eligibility
Hi, I am strongly opposed to a remote meeting registration process and remote meeting fees. This increases the financial bias towards large corporate control of IETF standards. I like the IETF because anybody can comment on a draft or write a draft without paying fees. I think there could be several ways to prove one has been recently involved in the IETF. IMO I-D or RFC authorship shows more involvement than just showing up at an IETF. People who never read, write or comment on any drafts can be more nomcom-qualified (by attendance metrics) than somebody who worked on 10 drafts over the same time span. Andy On Thu, Jun 27, 2013 at 6:36 AM, Dave Cridland d...@cridland.net wrote: On Thu, Jun 27, 2013 at 2:21 PM, Michael Richardson mcr+i...@sandelman.ca wrote: Arturo Servin arturo.ser...@gmail.com wrote: Today it is possible to verify that somebody attended to an IETF meeting. You have to register, pay and collect your badge. However, in remote participation we do not have mechanisms to verify that somebody attended to a session. We need to have registration for remote participation, even if we charge zero. I believe that perhaps we need to provide some magic token in jabber or in the NoteWell slide, that needs to be used by remote participants to check-in. They have to do that during the meeting itself. We could require room registration for the XMPP (Jabber) chatrooms, and have remote participants fill in an equivalent of the blue sheet in order to join the room. I'm not sure if the current XMPP implementation supports this, but it will work in principle with a number of existing deployed implementations. (And, note, we no longer have to care about Google Talk interop, which makes things easier). Dave.
Re: ietf@ietf.org is a failure
Hi, I'm not sure how the desire for IETF Last Call discussions to be on a dedicated and constrained mailing list in any way implies that this generalized and unconstrained list is somehow a failure. Filtering by subject line is unreliable. For example, please provide a filter that will not have any false positives or negatives over the past 20,000 emails on this list. Do we have tools that make sure no human has altered any subject line inappropriately? Filtering by mailing list address is much easier and more reliable. Andy On Sat, Jun 8, 2013 at 1:20 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 09/06/2013 07:55, Melinda Shore wrote: On 6/8/13 10:09 AM, SM wrote: As an off-topic comment, there are are alternative ways in making a decision; the best judgement of the most experienced or IETF Consensus. I don't think it's off-topic. Consensus (rough or otherwise) requires that at some point people can live with decisions with which they disagree. To the extent that we've seen recent misbehavior on this list, it's from only one person who's rejecting the consensus and rejecting the process. It's really annoying but I don't think it's particularly disruptive. If it becomes disruptive, there's a rarely-used hammer: the PR action. I agree. Whatever misbehaviour Melinda means hasn't troubled me; it must be a user or a thread that I filter to junk. Disagreement is fine as long as people in the end understand when they're in the rough and not in the consensus. There are times when this list annoys me too, but it is far from a failure IMHO. Brian
Re: Weekly posting summary for ietf@ietf.org
On Fri, Jun 7, 2013 at 7:49 AM, Thomas Narten nar...@us.ibm.com wrote: What the weekly stats really ought to tally up is the readers/postings ratio, so that folk would get more direct feedback as to whether what they are posting is actually being read... My strong suspicion would be that there is strong negative correlation between frequency of posts and actual readers of those posts... Also, I suspect that many people do not realize that a significant chunk of IETF contributers are no longer subscribed to the ietf list due to signal to noise ratio concerns... So why not move the signal? Put IETF Last Call mail on last-c...@ietf.org and leave this list for everything else. I don't really want people counting their bytes when they are concerned about a technical issue in an I-D. It may take several exchanges for a disagreement to be resolved. Social pressure to stay out of the top-N report could have a negative impact on last call debates. Thomas Andy
Re: Weekly posting summary for ietf@ietf.org
On Fri, Jun 7, 2013 at 8:52 AM, Ted Lemon ted.le...@nominum.com wrote: On Jun 7, 2013, at 11:48 AM, Andy Bierman a...@yumaworks.com wrote: So why not move the signal? Put IETF Last Call mail on last-c...@ietf.org and leave this list for everything else. The discussion still has to happen somewhere. I certainly am not restricting my meaningful participation in last calls, but even in that case it is important to be restrained and not get into long fruitless discussions, which, I am afraid, I am wont to do. Some people consider the last call discussions to be signal and the rest (vast majority) of discussions to be noise. They would subscribe to a last-call mailing list, but not this one. Andy
Re: Issues in wider geographic participation
Hi Jari, On Mon, May 27, 2013 at 5:15 AM, Jari Arkko jari.ar...@piuha.net wrote: John, * People aren't aware the IETF exists, or what it does, or that it has an open participation model * People don't read and write English well enough to be comfortable participating * People are unaccustomed to and perhaps uncomfortable expressing overt disagreement * People don't think they have anything to contribute to an organization that is mostly people from rich countries * People don't have adequate Internet access for mail, or to use the remote participation tools Thanks for sending out a list of potential issues. I think there may be one issue missing from the list. At the end of the day, what tends to drive people actual, concrete benefit to themselves or their organisations. A drive that is so big that it forces you to cross language and other barriers and make at least a time investment in participation. As an example, the number of Chinese participants has increased rapidly in the IETF. Why? We probably didn't suddenly get much better at welcoming new people at the IETF, but the new participants felt that work on the Internet is important to them personally, and their organisations felt that they need to be part of making Internet standards. This isn't very surprising, given, for instance, the rise of the Chinese technology industry to a very visible role in the world. So I feel that the issue in many cases is simpler than the ones in the list: What's in it for me? This obviously has to do with the role of vendors in the IETF and the distribution of tech industry in the world. It may also have something to do with doing things that are important. I'm sure we could be working on topics that are even better aligned to what the world needs… if the people who need them were here to tell us :-) This is the most important factor and trumps all other combined. If the standards work is relevant to your business or research then the probability that you will participate in the IETF goes way up. I think many people on this list forget how different doing engineering in the IETF is from engineering for a private enterprise. Tasks that take 1 or 2 months in a private enterprise often take 1 or 2 years (or more!). Competitors working on a standard have a completely different set of incentives than employees working on a product, so agreement on standards is much harder to achieve. Newbies can have a hard time adjusting to these differences. The IETF can't change the distribution of industries in the world, but we can, for instance, focus on the vendors that are there or work more on topics that are interesting for the operational folks. The latter would be a good idea for the IETF, anyway. 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) We've been looking at setting up something like that (not for BA specifically). Jari Andy
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
On Fri, May 17, 2013 at 6:29 PM, Keith Moore mo...@network-heretics.comwrote: On 05/17/2013 04:36 PM, Yoav Nir wrote: On May 17, 2013, at 6:37 PM, Dave Crocker d...@dcrocker.net wrote: On 5/17/2013 7:01 AM, Keith Moore wrote: But WGs should be able to periodically summarize what they're doing - what problem they're trying to solve, what approach they're taking, what technologies they're using, what major decisions they've made, what the current sticking points seem to be, what problems are as yet unresolved, what potential for cross-group and cross-area effects have been identified, and what efforts have been made to get the affected parties in the loop. For most groups that summary should be maybe 2-3 pages. The ADs should be able to verify that those summaries are accurate and reasonably complete, or appoint a trusted WG observer other than the chair to review each summary. ADs and other members of the community should be able to view those summaries and comment on their accuracy. The idea that working groups should be required to issue periodic project progress reports seems strikingly reasonable and useful. This makes the folks who are the most knowledgeable responsible for assessing their work, and should facilitate public review. Recording the sequence of reports into the wg datatracker could nicely allow evaluating progress over time. It also, of course, nicely distributes the work. d/ From: WG Chair To: ietf@ietf.org Sunbject: Progress Report - Foo WG There has been zero activity on the FOO list in the last three months (except for that Fake Conference message everybody got last month). I've tried emailing the WG document authors twice, but they're not answering my emails. So, the WG has 2 documents: draft-ietf-foo-use-cases-03, and draft-ietf-foo-proto-01. The use case document is just about done, but we haven't really started discussing the proto document. We haven't met in Orlando, and are unlikely to meet in Berlin That's it for this report. Cheers WGC Instead of a WG progress report, what I had in mind was a separate report for each work item. The report should briefly describe 1. The purpose of the work being undertaken 2. A description of the work being undertaken (including mention of major technologies on which the work is based) 3. All known parties and interests likely to be affected by the work 4. The current state of the work (what's been done, what hasn't been done) 5. Any major issues that have been identified but not resolved 6. Pointers to the WG's charter, the datatracker pages for each of the current draft document(s) associated with that work item, and any other useful material (e.g. open issues list, summaries of design decisions already taken and the rationale for each) A person who is knowledgeable about current Internet protocols should be able to read that single document and understand what the WG is doing with this particular work item, what state it's in, whether or not it will affect that person's are of interest, and where to look for detailed information. This seems like a good idea, although maybe a bit formal. IMO, big surprises at the tail end that cause lots of work to be thrown out are evidence of a management failure. The IESG and WG chairs should be more proactive wrt/ avoiding late surprises from ever happening. I notice that nowhere on this list is any mention of the charter milestones or dates. Is the Foo Proto draft due in 14 months or is it 14 months behind schedule? If the latter, why isn't the Foo WG meeting at the IETF? Keith Andy
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
On Fri, May 17, 2013 at 7:29 PM, Keith Moore mo...@network-heretics.comwrote: On 05/17/2013 10:21 PM, Andy Bierman wrote: I notice that nowhere on this list is any mention of the charter milestones or dates. Is the Foo Proto draft due in 14 months or is it 14 months behind schedule? If the latter, why isn't the Foo WG meeting at the IETF? 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. I think we can find some middle ground between ignore charter milestones completely and autobot to terminate WGs behind schedule. :-) Keith Andy
Re: call for ideas: tail-heavy IETF process
Hi, The evidence seems to show that the IESG is getting faster at their job and WGs are getting slower at theirs. I don't see any need for DISCUSS Rules. All the AD reviews I've experienced have improved the document, sometimes a lot. All DISCUSS issues got cleared with reasonable (even good) solutions. IMO, there is no question that applying the right expertise at the appropriate time in the WG draft process would improve the entire system and avoid surprises during I* Last Call. The question is the best way to do that. Andy On Tue, May 14, 2013 at 4:57 PM, Joel M. Halpern j...@joelhalpern.comwrote: And your bottom line is exactly what te rules say, what I said, what Ted said, and what Joe agreed is reasonable. It also matchesthe practice I have seen. Even the discuss that I had a lot of arguments with did include proposals for paths forward. Sometimes they were ard to understand. That's probably inevitable with all these opinionated humans doing this. Yours, Joel On 5/14/2013 7:15 PM, Dave Crocker wrote: On 5/14/2013 3:46 PM, Andrew Sullivan wrote: To be fair, for what it's worth as a WG chair I've had the latter experience at least as often as the former in the use of DISCUSS, and I've observed some DISCUSSes cleared without any change at all to the document in question. We suffer a continuing logic error in the IETF. We use sometimes it happens the other way as if that negates the existence and problem cause by what is being criticized. So, yeah, of course a Discuss /sometimes/ causes a small delay with no changes. /Sometimes/ ADs use the sledgehammer of the Discuss to ask for a bit of conversation. That's all irrelevant. What's relevant is the nature of the mechanisms, its capability, and the cost it can and does impose on authors and the working group. When a serious defect is identified, it's entirely worth the cost. When it isn't, it isn't. In all cases, the person imposing the cost has an obligation to facilitate closing it, including making clear the criteria for closing it. It is unreasonable to have those who must do the work to clear it play a guessing game.
Re: [Gen-art] Review: draft-ietf-netmod-rfc6021-bis-01
On Fri, May 10, 2013 at 7:37 AM, Joel M. Halpern j...@joelhalpern.comwrote: I am guessing that the authors intended the addition of the text emphasizing that the no-zone typedefs are derived general typedef addresses the difference in the patterns. Is there a YANG rule that says tat if typedef X is derived from typedef Y then the string for X must match the pattern for X and the pattern for Y? If so, then my concern below is misplaced. (The fact that I find the vague pattern for the child misleading is not a fault with the document, but rather in my head, under that requirement.) Yes. RFC 6020, sec. 9.4.6. All the patterns are ANDed together. Yours, Joel Andy On 4/19/2013 6:24 PM, Joel M. Halpern 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/GenArtfaqhttp://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-netmod-rfc6021-bis-**01 Common YANG Data Types Reviewer: Joel M. Halpern Review Date: 19-April-2013 IETF LC End Date: 1-May-2013 IESG Telechat date: N/A Summary: This document is nearly ready for publication as a Standards Track RFC Major issues: (The following may well be a non-issue.) In the revision of the ietf-inet-types, the patterns for the new ip4-address-no-zone and ipv6-address-no-zone are drastically simplified from the ipv4-address and ipv6-address patterns. The new ipv4-address-no-zone allows any sequence of decimal digits an periods, while the original was carefully defined as dotted quads of 0..255. Similarly, te ipv6-address-no-zone allows any arbitrary sequence of hex digits and colons. The original patterns were very careful to match rules for validity. Is there a reason for the change. Minor issues: Nits/editorial comments: __**_ Gen-art mailing list gen-...@ietf.org https://www.ietf.org/mailman/**listinfo/gen-arthttps://www.ietf.org/mailman/listinfo/gen-art
Re: call for ideas: tail-heavy IETF process
.. WG chairs might like to comment, but I suspect that one lunchtime training session every four months does not constitute proactive management. +1 !!! It works on down the line too. WG Chairs meeting with I-D editors once every 4 months isn't so great either. If the total time has gone up 100 days, and the IESG time has gone down 100 days, then clearly the WG process is the main problem. I'd like to see some stats on average delta between revisions of an I-D, with some metric for the number of changes per revision. I suspect it would show way too many drafts that have a few edits once every 4 months. (One of mine right now even ;-) The WG Chairs need more training on how to avoid the slow tweak mode problem. The ADs need to manage their WG chairs so this doesn't happen. Adrian Andy
Re: call for ideas: tail-heavy IETF process
On Wed, May 1, 2013 at 9:33 AM, Michael Richardson mcr+i...@sandelman.cawrote: #part sign=pgpmime Jari == Jari Arkko jari.ar...@piuha.net writes: Jari I wrote a blog article about how we do a fairly significant Jari amount of reviews and changes in the late stages of the IETF Jari process. Next week the IESG will be having a retreat in Jari Dublin, Ireland. As we brought this topic to our agenda, Pete Jari and I wanted to raise the issue here and call for feedback Jari ideas for improving the situation with all of you. Jari http://www.ietf.org/blog/2013/05/balancing-the-process/ I'll repeat what has been said repeatedly in the newtrk and related discussions. The step from ID to RFC is too large because we are essentially always aiming for STD rather than PS. I don't think this helps. We want the highest quality documents possible for developers to translate into implementations. IMO, the answer is to identify cross-area issues early, and more importantly, get early cross-area reviewers to help avoid bad decisions that won't make it through IESG review. Maybe a cross-area expert needs to join a design team for awhile to make sure good decisions are made. The ADs need to make sure these early reviews get staffed and completed. Maybe additional people (directorate?) helps manage this process. Andy If we are unwilling to bring RFC back to a place were it does not equal STD, then we need to create a new category of document which amounts to fully baked ID. Things like IANA allocations could occur at that point. In the days of dot-boom it was not unusual to see widespread implementation very early in the ID process and even interop and experimental deployment. While this still occurs for quite a number of things (and sometimes it's a problem that the ID can not be changed as a result), there is an equal amount of wait for the RFC to come out. I believe that we probably need to simply do less. Or perhaps we've reached the n^2 overhead problem, and since resources are less(%), if we can't increase resources allocated to overhead, then it's time to reduce n: the IETF should fork and/or shard somehow. (%)-it's not just about $$ invested, it's also, I think, that after many years of caffeine and sugar, many of us are simply immune to their effects, and/or have given them up. (2)-by adding an intermediate step in the ID process, I haven't removed the heavy part of the process, I've just redefined the process so that it's no longer at the tail of the process. This is, I admit, akin to adjusting the definition of unemployment. But, we can all agree when an ID is baked enough for the WG to consider it deployable, then we will actually get to the running code part sooner, which frankly is the only real way to get real experience. -- ] 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 [
Re: IETF Diversity Question on Berlin Registration?
On Wed, Apr 17, 2013 at 7:52 AM, Eliot Lear l...@cisco.com wrote: Dan, On 4/16/13 2:00 AM, Dan Harkins wrote: Under the belief of garbage in, garbage out, I tend to lie on these sorts of repugnant questions. I invite others to join me. The more suspect the quality of the data, the less value it has. Dan. Please don't. We are trying to understand who we are. Is that SO unreasonable? I don't object to filling out forms, and I would certainly answer honestly. Who is we? Just people who go to the Berlin IETF? - does it include remote participants via Jabber or other tools - does it include people who participate only on WG mailing lists? The only bias I see is that it takes a lot of employer backing and funding to participate in the IESG. It is therefore the companies that sponsor these participants have the most influence of all over the selection process. Hold another IETF in San Jose or San Francisco and I bet we get way more balanced data than a site that requires a lot of travel, especially since we have day passes now. Eliot Andy
Re: Purpose of IESG Review
On Thu, Apr 11, 2013 at 5:27 PM, Fred Baker (fred) f...@cisco.com wrote: In my opinion, some individual ADs seem to, from their behavior, feel that they have not done their jobs unless they have raised a discuss. The one that took the cake for me personally was a discuss raised by a particular AD (who shall remain nameless) that in essence wondered what he should raise a discuss about in my document. There were a couple of errors in that; he told me later that what he had done was opened the comment tool and typed that question, and subsequently accidentally hit the equivalent of send - the question wasn't intended to go out. But the question itself is telling: the issue was not does the document meet the requirements of BCP 9, it was what comment shall I raise? Also, in my opinion, IESG review that raises a certain number of issues should not result in the document sitting in the IESG's queue for a few months while the authors go back and forth with the AD or the GEN-ART reviewer pounding the document into someone's idea of shape without working group involvement. I personally would prefer that simple matters get sorted out between the ADs and the author, but complex changes or additional content requested by the AD should result in the document being sent back to the working group. Many of us can change the acronyms and describe a similar experience. I would say We don't have the authority to make that decision without asking the WG a lot. But this is a 2nd order problem. The real issue is the way the IESG manages WGs. Good management doesn't fall out for free. It is yet another continuous integration progress. The IESG is the overworked bottleneck in the system and the review process is the main reason. The ADs that own a WG should be the main IESG members that get involved at the details for any possible issue, and hopefully make these comments/changes as early in the WG process as possible. During IESG review, the ADs from other areas should restrict their comments to issues related to their area. The final review should avoid changes made which are feature redesigns or feature enhancements, and limit changes to bug fixes only. Andy
Re: [OPSAWG] Basic ietf process question ...
On Thu, Aug 2, 2012 at 9:59 AM, Romascanu, Dan (Dan) droma...@avaya.com wrote: Hi, The OPSAWG/OPSAREA open meeting this afternoon has an item on the agenda concerning the revision of RFC1052 and discussing a new architecture for management protocols. My personal take is that no one protocol, or one data modeling language can match the operational requirements to configure and manage the wide and wider range of hosts, routers and other network devices that are used to implement IP networks and protocols. We should be talking nowadays about a toolset rather than one tool that fits all. However, this is a discussion that just starts. NMS developers need to spend too many resources on translating naming and other data-modeling specific details so they can be usable within the application. So if 1 data modeling language is not used, then deterministic, loss-less, round-trip translation between data modeling languages is needed. Multiple protocols are not the problem -- incompatible data from multiple protocols is the problem. Regards, Dan Andy -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Robert Raszuk Sent: Thursday, August 02, 2012 7:25 PM Cc: ietf@ietf.org Subject: Basic ietf process question ... All, IETF documents have number of mandatory sections .. IANA Actions, Security Considerations, Refs, etc ... Does anyone have a good reason why any new protocol definition or enhancement does not have a build in mandatory XML schema section which would allow to actually use such standards based enhancement in vendor agnostic way ? There is a lot of talk about reinventing APIs, building network wide OS platform, delivering SDNs (whatever it means at any point of time for one) ... but how about we start with something very basic yet IMHO necessary to slowly begin thinking of network as one plane. I understand that historically we had/still have SNMP however I have never seen this being mandatory section of any standards track document. Usually SNMP comes 5 years behind (if at all) making it obsolete by design. NETCONF is great and very flexible communication channel for provisioning. However it is sufficient to just look at number of ops lists to see that those who tried to use it quickly abandoned their efforts due to complete lack of XML schema from each vendor they happen to use or complete mismatch of vendor to vendor XML interpretation. And while perhaps this is obvious I do not think that any new single effort will address this. This has to be an atomic and integral part of each WG's document. Looking forward for insightful comments ... Best, R. ___ OPSAWG mailing list ops...@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: primary Paris hotel booking
On 01/03/2012 08:52 AM, George, Wes wrote: Happy New Year, it's time for our triannual hotel complaint thread. I hate to do it, but I think that there are people who haven't looked at this yet, and I'm hoping that we can perhaps rectify it before the majority of folks try to book: Instructions for making reservations at Hotel Concorde: Please fill out the reservations form and fax it directly to the hotel at: +33 1 57 00 50 79 or email it to cmas...@concorde-hotels.com I crossed my fingers and clicked 'send' of the PDF with my credit card number in it. I didn't pay enough attention to the no-refund policy. :-( I emailed my reservation on 12/22 and got a confirmation email on 12/26. So far, my credit card has not been charged anything. I think there should always be a full-refund cut-off date for the IETF hotel, even if it is 2 months in advance. I thought the cut-off was 15 days, but that is just for 2 more nights billed in advance, not the first night. Andy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Recheck on draft-ietf-netconf-4741bis-09//RE: [secdir] Assignments
Hi, The get-config was removed from the diagram to make room for the notification stuff on the right. It does not mean that get-config was removed from the protocol. The box just showed 2 of the many operations, now only 1. Andy -Original Message- From: Tina Tsou [mailto:t...@huawei.com] Sent: Thursday, March 03, 2011 10:31 AM To: secdir-secret...@mit.edu; sec...@ietf.org; 'The IESG'; ietf@ietf.org Cc: draft-ietf-netconf-4741...@tools.ietf.org Subject: Recheck on draft-ietf-netconf-4741bis-09//RE: [secdir] Assignments Hi, I rechecked draft-ietf-netconf-4741bis-09, only one more comment: Why get-config is deleted from figure 1 compared with RFC4741? RFC4741: Layer Example +-+ +-+ (4) | Content | | Configuration data | +-+ +-+ | | +-+ +-+ (3) | Operations | | get-config, edit-config | +-+ +-+ | | +-+ +-+ (2) | RPC | |rpc, rpc-reply | +-+ +-+ | | +-+ +-+ (1) | Transport | | BEEP, SSH, SSL, console | | Protocol | | | +-+ +-+ RFC4741bis: Layer Example +-+ +-+ ++ (4) | Content | | Configuration | | Notification | | | | data | | data | +-+ +-+ ++ | | | +-+ +-+ | (3) | Operations | | edit-config | | | | | | | +-+ +-+ | | | | +-+ +-+ ++ (2) | Messages | | rpc, | | notification | | | | rpc-reply | || +-+ +-+ ++ | | | +-+ +-+ (1) | Secure| | SSH, TLS, BEEP/TLS, SOAP/HTTP/TLS, ... | | Transports | | | +-+ +-+ We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -Original Message- From: secdir-boun...@ietf.org [mailto:secdir-boun...@ietf.org] On Behalf Of Samuel Weiler Sent: Saturday, February 26, 2011 3:57 AM To: sec...@ietf.org Subject: [secdir] Assignments Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Hilarie Orman is next in the rotation. For telechat 2011-03-03 Reviewer LC end Draft Rob AusteinT 2011-02-16 draft-ietf-netconf-rfc4742bis-07 Alan DeKok T 2011-03-01 draft-ietf-hip-over-hip-05 Donald EastlakeT 2011-03-01 draft-ietf-6lowpan-usecases-09 Tobias Gondrom T 2011-03-01 draft-ietf-hip-cert-09 Love Hornquist-Astrand T 2011-02-21 draft-ietf-v6ops-v6-in-mobile-networks-03 Russ Mundy T 2011-02-17 draft-ietf-speermint-voipthreats-07 Tina TSOU TR2011-02-07 draft-ietf-netconf-4741bis-09 Sam Weiler TR2011-02-21 draft-ietf-sipcore-199-05 Sam Weiler T 2011-02-16 draft-ietf-hokey-ldn-discovery-06 Glen Zorn T 2011-02-10 draft-ietf-shim6-multihome-shim-api-16 For telechat 2011-03-17 Jeffrey Hutzelman T 2011-03-09 draft-zhu-mobility-survey-03 Catherine Meadows T 2011-03-09 draft-ietf-ancp-protocol-15 Kathleen Moriarty T 2011-03-11 draft-ietf-intarea-server-logging-recommendations-03 Magnus Nystrom T 2011-02-23 draft-meadors-multiple-attachments-ediint-10 Magnus Nystrom T 2011-03-10 draft-ietf-ipsecme-failure-detection-05 Carl Wallace TR2011-02-22 draft-herzog-setkey-03 For telechat 2011-04-14 Sandy Murphy T 2011-03-23 draft-kanno-tls-camellia-00 Last calls and special requests: Dave Cridland2011-02-21 draft-ietf-sidr-arch-12 Alan DeKok 2011-02-23
Re: secdir review of draft-ietf-netconf-partial-lock-09.txt
Wes Hardaker wrote: On Thu, 13 Aug 2009 13:55:15 -0700, Andy Bierman i...@andybierman.com said: AB Oherwise the agent would deadlock. AB discard-changes does not affect the running configuration. No, but it does affect the other users notion of changes. You should never be allowed to discard changes that another user has made. this assumes you have an access control model in mind. I do too -- they aren't the same. Without any standards for this, neither of us are wrong. AB It just resets the scratchpad database. AB Why bother applying the ACLs before the edit operation AB is attempted for real? user 1: add new important policy configuration user 2: discard-changes user 1: commit Granted, user 1 should be using locks of some kind. what is the NETCONF 'add new' operation? step 1 is very unclear. To undo changes it's rather important that someone with proper authorization to the everything changed (IE, an admin) performs the discard. Or are you suggesting that one shouldn't ever have access control applied to the candidate store in the first place? (I hope not). I apply it to the candidate and to running, except discard-changes, otherwise the agent would deadlock often and that would be counter-productive to network operations. When you start with an awful design premises like locking should be optional to use, then you might end up with messy code. Nothing new there. AB Requiring small embedded devices to serve as robust AB database engines may be more expensive than AB the rest of the code combined. We are coming from AB an operational environment based on humans using the CLI, AB which has no locking at all. The globally locked AB candidate edit, validate, and commit model AB is way better than anything we ever had in SNMP or CLI. If you look at history of operating just about anything, after it gets to a point where multiple operators need to scale things up you'll find that eventually stuff gets put into a multi-user revision database type system. We are far beyond the point where operators are editing single flat-files using vi and hitting save without any form of revision control. After that point, then went to locking version control systems (sccs? I'm forgetting the early version-control system names). Then people realized that caused huge headaches because the global file locking, although it prevented some types of problems, caused a bunch of other problems. Eventually more modern version control systems were developed that allowed people to simultaneously edit things and only get bothered when conflicts happen. This was a huge win, ask anyone who works with version control systems. But now, in this space, we're going back to the older methodologies of editing a single file and hoping that two people don't conflict (with or without a lock). again -- when locking is optional to use, the database is never going to be very good. I've said this before, but I'll repeat it now: netconf, from a protocol-operation point of view, is designed to work in a single-operator type environment. The instant you add multiple-users with or without different roles all these problems come up. This is actually just fine, but it needs to either: 1) be fixed so that these problems go away. 2) stop being advertised as a multi-operator type solution. I disagree. The partial-lock feature is not needed in every environment. NETCONF supports the SQL-like model (write directly to the persistent datastore) and that is good enough. Why does the scratchpad model need to be per-session? That is nice-to-have, but not important. I think being fixed is a great long term goal. But for right now, I'd suggest we simple say this is version 1 at the moment and it is currently designed for use by single-operator systems. (And it doesn't prevent an external version-control system for being the master and pushing the config down. It just doesn't work on the device itself). Andy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: secdir review of draft-ietf-netconf-partial-lock-09.txt
Stephen Hanna wrote: Thanks to Dan and Bert for answering my question. If most NETCONF implementations authenticate users and implement some form of authorization scheme, there should be no problem with including text in draft-ietf-netconf-partial-lock-09.txt that says NETCONF servers that implement partial locks MUST ensure that only an authenticated and authorized user can request a partial lock. Even a server that implements authentication but does not implement fine-grained authorization would meet this requirement. It would just be saying that all authenticated users are fully authorized to perform any operation on the server. Are there any concerns with this proposal? If so, please explain. The partial-lock operation does not work on the candidate database, yet the draft insists that this database is supported. It also says it works on the startup database, yet there is no way to edit this database, so why does it need to be partially locked? There is a global commit operation issued by a session. That session must be authorized to make all the changes to the running config that are contained in the candidate (all-or-nothing). The partial-lock design does not really have any affect on the candidate -- using it is just as ineffective as not using any locking at all. So it is subject to the 'candidate-deadlock' first described by Wes Hardaker: Let's say there is a simple config to edit: config foo3/foo barfred/bar /config Let's say user A is authorized to write /foo and user B is authorized to write /bar. 1) user A does partial-lock(target='candidate', data='/foo') 2) user B skips the lock and just edits the /bar leaf directly in the candidate database (even if user B took out a partial lock on /bar, the result would be the same) HALT: User A is not authorized to issue commit User B is not authorized to issue commit The database is wedged until somebody issues a discard-changes. discard-changes only works because authorization is ignored, otherwise the agent would be deadlocked. Only the global lock operation defined in RFC 4741 can prevent this problem. Thanks, Steve Andy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: secdir review of draft-ietf-netconf-partial-lock-09.txt
Wes Hardaker wrote: On Thu, 13 Aug 2009 08:26:54 -0700, Andy Bierman i...@andybierman.com said: AB discard-changes only works because authorization is ignored, AB otherwise the agent would be deadlocked. Huh why would discard-changes be authorization ignorant??? That's just as unsafe (unless you're only discarding your own changes). Oherwise the agent would deadlock. discard-changes does not affect the running configuration. It just resets the scratchpad database. Why bother applying the ACLs before the edit operation is attempted for real? AB Only the global lock operation defined in RFC 4741 AB can prevent this problem. The global lock has different issues. The problem isn't with the locking. Locking, and partial locking are good. It's with the global-level commit operation. Requiring small embedded devices to serve as robust database engines may be more expensive than the rest of the code combined. We are coming from an operational environment based on humans using the CLI, which has no locking at all. The globally locked candidate edit, validate, and commit model is way better than anything we ever had in SNMP or CLI. If concurrent edits instead of serialized edits are needed, then the :writable-running + :partial-lock capabilities support that. Andy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP
Joel M. Halpern wrote: To put it differently, the OPS area has as much right to propose their requirements as any other area (Transport Congestion, Security, ...) has. And generally, the community has listened to such requests and gone along with them. Yes, we have produced a bit of a problem that our initial standards now have a quality bar comparable with completed work. But we shouldn't suddenly pick on OPS for that. If we are going to address that problem, it ought to be in a coherent fashion that discusses how we deal with all the legitimate requirements, including the fact that stuff has to be operable. I agree, and I also agree with Randy about the lack of standardized NETCONF content. It is a clear indication that the vendors do not want any standardized configuration content. Every time 'content' has come up for charter consideration, the consensus has been to work on something else instead. But the NETCONF/YANG pieces are coming together, and it will allow WGs much more power and flexibility than SNMP/SMIv2 to define management interfaces which fit better with the native CLI than anything the IETF has had before. That is about as far as OPS-NM area can go. If a protocol WG do not want to define a standard configuration interface, then it does not matter how well SNMP or NETCONF supports this sort of work. (One might question whether using the same NM standardization methodology for 20 years and achieving consistently pathetic results means the methodology itself needs to be changed, not just the technology.) This does not mean we have to simply accept what they (OSP) say. But it does mean we should give it a fair review, looking at the details, rather than objecting on principle. Yours, Joel M. Halpern Andy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Running Code
Peter Saint-Andre wrote: On 3/3/09 9:08 PM, Masataka Ohta wrote: Andy Bierman wrote: Since the goal of our work is to produce specifications that will allow multiple independent implementations to inter-operate successfully, How can you define successful interoperation of implementations? You gather implementation reports. You conduct interoperability tests and bake-offs. This used to happen a lot more, back when advancing to Draft or Full Standard was considered important. IMHO you define it by running code -- that is, code which is used to run a functioning communications network. For me the canonical example is the medium we're using right now: email. In general (there are always exceptions!), you don't know or care what email clients people use, what email servers they use, whether they retrieve their email using POP or IMAP, etc. It just works, at least for the core use cases. And I think that's why running code (not just compiling code or functioning code, but a working network) is so important. Peter Andy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Running Code
Masataka Ohta wrote: Hallam-Baker, Phillip wrote: I don't see the value of running code quite as others do. I agree. It was valuable in good old days, when implmenting a protocol was purely voluntary with no budget. Existence of multiple independent implementations, then, meant the protocol was widely accepted by the society. However, after the overly introduction of standardization engineering to IETF, people satisfy requirements merely because they are required. So, existence of required running code does not mean much. I disagree. It means the specification is implementable. Since the goal of our work is to produce specifications that will allow multiple independent implementations to inter-operate successfully, I can think of no more valuable review input towards this goal than comments from implementers. I think adequate procedures exist for gathering implementation experience for the IESG to evaluate protocol interoperability. Masataka Ohta Andy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Experiment: More Meeting Time on Friday for IETF 73
Eric Rescorla wrote: At Fri, 18 Jul 2008 11:41:15 +0200, Eliot Lear wrote: Maybe it's just me, but... (Fanning the flames...) I do not understood why WGs are forbidden from conducting interim or other official extended technical f2f meetings before, during, or after, an IETF meeting. Consider the possibility that some participants are focusing on the charter of 1 or 2 WGs, and perhaps even writing code (!) in addition to I-Ds. These people are not too tired from attending 17 status meetings all week. These people do not want to devote an entire week to a few meetings. The time and cost involved in getting all/most of the principal technical contributors in the same building for a few days far out-weighs any fatigue factor cost. I don't think the IETF meeting fee should cover WG interim meetings, and I am not convinced there is a big demand for Friday afternoon WG slots, but if there is a meeting slot shortage, then adding to Friday is probably the easiest solution. I oppose this experiment. I already donate to my employer a significant amount of travel time on weekends without wanting to add to it. Flight schedules are tightening, thanks to the cost of fuel, which means that having sessions on Friday at all poses a problem now, if I want to get back by Saturday. Having afternoon sessions would put a nail in that coffin. I haven't decided whether I agree with Eliot entirely, but I think he raises some good points here. I would add two more: 1. I've attended IETFs where there was a meeting on Friday all day (e.g., the P2PSIP Ad Hoc at IETF 64) and it seemed to me that people were pretty wiped at that point, so even though they felt that they had to show up, I'm not sure much got done. 2. People's ability to meet tends to expand to fill out the available meeting time. With these two points in mind, It would be nice to have some metric of success that's more than just people showing up to the meetings. Unfortunately, I don't have such a metric. :( I propose two alternative experiments: 1. Required agendas and Approval No session can be approved without a posted agenda. Many agendas are late, which makes it difficult for people to know where they have to be and when. I completely agree with this. Before each IETF I attend I use automated tools (http://tools.ietf.org/tools/getdrafts/) to suck down each draft on the agenda and I regularly find a large fraction of WGs with missing agendas. As of today, the following WGs have no agenda: softwire, v6ops, mip4, dime, l3vpn, idnabis, l2vpn, ntp, savi, rtgwg, ecrit, capwap, radext, opsawg, rtgarea, pkix, opsec, isis, keyprov, vcarddav, netmod, pce, saag, grow, autoconf It's also not just an issue of knowing where to be and when but of getting prepared. It helps to know in advance which drafts you need to read. -Ekr Andy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: NETCONF Data Modeling Language (netmod)
Harald Alvestrand wrote: Eric Rescorla wrote: At Tue, 22 Apr 2008 19:17:47 -0600, Randy Presuhn wrote: Our ADs worked very hard to prevent us from talking about technology choices at the CANMOD BOF. Our original proposal for consensus hums included getting a of sense of preferences among the various proposals. We were told we could *not* ask these questions, for fear of upsetting Eric Rescorla. Well, it's certainly true that the terms--agreed to by the IESG and the IAB--on which the BOF were held were that there not be a beauty contest at the BOF but that there first be a showing that there was consensus to do work in this area at all. I'm certainly willing to cop to being one of the people who argued for that, but I was far from the only one. If you want to blame me for that, go ahead. In any case, now that consensus to do *something* has been established it is the appropriate time to have discussion on the technology. I certainly never imagined that just because there weren't hums taken in PHL that that meant no hums would ever be taken. It's been a month since PHL. The IETF's supposed to be able to work on mailing lists between meetings, including being able to work when no WG exists - which of course means working on mailing lists that are not WG lists. Agreed -- this also means that the 'technical approach' straw poll that did not occur in the CANMOD BoF is not really that important, since final consensus needs to be confirmed on a designated mailing list. I congratulate the participants who worked on the charter on managing to have the discussion and come to consensus on an approach. I think it's up to Eric to demonstrate to the IESG that there's support in the community for disagreeing with the consensus of the discussing participants. +1 15 person (large!) design team. 1000s of emails. Done in a month. This is more effort than most WGs can muster. Harald Andy ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: NETCONF Data Modeling Language (netmod)
David Harrington wrote: Here are my reasons why I support the charter, which align with yours: There are multiple types of users for data models. The operators and reviewers care about the semantic model much more than the syntactic mapping. Ease of use and stability have proven to be the most important factors for NM data models. YANG provides enough semantic modeling to be useful for the NM problem at hand, and since it will be owned by the IETF, the complexity and stability will also be controllable by the IETF. By decoupling the syntactic mapping from the semantic model, the specific mapping rules can change over time as W3C standards continue to evolve, without impacting any installed base of data models. Last year XSD was the only thing. Now we seem to be dropping XSD and adopting DSDL instead. I am not convinced XSD is dead, or the DSDL will be the final answer either. But if the YANG language stays stable, I don't care. Andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Rescorla I propose that you list (again) your (technical) objections to the the current proposal. Sure. Based on my knowledge of modelling/protocol description languages, the techniques that Rohan described based on RNG and Schematron seemed to me quite adequate to get the job done and the relatively large baggage introduced by defining another language (YANG) which is then translated into them seems wholly unnecessary. I appreciate that some people believe that YANG is more expressive and better suited for this particular purpose, but I didn't see any really convincing arguments of that (I certainly don't find the arguments in F.2 of draft-bjorklund-netconf-yang dispositive). Given what I know of the complexity of designing such languages, and of their ultimate limitations and pitfalls, this seems like a bad technical tradeoff. The people who believe that YANG is more expressive and better suited for this poarticular purpose include contributors to the design of SMIv2, MIB Doctors, members of the NMRG who helped develop the SMING information and data modeling language, contributors to the SMIng WG which worked on developing a proposed SMIv3 to converge the SMIv2 standard and the SPPI data modeling language standard and the NMRG SMING approach, and engineers who have multiple independent implementations of running code for Netconf data modeling. I respect their experience and combined knowledge of the complexity of designing such languages. I also respect operators' knowledge of the complexity of using such languages to actually manage networks. The NM community has been working to resolve the problem of the unsuitability of the IETF's SNMP-only approach to configuration for many years, and the NM comunity has deliberately sought out operators for feedback about what does and what doesn't work well for them in configuration data modeling. One of the major problems of designing a language for data modeling is that there are many different constituencies with very different requirements for a configuration language, which change over time, as can be seen in RFC3139 and RFC3216 and RFC3535. There are a tremendous number of potential tradeoffs to make a general-purpose language meet everybody's needs. In RFC4101 Writing Protocol Models, you argue that reviewers have only limited amounts of time and most documents fail to present an architectural model for how the protocol operates, opting instead to simply describe the protocol and let the reviewer figure it out. This is acceptable when documenting a protocol for implementors, because they need to understand the protocol in any case; but it dramatically increases the strain on reviewers. Reviewers need to get the big picture of the system and then focus on particular points. They simply do not have time to give the entire document the attention an implementor would. The NM comunity sought out multiple operator communities, and came to a similar conclusion. Operators need to review data model specifications, and quickly understand the model, often while in the middle of fire-fighting. To help address the need to quickly understand the model, the MIB Doctors have developed guidelines and templates for desecribing the data model in surrounding text. In practice, however, MIB modules are frequently distributed without the surrounding document text, and operators responding to network problems don't have time to find the right document and read it to understand the model. As a result, the NM community concluded that data models themselves need to be human readable. MIB modules, for example, are read by agent implementers, application implementers, operators, and applicatuon users (e.g., when MIB module descriptions are presented as help files). NM data models are frequently developed by enterprises
Re: WG Review: NETCONF Data Modeling Language (netmod)
Eric Rescorla wrote: I object to the formation of this WG with this charter. While there was a clear sense during the BOF that there was interest in forming a WG, there was absolutely no consensus on technical direction. Rather, a number of proposals were presented, but no strawpoll, hum, or sense of the room was taken, nor, as far as I can determine, has there been any such consensus call been taken on any list I'm aware of. This wasn't an accident--the BOF was explicitly intended only to determine whether some work in this area should proceed, not to select a technical approach. I understand that an approach like this was proposed in the OPSAREA meeting by Chris Newman and then that there was a breakout meeting where it was discussed further. The minutes don't record any consensus call on this combined direction (only strawpolls on the individual proposals), and even if such a consensus call had been held, the OPSAREA meeting would not be the appropriate place for it: this discussion needs to happen in either the BOF (to allow cross-area review) or in the designated WG, when it is formed. I believe there was consensus in the CANMOD BoF that the requirements were sufficiently understood, and the purpose of that BoF had been fulfilled. After the CANMOD BoF, a 15 person design team was formed, which reached consensus on a technical approach, embodied in the charter text. There was also unanimous agreement on the charter, outside the design team (on the NGO mailing list). Accordingly, if this WG is to be formed, the entire section (and corresponding milestones) which specifies the technology needs to be removed. Rather, the first work item should be to select a technical approach. I thought the charter text did specify a technical approach, which is to utilize YANG as a high-level DML and map YANG constructs to DSDL and XSD. Can you explain this work item further? -Ekr Andy NETCONF Data Modeling Language (netmod) Last modified: 2008-04-10 Current Status: Proposed Working Group Chair(s): TBD Operations and Management Area Director(s): Dan Romascanu dromasca at avaya.com Ronald Bonica rbonica at juniper.net Mailing Lists: General Discussion: ngo at ietf.org Description: The NETCONF Working Group has completed a base protocol to be used for configuration management. However, the NETCONF protocol does not include a standard content layer. The specifications do not include a modeling language or accompanying rules that can be used to model the management information that is to be configured using NETCONF. This has resulted in inconsistent syntax and interoperability problems. The purpose of NETMOD is to support the ongoing development of IETF and vendor-defined data models for NETCONF. NETMOD's requirements are drawn from the RCDML requirements draft (draft-presuhn-rcdml) and documents referenced therein. The WG will define a human-friendly modeling language defining the semantics of operational data, configuration data, notifications, and operations. This language will focus on readability and ease of use. This language must be able to serve as the normative description of NETCONF data models. The WG will use YANG (draft-bjorklund-yang) as its starting point for this language. Language abstractions that facilitate model extensibility and reuse have been identified as a work area and will be considered as a work item or may be integrated into the YANG document based on WG consensus. The WG will define a canonical mapping of this language to NETCONF XML instance documents, the on-the-wire format of YANG-defined XML content. Only data models defined in YANG will have to adhere to this on-the-wire format. In order to leverage existing XML tools for validating NETCONF data in various contexts and also facilitate exchange of data models and schemas with other IETF working groups, the WG will define standard mapping rules from YANG to the DSDL data modeling framework (ISO/IEC 19757) with additional annotations to preserve semantics. The initial YANG mapping rules specifications are expressly defined for NETCONF modeling. However, there may be future areas of applicability beyond NETCONF, and the WG must provide suitable language extensibility mechanisms to allow for such future work. The NETMOD WG will only address modeling NETCONF devices and the language extensibility mechanisms. Any application of YANG to other protocols is future work. The WG will consult with the NETCONF WG to ensure that NETMOD's decision do not conflict with planned work in NETCONF (e.g., locking, notifications). While it is desirable to provide a migration path from existing MIB modules to YANG data models (modules), it is not a requirement to provide full compatibility between SMIv2 and YANG. The Working Group will determine which constructs (e.g., conformance statements)
Re: WG Review: NETCONF Data Modeling Language (netmod)
Randy Presuhn wrote: Hi - From: Eric Rescorla [EMAIL PROTECTED] To: ietf@ietf.org; [EMAIL PROTECTED] Sent: Tuesday, April 22, 2008 10:10 AM Subject: Re: WG Review: NETCONF Data Modeling Language (netmod) ... Accordingly, if this WG is to be formed, the entire section (and corresponding milestones) which specifies the technology needs to be removed. Rather, the first work item should be to select a technical approach. ... I think the simplest answer would be to simply publish the work that's already been done and not bother with the IETF. There is simply no value in wasting electrons on battles like this. Sure, some opportunities for technological refinement and building a stronger community consensus migh tbe lost, but that might be a small price to pay in comparison to the time and energy required for all this pointless hoop-jumping. Particularly since the proposed/ draft/standard distinction has become so meaningless, it makes more sense to just publish the spec and ignore the peanut gallery. This 'simple' approach doesn't move standardized network configuration along at all, so it is not my first choice. IMO, there is strong community consensus for the charter as it is currently written. There are several technical approaches, such as 'continue to write data models in XSD' which are technically viable, but have no community consensus at all. I don't think a formal WG process is needed to determine that the strongest consensus exists for the approach currently outlined in the charter. The 15 people on the design team represented a wide cross section of those actually interested in this work. I am among the 10 - 15 people who were not involved in the design team, but agree with the charter. That seems like a lot of consensus for this technical approach. Randy Andy ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IAOC] IETF 72 -- Dublin!
Fred Baker wrote: On Feb 6, 2008, at 9:15 AM, Andy Bierman wrote: However, there are obvious logistical concerns, especially at lunch time. Is 90 minutes really enough time to bus into town, eat lunch, and get back? Lunch is always a problem. That's why we have a sandwich stand - to diminish exactly this concern. If 1000+ people are all trying to get lunch at the same time, a hotel coffee shop and a sandwich stand will probably not cut it. Adjusting the schedule for a 2 hour lunch would be better if traveling was the best option for lunch cost/selection. Andy ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 -- Dublin!
Dave Crocker wrote: Ray Pelletier wrote: The venue will be the beautiful Citywest Hotel, Ireland’s premier Conference, Leisure Golf Resort and one of Europe’s most popular International Conference destinations. The four star Citywest Hotel is only 20km from Dublin airport and 15km from Dublin City Centre. Ray, Every time the IETF has been held in an isolated venue, the experience has been problematic. The descriptions of the venue make clear that, once again, the IETF is meeting in a ghetto. Periodic bus service doesn't counteract that. Can you discuss the priorities that led to choosing an isolated venue again? This choice of venue does not alter my decision process for attending IETF 72 at all. Of course downtown locations are better, but could this be worse than Danvers? ;-) However, there are obvious logistical concerns, especially at lunch time. Is 90 minutes really enough time to bus into town, eat lunch, and get back? Without lots of frequent shuttles, people will be forced to rent a car. I would rather pay a little extra in the meeting fee for shuttles than rent a car for the week. d/ Andy ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
missing drafts
Hi, Several drafts posted on the morning of Feb. 1 are returning '404 not found' errors. These 5 were posted in sequence, at 10:36 AM PT: http://www.ietf.org/internet-drafts/draft-bjorklund-netconf-yang-01.txt http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-scvp-06.txt http://www.ietf.org/internet-drafts/draft-badra-ecdhe-tls-psk-03.txt http://www.ietf.org/internet-drafts/draft-ietf-mip4-generic-notification-message-03.txt http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-15.txt Any others? thanks, Andy ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: joining the IETF is luxury Re: 70th IETF - Registration
Adrian Farrel wrote: We shall see, but I don't know that putting up the price necessarily fixes the registration income issue. You only have to deter a relatively small proportion of attendees to wipe out the increase in charge. I assume that the converse is also being applied: viz. cutting meeting costs. It's hard for us oiks to tell because we only see: - registration fee - breakfasts/cookies Anyway, registration is still the smallest component of attendance for me. Hotel and travel are still bigger problems, and I continue to wonder whether we could increase attendance (and hence registration income) by facilitating cheaper accommodation and travel. It is easy to rationalize away Yao's concerns, especially for old-timers. The overall cost of meeting attendance keeps going up, and $700 to attend the IETF is not a small amount of money. Simple economics tells us that the number of attendees will continue to go down, the higher the costs get. One way to deal with the cost problem is to just ignore it, and focus instead on making IETF week as valuable as possible for as many people as possible. I think there has been a lot of progress in this area (Sunday tutorials, Wednesday beer night, etc. ;-) (I wonder how much the costs would go down if the meeting ended at 4PM Thursday instead of noon on Friday, and there was only one plenary night on Wednesday.) Cheers, Adrian Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Informational vs. Informational
Paul Hoffman wrote: On a thread about a specific document that is proposed to be an Informational RFC coming through the IETF process: At 1:12 PM -0400 8/20/07, Sam Hartman wrote: I've asked the sponsoring AD to make a consensus call on whether we have sufficient support to be making this sort of statement. If not, then I'll be happy to take my document to the rfc editor. This is pointless. No one other than an expert at the IETF process could differentiate between the two types of Informational RFCs in RFC repository (and many IETF process experts would not get it right on the first try). An Informational RFC is an Informational RFC regardless of the path that got it published. RFC 2026, sec. 4.2.2 does not appear to designate two different types of Informational RFCs. Where is this specified in the standards process? --Paul Hoffman, Director --VPN Consortium Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: on the value of running code (was Re: Do you want to have more meetings outside US ?)
Lixia Zhang wrote: .. I think we've seen several examples of where the IETF has spent significant amount of energy, ranging from heated discussions to specification work, on solutions that simply won't fly. It would be useful if that energy waste could be reduced. Having 'running code' as a barrier for serious consideration within the IETF may be one approach. I agree that running code should be given extra weight, but I am not sure that running code should be a requirement for something which is not well understood yet (some Lemonade WG documents come to mind). forgive me for jumping into the middle of a discussion (and I did not know which of the lemonade doc's the above referred to), but my past experience seems suggesting that an attempt to implement a not well understood idea is a good way towards a better understanding of how to make the idea work, or what can be potential issues. yes! I tried to resist the 47th rehash of this thread, but... too late... Within a commercial environment, the organization has to be fairly convinced that their better mousetrap is going to work, in order to fund it, productize it, document it, sell it, and support it. This process will always find more bugs in the mousetrap than simply documenting it and skipping all the other steps. If a vendor bothers to do all this, and multiple IETFers can say in a BoF that they have used the mousetrap and it really does work, that is worth a whole lot more than I read the draft and it looks pretty good. There is a certain amount of healthy risk that the IESG can take when chartering new standards-track work. Prior implementations should not be a gating factor, but it makes their decision much easier when there is objective evidence the mousetrap actually works and it is already being used by the industry. But implementation and deployment are not enough alone. There also needs to be some pre-existing consensus that a standard version could be written and approved by the IETF, and people are willing to work on it. The slogan says rough consensus and running code. It doesn't say rough consensus, then running code. Without running code, there is no deployment. Without deployment, there is no point to this exercise. Andy IMHO, running code gets more credit than is warranted. While it is certainly useful as both proof of concept and proof of implementability, mere existence of running code says nothing about the quality of the design, its security, scalability, breadth of applicability, and so forth. running code was perhaps sufficient in ARPAnet days when there were only a few hundred hosts and a few thousand users of the network. It's not sufficient for global mission critical infrastructure. it seems to me the above argues that running code is necessary, but not sufficient as evidence of a sound design. (well, that is the interpretation; I have not seen anywhere a claim that running code is sufficient, but rather simply to filter out the weed) Lixia ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Do you want to have more meetings outside US ?
JORDI PALET MARTINEZ wrote: Well I was not indicating that, but simple maths can also say so. As it seems that more people is contributing from Europe than from US, it means for more people more traveling time, more time with immigration issues, etc. Probably we could count from 16 to 40 hours per each individual. Those hours can be applied to do more IETF work (it is not necessarily the case, but in any case is time worth saving). I support your desire to have more non-US meetings, but maybe not for the same reasons. There is a certain moral responsibility to fairly distribute the travel costs amongst the existing IETF participants. This has to be balanced with some very practical concerns wrt/ the actual meeting location and facility itself (as the Palmer House Hilton construction workers demonstrated for us). My participation in the IETF is self-funded. The airline flight is not a real factor because I can use FF miles. The hotel is the major cost but I could choose not to stay in the IETF hotel and significantly reduce that cost. (Same for food and beer choices. ;-) The meeting fee is almost the single largest monetary expense for me, and it keeps going up. I would rather the IETF hold sponsored meetings, than the IETF pick interesting vacation spots all over the world to hold meetings. I don't have any complaints with the current 'system'. I just want to meeting fees to be as low as possible, and the locations to be known far enough in advance so some frequent flier award seats are left. Regards, Jordi Andy De: Stewart Bryant [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Sun, 29 Jul 2007 16:04:23 +0100 Para: [EMAIL PROTECTED] CC: ietf@ietf.org Asunto: Re: Do you want to have more meetings outside US ? Do we have any firm evidence that we would get more work done if we had more meetings outside the US? Stewart ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Do you want to have more meetings outside US ?
Brian E Carpenter wrote: I was talking to a couple of people this week about what I consider to be a related issue: the fact that for the two or three wg meetings I'm interested in, there's little point in me being at the meeting for a whole week. What about holding two or three meetings smaller meetings a year for each area, and then just one big meeting for the full IETF? That would bring down the cost of the individual area meetings and therefore the admission fee, make them smaller and therefore capable of fitting into a wider range of hotels, and would likely result in fewer nights of hotel stay for a lot of people. The financial fallacy in that is failing to note that about half the meeting fee isn't used to fund meeting expenses, but to fund continuing operations of the IETF as a whole (secretariat, RFC Editor, etc.) So restructuring the meetings would have to be done in a way that preserves the meetings surplus at about the same annual total as today. I like the idea of trying a different meeting structure instead of, or in addition to, the '2 hour status meeting' structure we have now. It has nothing to do with money, but rather getting work done, by applying the right resources in the right place at the right time. I know all about the cross-participation/review argument. IMO, the ability for a few WGs (or entire area, whatever) to cancel all WG meetings for the area for an entire day and conduct some sort of on-site workshop or design meeting, would actually enforce cross participation. It might actually resemble the Real Engineering practices some of us go through in our 'day jobs'. It should be up to the ADs and the Chairs, and depend on the situation at hand, as to how many hours or even days worth of IETF WG meetings they would preempt for such a meeting. Also, personally, I think that once a year wouldn't be enough to keep the cross-checking between the areas at a sufficient level. And personally, even if I'm only active in two or three WGs, the chance to sample what's going in related and even in unrelated WGs, as well as research groups and BOFs, makes it well worth staying all week. Brian Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
take the train in Chicago
FYI, According to the WEB, it is really easy and really cheap to take the train from the O'Hare airport to the IETF hotel. (I have not verified this info however...) From the airport: 1) Walk east on the terminal 2 CTA Rail Walkway to the station 2) Take the Blue line train southbound (fare $2 USD) 3) After approx. 45 min. ride, get off at the Monroe/Dearborn stop 4) Exit through the Monroe/Adams Mezzanine 5) Walk 1 block east on Monroe St. to the hotel at 17 E. Monroe St. Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: consensus and anonymity
Brian E Carpenter wrote: Combined response: On 2007-05-31 23:07, Andy Bierman wrote: I think the inability of the IETF to make decisions in an open, deterministic, and verifiable manner is a major flaw. It promotes indecision and inaction. I think the ability of some other SDOs to take go/no go decisions on unpublished documents by a fixed deadline, based on corporate voting, is a major flaw. It promotes superfical review and flawed documents. This has more to do with corporate culture and the low priority of 'quality' in the business model. The IETF's reluctance to accurately quantify consensus is a different matter. Making bad decisions on time is not the only other option. On 2007-06-01 01:14, Andy Bierman wrote: I don't understand why such a comment needs to be private. Once the issue comes to light in the WG, it is no longer going to be private. You are assuming the Chair can and should be a proxy for a WG member who wishes to remain anonymous. I disagree. Why is this a problem? Again, our goal is to discover technical flaws (or make technical improvements) in drafts. What does it matter if someone has good reason to request anonymity and to use the AD (or anyone else) as a proxy? This is only a problem as the debate escalates. It is not a problem bringing issues to light. I suppose if the Chair is willing to proxy for both sides of the issue, and make it clear when they are making a comment as a proxy or as a Chair, then it is not an issue. On 2007-06-01 04:09, Henning Schulzrinne wrote: I think a fair vote requires - a clear definition of who can vote Which is fundamentally impossible in the IETF. On 2007-06-01 04:22, Lakshminath Dondeti wrote: Can anyone point to me where it is written that voting at a meeting is the decision making process when rough consensus (hum or whatever) has been inconclusive? There must be something in between humming and corporate voting, which is better than flipping a coin and arbitrarily picking a winner. Definitely, nowhere. But there is a model that has been used where a WG agrees *by rough consensus* to accept an arbitrary decision method when a technical rough consensus cannot be reached. Example: http://www1.ietf.org/mail-archive/web/ietf/current/msg46040.html Brian __ Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: consensus and anonymity
Spencer Dawkins wrote: Just following up here... From: Lakshminath Dondeti [EMAIL PROTECTED] But, I wonder why anonymity is an important requirement. The mailing list verification has at least two properties that are more important to the IETF: the archives provide for anyone to be able to verify the consensus independent of the IETF hierarchy (chairs, ADs and whoever); further the archives provide a means to verify the consistency of any IETF participant, chairs or ADs at any given moment, candidates for WG chair and I* positions, and anyone in general. We've been telling new WG chairs for several years that - they really need to have most discussions in public/on mailing lists, - we recognise that some people aren't comfortable challenging others in public, and - we recognise that this discomfort may be more common in some cultures than in others. So, for reasons that both John and Lakshminath identified, we've been asking WG chairs to encourage participants to engage in public discussions, but to be receptive to private requests for assistance on how to carry out those discussions. The alternative - a WG chair who tells the working group that the apparent WG consensus on the mailing list is being overruled because of anonymous objections that the WG chair cannot share with the WG, or because of private objections that the WG chair is channeling from a back room - would make voting seem reasonable (or, to use Mark Allman's characterization in another thread, seem charming). This is not an alternative. If you are not willing to make your technical objections to a technical specification publicly, then they cannot be part of the IETF decision-making process. What's to prevent a WG Chair from padding the anonymous votes? If 5 people in public (WG meeting or mailing list) are for some proposal, and the Chair says, I heard from 6 people who are against this, but don't want their identities known, so the proposal is rejected. Not acceptable. Thanks, Spencer Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: consensus and anonymity
Michael Thomas wrote: Andy Bierman wrote: Spencer Dawkins wrote: Just following up here... From: Lakshminath Dondeti [EMAIL PROTECTED] But, I wonder why anonymity is an important requirement. The mailing list verification has at least two properties that are more important to the IETF: the archives provide for anyone to be able to verify the consensus independent of the IETF hierarchy (chairs, ADs and whoever); further the archives provide a means to verify the consistency of any IETF participant, chairs or ADs at any given moment, candidates for WG chair and I* positions, and anyone in general. We've been telling new WG chairs for several years that - they really need to have most discussions in public/on mailing lists, - we recognise that some people aren't comfortable challenging others in public, and - we recognise that this discomfort may be more common in some cultures than in others. So, for reasons that both John and Lakshminath identified, we've been asking WG chairs to encourage participants to engage in public discussions, but to be receptive to private requests for assistance on how to carry out those discussions. The alternative - a WG chair who tells the working group that the apparent WG consensus on the mailing list is being overruled because of anonymous objections that the WG chair cannot share with the WG, or because of private objections that the WG chair is channeling from a back room - would make voting seem reasonable (or, to use Mark Allman's characterization in another thread, seem charming). This is not an alternative. If you are not willing to make your technical objections to a technical specification publicly, then they cannot be part of the IETF decision-making process. If that's true, then why do we have hums at wg meetings at all? A hum doesn't give the reasoning; it's a binary quantity. I think the inability of the IETF to make decisions in an open, deterministic, and verifiable manner is a major flaw. It promotes indecision and inaction. What's to prevent a WG Chair from padding the anonymous votes? If 5 people in public (WG meeting or mailing list) are for some proposal, and the Chair says, I heard from 6 people who are against this, but don't want their identities known, so the proposal is rejected. Not acceptable. Dishonesty by the management is a problem regardless of what system we have. Most wg's these days have two chairs, so collusion would need to be at least that deep, and probably require an AD to be on board too. If that really were the case, I doubt any system is likely to perform very well. Only transparency can prevent corruption. But this cultural thing does bug me. It seems unsatisfying to me that our pat answer to cultural differences is become more western. The language issue is already asking quite a lot of the rest of the world. I don't see the cultural bias here. I see the bias in English only, but these are public standards being developed. Everybody in the IETF should be able to read all of the comments made on a draft, not just a privileged elite. Mike Thanks, Spencer Andy Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: consensus and anonymity
Sam Hartman wrote: Andy == Andy Bierman [EMAIL PROTECTED] writes: Andy This is not an alternative. If you are not willing to make Andy your technical objections to a technical specification Andy publicly, then they cannot be part of the IETF Andy decision-making process. At one level I agree here. Andy What's to prevent a WG Chair from padding the anonymous Andy votes? If 5 people in public (WG meeting or mailing list) Andy are for some proposal, and the Chair says, I heard from 6 Andy people who are against this, but don't want their identities Andy known, so the proposal is rejected. Not acceptable. I think that would be unacceptable. I think that a WG chair going to people who expressed private concerns and saying something like Hey, you need to express your concerns in public. They are shared; if all of the people who have these concerns bring them forward then we would have enough interest in dealing with this issue. You have a week, is entirely fine. I also think it is fine for a WG chair to look at private technical concerns, realize they are correct and raise them to the WG. I received a private concern; that mail pointed out that the following trivial attack will break the security of this protocol. We are not moving forward until someone fixes this problem or someone explains why I'm misunderstanding the situation. I don't understand why such a comment needs to be private. Once the issue comes to light in the WG, it is no longer going to be private. You are assuming the Chair can and should be a proxy for a WG member who wishes to remain anonymous. I disagree. It's probably even fine to say I received a lot of private concerns. Are the people willing to make public comments firmly behind their support? I am specifically referring to technical comments. I realize that WG members may have non-technical concerns which are appropriate to convey to the Chair privately. I think the IETF consensus process is severely flawed. Many times I have encountered deadlocks because 3 people are strongly for something, 3 people are strongly against it, and 40 people couldn't care less which way the decision goes. Determining consensus based on hearsay and humming makes matters even worse. --Sam Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: consensus and anonymity
Michael Thomas wrote: Andy Bierman wrote: Michael Thomas wrote: I think the inability of the IETF to make decisions in an open, deterministic, and verifiable manner is a major flaw. It promotes indecision and inaction. Is there any human decision making process that has all of these characteristics? Or that even believes that those are axiomatic? no, but there is some evidence that the IETF does not regularly make timely and effective decisions, relative to the expectations of the participants. IMO, this is due to a flawed process which only works well in landslide decisions. The track record for close or difficult decisions is not very good. Dishonesty by the management is a problem regardless of what system we have. Most wg's these days have two chairs, so collusion would need to be at least that deep, and probably require an AD to be on board too. If that really were the case, I doubt any system is likely to perform very well. Only transparency can prevent corruption. Preventing corruption is not the end product of the IETF. Producing good/useful protocol specs is the end product of the IETF. Thus corruption is just one consideration. Life is messy that way. The end product is a document. The document is a result of decisions made (or punted). The text in the document is fair game for any kind of comment, as long as the comment is made openly for everyone in the WG to consider. If there was an anonymous mailing service, such that people could comment on WG issues without revealing their identity, then how do we know everybody using the service will only make their comment once? What is to prevent them from making the same comment N times, hoping to deceive the WG into thinking the comments represent the views of N people? But this cultural thing does bug me. It seems unsatisfying to me that our pat answer to cultural differences is become more western. The language issue is already asking quite a lot of the rest of the world. I don't see the cultural bias here. Which culture are you from? Kalifornia -- as if that matters. The IETF is not an academic exercise. I have found that people from the academic culture are appalled at how their documents are treated by others in the IETF. In the competitive culture of the IETF, documents are often attacked (or ignored) in ways that are not common in the academic world. This is unfortunate, but not enough of a reason to allow the IETF decision making process to be even more murky and secretive. Mike Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFID (was: identifying yourself at the mic)
Schliesser, Benson wrote: Eric- It sounds like your argument is: We're too incompetent to say our names at the mic, so we're probably too incompetent to use a RFID system. Did I get that right? This sounds like a Rube Goldberg joke, not a serious thread. Could we possibly find a more over-engineered solution to such an unimportant problem? I doubt it. There are so many Process Wonks in the IETF who feel it is their sworn duty to yell State your name please! every time somebody steps to the mike, that I don't think we need to introduce expensive technology into the mix. How much are the IETF meeting fees going to go up to pay for RFID name badges anyway? While I'm certainly not going to defend the competence of every IETF participant, I don't find much merit in that argument. In my (unscientific) first-hand experiences, it seems that most people do manage to wear their nametags at the meeting. And many of the names on those tags are of cultural origins other than my own, i.e. from a non-English speaking country. If I could actually see the name of the person speaking, it seems like a great improvement over hearing a name which is unintelligible to my ears or hearing no name at all. And if somebody forgets their RFID-badge, then I'm no worse off than I am today. In other words, I think we could come up with a system that worked well enough to be a net improvement over our current operational model. On the other hand, I am amused by your idea of scanning the streets for RFID responses that look like IETF-badges. Then my robot army could track down and kill all IETF participants whom oppose my plans to take over the Internet! Or maybe I could just use them for some fun practical jokes instead... Cheers, -Benson Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFID
Jeffrey Hutzelman wrote: On Tuesday, March 27, 2007 02:42:19 PM -0700 Andy Bierman [EMAIL PROTECTED] wrote: There are so many Process Wonks in the IETF who feel it is their sworn duty to yell State your name please! I think it's unfair to call people who do that process wonks or any other derogatory term. Most of them are people who want to know who is speaking. Some of them are people who assume the rest of the room want to know who is speaking, probably don't, and probably don't feel comfortable speaking up and saying so. http://en.wikipedia.org/wiki/Wonk_%28slang%29 According to wikipedia, a policy wonk is someone knowledgeable about and fascinated by details of government policy and programs If that is derogatory then I'm sorry. IMO it is accurate to say there are many people in the IETF that fit this description. that said... I don't think we need to introduce expensive technology into the mix. I very much agree with this. -- Jeff Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFID
Jeffrey Hutzelman wrote: On Tuesday, March 27, 2007 03:51:56 PM -0700 Andy Bierman [EMAIL PROTECTED] wrote: http://en.wikipedia.org/wiki/Wonk_%28slang%29 According to wikipedia, a policy wonk is someone knowledgeable about and fascinated by details of government policy and programs If that is derogatory then I'm sorry. It carries a derogatory connotation. IMO it is accurate to say there are many people in the IETF that fit this description. And I don't dispute that. I just don't think it's appropriate to apply that description to people who say XXX, tell us your name! the third time someone gets up to the mic without saying their name. I find it rather annoying to listen to the constant interruptions, reminding people of the process. The only reasons for such an interruption are: 1) it is very important to you that detailed and accurate minutes record every he said, she said comment made at the microphone 2) you plan to base your opinion of the imminent comment on either who says it or more likely, what company they work for In either case, the interruption is not adding value to the technical discussion. -- Jeff Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFID
Philip Guenther wrote: On Mar 27, 2007, at 8:10 PM, Andy Bierman wrote: ... I find it rather annoying to listen to the constant interruptions, reminding people of the process. The only reasons for such an interruption are: ... 2) you plan to base your opinion of the imminent comment on either who says it or more likely, what company they work for In either case, the interruption is not adding value to the technical discussion. Are you saying that we should not consider reputation when judging the technical soundness of comments? I disagree. I can think of at least three cases in which knowing which person said something will affect my interpretation of a comment. I am saying that the interruption is annoying, and if it is really important to record the speaker's name for the minutes, then post little signs on the microphone that say state your name!. If that doesn't work, then interrupt the person after it is determined that a really important statement has been made and the speaker of those words needs to be identified for the record. Otherwise, being quiet and letting the person finish their sentence would be better than loud and repeated interruptions. Maybe we could get a good DoS attack going in these meetings. Somebody starts to say something important at the mike, but forgets to state their name. Somebody in the back then screams at them to state their name. Person at the mike screams back Stand up and make your comment into the microphone. Person in the back walks to microphone, forgets to state their name, says state your name, but is interrupted by someone in the back yelling You state Your name! :-) Andy 1) When a working group is discussing something involving other WGs or areas (security in an apps group, etc), knowing that a comment came from someone who *is* strong in that area does affect whether I consider it as resolving the question. Hearing TLS can/can't do what you need from a random apps WG chair means something different than hearing it from, say, EKR. For the former, I might ask for details to find whether the person might be thinking of a similar-but-not-quite case, while for the latter I might jump directly to asking for a direct recommendation on where to look next. 2) Whenever someone uses the phrase in my experience, I cannot evaluate their statement without some knowledge of the breadth their experience. While asking the person to describe that would also suffice, it saves a lot of time if people can let their name serve as a placeholder. 3) some people are quite understated in their comments, others more pedantic. Evaluating how strongly held someone's opinion is often involves knowing their style. Philip Guenther ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
John C Klensin wrote: --On Tuesday, 13 March, 2007 16:58 +0100 Simon Josefsson [EMAIL PROTECTED] wrote: Hallam-Baker, Phillip [EMAIL PROTECTED] writes: Arguments on complexity are too easy to make. Every time a proposal is made I hear the complexity argument used against it. Everything we do is complex. Computers are complex. Committee process usually increases complexity somewhat. If an argument can always be used what is the discrimination power? How about using answers to the question Is this complexity needed? as a discriminator? Sometimes, there is no better solution than one with certain complexity. That isn't inherently bad. I'm not sure the need for this particular complex solution was demonstrated. I don't recall anyone defending it. The experimental track thus seems appropriate, if it should be published at all. But that was precisely where the other thread, if I recall, came out. It wasn't an argument against complexity. It was an argument about introducing another optional way of doing things because we _know_ that many options lead to worse interoperability. And it was a suggestion/ request that, before this document was published in _any_ form, that it at least acquire a clear discussion as to when one would select this form over the well-established ASN.1 form for which there is existing deployment, existing tools, etc. Put differently, we all know that this _can_ be done but, if there is another solution already out there, widely deployed, and in active use, a clear explanation about _why_ it should be done and under what circumstances it is expected to useful is in order. That suggestion about an explanation was a specific request about the document, not idle theorizing about the character of ASN.1 or the nature of complexity. And, again, pretending that the discussion didn't occur impresses me as a little strange. I was going to raise this issue, but I deleted the mail when I realized this is going to be an Experimental RFC (according to the subject line). I don't think it harms interoperability to introduce an experiment into the mix. If deployment and useful tools follow, then maybe a later revision can move to the standards track. john Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Protest: Complexity running rampant
Dave Crocker wrote: Fred Baker wrote: is it a bad thing to provide the expressive nature of ASN.1 in a human-readable and popular data representation? The one thing IETF standardization certainly ought to imply is that there is a real constituency interesting in using the specification in the near-term. Who wants to use this spec, now, and why? I almost sent an email asking this question when I read the drafts. My reaction was This seems like a lot of stuff to put on the standards track without being the output of a WG. I didn't, because I figured there must be some significant constituency that wants this standardized. So, is there or not? d/ Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IETF 68 hotel full
Hi, There is only one hotel listed for IETF 68: http://www3.ietf.org/meetings/68-hotels.html There are no more rooms at the IETF rate, and perhaps at any rate. The online form says no rooms are available that week. I'm having trouble finding Pobrezni 1 186 00 Prague 8 Czech Republic with online maps. Does anybody know which hotels are close to the Hilton Prague? thanks, Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF 68 hotel full
Janet P Gunn wrote: IIRC the hotel web site has a map. You could use that to find the names of nearby streets. Really? Where? The one I found didn't have street names. http://www1.hilton.com/en_US/hi/hotel/PRGHITW/directions.do#localmap Janet Andy Andy Bierman [EMAIL PROTECTED] wrote on 12/18/2006 01:37:43 PM: Hi, There is only one hotel listed for IETF 68: http://www3.ietf.org/meetings/68-hotels.html There are no more rooms at the IETF rate, and perhaps at any rate. The online form says no rooms are available that week. I'm having trouble finding Pobrezni 1 186 00 Prague 8 Czech Republic with online maps. Does anybody know which hotels are close to the Hilton Prague? thanks, Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF 68 hotel full
Andrew G. Malis wrote: You're much better off following this link (but I think you have to use Internet Explorer for it to work): http://local.live.com/default.aspx?v=2cp=50.09292~14.437961style=rlvl=17tilt=-90dir=0alt=-1000rtp=null~null http://local.live.com/default.aspx?v=2cp=50.09292~14.437961style=rlvl=17tilt=-90dir=0alt=-1000rtp=null~null You can very easily see the Hilton. thanks. Somebody sent me a private email and said Friday (3/23) was sold out at the hotel. When I used the online form (and called the 800#), I was trying to checkout on 3/25. When I entered 3/23 as the checkout date in the online form, I was able to get a room at the IETF rate. Cheers, Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
Hallam-Baker, Phillip wrote: From: Keith Moore [mailto:[EMAIL PROTECTED] that's my understanding also. but nothing you said here contradicts my statement. if connection of the host to the network is predicated on having the host conform to whatever arbitrary policy the network wishes to impose on how the host is configured, then it's unreasonable. So what if it is unreasonable. My network, my rules. If you don't like them go to the nearest Panera and use their free WiFi. If you want to connect to my network, my rules apply. That's not arbitrary, that's my right and my choice. I'm unclear on what host requirements NEA is proposing to add. The reality is that I have about 2 giant corporations to choose from for Internet connectivity where I live. I don't want either one of them installing mandatory software on my computers that denies access to the Internet if any unapproved applications are found. I would rather decide which applications I get to run, and if the ISP chooses to firewall certain protocols, then fine. Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Eliot Lear wrote: Andy Bierman wrote: I don't agree that this is low-hanging fruit. The server component of this system seems like a wonderful new target for DDoS and masquerade attacks. Well, first of all I don't see why this is any different than a radius server. In fact it could be that the access box forwards information in a very similar way. But let's say that it doesn't work that way just for yucks. Another approach is that the clients themselves must have a server on them and the queries go the other way. In this case the server need only check either a source address or a transaction ID. Furthermore, there is no reason for clients outside of that AS to have access to that server, so it's a good candidate for an ACL. Of course this creates a risk of attack on the clients themselves, which brings me to one of my greater concerns: In many of the mechanisms that communicate between client and network we are not finding good ways to prove the legitimacy of the service to the client. This is an area that perhaps it would be good to get the IRTF to work on. My comment was on Harald's characterization of this work effort as 'low hanging fruit'. IMO, that term is reserved for huge gains for very little effort. I don't think that is the case here. Eliot Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Harald Alvestrand wrote: A typical NEA case (taken out of what Cisco's NAC is supposed to be good for): - Worker goes on holiday, takes laptop - New attack is discovered that exploits a newly discovered Windows vulnerability - Patch is created, distributed and installed - NEA posture requirement is increased to must have patch - Worker comes back, plugs in laptop Without NEA-like functionality: - Worker is admitted - Worker gets attacked compromised - IDS other alarms go off - Remediation efforts do what they usually do With NEA: - Worker gets sandboxed - Worker gets upgraded - Worker gets admitted - No compromise, so no remediation No ill intent on the part of any participant (except the attacker). Just a TCO issue. The fact that some fruit is low-hanging doesn't mean it's not worth picking. I don't agree that this is low-hanging fruit. The server component of this system seems like a wonderful new target for DDoS and masquerade attacks. Harald Andy Alan DeKok wrote: Brian E Carpenter [EMAIL PROTECTED] wrote: What if your contractor has carefully configured the laptop to give all the right answers? What if it has already been infected with a virus that causes it to give all the right answers? Yes, that's a problem with NEA. No, it's not a problem for many (if not most) people using NEA. The people I talk with plan on using NEA to catch the 99% case of a misconfigured/unknown system that is used by a well-meaning but perhaps less clueful employee or contractor. The purpose of NEA is to enhance network security by allowing fewer insecure end hosts in the network. No one can prevent a determined attacker from getting in. But by providing fewer hosts for him to attack, the attacks become less feasibly, and more visible. Alan DeKok. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Proceeding CDs
IETF Administrative Director wrote: The IAOC is preparing the 2007 budget and would like feedback on whether or not to continue producing the IETF meeting CDs of the Proceedings. It has been suggested as a way of employing limited Secretariat labor more productively that the IAOC discontinue production of the Proceedings on CDs and, instead, make the files available collectively on the web site for each meeting in a zip file for downloading. Is there strong rationale for maintaining production of the CDs? No. IMO, free online retrieval of IETF proceedings is sufficient. Spend the time and money on something more important. My 2 cents on data format: If I really wanted to have a CD of the proceedings, then I would want to retrieve a .iso file from the archive. (Moving from the Print Era to the Electronic Age is hard... I just recycled my collection of paper IETF proceedings a year ago. I bet some of you still have every one!) Ray Pelletier IAD Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Its about mandate RE: Why cant the IETF embrace an open Election Process
Hallam-Baker, Phillip wrote: From: Nelson, David [mailto:[EMAIL PROTECTED] I think NOMCOM is like a Representative Town Meeting, in which the representatives are chosen by a random selection process, rather than by election. The outcome, which supports in-depth consideration and substantial, informed debate, is much the same. The NOMCON process is certainly grounded in academic theories of governance that were popular in the 80s. Many of them attempt to provide a practical implementation of Rawl's theory of justice. The problem I see is NOT who gets elected but the lack of authority and mandate. The reason that the time spent on NEWTRACK was wasted is that nobody feels that they have a mandate to change anything. As a result the IETF is a standards body with 2000 active participants that produces on average less than 3 standards a year and typically takes ten years to produce even a specification. I think Quality and Timeliness are real problems (unlike this one), but the IETF output is much better than you suggest, and IMO it is improving. I do not want NOMCOM to be replaced by an election process. I want dedicated volunteers to continue the in-depth selection process. I have no faith whatsoever that the community-at-large would put any significant effort into an election process. I am concerned that financially motivated companies would abuse the election process to gain more control of the IETF. Then massive efforts would be needed to fix the new mess. Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Fwd: IETF Process discussions - next steps]
Brian E Carpenter wrote: I was quite surprised to discover that this message is not in the mailing list archive, so I am repeating it. A copy certainly reached the newtrk WG prior to its closure. Original Message Subject: IETF Process discussions - next steps Date: Thu, 10 Aug 2006 11:41:47 +0200 From: Brian E Carpenter [EMAIL PROTECTED] Organization: IBM To: IETF discussion list ietf@ietf.org Here are my conclusions from the plenary discussion and the General Area open meeting at IETF 66. 1. Conclusions from plenary discussion on Newtrk issues (draft-carpenter-newtrk-questions-00.txt) IMO, there are IETF-wide and area-wide standards-track advancement issues are varying importance. I think each AD should at least consider (and hopefully write down) what the advancement policy is for their area. For example, we have learned through experience that advancement of MIB modules is quite problematic, even though it is very straight-forward to define and evaluate the interoperability requirements. Vendors have been rather reluctant to respond to implementation surveys. (This isn't that surprising, since SW engineers usually have to fill out the surveys, and we hate to write documentation :-) Even when this seemingly harmless survey is returned, many respondents say they don't believe this effort is of any value. So the reports are inaccurate and difficult to obtain. Worse yet, decisions to keep or deprecate MIB objects are based on these reports. In the Entity MIB WG, we actually found our efforts to deprecate some MIB objects (per SOP) during advancement to be harmful to interoperability. I believe we now have an unofficial don't ask, don't advance policy. That is, the WG Chairs won't attempt to advance RFCs containing MIB modules beyond Proposed Standard anymore, and the ADs won't ask them to do so. Yet, I believe there is some value for operators to know the difference between a mature MIB module like RMON-MIB and the first version of a MIB module like RAQMON-MIB. The SMI sort of provides that info, but not very clearly to non-experts. Andy A clear theme in the plenary discussion in Montreal was declare victory. Unfortunately, in reading the notes and listening to the audio recording, and reading subsequent emails, it is also clear that different speakers meant different things by this phrase - anywhere from clarifying today's standards track, through reducing it to two or one stages, to simply sitting down and shutting up. Although on the order of 40 people out of several hundred in the plenary appeared to believe that formal changes to the standards process should be made, and some people are ready to do work (thanks!) there was no firm consensus for a given direction (as there never has been in the Newtrk WG). One useful observation was that there is nothing in present rules and procedures to prevent the writing and publication of overview standards documents (ISDs in Newtrk parlance), as long as they fit into RFC 2026 rules as Applicability Statements. A need was observed for lightweight documentation of the real world deployment status of individual standards, as concrete feedback from running code. Again, no rule prevents this today, but neither do we have guidelines as to the format, status and indexing of such documents. My conclusions are that: 1.1. There is insufficient pressure and energy in the community to justify the effort of reaching consensus on formal changes to the standards process at this time. 1.2. For complex standards where a normative or informative overview document would be beneficial, nothing in today's rules and procedures prevents interested parties from writing and submitting such documents within the rules set by RFC 2026, and such efforts should be welcomed. 1.3. The community should be encouraged to produce documentation of deployment and interoperability of individual IETF standards, even if there is no proposal to advance them on the standards track. Such documents should be directed towards efforts to update IETF standards and/or to document errata and operational issues. A more systematic framework than today's implementation reports would be beneficial. 1.4. The newtrk WG should be closed. 2. Conclusion from GenArea mini-BOF on IESG structure and charter. It seemed clear in the room that people felt there was not a serious enough problem with RFC 3710 to justify a significant effort. There was some support for undertaking at least the first step: * List Tasks that Currently Gate on the IESG in order to document whether there is in fact a problem worth solving. My conclusion is to ask John Leslie to lead a small team to carry out this very specific task for the information of the community. 3. Conclusion from GenArea mini-BOF on WG Procedures (RFC 2418) It seems there is some feeling that the RFC is beginning to show its age, and would be worth updating. My conclusion is that the best first step is to ask Margaret
Re: RFC Editor RFP Review Request
todd glassey wrote: So let me ask the obvious thing... why is the RFP content being voted on? This is a business decision in regard to services and process. Why is any of it open to review inside the IETF? Because the lunatics want to run the asylum? ;-) Seriously though, it seems to me that most people agree with us, and want to let the IAD and IESG do their jobs, and stop all this obsessing over every detail of our Process. How about if we get that quality and timeliness thing under control before spending a lot of time agreeing on the 427 most important factors in selecting IETF meeting locations? (Just my $0.02. OK, maybe it's the whole dollar :-) Todd Andy - Original Message - From: John C Klensin [EMAIL PROTECTED] To: Ted Hardie [EMAIL PROTECTED]; Jeffrey Hutzelman [EMAIL PROTECTED]; Allison Mankin [EMAIL PROTECTED]; IETF Administrative Director [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; ietf@ietf.org Sent: Wednesday, July 26, 2006 2:56 PM Subject: Re: RFC Editor RFP Review Request --On Wednesday, 26 July, 2006 13:58 -0700 Ted Hardie [EMAIL PROTECTED] wrote: At 3:28 PM -0400 7/26/06, John C Klensin wrote: The other is that, to some readers, it appears to impose binding requirements on how the RFC Editor deals with input from the IESG, either directly (as in if we recommend that this text be inserted, you must insert it or not publish) or indirectly (as in if you don't follow our recommendations, we will see to it that your funding is cut off). For those of us who believe that it is important to the Internet that the RFC Editor function as an independent, cooperating, entity rather than as a subsidiary of the IETF, that level of requirement is not acceptable (that consideration is the source of this discussion about aspects of the RFP and what should, or should not, be in it). While the IETF can attempt to establish links to particular funding sources and apply leverage that way (which some of us are trying to discourage), it is also beyond the ability of the IETF to give itself the authority to impose such requirements directly, any more than approval of a document as an IETF Standard can force someone to conform to it. I don't agree with this understanding, but I appreciate your taking the time to clarify it. The imposition of binding requirements you cite above is, from my way of looking at it, instead a description of how the two cooperating entities cooperate. Putting descriptions of that kind into the RFP (or, rather, references to them) is useful for a potential respondent so that know what timelines and level of external, unpaid effort to expect from the IETF. Other ways around this seem to have their own headaches. For example, requiring the publisher of the independent stream to establish that a document does not inappropriately usurp an unregistered standards-dependent IANA namespace or reserved protocol bits would otherwise take the time and talents of the publisher's review teams. That slows the stream or increases costs in a different way. Then I think we are more or less on the same page. The challenge now is to get the RFP to appropriately reflect that shared understanding. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: LA - San Diego transportation (Was: Re: Meetings in other regions)
Dave Crocker wrote: Clint Chaplin wrote: One data point: IEEE 802 is in San Diego this week, and I've met at least one attendee who flew through LAX to get here; that is, he took LAX - SAN as his last leg. the flight is so short, one can feel guilty taking it. however the effort to rent a car from an airport, drive through Southern California traffic, and then either have the car sit for a week or try to dump it upon arrival, all make taking that short flight a reasonable choice. First, I want to clarify my original mail. I meant that if you live in LA, it doesn' pay to fly to San Diego. It's way faster and cheaper to drive your own car there instead of flying. Second, remember that the San Diego location is not close to very many good dining and drinking spots, so having a car at the next IETF will be useful. Third, renting a car in LA and driving is a really bad idea (instead of getting a free connecting flight) unless you want to visit LA or the area between LA and San Diego while you at the next IETF. (Trust me, if you have never been to Laguna Beach, go there if you want to see what SoCal is really like.) d/ Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meetings in other regions
Marshall Eubanks wrote: Nobody flies from LAX to San Diego because it ends up taking twice as long as driving for 10 times as much, so don't expect lots of flights from LA. For visitors, you might want to fly to LAX, rent a car, drive down the 405, and take a detour to the Laguna Beach area on the way down (or back) for a little vacation time. BTW, 3 comments on some real topics: - Meeting location is a minor factor for me when I go to the IETF meeting. Whether or not I have active drafts in WGs (author or chair) is the gating factor whether I go to the IETF at all, regardless of where it is located. - I strongly support Fred Baker's notion of location fairness, just as I did when Fred was IETF Chair. - I didn't find a terminal room, but instead a giant 'break room' for ad-hoc meetings and food breaks. This was wonderful, and about time! 802.11 has thankfully made the terminal room obsolete. I want this format every time. Please consider 2 enhancements: - A/C around the perimeter for laptop power - beverages available (at least pitchers of water) all day Andy On Jul 17, 2006, at 8:45 AM, Marshall Eubanks wrote: Hello; On Jul 17, 2006, at 8:21 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: John C Klensin wrote: It also means such things as: * picking places within those countries or regions that have good airports with easy (and multiple) international connections. Even San Diego is a little marginal in that regard. Based on experience in the last year or so, I'd suggest that Cape Town and Marrakech (suggested in another posting) should be utterly disqualified (although J-berg and Casablanca are more plausible on this dimension). Some data about San Diego: Today, the flight information page on San Diego International Airport web site shows a couple of flights to/from Mexico and a couple to/from Canada -- all the others are within US. When meeting in North America, I would strongly prefer cities that have several direct flight connections from both Europe and Asia. Of the recent IETF meeting places, San Diego is the only one that clearly fails this criteria... so why are we going there again? Even direct flights within the US can be hard to find. Depending on where you are coming from, and when you purchase your tickets, you may find it faster / cheaper / better to fly to LAX or Long Beach and drive down to San Diego. (LAX - San Diego is ~ 200 km, and LAX is basically on the San Diego Freeway.) I did this for the one San Diego IETF. s/the one San Diego IETF/the one San Diego IETF I attended/ Sorry for the typo Marshall If you do that, be aware that there is a permanent immigration checkpoint on the San Diego freeway Northbound, which can cause backups returning. Regards Marshall Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Author Count and IPR
David Harrington wrote: If I remember correctly, we only limit the number of suthors on the first page of the document. It is perfectly acceptable to list a longer set of names inside the document in an contributors section. It's not just the first page. It also affects the reference citation used in the RFC Index and all other RFCs. I believe the 5 author rule was used as justification to remove most of the original SNMPv2 authors from the author list and all further reference citations, when the RFC 1901-1909 series was advanced. I don't really understand what purpose this serves. I also have concerns about who should be listed as an author and have copyrights when a work is developed by a WG. The demand to do things with IETF documents beyond IETF standards work seems to be growing, so it will be an increasingly difficult problem if we do not identify all the people who contributed significant portions of a document (where significant is of course open to debate). There is a problem with companies piling on the authors for I-D proposals to make it look like lots of people worked really hard on it and all agree on the contents. (This is hardly ever the case.) Then when you go to WG draft, there are already 5 or 7 names as authors, and the WG wants to add more. I think then, you have to pick a real Editor (responsible for all edits all the way through AUTH48) and just list that person as Editor on the first page and citations, and put everybody in the Authors section in the back. IMO, this is different than removing the author(s) of a previous version of an RFC. I object to that practice. dbh Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: About cookies and refreshments cost and abuse
Stewart Bryant wrote: In Paris, we switched to a late dinner which was necessary in Paris but we did this in Dallas. Was this a general decision that I missed? I prefer dinner from 6 - 8 and a night session where the local customs support this. This might also cut down the need for afternoon sugar consumption. I normally fly in from Europe and strongly prefer the later dinner - not because I like late dinners - but because I prefer to have the sessions before I fall asleep with jet lag. I heard this comment in Dallas from several people. It works in reverse when I fly to Europe from California. (I'm ready to start WG meeting at 4am :-) I think one's opinion of the new schedule has more to do with whether you had any night sessions to attend that your country of origin. If you go to any night sessions, the old schedule is awful. If not, you don't care so much. - Stewart Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meeting format (Re: Moving from hosts to sponsors)
Brian E Carpenter wrote: Andy, As I hope everybody knows, about 60% of the IASA budget comes from meeting fees, and we must make enough surplus on the meetings to fund the secretariat. So, if we did decide to change the nature of any of our meetings, we'd really have to understand the budget implications. That being said, we should certainly explore alternatives to the present way of doing things. My own experience as a WG chair is that interim meetings are highly effective when starting out on a new effort and consensus has to be reached on fundamentals. I'm less convinced that longer meetings are useful when refining complex documents - that is when editorial teams and issue trackers seem to be effective. As I said the other day, cross-fertilization remains important. It's hard to imagine how we could run multiple in-depth meetings in parallel without losing cross-fertilization. Maybe we could experiment with a meeting with one day (out of 4.5) dedicated to 7 in-depth WG meetings, and the other 3.5 days traditional? This would be great. If we could get the sponsors who who have paid for the entire interim meeting costs somewhere else chip in, the the IETF could extend room and network services until 8 PM Friday, and we could have Interim Friday. This would have the least impact on regular IETF activities. Since only dedicated people show up to interims anyway, holding them on Friday won't impact the masses in the slightest. Of course, you would need volunteer WGs who even want to have a 1 day interim instead of a 2 hour slot in Montreal. (NETCONF WG volunteers right now ;-) (IMO, BOFs should be early in the week, not on Friday. Cross-area review of new ideas is just as important as anything else.) Brian Andy Andy Bierman wrote: Harald Alvestrand wrote: Andy Bierman wrote: Ray Pelletier wrote: ... A more workable model would be to treat the current type of meeting as an Annual Plenary, full of Power-Point laden 2 hour BOFs, and status meetings of almost no value in the production of standards-track protocols. The other 2 IETFs would be Working Group Meetings. Essentially, this as a collection of WG Interim Meetings. WGs meet for 1-3 days and mash through documents and get them done fast. Decisions validated on the WG mailing list within 2 weeks of IETF Friday. are you seeing these as meetings of *all* WGs, or do you envision multiple meetings, each with some subset of WGs? If (guesstimate) 50 of 120 WGs decide to meet in this format, the number of parallell tracks at one monster meeting will run between 15 and 30. There would need to be lots of overlap. Lots of preparation for joint-meetings would be needed. Not everybody can work on everything at once. (More accurately, most people won't be able to read email while ignoring the meeting in as many WGs. ;-) Meeting slots would be divided into 3 categories, times, allocations, and proportions decided by the IESG. - WG - intra-area - inter-area This might even lead to more shared work, more cross area review, more consistency. You know -- proper Engineering. (Maybe we have way too many WGs. That problem is out of scope here.) It should take 1 year to get a standards-track RFC out the door. Not 6+ years. The solution is obvious. Quit messing around and get some work done. This turtle pace has got to end. Interim meetings should not be a almost-never way to get work done. Any IETF veteran knows it's the only way anything gets done around here. I'm intrigued by the idea of replacing one or more IETF meetings with large interims, but would like to work through exactly what's being proposed. (Of course, scheduling 2 years out DOES interfere with quick experiments) The meeting slot allocation (General Agenda) is set in stone 30 days in advance of IETF Sunday. BOF agendas are due 30 days in advance of IETF Sunday. WG agendas are due 15 days in advance of IETF Sunday. No exceptions. and cancellation on those WGs who do not provide such agendas? Just checking Remote audio and jabber for all meetings of course, and better remote meeting participation tools over time. If the meeting fees could be lowered over time because smaller venues are needed 2 out of 3 IETFs, then more people will be able to participate. The meeting fee represented 41% of the total cost of my attendance to IETF 65. IMO, sponsors at the Plenary meeting would be appropriate, and could help the IETF fund a cheaper, more stable, IETF-controlled, conference. My cost for this meeting (VERY rough, off the top of my head): - Hotel: 800 dollars - Food: 400 dollars - Airfare: 1200 dollars - Meeting fee: 550 dollars - Misc: 50 dollars Total: 3000 dollars. Meeting fee percentage: 18%. But we've been around the how much does the meeting fee matter bush before. Next time I go to Europe instead of US, our expense ratios will be reversed. These 2 data points aren't meaningful. Cheaper is better, and how
Re: 2 hour meetings
Brian E Carpenter wrote: Thanks to Keith for changing the Subject when changing the subject. I know you've heard this all before, but it's been getting increasingly difficult for us WG Chairs to get all the key people working on a protocol to fly across the planet for a 2 hour meeting. These are busy people who can't afford to block out an entire week because they don't know when or where the 2 hour meeting is going to be. (This even applies to some WG Chairs ;-) Andy, you've heard _this_ before, I'm sure: the reason we do IETF weeks with many WGs in one place is to foster cross-fertilization, and to strongly encourage people to become aware of work in other WGs and other Areas that may impact their own topic. There are very few cases of WGs that can safely work in isolation from the rest of the IETF. We're all busy, but missing out on what's happening elsewhere is a good recipe for getting unpleasant late surprises when a draft finally gets a cross-area review. If somebody comes to the IETF for a two hour meeting and wastes the opportunity of another 30+ hours of learning about what other WGs and BOFs are up to, that would indeed be a shame. I understand that is a goal of IETF participation for some people. IMO, the people who can help the most on development of a particular protocol are not doing that. The current solution is for progress-conscious WGs to hold interim meetings, which seem to be discouraged, and certainly increase travel cost for most to participate. I do not envision a WG Interim IETF to be a regular IETF, except people read email all day in 1 WG instead of 5. Cross-area review is a reactive process. A cross-area interim design meeting is a proactive process, that encourages better design reuse, consistency, and robustness. I think some joint-WG interims, intra-area planned project development meetings, inter-area interims are important. The IESG would need to prioritize the meeting slot usage as always. It would be awesome if the key people to answer an unexpected question that comes up in an interim just happen to be in the building for a different interim. We would get much more cross-area review in the design phase, where it does the most good. We could have every 3rd or 4th IETF be work-focused instead of cross-review focused. We could try it once. Or we could do nothing and just accept the slow pace of progress, and the cost of WG interim meetings. Brian Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: 2 hour meetings
Edward Lewis wrote: At 15:51 +0100 3/25/06, Brian E Carpenter wrote: If somebody comes to the IETF for a two hour meeting and wastes the opportunity of another 30+ hours of learning about what other WGs and BOFs are up to, that would indeed be a shame. I agree with this, but find that (in some instances) that meetings are run counter to this goal. I sat in an session outside my area of experience and heard this from the first speaker, if you haven't read the drafts, you shouldn't participate here. Therefore I will not have slides and dive into the details. As this was outside my area of experience, I had not taken the time to read up on the session. I figured that having scribed for it at the previous meeting would give me enough cover. Before each speaker in that session, the question who has read was asked, with few hands going up each time. It would be far more helpful to try to be inclusive rather than exclusive towards us tourists. If the IETF wants to foster cross-fertilization, which is the reason for the mass enclaves, then temper the theme of you must have read all the drafts. Temper, not remove. Taking a few moments to set the problem up for the uninitiated and then assuming they have the protocol engineering smarts is all I'm asking. IMO, the purpose of a Working Group meeting is to gather people together to work. If 40 out of 45 people come to the meeting totally unprepared to work on the stated agenda, then don't be surprised if you don't get any work done. The purpose is not to explain the entire draft to tourists with slideware. If the purpose of all our face to face meetings is to foster cross-area review and not for WGs to get any work done, then I guess this is not a problem. IMO, 1 out of 3 of these non-work-oriented meetings would be plenty, and 3 out of 3 is clearly harming productivity. Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Moving from hosts to sponsors
Henning Schulzrinne wrote: Indeed. Not only is it small, it isn't where corporate bean counters put their attention, which is air fare, hotel, and per diem. Brian, this is not universally true. With cheaper air fares and not staying in the overpriced Hilton hotel rooms, my IETF65 meeting fee was almost exactly the same as my combined hotel and air fare costs. For those of us not on corporate expense accounts, it's the total amount that matters. Sometimes, people even use frequent flier miles, double up in rooms, and don't eat every meal in an over-priced restaurant, just to attend an IETF. (Not me, but some people ;-) For people paying their own way, the meeting fee is the only fixed cost in the trip. It's expensive already, and trending upwards (not expensive if you stay all 5 days, but some of us don't). I guess I was just wishing out loud when I said maybe the meeting fee could trend down instead of up. I would be happy if the IETF had more control over the meetings so the fees were stable, the network was stable (use sponsor money to buy more gear and let our ace NOC team control it), and the venues were set far enough in advance to give me the maximum travel options. The old single sponsor system isn't working anymore. I'm concerned the IETF will fix the problem by raising the meeting fee $50 every 6 months. Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Moving from hosts to sponsors
Marshall Eubanks wrote: I think that the IETF neglects (or, rather, has neglected in the past) many possible opportunities for sponsorship. That implies that increasing the income from sponsorship should be possible. People who are concerned with this issue should talk (or email) our IAD, Ray Pelletier, who has a number of ideas in this area (and who reads this list). If people feel that some sorts of sponsorship are not appropriate, I am sure that Ray would like that input too. In the new IASA / NeuStar system, there is no choice but to be realistic with cost figures. Note that the registration fee and the attendance both went up with this meeting, which of course means that revenue increased. I actually think that, with revenue and sponsorship both increasing, the IETF should be able to improve the meeting support and experience even more in the future. I know you've heard this all before, but it's been getting increasingly difficult for us WG Chairs to get all the key people working on a protocol to fly across the planet for a 2 hour meeting. These are busy people who can't afford to block out an entire week because they don't know when or where the 2 hour meeting is going to be. (This even applies to some WG Chairs ;-) I would support any plan that will make meetings cheaper and easier to attend for everybody. I'd like quick action, not a 2 year study to think about it. Regards Marshall Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Moving from hosts to sponsors
JORDI PALET MARTINEZ wrote: I don't think the meeting fees could actually go down, may be more in the other way around if we are realistic with the cost figures. Actually the cost is already high for a sponsor, and I believe trying to get more from the industry (or other kind of sponsors) for each meeting will be really difficult. IMO, the current trend and situation is not sustainable. It may be fine for professional standards attenders, but I'm trying to get some people to show up in my WG who actually write code and run networks for a living. They don't want to come here anymore. Regards, Jordi Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meeting format (Re: Moving from hosts to sponsors)
Harald Alvestrand wrote: Andy Bierman wrote: Ray Pelletier wrote: ... A more workable model would be to treat the current type of meeting as an Annual Plenary, full of Power-Point laden 2 hour BOFs, and status meetings of almost no value in the production of standards-track protocols. The other 2 IETFs would be Working Group Meetings. Essentially, this as a collection of WG Interim Meetings. WGs meet for 1-3 days and mash through documents and get them done fast. Decisions validated on the WG mailing list within 2 weeks of IETF Friday. are you seeing these as meetings of *all* WGs, or do you envision multiple meetings, each with some subset of WGs? If (guesstimate) 50 of 120 WGs decide to meet in this format, the number of parallell tracks at one monster meeting will run between 15 and 30. There would need to be lots of overlap. Lots of preparation for joint-meetings would be needed. Not everybody can work on everything at once. (More accurately, most people won't be able to read email while ignoring the meeting in as many WGs. ;-) Meeting slots would be divided into 3 categories, times, allocations, and proportions decided by the IESG. - WG - intra-area - inter-area This might even lead to more shared work, more cross area review, more consistency. You know -- proper Engineering. (Maybe we have way too many WGs. That problem is out of scope here.) It should take 1 year to get a standards-track RFC out the door. Not 6+ years. The solution is obvious. Quit messing around and get some work done. This turtle pace has got to end. Interim meetings should not be a almost-never way to get work done. Any IETF veteran knows it's the only way anything gets done around here. I'm intrigued by the idea of replacing one or more IETF meetings with large interims, but would like to work through exactly what's being proposed. (Of course, scheduling 2 years out DOES interfere with quick experiments) The meeting slot allocation (General Agenda) is set in stone 30 days in advance of IETF Sunday. BOF agendas are due 30 days in advance of IETF Sunday. WG agendas are due 15 days in advance of IETF Sunday. No exceptions. and cancellation on those WGs who do not provide such agendas? Just checking Remote audio and jabber for all meetings of course, and better remote meeting participation tools over time. If the meeting fees could be lowered over time because smaller venues are needed 2 out of 3 IETFs, then more people will be able to participate. The meeting fee represented 41% of the total cost of my attendance to IETF 65. IMO, sponsors at the Plenary meeting would be appropriate, and could help the IETF fund a cheaper, more stable, IETF-controlled, conference. My cost for this meeting (VERY rough, off the top of my head): - Hotel: 800 dollars - Food: 400 dollars - Airfare: 1200 dollars - Meeting fee: 550 dollars - Misc: 50 dollars Total: 3000 dollars. Meeting fee percentage: 18%. But we've been around the how much does the meeting fee matter bush before. Next time I go to Europe instead of US, our expense ratios will be reversed. These 2 data points aren't meaningful. Cheaper is better, and how much it matters varies widely between people. Harald Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Moving from hosts to sponsors
Dave Crocker wrote: Michael StJohns wrote: What I think Jordi is saying is that he wants the US sponsors to subsidize the cost of the overseas meetings. At least that's what it works out to be This view can be mapped to a classic model that would have significant benefits for the IETF: A host gets all sorts of marketing leverage out of the role in producing an IETF. There is nothing that requires that the event site management effort be coupled with a particular host's venue. If we moved to a model of having companies provide sponsorship funds, in return for which they get appropriate marketing presence, then we could have meeting venue management move to the sort of predictable and timely basis -- ie, far enough ahead of time -- that has been a concern for many years. Amen! And maybe the meeting fees could actually go down with enough sponsors. An additional room like the terminal room (not out in the open) could be used. Also, the IETF could maintain control of the network if there were multiple sponsors instead of a single host. They would not be allowed to ignore the advice of the NOC team, and let the wireless meltdown right off the bat. d/ Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Stephane Bortzmeyer wrote: On Sun, Mar 19, 2006 at 12:42:17PM -0800, Ned Freed [EMAIL PROTECTED] wrote a message of 35 lines which said: The privileged port concept has some marginal utility on multiuser systems where you don't Joe-random-user to grab some port for a well known service. had, not has. The concept was invented at a time where multi-users machines were rare and expensive monsters. So, a request coming from source port 513 probably was serious. Today, any highschool student is root on his PC and therefore this protection is almost useless. But does that student have access to the root account on servers which are part of the networking infrastructure? Who cares if Joe User blows up his own config. on a PC that nobody else depends on but Joe? I find the argument flawed -- that because Joe User can be root on his own PC, the concept of privileged access to shared system-critical infrastructure is somehow obsolete. Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: too many notes -- a modest proposal
Anthony G. Atkielski wrote: Andy Bierman writes: I think you missed my point. I should have said enforce or abide by draconian rules. Automating the process is even worse. Then stupid scripts disrupt WG activity on a regular basis. Inappropriate mailing list use should be dealt with by the WG Chair(s) in a more diplomatic manner. Well, one option is to stop trying to restrict access to lists to begin with. The problem with having a human being make the decision is that human beings are notoriously biased. If we did this, our mailing lists would be bombarded with SPAM from non-subscribers. There is an appeals process (of that we are too painfully aware) that can be used for people who are told by a WG Chair that they are using the mailing list in an inappropriate manner, and still insist on continuing their behavior. I have found that only the worst managers deal with bad apples by burdening the entire group with oppressive rules. Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: too many notes -- a modest proposal
Steve Silverman wrote: It seems to me that limiting users to 3 messages / day (perhaps with a maximum number of bytes) would be a minimal impact on free speech but would limit the damage done by overly productive transmitters. This could be limited to users who are nominated to a limit list by many users. How difficult this would be to implement on the message exploders is another question. I do not share your regulatory zeal. As a WG Chair and WG participant, I have enough rules to follow already. The last thing I want to do is count messages and bytes, and enforce draconian rules like this. Steve Silverman Andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Michael Thomas Sent: Wednesday, January 25, 2006 3:26 PM To: IETF Discussion Subject: too many notes -- a modest proposal It seems to me that a lot of what causes working group lists to melt down is simply the volume of traffic -- usually with plenty of off-topic banter, or exchanges of dubious value, with the resulting conjestive collapse of our wetware buffering. On good days, the drop algorithm may be more sophisticated than tail drops; on bad days... Perhaps we should take a lesson from TCP and set a receive window on IETF mailing lists in the face of conjestion. The sender is thus obligated to keep the transmission within the window, and as a side effect to consider the quality of the, um, quantity. Just this simple step would greatly limit (purposeful) DOS attacks and other death spirals. It also mitigates the free speech attacks by not throttling based on content (which is inherently contentious), but based on wg mailing list bandwidth. in all modesty, Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: too many notes -- a modest proposal
Anthony G. Atkielski wrote: Andy Bierman writes: I do not share your regulatory zeal. As a WG Chair and WG participant, I have enough rules to follow already. The last thing I want to do is count messages and bytes, and enforce draconian rules like this. But counting messages and bytes happens to be something that can be easily automated, and it can be applied with absolute consistency to everyone, without prejudice. Of course, those are exactly the reasons why many people would reject the idea--they want to keep other people from posting, but they also fear being prevented from posting themselves. I think you missed my point. I should have said enforce or abide by draconian rules. Automating the process is even worse. Then stupid scripts disrupt WG activity on a regular basis. Inappropriate mailing list use should be dealt with by the WG Chair(s) in a more diplomatic manner. Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Working Group chartering
Burger, Eric wrote: IMHO, *way* too many I*E*TF work groups get chartered based on an idea. We then spend tons of resources on figuring out if the idea will work. We produce lots of half-baked documents with little basis in working code. Then folks try implementing what's been spec'ed, find it doesn't work, but then find a ton of resistance to change, because the specs are three years old and we don't want to break draft-mumble-05 implementations. I completely agree with you. I wonder if we are in the minority opinion? Standardize stuff that already works -- what a concept. When we see a proposal without any running code to back it up, we should be asking: If this is so good, then why aren't you using it yourself? If something is an idea, let's make it politically acceptable for the work to be done in the I*R*TF first. I don't care how the technology gets developed. IRTF, vendors, universities, whatever. Show us running code that's reasonably close to what you want to standardize. Let's get feedback from people who have used the technology, too. Yes, I agree that the process should be fuzzy - the AD should be able to figure out if something is likely to work in the real world. However, building a work group out of an idea, rather than somewhat working code or a demonstration framework, should be the exception, rather than the rule. Agreed, but I'm no fan of more process rules. Area Directors who want to produce successful standards will know how to make this decision. ADs have to be tough enough to say Come back when you've done more work. Andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Crocker Sent: Tuesday, January 03, 2006 1:13 PM To: Jeffrey Hutzelman Cc: ietf@ietf.org Subject: Working Group chartering [snip] And here is where we have the major disconnect. Working groups start from a wide variety of places. Some start with an idea. Some with a detailed proposal. Some with a detailed specification and some with existing and deployed technology. When a working group starts, it must make the strategic decision about how much prior work to preserve, versus how much new work to encourage or require. [snip] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: jabber rooms
Brian E Carpenter wrote: I don't think I've seen a reminder this week that jabber room for the XXX WG or BOF is [EMAIL PROTECTED] FYI: Audio feed info: http://videolab.uoregon.edu/events/ietf/ Jabber info: http://www.xmpp.org/ietf-chat.html Meeting slides: https://onsite.ietf.org/public/meeting_materials.cgi?meeting_num=64 Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Where can I find capwap BOF Agenda ?
At 05:44 PM 7/1/2003, Soohong Daniel Park wrote: Hi all I am searching for capwap Agenda http://www.ietf.org/ietf/03jul/capwap.txt Friday, July 18 OPS capwap Control And Provisioning of Wirelsss Acc. Point BOF Daniel (Soohong Daniel Park) Mobile Platform Lab,SAMSUNG Electronics Andy
Re: Financial state of the IETF - to be presented Wednesday
At 03:20 PM 3/15/2003 -0500, Melinda Shore wrote: My guess is that going to two would hurt income, unless we raise fees by 50% - the same people would come, I think. Going to four would be damaging to my sanity, at least - don't know about others' we whould expect slightly lower per-meeting attendance, but many would indeed feel obligated to go to all four, so would pay more, I think. Whether they would get more things done is an open question. I hate the idea of more travel, plus I suspect 4 may be harder to justify to management. However, try as we may to do things right, the IETF is increasingly doing its work at meetings instead of mailing lists. If we can't fix it we should probably accept it. Also, more regular meetings might tend to discourage interim meetings, which would be excellent. I agree. Given that the work of the IETF is centered on the publication of documents, and given that most I-Ds are published near the I-D cutoff deadlines, it stands to reason that IETF productivity will increase by 33% if the number of publication cycles per year is increased from 3 to 4. Melinda Andy
Re: Splitting the IETF list
At 09:29 AM 11/19/2001 +0100, Brian E Carpenter wrote: Andy, I don't see how this will help. The nonsense messages will still come, from the usual sources, often copied to both lists, which will only increase the level of annoyance. IETF Last Call is a critical part of the Standards Process. It's our last chance to do a cross-domain sanity check on new technology, and give this input to the IESG, before they decide to approve a standard or not. These critical emails comprise less than 1 percent of the traffic on the IETF list. (My unscientific survey says...) I wouldn't characterize the other 99% as pure noise, maybe just 95%. I know of several longtime IETFers who ignore this list because of S/N ratio is so bad. If there was a [EMAIL PROTECTED] mailing list, more people might make Last Call comments. People who post off-topic messages will be shouted off the list and if they keep doing it, they will be blocked from posting. Andy [Splitting the -announce list doesn't have this disadvantage.] Brian Andy Bierman wrote: Hi, I would like the IESG to consider splitting this list into 2 lists. One list for discussion of Last Call issues and another for everything else (including minor stuff like splitting the IETF-Announce or IETF lists :-) thanks, Andy
Splitting the IETF list
Hi, I would like the IESG to consider splitting this list into 2 lists. One list for discussion of Last Call issues and another for everything else (including minor stuff like splitting the IETF-Announce or IETF lists :-) thanks, Andy
[Fwd: RMONMIB WG interim meeting announcement]
Hi, The RMONMIB WG intends to hold an interim meeting to work on all aspects of the new charter. This includes: - Application Performance Monitoring (APM) - Transport Performance Metrics (TPM) - User-Defined TopN Monitoring MIB (UsrTopN) - DIFFSERV Monitoring MIB (DS-MON) Meeting Dates: Monday, May 15 9am - 6pm Tuesday, May 16 9am - 6pm Location: (Meeting Site TBD) San Francisco or San Jose, CA Sponsor: A sponsor or co-sponsors are needed to host this meeting. A hotel meeting room is preferred, but corporate facilities will be good enough. Please contact me at [EMAIL PROTECTED] if you can help.
