net.stewards [Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)]
Michael Thomas wrote: Scott W Brim wrote: On 09/15/2005 17:09 PM, Paul Hoffman allegedly wrote: At 1:50 PM -0700 9/15/05, Michael Thomas wrote: Which is pretty much the elephant in the room, I'd say. How much of the net traffic these days is, essentially, not in any way standardized, and in fact probably considers ietf old and in the way? Not sure why this is an elephant; who cares? I have seen numbers that show that a huge percentage of traffic is P2P of various flavors, but I haven't seen anyone saying that this is having any negative effects. The metaphor I'm trying to use this week is that the IETF is landscapers and we provide a fertile, beautiful area for people to go wild and create excellent gardens. What you're describing is not a bug, it's feature. It means the IETF have done their job. If there were interoperability problems in the fundamental and/or widespread technologies being used in the Internet, then there would be a problem (we're working on those). Congratulations. Perfect. And then someone with less clue decided to plant Kudzu. We have nothing to say about that? I just read today that kudzu extract may reduce the desire for alcohol (Scientific American, 8/2005, p 17). What seems evil may not always be evil. I know that we aren't the net.cops, but are we not net.stewards either? Up to a point, but there are limits to what we can do. We can request that the RFC Editor not publish things we think are damaging. The IESG does this a few times a year. Similarly, we can request that IANA not register things we think are damaging, or at least to label them as potentially dangerous. We can publish screeds about damaging practices. The IAB does this a few times a year. We can try to develop non-damaging solutions for requirements where the easy solutions are damaging, and we can try to repair our own damage (as HTTP 1.1 repairs HTTP 1.0). We can try to ensure that the Internet can 'route around damage' - that's one of the main reasons for defending the e2e principle, for example. But we can't prevent people from deploying solutions that we didn't develop, and we shouldn't even try to IMHO. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: net.stewards [Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)]
Behalf Of Brian E Carpenter Up to a point, but there are limits to what we can do. We can request that the RFC Editor not publish things we think are damaging. The IESG does this a few times a year. Similarly, we can request that IANA not register things we think are damaging, or at least to label them as potentially dangerous. We can publish screeds about damaging practices. The IAB does this a few times a year. We can try to develop non-damaging solutions for requirements where the easy solutions are damaging, and we can try to repair our own damage (as HTTP 1.1 repairs HTTP 1.0). We can try to ensure that the Internet can 'route around damage' - that's one of the main reasons for defending the e2e principle, for example. But we can't prevent people from deploying solutions that we didn't develop, and we shouldn't even try to IMHO. Mao was wrong, the root of power is not coercion, it is persuasion. Sure the IETF can pursuade IANA not to register a code point. But if that happens it only makes things worse. There is nothing that can be done to prevent unregistered use and no real disadvantage to doing so as nobody will want to accept an official registration polluted by prior use. I do not see an argument being made that BitTorrent is worse than the alternatives that can be used. Instead there is a NIH argument that BitTorrent is in competition with multicast. I think it is important to distinguish net.stewardship from special pleading trying to use the vast political influence of the IETF as described by Brian to force consumers to adopt the anointed solution over the deployed. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)
Scott W Brim sbrim@cisco.com writes: The metaphor I'm trying to use this week is that the IETF is landscapers and we provide a fertile, beautiful area for people to go wild and create excellent gardens. Exactly. The beauty of TCP/IP (and indeed many protocols when done well) is that they are generic enablers for additional higher-level uses. TCP/IP creates opportunity for innovation, and does so in a way that is generally safe for the network. In the case of BitTorrent, it runs on top of TCP. It is silly to assume/expect all application protocols to be developed in the IETF. It is true that BitTorrent (or more precisely its heavy use) creates interesting dynamics that have implications for the net and maybe even the IETF. For example, BitTorrent creates an environment in which end users start running background jobs that run for hours and suck up idle background network capacity. I've heard ISPs use figures of 30% or more of their capacity This is Just Fine at one level, but also upsets some business models. Wouldn't it be nice if BitTorrent traffic (at least in some cases) could be labeled as background traffic so that ISPs had the ability to better prioritize or figure out when it is critical to add more bandwidth vs. just nice to have? Maybe more work here for diffserv? Thomas ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: net.stewards [Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)]
Hallam-Baker, Phillip wrote: Behalf Of Brian E Carpenter Up to a point, but there are limits to what we can do. We can request that the RFC Editor not publish things we think are damaging. The IESG does this a few times a year. Similarly, we can request that IANA not register things we think are damaging, or at least to label them as potentially dangerous. We can publish screeds about damaging practices. The IAB does this a few times a year. We can try to develop non-damaging solutions for requirements where the easy solutions are damaging, and we can try to repair our own damage (as HTTP 1.1 repairs HTTP 1.0). We can try to ensure that the Internet can 'route around damage' - that's one of the main reasons for defending the e2e principle, for example. But we can't prevent people from deploying solutions that we didn't develop, and we shouldn't even try to IMHO. Mao was wrong, the root of power is not coercion, it is persuasion. Sure the IETF can pursuade IANA not to register a code point. But if that happens it only makes things worse. There is nothing that can be done to prevent unregistered use and no real disadvantage to doing so as nobody will want to accept an official registration polluted by prior use. All true. That's why I wrote or at least to label them as potentially dangerous. I do not see an argument being made that is worse than the alternatives that can be used. Instead there is a NIH argument that is in competition with . I am not making any comment about specific technologies. I think it is important to distinguish net.stewardship from special pleading trying to use the vast political influence of the IETF as described by Brian to force consumers to adopt the anointed solution over the deployed. Sigh. That's exactly my point; our stewardship role is really limited to advocacy and to providing better altermatives. I don't see where you can find special pleading, vast political influence, force or anointed in what I wrote. I think we would do well to avoid polemic language on this list. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should beon WG to fix it)
Wouldn't it be good if an ISP could install a machine that would function as a local head end BitTorrent cache? There are probably multiple folk on my comcast drop who are viewing the same feeds from CNN and Crooks and Liars etc. Peer to Peer is not the optimal way to support this but it is the optimal way to bootstrap. This is of course leading to a discussion where someone says 'you want to work out the optimal routing path, that's hard' and someone else says 'I thought we were meant to be the ones with brains the size of a planet'. Don't bother with optimal, just do SRV lookups on the reverse DNS. The network operator can do the optimal cache placement and use the reverse DNS to advertise the correct location. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Narten Sent: Friday, September 16, 2005 9:24 AM To: Scott W Brim Cc: Michael Thomas; Paul Hoffman; ietf@ietf.org Subject: Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should beon WG to fix it) Scott W Brim sbrim@cisco.com writes: The metaphor I'm trying to use this week is that the IETF is landscapers and we provide a fertile, beautiful area for people to go wild and create excellent gardens. Exactly. The beauty of TCP/IP (and indeed many protocols when done well) is that they are generic enablers for additional higher-level uses. TCP/IP creates opportunity for innovation, and does so in a way that is generally safe for the network. In the case of BitTorrent, it runs on top of TCP. It is silly to assume/expect all application protocols to be developed in the IETF. It is true that BitTorrent (or more precisely its heavy use) creates interesting dynamics that have implications for the net and maybe even the IETF. For example, BitTorrent creates an environment in which end users start running background jobs that run for hours and suck up idle background network capacity. I've heard ISPs use figures of 30% or more of their capacity This is Just Fine at one level, but also upsets some business models. Wouldn't it be nice if BitTorrent traffic (at least in some cases) could be labeled as background traffic so that ISPs had the ability to better prioritize or figure out when it is critical to add more bandwidth vs. just nice to have? Maybe more work here for diffserv? Thomas ___ 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: net.stewards [Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)]
Brian writes Sigh. That's exactly my point; our stewardship role is really limited to advocacy and to providing better altermatives. I don't see where you can find special pleading, vast political influence, force or anointed in what I wrote. I think we would do well to avoid polemic language on this list. I was replying to the wider debate identified in the original subject line there. I was not disagreeing with your points. I thought that was clear. I disagree with your point about advocacy, I think the IETF can do a bit more than that. There is a common assumption that the role of the IETF standards process is to decide what is used on the net. The idea being that once something is agreed as a standard it will automatically be implemented and used. This way of thinking is likely to lead to disappointment. A much more useful way to think about the IETF (or OASIS or W3C) is that it is one place where you can meet others to build the necessary support constituency to achieve deployment. Most folk get it, a few don't. BitTorrent has succeeded (so far) without IETF involvement. There might well be a point in the future where an IETF group could help further deployment. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: net.stewards [Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)]
In message [EMAIL PROTECTED], Brian E Carpenter writes: Michael Thomas wrote: Perfect. And then someone with less clue decided to plant Kudzu. We have nothing to say about that? I just read today that kudzu extract may reduce the desire for alcohol (Scientific American, 8/2005, p 17). What seems evil may not always be evil. Have you ever lived in the southern U.S.? It's amazing driving through some areas, where you see kudzu covering trees, barns, telephone polls, and some slow-moving cows... I know that we aren't the net.cops, but are we not net.stewards either? Up to a point, but there are limits to what we can do. We can request that the RFC Editor not publish things we think are damaging. The IESG does this a few times a year. Similarly, we can request that IANA not register things we think are damaging, or at least to label them as potentially dangerous. We can publish screeds about damaging practices. The IAB does this a few times a year. We can try to develop non-damaging solutions for requirements where the easy solutions are damaging, and we can try to repair our own damage (as HTTP 1.1 repairs HTTP 1.0). We can try to ensure that the Internet can 'route around damage' - that's one of the main reasons for defending the e2e principle, for example. But we can't prevent people from deploying solutions that we didn't develop, and we shouldn't even try to IMHO. Agreed. Sometimes the IETF does the initial engineering, sometimes it has to do garbage collection and repair, and hope that the operators can cope in the meantime. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: net.stewards [Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)]
On Sep 16, 2005, at 3:29 PM, Steven M. Bellovin wrote: In message [EMAIL PROTECTED], Brian E Carpenter writes: Michael Thomas wrote: Perfect. And then someone with less clue decided to plant Kudzu. We have nothing to say about that? I just read today that kudzu extract may reduce the desire for alcohol (Scientific American, 8/2005, p 17). What seems evil may not always be evil. Have you ever lived in the southern U.S.? It's amazing driving through some areas, where you see kudzu covering trees, barns, telephone polls, and some slow-moving cows... wow, i never heard of it but it looks very nice http://www.jjanthony.com/kudzu/ greetings I know that we aren't the net.cops, but are we not net.stewards either? Up to a point, but there are limits to what we can do. We can request that the RFC Editor not publish things we think are damaging. The IESG does this a few times a year. Similarly, we can request that IANA not register things we think are damaging, or at least to label them as potentially dangerous. We can publish screeds about damaging practices. The IAB does this a few times a year. We can try to develop non-damaging solutions for requirements where the easy solutions are damaging, and we can try to repair our own damage (as HTTP 1.1 repairs HTTP 1.0). We can try to ensure that the Internet can 'route around damage' - that's one of the main reasons for defending the e2e principle, for example. But we can't prevent people from deploying solutions that we didn't develop, and we shouldn't even try to IMHO. Agreed. Sometimes the IETF does the initial engineering, sometimes it has to do garbage collection and repair, and hope that the operators can cope in the meantime. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Sic transit gloria mundi Les Enfants Terribles www.let.de smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: net.stewards [Re: BitTorrent (Was: Re: [Isms] ISMS charter br oken- onus should be on WG to fix it)]
Philip, Apology in advance if this seems to be removed from context, but your statement (below) seems to have been made generally and is not self consistent. Perhaps you could clarify it somewhat? --- [ SNIP ] --- -- -- Sure the IETF can pursuade IANA not to register a code point. But if -- that happens it only makes things worse. There is nothing that can be -- done to prevent unregistered use and no real disadvantage to doing so as -- as nobody will want to accept an official registration polluted by prior -- use. -- --- [ SNIP ] --- Generally, the existence of an assignment authority does encourage its (proper) use - mostly for the reason you state above. Just as nobody will want to accept an official registration polluted by prior use, nobody (deliberately in quotes) will want to attempt to establish an unofficial registration using the approach you've described. Doing so is - at the very least - going to adversely affect popularity and is very likely to result in interference and potentially even litigation. Of course the assignment authority has to be credibly recognized as the sole assignment authority for this to be true. IANA is certainly such an authority. -- EG ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Control RE: net.stewards [Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)]
From: Gray, Eric [mailto:[EMAIL PROTECTED] Philip, Apology in advance if this seems to be removed from context, but your statement (below) seems to have been made generally and is not self consistent. Perhaps you could clarify it somewhat? --- [ SNIP ] --- -- -- Sure the IETF can pursuade IANA not to register a code point. But if -- that happens it only makes things worse. There is nothing that can -- be done to prevent unregistered use and no real disadvantage to -- doing so as as nobody will want to accept an official registration -- polluted by prior use. -- --- [ SNIP ] --- Generally, the existence of an assignment authority does encourage its (proper) use - mostly for the reason you state above. Just as nobody will want to accept an official registration polluted by prior use, nobody (deliberately in quotes) will want to attempt to establish an unofficial registration using the approach you've described. Doing so is - at the very least - going to adversely affect popularity and is very likely to result in interference and potentially even litigation. That is only the case up to the point that an attempt is made to use the registry as a means of political control. For example if the US congress was to decide to 'require' ICANN to drop Cuba, North Korea, Palestine etc. out of the DNS master zone file the result would be an immediate end to the authority of ICANN beyond the borders of the US. It would not result in the zones disappearing. Similar issues crop up all the time in radio frequency spectrum allocations. People will not want to use an unofficial registration unless the registration process is unacceptable, either because the process itself is too tedious or there are unacceptable costs such as politically driven side constraints. The DNS extensions draft proposed by some members of the IAB suffers from this falacy. They essentially conclude that the only legitimate way to extend the DNS is by registering a new RR with IANA. The only 'benefit' of this approach is that it gives political control over use of the DNS to the DNSEXT working group. This is not considered a benefit by any of the groups looking to create DNS policy extensions and in each case the group has essentially decided to reuse TXT records, either with or without prefixes. Nobody has the slightest intention of ever using the proposed 'proper' DNS record, as has been demonstrated at some length publishing the same information through different mechanisms leads to inconsistency. But this approach is inisted on because 1) the fear of losing control and 2) in order to force the pace of DNS server upgrades that allow use of new resource records. What has happened here is that the result is very much worse for all parties than could be achieved if the insistence on control was dropped - control that is in any case illusory. Forcing IETF-firendly initiatives such as SPF and DKIM to accept IETF control does nothing to prevent the introduction of 'dangerous' records that might actually cause severe problems. If the insistence on cutting new RRs is dropped it is entirely possible to define a method of applying prefixed records that provides all the wildcard administrative functionality that is possible with a new RR. This means that the protocols can be supported by the existing DNS rather than only 50% of deployments according to empirical measurement. It also means that we can get more protocols that make use of DNS based policy statements which in turn means that the security of the DNS becomes a much more important issue which in turn means that DNSSEC becomes a much more important issue which in turn means that there is a real incentive to deploy the DNS extensions to support deployment of new RRs. If you run the numbers through a spreadsheet simulation you will soon discover that making new protocols *dependent* on an infrastructure deployment is a much less effective deployment strategy than designing the new protocols to be independent of the infrastructure deployment but capable of taking advantage of the infrastructure where it exists. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: net.stewards [Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)]
Generally, the existence of an assignment authority does encourage its (proper) use - mostly for the reason you state above. Just as nobody will want to accept an official registration polluted by prior use, nobody (deliberately in quotes) will want to attempt to establish an unofficial registration using the approach you've described. Doing so is - at the very least - going to adversely affect popularity and is very likely to result in interference and potentially even litigation. litigation? Do we have prior art that this is a likely result? Spencer, honestly confused (for once)... ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Process Evolution
I would like to note that the use of this process was not agreed to by a consensus of the IESG. Brian sent early versions of this proposal to the IESG, and it received considerable pushback, some of it from me. I strongly encouraged Brian to use a design team to draft a charter for a tightly focused working group in the General Area instead. I agree with Brian that general discussion of IETF process change tends to diverge and to move slowly, but I believe that working groups like NomCom show that we can succeed with focused charters in establishing new procedures or revising existing ones. I believe the public chartering process of a focused working group is a useful, necessary part of the openness of the IETF process, and that the public discussion within that charter, once established, is critical for process change of the scope envisioned. It is not clear from the note below whether every volunteer to serve will be a part of the PESCI team team, or whether the group will be selected from among the volunteers by Brian. I ask him to clarify that point. It is not clear from the note below whether the pesci-discuss list is the discussion list for the PESCI design team or a conduit of community input into its deliberations. I ask Brian to clarify that point. Brian notes that after his design team reports to the IETF on the IETF's goals and principles multiple things may happen, among them: - decide whether to renew the PESCI design team (assumed below) or use an alternative discussion forum - consider various process change proposals from any source - reach a team consensus on a consistent set of proposals and a sequence for implementing them, with target dates. All proposals must embed the principle of rough IETF consensus and must provide an appeal mechanism. - one of the proposals, likely the first, may be a proposal for a new process for process change - post the proposals as Internet-Drafts intended for publication as BCPs It is not clear who decides whether to renew the PESCI design team. Its creation is a unilateral decision of Brian as Chair; is the decision for renewal subject to public review? Given the lack of a working group, who decides among alternatives agreed to by consensus of this design team and those proposed outside of this mechanism, should there be alternate proposals that are proposed to the IETF? Though Brian notes that there are multiple possible outcomes after PESCI reports, this step appears to be a concrete proposal for how to proceed: forward proposals for approval as BCPs* and acceptance by the ISOC Board. Until such time as the new process for process change has been approved, the proposals will be submitted directly to the General Area Director and the approval body will be the IESG. However, the IESG members' principal chance to comment on and influence the proposals is prior to their forwarding for approval. Brian has commented in the past on the difficulty of him being both Chair and General Area Director, and this highlights the problem. Brian is choosing to start the PESCI effort as IETF Chair(Roll 1); he will lead it (Roll 2); he will then forward its proposal to himself as General Area Director (Roll 3). The IETF has had a serious queueing problem for a long time, as things have evolved such that important to the IETF has meant passes through the IESG. That's deeply wrong (and very slow), and it needs to change. Getting us to a point where new queues are available for distinct tasks is a good idea, and process change management is clearly a distinct task from manage working groups, which is the IESG's basic job. But getting us to that new point by funneling the interim change process through a single individual (in however many multiple roles) is equally wrong. I ask Brian to adjust this plan so that PESCI's output is a charter for a working group that can achieve at least the first task set up a new change management process according to the existing system. I strongly support the need for change, and I believe that to achieve the appropriate community involvement this is required. regards, Ted Hardie At 11:21 AM -0400 9/16/05, IETF Chair wrote: There has been quite a bit of community discussion of IETF process change in recent months. Obviously, process changes must obtain rough consensus in the IETF and follow the procedures in place (principally RFC 2026 today). However, past experience has shown that general discussion of IETF process change on the main IETF list, or in a normal working group, rapidly tends towards divergent opinions with consensus being extremely hard and slow to establish. On the other hand, we have experience that discussion of simply formulated principles and of consistent process proposals can be constructive and convergent. This note describes a method of starting the next phase of IETF IETF
RE: net.stewards [Re: BitTorrent (Was: Re: [Isms] ISMS charterbroken- onus should be on WG to fix it)]
Behalf Of Spencer Dawkins Generally, the existence of an assignment authority does encourage its (proper) use - mostly for the reason you state above. Just as nobody will want to accept an official registration polluted by prior use, nobody (deliberately in quotes) will want to attempt to establish an unofficial registration using the approach you've described. Doing so is - at the very least - going to adversely affect popularity and is very likely to result in interference and potentially even litigation. litigation? Do we have prior art that this is a likely result? DNS administration has certainly not been a litigation-free zone... I can't quite see a circumstance in which IANA could block the use of an unauthorized port assignment, or even the legal theory under which a claim might be made. There might be a claim if someone tried to falsely claim that a code assignment was authorized by IANA. If all the parties involved in a communication agree on the use of the assignment I can't see a hacking type claim. Regardless I don't think IANA has the resources to make this type of legal threat if it wanted to. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: net.stewards [Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)]
Brian E Carpenter wrote: Michael Thomas wrote: I know that we aren't the net.cops, but are we not net.stewards either? Up to a point, but there are limits to what we can do. We can request that the RFC Editor not publish things we think are damaging. The IESG does this a few times a year. Similarly, we can request that IANA not register things we think are damaging, or at least to label them as potentially dangerous. We can publish screeds about damaging practices. The IAB does this a few times a year. We can try to develop non-damaging solutions for requirements where the easy solutions are damaging, and we can try to repair our own damage (as HTTP 1.1 repairs HTTP 1.0) This is more or less what I had in mind. Correct me if I'm wrong, but http 1.0 wasn't the invention of the ietf, but sprang forth outside of its purview. Http 1.1 was a response to the many difficulties placed on the net because of http 1.0, and there was an active feedback loop between the http world and the net (ietf) world to adapt both at layer 7 as well as below. Http, after all, was The Big Thing for all parties, so it's not surprising that there was active cross interest. What facinates me about p2p is that it was clearly the next Big Thing, but there seems to be no feedback loop operating whatsoever. I guess that surprises me. Thomas brought up qos/diffserv and operator business models which is certainly something ietf clue level could assist on, but it seems that we neither know them, nor do they know us and that both sets of people seem satisfied with that. I'm not saying that it's bad -- it's just a very surprising outcome. Ought both sides be that confident that the net as engineered today is what it needs to be for this Big Thing and the Big Thing after that? Or that our fertilization is really the correct mix to prepare the ground for the next Big Thing? But we can't prevent people from deploying solutions that we didn't develop, and we shouldn't even try to IMHO. I wasn't suggesting control, but much more that the cross pollination of clue isn't happening and whether we should be alarmed about that. In particular, what does that say about ietf? Some have suggested that it means that we've done our job, but that strikes me as a wee bit too self-satisifed for my taste. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: net.stewards [Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)]
Behalf Of Michael Thomas This is more or less what I had in mind. Correct me if I'm wrong, but http 1.0 wasn't the invention of the ietf, but sprang forth outside of its purview. Http 1.1 was a response to the many difficulties placed on the net because of http 1.0, and there was an active feedback loop between the http world and the net (ietf) world to adapt both at layer 7 as well as below. Http, after all, was The Big Thing for all parties, so it's not surprising that there was active cross interest. True enough, the 1.0 draft was mostly developed before it was submitted to the IETF. But the differences between 1.0 and 1.1 are hardly save the net stuff. The only change that has been made that is really significant is the introduction of the host address header, and that was a unilateral action by Netscape without any external discussion of any kind. The rest of the 1.1 changes are mostly incremental. The chunking mechanism is an improvement and it makes keep-alive possible but that is an incremental improvement that was proposed independently of the IETF. The majority of the WG effort was spent perfecting the cache mechanism to work with proxies. Only these days we do not use client side proxies to any real extent - the exception being transparent firewall proxies. Most Web content is active with very short expiry times. So yes the WG effort was useful but it certainly did not 'save the Internet'. Nor was that ever going to be possible, Netscape made it clear that it would act unilaterally to introduce its own standards from day one. It was only after they ceased to be the dominant browser that they discussed proposed changes to their version of the spec before releasing code. It is arguable that things could have been improved if we started earlier. The digest authentication mechanism only exists because of the IETF attempt to eliminate en-clair transmission of passwords. Unfortunately very few web sites use it, almost all use the HTML form field instead. What facinates me about p2p is that it was clearly the next Big Thing, but there seems to be no feedback loop operating whatsoever. I guess that surprises me. Thomas brought up qos/diffserv and operator business models which is certainly something ietf clue level could assist on, but it seems that we neither know them, nor do they know us and that both sets of people seem satisfied with that. I'm not saying that it's bad -- it's just a very surprising outcome. Ought both sides be that confident that the net as engineered today is what it needs to be for this Big Thing and the Big Thing after that? Or that our fertilization is really the correct mix to prepare the ground for the next Big Thing? I think the problem you identify here is that the focus of the IAB is inward, looking at what the IETF is doing. It does not look outward to look at what the Internet community is doing. It is just assumed that they are the same thing. * We did not have a note from the IAB in 2000 saying 'hey this spam thing that was predicted as a possibility in 1982 is beginning to get really out of hand and become a criminal nuisance' * We have not had architectural guidance of the form 'stop pushing BEEP onto IETF working groups, the Web Services platforms have unanimously adopted SOAP and the WS-* stack' * We have not had information of the form 'phishing and social engineering are becoming major engines for Internet crime' * We have not had any real analysis of the botnet problem. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Possible new Real-Time Applications and Infrastucture (RAI) Area
I'm of conflicting thoughts about this. On one hand, more Ads could have more opportunity to do more hands-on work with working groups, etc. This would be a good thing, and could potentially help WGs to progress drafts through WGs faster. On the other hand, 2 more ADs means two more potential DISCUSSes and more Ads spending time on document reviews. I'm not sure if what the IETF needs is more Ads to review the documents and file DISCUSSes. If there was a way to lighten-up the IESG review process, then this would be a good idea. For example, having a single DISCUSS per Area would be one way to reduce this could be one solution. In summary, I think that expanding the IESG would only be a good idea only if we could adjust the IESG review load / process so that we are not just expanding the number of potential DISCUSSes. thanks, John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext IETF Chair Sent: 16 September, 2005 16:14 To: IETF Announcement list Subject: Possible new Real-Time Applications and Infrastucture (RAI) Area As mentioned in the recent call for NomCom volunteers, the IESG is considering the creation of a new area, as set out below. We solicit feedback from the community on the scope of this potential new area as well as the impact on the IETF's infrastructure and efficiency of setting up this new area. We need to decide quite quickly, to fit the NomCom schedule. Please write to iesg@ietf.org, or to ietf@ietf.org if you want community discussion of your comment. (There's no need to write to both!) Brian Carpenter - Real-Time Applications and Infrastucture (RAI) Area Description The Real-Time Applications and Infrastructure Area develops protocols and architectures for delay-sensitive interpersonal communications. Work in this area serves an emerging industry whose applications and services include voice and video over IP, instant messaging and presence. These applications and services are real-time in the sense that delay impedes human participation in the associated systems. The RAI Area is seeded with existing working groups from the Transport and Applications Area: SIP, SIPPING, XCON, SIMPLE, GEOPRIV, ECRIT, ENUM, IPTEL, MEGACO, MMUSIC, IEPREP, SPEECHSC, and SIGTRAN. A good rule of thumb for the incorporation of new work into RAI, as opposed to Transport or Applications, is that the work in question has major goals supporting instant interpersonal communication or its infrastructure. For example, they can range from applications to help users make decisions about how best to communicate using presence services, to session signaling protocols and emergency call routing solutions, to work on the layer five issues for Internet telephony. Like all areas of the IETF, the RAI Area draws on the work of numerous other areas, and as such there can be no neat mathematical boundaries delineating RAI's work from the rest of the IETF. The new area will allow an existing community within the IETF to solidify its vision and to benefit from increased institutional support. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Process Evolution
From: Ted Hardie [EMAIL PROTECTED] I would like to note that the use of this process was not agreed to by a consensus of the IESG. Brian sent early versions of this proposal to the IESG, and it received considerable pushback, some of it from me. I strongly encouraged Brian to use a design team to draft a charter for a tightly focused working group in the General Area instead. I agree with Brian that general discussion of IETF process change tends to diverge and to move slowly, but I believe that working groups like NomCom show that we can succeed with focused charters in establishing new procedures or revising existing ones. I believe the public chartering process of a focused working group is a useful, necessary part of the openness of the IETF process, and that the public discussion within that charter, once established, is critical for process change of the scope envisioned. Hi, Ted, There are a lot of very helpful comments later in your note to Brian, which I snipped, but I wanted to respond to this paragraph. While it seems plausible that we could use the same mechanism for protocol design and for process evolution, my understanding of the Problem working group's efforts and the subsequent newtrk/icar/proto/mpowr (and yes, there were others) efforts is that this approach simply does not work. I used to believe that it could, and was honestly surprised when it didn't. I was wrong. It happens. I wrote my observations on why working groups don't work for process change in an early draft of what became RFC 3933. I agreed to remove the observations in order to publish the draft (the question was, do you want to publish the draft or argue about the observations?), but I still think Sections 1, 2 and 3 of http://bgp.potaroo.net/ietf/all-ids/draft-klensin-process-july14-01.txt were accurate when they were written, and I do not know why these observations would have been invalidated in the past two years. Whenever I refer to this version of the draft, I need to add this disclaimer: The reason this approach fails isn't anyone's fault - it's systemic. I continue to have the highest respect for the ADs who supported these efforts to improve things, and for the BOF chairs, WG chairs, and editors who tried to make improvements happen. But we've already been here. At the very least, I expect coming up with a tight charter to derail any discussion of evolution until IETF 65. That's what happened in newtrk and icar, when IETF participants went from discussing proposals to discussing a charter. Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: net.stewards [Re: BitTorrent (Was: Re: [Isms] ISMS charter br oken- onus should be on WG to fix it)]
Spencer, I will make three observations regarding your question. It may be that this will help the confusion, one way or the other. 1) I will not be suckered into a search for prior art on this. I am not certain it exists, but I am certain that its existence is not necessarily relevant. :-) 2) Ultimately, civilized people recognize assignment authorities as the mechanism by which values can become property. Any time you have property, you may have either litigation, or murder, when a question of ownership arises. 3) Sometimes, the likelihood of an event is unmeasurable and possibly irrelevant in the face of the fact that the possibility certainly exists. -- EG -- -Original Message- -- From: [EMAIL PROTECTED] -- [mailto:[EMAIL PROTECTED] Behalf Of -- Spencer Dawkins -- Sent: Friday, September 16, 2005 12:39 PM -- To: ietf@ietf.org -- Subject: Re: net.stewards [Re: BitTorrent (Was: Re: [Isms] -- ISMS charter -- broken- onus should be on WG to fix it)] -- -- -- Generally, the existence of an assignment authority does encourage -- its (proper) use - mostly for the reason you state above. Just as -- nobody will want to accept an official registration polluted by -- prior use, nobody (deliberately in quotes) will want -- to attempt -- to establish an unofficial registration using the approach you've -- described. Doing so is - at the very least - going to adversely -- affect popularity and is very likely to result in interference and -- potentially even litigation. -- -- litigation? -- -- Do we have prior art that this is a likely result? -- -- Spencer, honestly confused (for once)... -- -- ___ -- 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 Process Evolution
At 1:39 PM -0500 9/16/05, Spencer Dawkins wrote: While it seems plausible that we could use the same mechanism for protocol design and for process evolution, my understanding of the Problem working group's efforts and the subsequent newtrk/icar/proto/mpowr (and yes, there were others) efforts is that this approach simply does not work. Spencer, simply does not work is good rhetoric, but it doesn't fit all the facts. Groups like NomCom and IPR have taken on tasks and done them, with community discussion of their charters and with community discussion as their documents went through the process. They are process change groups, and they work. Let's say I put forward a charter like the following: WG Name: New Queues (NQ) Description of Working Group: The IETF has too many decisions passing through the same body, the IESG. The creation of the IASA and IAD has removed one set of tasks from that queue, but there are a considerable number of others which might be moved. In order to return the IESG to its historic task of managing working groups and their output, this working group will describe a process by which new decision making queues can come into being. While the process will be general, the working group will fully specify the creation of a process management decision making body. Among other targets for new queues: oversight of registered values in IANA registries; IETF responses to RFC-Editor queries related to RFC-Editor published documents; approval of experimental and informational documents that are not created by working groups. Goals and Milestones: 1st Draft of document describing general queue creation mechanism 1st Draft of document describing process management decision making body 2nd Draft of GQCM 2nd Draft of PMDM WGLC GQCM WGLC PMDM Publish QGCM Publish PMDM Re-charter to use GQCM for new queues, or close. Can the IETF community not discuss whether this is the output it wants and this is the direction of change it wants in terms of this charter? It may say no, but how to say yes or no to a charter is pretty clear, as is how to participate in the group or react to its output. Using an ad hoc mechanism to get from the existing process change mechanism to a new one would work well if we had strong consensus on where we want to go in process change, but that is the same condition in which working groups achieve success as well. If we do not have strong consensus on the desired process change, the ad hoc mechanism has far muddier mechanisms by which it is created, by which people participate, and by which its output may be challenged. The most obvious mechanism for the last is for someone to put forward an alternate proposal. If there are alternate proposals than those coming from the design team, how do you want to decide among them in the absence of a working group? Sure, we can invent all kinds of mechanisms to handle it that are equally ad hoc, but as I said in the Paris plenary, the hard but probably right answer is to use the existing mechanism one last time to replace it, then move on. That will require a lot of work from the Area Director, the WG Chair, and the community, but it is still the right answer. regards, Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Process Evolution
Groups like NomCom and IPR have taken on tasks and done them, with community discussion of their charters and with community discussion as their documents went through the process. They are process change groups, and they work. Ted, Groups like nomcom and ipr have not had a multi-year crisis with a history of extensive activity and little measurable improvement to show for it. (How long ago was Yokohama?) So, Ted, how long should be allocated for this process to define a charter to define a working group that will define process changes? How long to get community acceptance for it? How long to get a resulting working group to produce something useful? And since all other public development efforts for process change have frankly fallen flat, as Brian has cited, what is your basis for believing that a working group charter will somehow make yet-another public process more effective at developing a specification for change? Design teams design solutions, not plans for solutions or charters for working groups. If the design team knows enough about its topic -- especially when the topic is complex and not all that well understood -- it is usually a far more effective vehicle for solution specification than is the working group framework. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Process Evolution
On Fri, 16 Sep 2005, Ted Hardie wrote: At 1:39 PM -0500 9/16/05, Spencer Dawkins wrote: While it seems plausible that we could use the same mechanism for protocol design and for process evolution, my understanding of the Problem working group's efforts and the subsequent newtrk/icar/proto/mpowr (and yes, there were others) efforts is that this approach simply does not work. Spencer, simply does not work is good rhetoric, but it doesn't fit all the facts. Groups like NomCom and IPR have taken on tasks and done them, with community discussion of their charters and with community discussion as their documents went through the process. They are process change groups, and they work. From my perspective I would have to say that the preponderance of the evidence supports Spencer's position. My reaction to your initial response to Brian's message proposing yet another WG was oh, and it will be as successful as newtrk. Of course I could have added icar or sirs or the others that Spencer mentioned. And it's funny that you metion IPR as a success ... it seems to me that a lot of energy was spent to get very little, and in may ways it was a step backward (e.g., non-IETF folks now have to go to document authors to get permission to use a MIB etract or program fragment). For sure, the IPR effort has resulted in a delay of at least 18 months (with the clock still ticking) in getting the MIB review guidelines doc published (and I suspect, but cannot prove, that it is largely responsible for the long delay in getting rfc2223bis published). Even granting that nomcom has been a success -- I don't know the evidence in that case one way or another -- I'd have to say that the overall record for process change WGs has been very poor. In any case I would like to go on record as strongly supporting Brian's initiative. Given the lack of progress in newtrk and the like I think it's the only hope of moving forward. Mike Heard ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Fwd: I-D ACTION:draft-blanchet-v6ops-routing-guidelines-00.txt
sorry, the I-D has no information as to where this should be discussed... so: i am convinced that the IETF has no business telling me what routes i may or may not accept from or send to my peers, with the exception of prefixes of undefined BEHAVIOUR, much like the IPv4 class E space. That said, if these are Guidelines, as the title suggests, then there is no place for the MUST/MAY/SHOULD keywords. Even now, within the RIR and operational communities, there are discussions on changing the /48 boundaries. this draft should be abandon, imho. if kept, it needs serious surgery. --bill Begin forwarded message: From: [EMAIL PROTECTED] Date: September 16, 2005 12:50:02 PDT To: i-d-announce@ietf.org Subject: I-D ACTION:draft-blanchet-v6ops-routing-guidelines-00.txt Reply-To: [EMAIL PROTECTED] A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Routing Policies Guidelines Author(s) : M. Blanchet Filename : draft-blanchet-v6ops-routing-guidelines-00.txt Pages : 7 Date : 2005-9-16 Guidelines on how to handle IPv6 routes are needed for operators of networks, either providers or enterprises. This document is a followup of RFC2772 work but for the production IPv6 Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-blanchet-v6ops-routing-guidelines-00.txt To remove yourself from the I-D Announcement list, send a message to [EMAIL PROTECTED] with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username anonymous and a password of your e-mail address. After logging in, type cd internet-drafts and then get draft-blanchet-v6ops-routing-guidelines-00.txt. A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: [EMAIL PROTECTED] In the body type: FILE /internet-drafts/draft-blanchet-v6ops-routing-guidelines-00.txt. NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the mpack utility. To use this feature, insert the command ENCODING mime before the FILE command. To decode the response(s), you will need munpack or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with multipart MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: [EMAIL PROTECTED]> ___ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Fwd: I-D ACTION:draft-blanchet-v6ops-routing-guidelines-00.txt
Hi Bill, At 02:55 PM 09/16/2005, Bill Manning wrote: sorry, the I-D has no information as to where this should be discussed... so: Umm, from the file name I would have thought V6OPS is the intended venue to discuss it. draft-blanchet-v6ops-routing-guidelines-00.txt Suggesting moving any follow up discusson there. Bob ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Process Evolution
At 2:28 PM -0700 9/16/05, Dave Crocker wrote: And since all other public development efforts for process change have frankly fallen flat, as Brian has cited, what is your basis for believing that a working group charter will somehow make yet-another public process more effective at developing a specification for change? Possibly I'm wrong in this, but I believe that the public process works when the community cares about the outcome. The IASA work is done, and I believe it is a success because enough people cared about the outcome to make it one. As you noted a few days ago: Successful IETF work begins by developing support to do the development work and support to use the output of that work. The work is then done for development and deployment. The procedural simplicity and practical utility of this model tend to be vastly under-appreciated. I believe the community will care enough about this to get it to work, and I hope I'm right, as it will be a requirement whatever process we use to get to a new change process. As I said at the beginning of this thread, I believe using PESCI to scope the work and develop support for is fine. I'm deeply concerned, however, about it doing the development work itself, as a process in which selected volunteers replace the public work of those who will use the outcome. regards, Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Process Evolution
Two observations: 1) Having been an active participant in the Nomcom working group, it is amaxing it actually worked. The process took an absurdly long time to converge on a very small set of changes. Having tried to drive ICAR, which many people said was important, I again conclude that WGs are just the wrong tool for this. 2) If we were at the point that we knew that the changes below were what we wanted, that might be reasonable. But at the moment we have a polarized community who collectively want multiple incompatible things. And they want them all now. A working group will not resolve such a situation. Yours, Joel PS: I don't know if Brian's proposal is the right answer. But it is sure a heck of a lot better than chartering anotehr working group. At 03:22 PM 9/16/2005, Ted Hardie wrote: At 1:39 PM -0500 9/16/05, Spencer Dawkins wrote: While it seems plausible that we could use the same mechanism for protocol design and for process evolution, my understanding of the Problem working group's efforts and the subsequent newtrk/icar/proto/mpowr (and yes, there were others) efforts is that this approach simply does not work. Spencer, simply does not work is good rhetoric, but it doesn't fit all the facts. Groups like NomCom and IPR have taken on tasks and done them, with community discussion of their charters and with community discussion as their documents went through the process. They are process change groups, and they work. Let's say I put forward a charter like the following: WG Name: New Queues (NQ) Description of Working Group: The IETF has too many decisions passing through the same body, the IESG. The creation of the IASA and IAD has removed one set of tasks from that queue, but there are a considerable number of others which might be moved. In order to return the IESG to its historic task of managing working groups and their output, this working group will describe a process by which new decision making queues can come into being. While the process will be general, the working group will fully specify the creation of a process management decision making body. Among other targets for new queues: oversight of registered values in IANA registries; IETF responses to RFC-Editor queries related to RFC-Editor published documents; approval of experimental and informational documents that are not created by working groups. Goals and Milestones: 1st Draft of document describing general queue creation mechanism 1st Draft of document describing process management decision making body 2nd Draft of GQCM 2nd Draft of PMDM WGLC GQCM WGLC PMDM Publish QGCM Publish PMDM Re-charter to use GQCM for new queues, or close. Can the IETF community not discuss whether this is the output it wants and this is the direction of change it wants in terms of this charter? It may say no, but how to say yes or no to a charter is pretty clear, as is how to participate in the group or react to its output. Using an ad hoc mechanism to get from the existing process change mechanism to a new one would work well if we had strong consensus on where we want to go in process change, but that is the same condition in which working groups achieve success as well. If we do not have strong consensus on the desired process change, the ad hoc mechanism has far muddier mechanisms by which it is created, by which people participate, and by which its output may be challenged. The most obvious mechanism for the last is for someone to put forward an alternate proposal. If there are alternate proposals than those coming from the design team, how do you want to decide among them in the absence of a working group? Sure, we can invent all kinds of mechanisms to handle it that are equally ad hoc, but as I said in the Paris plenary, the hard but probably right answer is to use the existing mechanism one last time to replace it, then move on. That will require a lot of work from the Area Director, the WG Chair, and the community, but it is still the right answer. regards, Ted Hardie ___ 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 Process Evolution
Dear Ted, As I said at the beginning of this thread, I believe using PESCI to scope the work and develop support for is fine. I'm deeply concerned, however, about it doing the development work itself, as a process in which selected volunteers replace the public work of those who will use the outcome. I understand this concern. If I am parsing correctly, you and I are closer than I thought after seeing your first note. Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Process Evolution
Ted, I finding myself agreeing with you in many ways, but probably for different reasons. I'm trying to better formulate the differences instead of (or at least before) posting something incoherent, but, in the meantime... --On Friday, 16 September, 2005 16:45 -0700 Ted Hardie [EMAIL PROTECTED] wrote: At 2:28 PM -0700 9/16/05, Dave Crocker wrote: And since all other public development efforts for process change have frankly fallen flat, as Brian has cited, what is your basis for believing that a working group charter will somehow make yet-another public process more effective at developing a specification for change? Possibly I'm wrong in this, but I believe that the public process works when the community cares about the outcome. The IASA work is done, and I believe it is a success because enough people cared about the outcome to make it one. I think there are two conditions. The first is caring and the second is a very narrow and specific focus, with serious thought and debate going into that focus. There were good things about the AdminRest-IASA process and bad things about it, but there was a clearly-defined problem to be solved and a process that produced a solution. Dave believes, I think, that, as it worked out, it was the wrong problem to be solving at the time and I'm at least sympathetic to that view, but that doesn't change the properties of fairly well-defined problem, fairly well-defined solution space, mechanisms that were fairly open at critical times (although, IMO, not nearly open enough at others). In that regard, I see the difference between, e.g., IPR and Poisson as being the difference between creating a WG with a very specific focus and problem to be solved and creating a more or less standing WG and telling them to look at Process issues, figure out what needs to be done, and do it. As we could all predict from our experience with technical/engineering WGs with narrow and well-understood scope versus those that are expected to figure out what the problem is before trying to solve it, IPR was productive while Poisson spent a lot of time in the weeds. In that context, part of what concerns me about the PESCI idea is that the is no clear problem definition. If there were a clear and concise problem definition on which there was obvious community consensus, I wouldn't worry much about the committee -- the problem definition would provide a good platform from which to evaluate success. If it were a spontaneously-occurring design team in which a few colleagues got together to sort out a problem and generate a proposal that would be treated as an individual submission with not more authority than any other such submission, I wouldn't worry about it: as Dave points out, some of our best work comes out of such teams. But this one appears to represent neither of those cases. But this is neither of those cases. Instead, either the problem area is open-ended or there are ideas that will steer it that Brian has not made public (I assume from his note that it is the first). The group isn't going to be spontaneous, it is going to be hand-picked by the IETF Chair and presided over by him and that will give it and its product a certain level of authority. There is also actually a difference between sufficient people who care to do the work and a sufficient number of experienced and relevant people in the community who care and are involved enough to be sure the work is right. That, to me, is the area of greatest difference between process WGs and engineering/ specification ones: with the latter, most of the people who get in there and do serious work are directly involved with the quality of the outcome (whether they do well or not is a separate matter). Process WGs tend to draw a disproportionate number of people who are interested in and care about process but who are not otherwise significantly contributing to the IETF's technical work. So... As I said at the beginning of this thread, I believe using PESCI to scope the work and develop support for is fine. I'm even concerned about that for the reasons above. Agenda-setting is an important part of the process and the historical observations about the importance of being the party who picks the battlefield or moves first are relevant. If the group were to be chosen via a more open process, including some advice and consent by, e.g., the IESG or IAB or Nomcom, than Brian apparently contemplates, I'd feel better about it. But... I'm deeply concerned, however, about it doing the development work itself, as a process in which selected volunteers replace the public work of those who will use the outcome. While we agree, I think, about the risks of the selected volunteers part, I'm not sure whether we agree or not on the rest of the sentence. If, by public work of those who will use the outcome you intend to suggest a process that is controlled by the IESG, I don't think that works either. The
Possible new Real-Time Applications and Infrastucture (RAI) Area
As mentioned in the recent call for NomCom volunteers, the IESG is considering the creation of a new area, as set out below. We solicit feedback from the community on the scope of this potential new area as well as the impact on the IETF's infrastructure and efficiency of setting up this new area. We need to decide quite quickly, to fit the NomCom schedule. Please write to iesg@ietf.org, or to ietf@ietf.org if you want community discussion of your comment. (There's no need to write to both!) Brian Carpenter - Real-Time Applications and Infrastucture (RAI) Area Description The Real-Time Applications and Infrastructure Area develops protocols and architectures for delay-sensitive interpersonal communications. Work in this area serves an emerging industry whose applications and services include voice and video over IP, instant messaging and presence. These applications and services are real-time in the sense that delay impedes human participation in the associated systems. The RAI Area is seeded with existing working groups from the Transport and Applications Area: SIP, SIPPING, XCON, SIMPLE, GEOPRIV, ECRIT, ENUM, IPTEL, MEGACO, MMUSIC, IEPREP, SPEECHSC, and SIGTRAN. A good rule of thumb for the incorporation of new work into RAI, as opposed to Transport or Applications, is that the work in question has major goals supporting instant interpersonal communication or its infrastructure. For example, they can range from applications to help users make decisions about how best to communicate using presence services, to session signaling protocols and emergency call routing solutions, to work on the layer five issues for Internet telephony. Like all areas of the IETF, the RAI Area draws on the work of numerous other areas, and as such there can be no neat mathematical boundaries delineating RAI's work from the rest of the IETF. The new area will allow an existing community within the IETF to solidify its vision and to benefit from increased institutional support. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
