Re: article on innovation and open standards
On Tue, 14 May 2013, Dale R. Worley wrote: The critical difference is that the IETF is an organization of *buyers* rather than an organization of *sellers*. Not that I have been active in the IETF that long (only a few years), but IETF is pretty vendor-heavy. Otoh hand the whole point with IETF is that *nobody* is *excluded*, it consists of all interested parties and the barrier of entry is really low. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: article on innovation and open standards
On 05/15/2013 02:00 AM, Mikael Abrahamsson wrote: Otoh hand the whole point with IETF is that *nobody* is *excluded*, it consists of all interested parties and the barrier of entry is really low. That's what many of us would like to believe. But IETF certainly doesn't consist of all interested parties, and the barrier to effective participation (regularly showing up at meetings all over the world and spending significant time participating in mailing lists) can be prohibitively high. Yes, I'm aware that some people (including myself) have effectively participated on occasion without doing either of the above. But I think it's hard to effectively participate in IETF on a regular basis without a significant investment in both time and money. Keith
Re: article on innovation and open standards
On Wed, 15 May 2013, Keith Moore wrote: Yes, I'm aware that some people (including myself) have effectively participated on occasion without doing either of the above. But I think it's hard to effectively participate in IETF on a regular basis without a significant investment in both time and money. Personally I've only been on a single physical IETF meeting. I participate mainly via mailing lists. And yes, it's hard to participate without spending (significant) time. I don't know how else this could be done though. It's at least my opinion that if time is made available, the barrier of entry is probably the lowest of any similar organisation I can think of. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: article on innovation and open standards
On 05/15/2013 02:42 AM, Mikael Abrahamsson wrote: On Wed, 15 May 2013, Keith Moore wrote: Yes, I'm aware that some people (including myself) have effectively participated on occasion without doing either of the above. But I think it's hard to effectively participate in IETF on a regular basis without a significant investment in both time and money. Personally I've only been on a single physical IETF meeting. I participate mainly via mailing lists. And yes, it's hard to participate without spending (significant) time. I don't know how else this could be done though. It's at least my opinion that if time is made available, the barrier of entry is probably the lowest of any similar organisation I can think of. I'd like to see WGs be more pro-active about periodically summarizing the salient points of their proposals, determining which parties outside of the WG are likely to be affected, explicitly soliciting input from those parties, and explicitly considering that input in their deliberations. Some WGs do this, but for most WGs I don't think it happens often enough or formally/transparently enough. Last Call shouldn't be the first time that we explicitly solicit feedback on proposals from interested parties outside the WG. As far as I can tell, the primary reason that WGs are so resistant to IESG feedback is that too often the WGs have labored long and hard with little or no feedback from external sources, and they've reached consensus mostly by exhaustion. By the time a document gets to IESG review and community-wide Last Call, the WG is usually too exhausted and/or too committed to that particular solution to fix any major flaws. At this point there are often no good solutions - simple text changes and IESG notes are usually inadequate, and publishing the document in its current form may do more harm than good. But if WGs got feedback from outside parties much earlier in the process, there's a much better chance that such problems could be fixed before the WG were exhausted and committed. Of course anyone can send input to a WG's mailing list at any time. But someone who doesn't regularly follow the mailing list can have a difficult time understanding the state of things and knowing how and when to provide useful input. Keith
Re: NomCom 2013-2014 Call for Volunteers - CORRECTED dates in first sentence
For diversity purposes in NomCom-participants we may need both face-to-face participants and remote participant opportunities considered (may be 5% NomCom to be remote). RFC3777 does make conditions, but changing it in IETF may not be wanted by active participants because they are face-to-face ones. I know that if I write a I-D for update I may have about 1200 participants that will go against my proposals so I will need to find 1000 remote participants. IMHO, it is hard to make 1200 face-to-face participants to change their mind, but not hard to find 1000 remote ones that agree. AB just comments from a remote participant, for future efforts. On 5/13/13, Mankin, Allison aman...@verisign.com wrote: The IETF nominating committee (nomcom) process for 2013-14 has begun. The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. This year, a challenge: let's get beyond the 100-mark for number of volunteers. Let's get to 200 volunteers! The details of the operation of the nomcom can be found in RFC 3777. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 3777, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended three are IETF 82, 83, 84, 85, 86. If you qualify, please volunteer. However, much as we want this, before you decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible. The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: Chris Griffiths IAB: Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG: Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) The primary activity for this nomcom will begin in July 2013 and should be completed in January 2014. The nomcom will have regularly scheduled conference calls to ensure progress. There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. Thus, being a nomcom member does require some time commitment. Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours) June 16, 2013, as follows: To: aman...@verisign.com Subject: Nomcom 2013-14 Volunteer Please include the following information in the email body: Your Full Name // First/Given Name followed by Last/Family Name // matching how you enter it in the IETF Registration Form) Current Primary Affiliation // Typically what goes in the Company field // in the IETF Registration Form [All email addresses used to register for the past 5 IETF meetings] Preferred email address Telephone number // For confirmation if selected You should expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag RESEND added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Volunteering for the nomcom is a great way to contribute to the IETF! I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple weeks. Thank you! Allison Mankin aman...@verisign.com P.S. Because the 2012-2013 nomcom is still at work, we cannot use the ietf addresses for the nomcom chair or the nomcom committee yet, so please send all the volunteer mail (and any questions/comments you may have) to the address given.
Re: article on innovation and open standards
And yes, it's hard to participate without spending (significant) time. I don't know how else this could be done though. It's at least my opinion that if time is made available, the barrier of entry is probably the lowest of any similar organisation I can think of. That is my experience as well, at least when talking about organisations that I think of as standards bodies. There are other forms of co-operation (just a set of interested people on a mailing list, for instance) where costs might be even lower. But it is hard for me to think there would not be at least some time spent, if you are making a comment on anything in any setting. You have to get somewhat familiar with the topic, you may have spent time finding out that there is a discussion that you want to participate in to begin with, you may have invested your own time in building something which made you an expert on the topic, etc. Anyway, I think relevance, timeliness, openness are probably higher up in my set of priorities for standards making than cost minimisation, except where costs are a barrier to the priorities higher up in priority. But in any case, the point that Keith made about explicitly searching and soliciting for outsider's input is important. Well run standards efforts do this, and try to reach out to people who might care. Even if they have no time or possibility to attend IETFs or join mailing lists. We should probably try to do it even more than we are now. Sounds like a task for working group chairs. Jari
Re: call for ideas: tail-heavy IETF process
I feel that the discussion is stuck on the different perceptions on whether an AD's actions are either blocking reasonable progress, or an essential correction to a mistake that went undetected. I'd like to make a couple of observations. First of all, we at the IESG process 10-25 documents every second week, and several points (comment or discuss) are raised for each one. Given that both working groups and the IESG consist of humans, I'm guessing that none of us are making perfect decisions all the time. While the Discuss Criteria document is very useful, I'd warn against trying to codify the proper behaviour too much. It would be very difficult, and ultimately it comes down to making a call on whether an issue is really crucial for the Internet or not. I feel that the discussion and pressure from other ADs and authors and the rest of the working group is a more useful avenue to ensure that we really are fixing the necessary bugs and only those. And I know you are doing that - lets make sure we keep doing it. If you see something, say something. It is everyone's responsibility to try to do the right thing, and if you feel it is not happening, say so. I think the current IESG has a very good mood for receiving feedback and acting on it. (Speaking as the longest serving member in the current IESG, who frequently gets shown to be wrong by other ADs or WG folk.) In addition, as discussed separately, moving more of the issue resolution to the open and to the WG is a good thing. Jari
Re: article on innovation and open standards
And yes, it's hard to participate without spending (significant) time. I don't know how else this could be done though. It's at least my opinion that if time is made available, the barrier of entry is probably the lowest of any similar organisation I can think of. I like the article it is a great benefit for us (i.e. permissionless), and regarding time spent by participants, I think what is important is not what was *spent*, but what was *used*, time is money for us and IETF. The IETF is gaining time as long participants spend it for the IETF, but the most important times are the ones used in IETF. The beauty of IETF working time it is not fixed but dynamic per day (including weekends), no organisation can get similar gain only through *remote participations*. If IETF reduces remote participation services, then it will not gain much working times. I agree that IETF may not be using well the working times spent in WGs. I hope all WGs encourage permissionless for remote-participants. I spend 30 minutes for this, including reading thread, but my aim is used or benefits by someone. AB
Re: article on innovation and open standards
Mikael Abrahamsson wrote: On Tue, 14 May 2013, Dale R. Worley wrote: The critical difference is that the IETF is an organization of *buyers* rather than an organization of *sellers*. Not that I have been active in the IETF that long (only a few years), but IETF is pretty vendor-heavy. Some sections of the IETF would be more vendor-heavy, e.g. the routing area. In those sections, only a serious economic study might tell to which extent the patent pool (wikipedia is your friend) excludes the permissionless inventor in those IETF sections. The DNS aspects pertaining to very high throughput nameservers appears vendor-heavy. I noticed some patents that are under the IETF IPR policy in this niche IT sector, and I am not aware of patent pools in this specific case. Otoh hand the whole point with IETF is that *nobody* is *excluded*, it consists of all interested parties and the barrier of entry is really low. Still in the DNS field, the lack of support of authoritative nameservers for generic resource record type would be a barrier to entry for permisionless innovation, maybe with a root cause linked to vendor-weight in a portion of the DNS field. Thus, permissionless invention occurs with the DNS TXT resource record type. Let me insist that these two observations are hypotheses. -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, QC, Canada H2M 2A1 Tel. +1-514-385-5691
Re: article on innovation and open standards
On Wed, 15 May 2013, Keith Moore wrote: I'd like to see WGs be more pro-active about periodically summarizing the salient points of their proposals, determining which parties outside of the WG are likely to be affected, explicitly soliciting input from those parties, and explicitly considering that input in their deliberations. Some WGs do this, but for most WGs I don't think it happens often enough or formally/transparently enough. I agree. I'm also participating on nanog-l and other operator lists, and it's very rarely that a WG solicits feedback in those kinds of forums. Question is, if larger feedback is requested, a lot of the time a larger feedback will be generated, and more work needed to go through this feedback and answer it. End result might be better, but overall workload would be up, both in preparation phase and when feedback is coming in. I'm sure end result would probably be better, but more work would be needed, probably resulting in less technical work being done. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: article on innovation and open standards
On 05/15/2013 10:00 AM, Mikael Abrahamsson wrote: On Wed, 15 May 2013, Keith Moore wrote: I'd like to see WGs be more pro-active about periodically summarizing the salient points of their proposals, determining which parties outside of the WG are likely to be affected, explicitly soliciting input from those parties, and explicitly considering that input in their deliberations. Some WGs do this, but for most WGs I don't think it happens often enough or formally/transparently enough. I agree. I'm also participating on nanog-l and other operator lists, and it's very rarely that a WG solicits feedback in those kinds of forums. Question is, if larger feedback is requested, a lot of the time a larger feedback will be generated, and more work needed to go through this feedback and answer it. End result might be better, but overall workload would be up, both in preparation phase and when feedback is coming in. I'm sure end result would probably be better, but more work would be needed, probably resulting in less technical work being done. We need to be careful about the tendency to measure IETF's output in terms of the number of RFCs produced. I'd like to see IETF produce fewer (and sometimes shorter) RFCs of more relevance and higher technical quality, than we do now. Keith
Re: call for ideas: tail-heavy IETF process
On 5/14/2013 5:53 PM, Ted Lemon wrote: On May 14, 2013, at 8:27 PM, Joe Touch to...@isi.edu wrote: That is what happens exactly because the DISCUSS holds up the document, and most ADs don't want to burn time stalling their documents if there's a way around that delay. It can only happen if an author values getting their document through the process more than getting it right, in which case one has to wonder why they tried to publish the document in the first place. (I assume you meant authors, not ADs above). No; there are times when the document authors are pressured by ADs to do anything to resolve pending DISCUSSes, rather than stand up to the fact that the issue is either incorrect or the DISCUSS is invalid. The IESG processes documents quite quickly; I don't think it's valid to say that there is some terrifying stall in the document process as a result of the IESG, such that an author needs to chew off their leg to finally get the thing through. Well, there are IESG members who stand their ground even when it's incorrect, such as: - claiming that determining WG consensus is up to the AD, then repeatedly demanding evidence of that consensus - failing to drop a DISCUSS even when it meets their own criteria Those hold up a document too, as you should know (these are examples from your review of my doc). As does demanding a document revision while there remain open ballot positions, as was done today - on this document, to address your pending DISCUSS. Joe
Re: call for ideas: tail-heavy IETF process
On 5/14/2013 4:57 PM, Joel M. Halpern wrote: And your bottom line is exactly what te rules say, what I said, what Ted said, and what Joe agreed is reasonable. Unfortunately, it's not what happens/is happening right now. Joe
Re: call for ideas: tail-heavy IETF process
On 5/14/2013 4:03 PM, Ted Lemon wrote: The whole point of a DISCUSS is to have a discussion. The *whole* point of a DISCUSS is to hold a document in IETF review until a discussion is *resolved*. There are thus three parts: - having a discussion - pausing the document - waiting for resolution Nothing limits the IESG to having a discussion by issuing a DISCUSS; they can issue COMMENTs in any position and simply ask for a dialogue. Because DISCUSS includes these other properties, it influences authors to make changes simply to make a DISCUSS go away, due to pressure by the IESG or their own ADs. That's why they need to be used only where that pressure is appropriate and not inappropriate; that's the reason there are both DISCUSS and NON-DISCUSS criteria, and why it's very important for those in IESG review to hold the IESG to that distinction. Joe
Re: call for ideas: tail-heavy IETF process
On 5/14/2013 9:54 PM, Keith Moore wrote: Publishing broken or unclear documents is not progress. Keith Broken, agreed. Unclear, nope - please review the NON-DISCUSS criteria, notably: The motivation for a particular feature of a protocol is not clear enough. At the IESG review stage, protocols should not be blocked because they provide capabilities beyond what seems necessary to acquit their responsibilities. The DISCUSS isn't there to make documents better - that's for COMMENTs. A DISCUSS there to catch a set of problems and to *block* the document's progress until that problem is resolved. Joe
Re: call for ideas: tail-heavy IETF process
On 05/15/2013 10:39 AM, Joe Touch wrote: On 5/14/2013 9:54 PM, Keith Moore wrote: Publishing broken or unclear documents is not progress. Keith Broken, agreed. Unclear, nope - please review the NON-DISCUSS criteria, notably: The motivation for a particular feature of a protocol is not clear enough. At the IESG review stage, protocols should not be blocked because they provide capabilities beyond what seems necessary to acquit their responsibilities. The DISCUSS isn't there to make documents better - that's for COMMENTs. A DISCUSS there to catch a set of problems and to *block* the document's progress until that problem is resolved. I strongly disagree with what the NON-DISCUSS criteria say. DISCUSS isn't just for blocking documents. And document quality is as important (in the sense that poor document quality can lead to as many interoperability or other problems) as technical correctness. Why are people trying to sabotage IESG? Keith
Re: call for ideas: tail-heavy IETF process
On 5/14/2013 10:05 PM, Keith Moore wrote: ... For that matter, working groups are too often echo chambers where a set of people manage to isolate themselves from input from those whose work they might otherwise effect.Some people seem to think that working group output should be sacrosanct. There's absolutely no reason to believe that. WGs often make technical mistakes that are uncovered by external review. Even when no such mistakes are encountered, WG output rarely represents rough consensus of all interested parties, and WGs often fail to do due diligence in considering the interests of the broad spectrum of those potentially affected by their work. Of course IESG isn't infallible either, and shouldn't behave as if it is. But review by experts from outside of the WG generally seems to improve the IETF's output. Sure, but note that there is a specific NON-DISCUSS criteria on this point: Disagreement with informed WG decisions that do not exhibit problems outlined in Section 3.1 (DISCUSS Criteria). In other words, disagreement in preferences among technically sound approaches. Finding technical mistakes is good, but imposing the IESG's preferred technical solution over the WG's preference is inappropriate, but happens. As important as the DISCUSS criteria are, there are NON-DISCUSS criteria that ought to be more carefully followed - including the point that disagreements with the WG or clarifications are not justification for DISCUSS. Strongly disagree. First, DISCUSS only means that there's something the AD wants to discuss. As noted in another post, it means hold this doc until the DISCUSS is resolved. Discussions can happen as a result of COMMENTs in any IESG position. In particular, disagreements with the WG about technical quality are always appropriate for IESG to raise. Yes. same is true of requests for clarification. Sometimes - there's a specific NON-CRITERIA about clarification, however: The motivation for a particular feature of a protocol is not clear enough. At the IESG review stage, protocols should not be blocked because they provide capabilities beyond what seems necessary to acquit their responsibilities. Ted pointed out that DISCUSS doesn't mean the IESG doesn't like a document - agreed, but it *does* hold up a document until the IESG member clears it. But there are also procedures within IESG to ignore a single DISCUSS vote. So ultimately it takes multiple DISCUSS votes to hold up a document indefinitely. Those procedures take time, so even a single DISCUSS holds things up. DISCUSS is a heavyweight mechanism that holds up document resolution; it should be used only where absolutely appropriate. If the IESG wants to have a discussion with the authors, they are welcome to participate in the WGs or IETF LC, or to contact them out of band. DISCUSS is not supposed to be a heavyweight mechanism, and actually it's hard to imagine a lighter weight mechanism that gives IESG review any weight. Oh, I'm not suggesting removing the DISCUSS mechanism. First, it ought to have a new name - one that makes clear that this is heavyweight. Perhaps HOLD FOR REVISION, which is the net effect it already has. The key bug is that the IESG can't easily issue a question without casting a ballot position, but that may also be a feature. It might be useful to be able to issue a QUESTION withouth changing a ballot position, though. Informal communication doesn't generally work well in practice because it lacks transparency, and it can cause additional delay without resolving the problem. Voting DISCUSS puts pressure on BOTH the AD and the WG to resolve the issue. Which is appropriate only when the IESG should have the right to force that resolution, and when the path to that resolution is sufficiently clear. If there is no path, then vote NO. If forcing resolution and putting pressure isn't warranted, issue a COMMENT on any other ballot position. Joe
Re: call for ideas: tail-heavy IETF process
On May 15, 2013, at 10:39 AM 5/15/13, Joe Touch to...@isi.edu wrote: On 5/14/2013 9:54 PM, Keith Moore wrote: Publishing broken or unclear documents is not progress. Keith Broken, agreed. Unclear, nope - please review the NON-DISCUSS criteria, notably: The motivation for a particular feature of a protocol is not clear enough. At the IESG review stage, protocols should not be blocked because they provide capabilities beyond what seems necessary to acquit their responsibilities. The DISCUSS isn't there to make documents better - that's for COMMENTs. A DISCUSS there to catch a set of problems and to *block* the document's progress until that problem is resolved. I'll agree with you *if* you consider an unclear description of a feature of a protocol, severe enough that reader of the specification are not able to build interoperable implementations, as a problem for which a DISCUSS can be posted. In my opinion, there are many ways in which document can be unclear beyond the motivation for a particular feature of a protocol is not clear enough. - Ralph Joe
Re: call for ideas: tail-heavy IETF process
On May 15, 2013, at 10:41 AM, Keith Moore mo...@network-heretics.com wrote: The motivation for a particular feature of a protocol is not clear enough. At the IESG review stage, protocols should not be blocked because they provide capabilities beyond what seems necessary to acquit their responsibilities. I strongly disagree with what the NON-DISCUSS criteria say. DISCUSS isn't just for blocking documents. And document quality is as important (in the sense that poor document quality can lead to as many interoperability or other problems) as technical correctness. The interpretation of this particular NON-DISCUSS criterion that Joe has given is simply wrong. The key word to pay attention to to see the error is motivation. The point of this criterion is to eliminate a very specific sort of stall that has been known to happen in the past: the stall where the AD doesn't understand why the document is being put forward at all, and therefore blocks the document until the authors explain the motivation behind the document to the satisfaction of the AD who is holding the DISCUSS. This is a real issue that has created real problems in the past, and that is why it is in the NON-DISCUSS criteria. But this criterion _does not_ mean that a criticism that the document itself is unclear is not a valid reason to hold a DISCUSS on it. In fact, it's an excellent reason to hold a DISCUSS on it. A lack of clarity in a document can result in it being implemented incorrectly, or in the case of a BCP, interpreted incorrectly. Or in extreme cases, not read at all. This is a bad outcome, worth spending time on, even if the authors would rather be quit of it.
Re: call for ideas: tail-heavy IETF process
IMO, IESG should have grounds to reject any document that isn't specifically authorized in a WG's charter. - Keith On May 15, 2013, at 10:55 AM, Ted Lemon ted.le...@nominum.com wrote: On May 15, 2013, at 10:41 AM, Keith Moore mo...@network-heretics.com wrote: The motivation for a particular feature of a protocol is not clear enough. At the IESG review stage, protocols should not be blocked because they provide capabilities beyond what seems necessary to acquit their responsibilities. I strongly disagree with what the NON-DISCUSS criteria say. DISCUSS isn't just for blocking documents. And document quality is as important (in the sense that poor document quality can lead to as many interoperability or other problems) as technical correctness. The interpretation of this particular NON-DISCUSS criterion that Joe has given is simply wrong. The key word to pay attention to to see the error is motivation. The point of this criterion is to eliminate a very specific sort of stall that has been known to happen in the past: the stall where the AD doesn't understand why the document is being put forward at all, and therefore blocks the document until the authors explain the motivation behind the document to the satisfaction of the AD who is holding the DISCUSS. This is a real issue that has created real problems in the past, and that is why it is in the NON-DISCUSS criteria. But this criterion _does not_ mean that a criticism that the document itself is unclear is not a valid reason to hold a DISCUSS on it. In fact, it's an excellent reason to hold a DISCUSS on it. A lack of clarity in a document can result in it being implemented incorrectly, or in the case of a BCP, interpreted incorrectly. Or in extreme cases, not read at all. This is a bad outcome, worth spending time on, even if the authors would rather be quit of it.
Re: call for ideas: tail-heavy IETF process
Joe, Broken, agreed. Yep. Unclear, nope - please review the NON-DISCUSS criteria, notably: The motivation for a particular feature of a protocol is not clear enough. At the IESG review stage, protocols should not be blocked because they provide capabilities beyond what seems necessary to acquit their responsibilities. The DISCUSS isn't there to make documents better - that's for COMMENTs. A DISCUSS there to catch a set of problems and to *block* the document's progress until that problem is resolved. Yes, but note that there are multiple aspects of unclear. You cite above the motivation aspect. There's also a DISCUSS criteria for other forms of unclear, e.g., if I can't figure out what I should do in the implementation, it would be an issue. The criteria document confirms: The specification is impossible to implement due to technical or clarity issues. Sure, but note that there is a specific NON-DISCUSS criteria on this point: Disagreement with informed WG decisions that do not exhibit problems outlined in Section 3.1 (DISCUSS Criteria). In other words, disagreement in preferences among technically sound approaches. Finding technical mistakes is good, but imposing the IESG's preferred technical solution over the WG's preference is inappropriate, but happens. If you are hit with a Discusss that is about preferring another technical solution, you should push back. Jari
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: call for ideas: tail-heavy IETF process
On May 15, 2013, at 6:06 PM, Keith Moore mo...@network-heretics.com wrote: IMO, IESG should have grounds to reject any document that isn't specifically authorized in a WG's charter. - Keith Why? There's definitely a process failure there, and it should be blamed on the WG chairs and/or the AD, who should have either moved the work out of the working group or worked on updating the charter. But the IESG handles documents from both working groups and from individuals, and individuals don't have charters. Why should an otherwise good document be rejected after it has gone through IETF last call and has been brought to the IESG by one of their own? Yoav
Re: call for ideas: tail-heavy IETF process
+1 to what Jari says below. From my perspective, the important things to keep in mind: 1) Discuss criteria should be principles, not rigid rules. The details of the issue at hand always matter, and it will sometimes come down to judgement calls where reasonable individuals just might disagree. And if we try to replace judgement with rigid, overly specified rules, we surely won't like the results. i.e, the process requires we do X, when X is really a bad outcome overall. 2) There will always be judgement calls, where an AD and an author (or WG) don't necessarily agree. Fine tuning the rules won't fix that. By default, when there is disagreement, the presumption needs to be the AD could be right and needs to be convinced. That is the essence of what a DISCUSS is intended to be. If the dialog between author/WG/AD is not progressing, bring in someone else. I.e., the way to overrule a stubborn AD is to convince other ADs (and/or WG members) to weigh in based on the merits. If an author/WG can't do that, that says something... Thomas Jari Arkko jari.ar...@piuha.net writes: I feel that the discussion is stuck on the different perceptions on whether an AD's actions are either blocking reasonable progress, or an essential correction to a mistake that went undetected. I'd like to make a couple of observations. First of all, we at the IESG process 10-25 documents every second week, and several points (comment or discuss) are raised for each one. Given that both working groups and the IESG consist of humans, I'm guessing that none of us are making perfect decisions all the time. While the Discuss Criteria document is very useful, I'd warn against trying to codify the proper behaviour too much. It would be very difficult, and ultimately it comes down to making a call on whether an issue is really crucial for the Internet or not. I feel that the discussion and pressure from other ADs and authors and the rest of the working group is a more useful avenue to ensure that we really are fixing the necessary bugs and only those. And I know you are doing that - lets make sure we keep doing it. If you see something, say something. It is everyone's responsibility to try to do the right thing, and if you feel it is not happening, say so. I think the current IESG has a very good mood for receiving feedback and acting on it. (Speaking as the longest serving member in the current IESG, who frequently gets shown to be wrong by other ADs or WG folk.) In addition, as discussed separately, moving more of the issue resolution to the open and to the WG is a good thing. Jari
Re: Gather Profiles/Resumes [was Re: call for ideas: tail-heavy IETF process]
I don't think the IETF needs to be in the profile/resume business. There are plenty of other places that do a fine job already. What I do think the IETF should do is *require* that participants identify themselves. That means knowing who they are (a name and email contact) and an affiliation. For 80% of the participants, this info is not very hard to figure out (see below). But we also have participants that use obscure email handles that don't correlate to anything obvious, whether a real person or to a name in the list of registered attendees, etc. I suspect these folk are *not* intenending to be anonymous participants, but in practice they are. And yes, knowing who someone is, their background and who they work for is important to me in figuring out how to guage their input. E.g., I would likely pay more attention to an operator's comments on a proposed use case than from someone else. How to figure out who someone is: 1) look at the list of registered attendees. (but that doesn't include email addresses, so no clean way to map attendee name into email addresses being used). Also, for some reason, some people who register don't bother giving an affiliation. In some cases this is intentional, but there are others where it doesn't make sense (e.g., someone who has worked for the same employer for 10+ years and is still working for that employer). E.g., if you look at the registration list for Orland0, fully 180 names don't list affiliations -- and there are a number pretty obvious surprises in that list... 2) look at email addresses. But nowadays they are often generic (e.g., gmail) and don't correlate back to an obvious sponsor. 3) Google names, look at authorship info in RFCs, linked in, etc. Works in a lot of cases, but is sometimes more work than seems appropriate. And for those with less history in the IETF, knowing where to look for this stuff is trickier. But even doing the above, there are people participating (e.g., posting on the IETF list) who I don't know who they are, even after spending some time trying to figure who who they are and what their background is. For an open standards organization, that somehow doesn't seem quite right. Thomas
Re: call for ideas: tail-heavy IETF process
On 5/15/2013 7:55 AM, Ted Lemon wrote: On May 15, 2013, at 10:41 AM, Keith Moore mo...@network-heretics.com wrote: The motivation for a particular feature of a protocol is not clearenough. At the IESG review stage, protocols should not be blocked because they provide capabilities beyond what seems necessary to acquit their responsibilities. I strongly disagree with what the NON-DISCUSS criteria say. DISCUSS isn't just for blocking documents. And document quality is as important (in the sense that poor document quality can lead to as many interoperability or other problems) as technical correctness. The interpretation of this particular NON-DISCUSS criterion that Joe has given is simply wrong. The key word to pay attention to to see the error is motivation. The point of this criterion is to eliminate a very specific sort of stall that has been known to happen in the past: the stall where the AD doesn't understand why the document is being put forward at all, and therefore blocks the document until the authors explain the motivation behind the document to the satisfaction of the AD who is holding the DISCUSS. I'm impressed that you have such a specific interpretation that this criteria refers to the entire document, even when it talks about the feature of a protocol. So now we're supposed to accept your interpretation of this rather than the explicit text? This is a real issue that has created real problems in the past, and that is why it is in the NON-DISCUSS criteria. But this criterion _does not_ mean that a criticism that the document itself is unclear is not a valid reason to hold a DISCUSS on it. Agreed - this does not refer to the document. It refers to a specific feature of a protocol. In fact, it's an excellent reason to hold a DISCUSS on it. A lack of clarity in a document can result in it being implemented incorrectly, or in the case of a BCP, interpreted incorrectly. I agree that THESE are good reasons for a DISCUSS, but simply not being clear is NOT. Or in extreme cases, not read at all. There's nothing you can do about that; RFCs are not read all the time. Joe
Re: call for ideas: tail-heavy IETF process
On May 15, 2013, at 12:36 PM, Joe Touch to...@isi.edu wrote: I'm impressed that you have such a specific interpretation that this criteria refers to the entire document, even when it talks about the feature of a protocol. The motivation for a feature of a protocol is not clear enough. What's ambiguous or subject to interpretation about that? The commentary exactly echoes what I said. This does not mean that all lacks of clarity are not DISCUSS criteria: only that a lack of clarity with respect to motivation is not.
Re: call for ideas: tail-heavy IETF process
On 5/15/2013 10:15 AM, Ted Lemon wrote: On May 15, 2013, at 12:36 PM, Joe Touch to...@isi.edu wrote: I'm impressed that you have such a specific interpretation that this criteria refers to the entire document, even when it talks about the feature of a protocol. The motivation for a feature of a protocol is not clear enough. What's ambiguous or subject to interpretation about that? The commentary exactly echoes what I said. This does not mean that all lacks of clarity are not DISCUSS criteria: only that a lack of clarity with respect to motivation is not. And yet that is the precise issue of your pending DISCUSS on my current document. You don't agree that the motivation for the difference between using 16-bit vs. 32-bit ExIDs is sufficient, even though that is already discussed in the document. Joe
Re: call for ideas: tail-heavy IETF process
At 08:06 15-05-2013, Keith Moore wrote: IMO, IESG should have grounds to reject any document that isn't specifically authorized in a WG's charter. I read a few charters: core: Dec 2099 - HOLD (date TBD) Constrained security bootstrapping specification submitted to IESG ancp: Sep 2010 - Access Node Control Protocol (ANCP) Last Call Dec 2010 - ANCP MIB Last Call Dec 2010 - ANCP Multicast Extensions last call Jan 2011 - ANCP applicability to PON last call Mar 2011 - Re-charter or conclude Working Group 6man: Jan 2008 - Submit PPP Compression Negotiation specification to IESG as a Proposed Standard Mar 2008 - Determine way forward for ULA-C specification l2tpext: Mar 2008 - Submit Internet-Draft of PPP over L2TPv3 to IESG Done - WG Last Call on TDM over L2TPv3 Jun 2008 - WG Last Call on IP over L2TPv3 drinks: Apr 2012 - Request publication of SPPP over SOAP Document Apr 2012 - Request publication of Framework Document straw: Nov 2011 - Specification for a SIP overload control mechanism based on implicit/explicit feedback to IESG for publication as Proposed Standard Feb 2012 - Specification for a SIP load filtering mechaism to IESG for publication as Proposed Standard idr: Mar 2010 - Solicit work items for scalability improvements Aug 2010 - Submit AS-wide Unique BGP Identifier for BGP-4 to IESG as a Proposed Standard Aug 2010 - Submit Dynamic Capability for BGP-4 to IESG as a Proposed Standard Aug 2010 - Submit ASpath ORF draft to IESG as a Proposed Standard Aug 2010 - Submit MIB v2 for BGP-4 to IESG as a Proposed Standard Nov 2010 - Submit BGP Support for Four-octet AS Number Space (revised version) to IESG as a Proposed Standard Nov 2010 - Submit Revisions to the BGP 'Minimum Route Advertisement Interval' to IESG as a Proposed Standard Nov 2010 - Submit Advertisement of Multiple Paths in BGP to IESG as a Proposed Standard Nov 2010 - Submit BGP Link Bandwidth Extended Community to IESG as a Proposed Standard Nov 2010 - Submit Advertisement of the best external route in BGP to IESG as a Proposed Standard Dec 2010 - Submit Multisession BGP to IESG as a Proposed Standard Dec 2010 - Submit Error Handling for Optional Transitive BGP Attributes to IESG as a Proposed Standard Dec 2010 - Submit ASpath ORF to IESG as a Proposed Standard Dec 2010 - Revise WG charter pim: Aug 2011 - First WG version of udated RFC 4601 Aug 2011 - Submit a more reliable PIM solution (refresh reduction) to the IESG Nov 2011 - Submit a population count extension to PIM to the IESG Dec 2011 - Submit update of RFC 4601 to IESG for advancement to Draft Standard pkix: Sep 2007 - Progression of CRMF, CMP, and CMP Transport to DRAFT Standard Sep 2007 - Progression of Qualified Certificates Profile RFC to DRAFT Standard Sep 2007 - Progression of Certificate CRL Profile RFC to DRAFT Standard Sep 2007 - Progression of Time Stamp Protocols RFC to DRAFT Standard Sep 2007 - Progression of Logotype RFC to DRAFT Standard Nov 2007 - Progression of Proxy Certificate RFC to DRAFT Standard Nov 2007 - Progression of Attribute Certificate Profile RFC to DRAFT standard Feb 2008 - Update to CMC approved as PROPOSED Standard Mar 2008 - ECC Algorithms approved as PROPOSED Standard RFC Mar 2008 - Progression of CMC RFCs to DRAFT Standard Mar 2008 - SCVP approved as PROPOSED Standard RFC ippm: Nov 2010 - Final version of process draft Nov 2010 - Implementation report based on process draft Mar 2011 - Revise charter ppsp: Dec 2010 - Submit problem statement to IESG as Informational Apr 2011 - Submit architectural survey to IESG as Informational Apr 2011 - Submit requirements document to IESG as Informational Aug 2011 - Submit PPSP peer protocol to IESG as Proposed Standard Aug 2011 - Submit PPSP tracker protocol to IESG as Proposed Standard Dec 2011 - Submit usage guide to IESG to IESG as Informational I did not verify whether the drafts mentioned about left the working group or not. The IESG would be rejecting a lot of documents if it looked into what was authorized by the charter. At 08:33 15-05-2013, Yoav Nir wrote: Why? There's definitely a process failure there, and it should be blamed on the WG chairs and/or the AD, who should have either moved the work out of the working group or worked on updating the charter. There would be a lot of WG chairs and/or ADs to blame as there are dates up to five years in the past in the charter extracts mentioned above. At 07:25 15-05-2013, Joe Touch wrote: Well, there are IESG members who stand their ground even when it's incorrect, such as: - claiming that determining WG consensus is up to the AD, then repeatedly demanding evidence of that consensus If there was WG consensus it shouldn't be much of a problem to provide evidence. I read a write-up
Re: call for ideas: tail-heavy IETF process
On May 15, 2013, at 1:23 PM, Joe Touch to...@isi.edu wrote: You don't agree that the motivation for the difference between using 16-bit vs. 32-bit ExIDs is sufficient, even though that is already discussed in the document. I don't think this is a topic that the IETF as a whole is likely to find very interesting. However, if anyone is curious, they are welcome to read the DISCUSS here and see if they agree with your characterization of my question: http://datatracker.ietf.org/doc/draft-ietf-tcpm-experimental-options/ballot/ For those who may be interested, the last sentence of the first paragraph is the motivation for this being a DISCUSS position (as opposed to a comment).
Re: Gather Profiles/Resumes [was Re: call for ideas: tail-heavy IETF process]
--On Wednesday, May 15, 2013 18:25 +0200 Thomas Narten nar...@us.ibm.com wrote: I don't think the IETF needs to be in the profile/resume business. There are plenty of other places that do a fine job already. What I do think the IETF should do is *require* that participants identify themselves. That means knowing who they are (a name and email contact) and an affiliation. For 80% of the participants, this info is not very hard to figure out (see below). But we also have participants that use obscure email handles that don't correlate to anything obvious, whether a real person or to a name in the list of registered attendees, etc. I suspect these folk are *not* intenending to be anonymous participants, but in practice they are. Thomas, I completely agree, but.. Also, for some reason, some people who register don't bother giving an affiliation. In some cases this is intentional, but there are others where it doesn't make sense (e.g., someone who has worked for the same employer for 10+ years and is still working for that employer). E.g., if you look at the registration list for Orland0, fully 180 names don't list affiliations -- and there are a number pretty obvious surprises in that list... Ok. I'm probably one of the 180, although I would be surprised if I were one of the obvious surprises. I had a corporate affiliation until somewhat over a decade ago and showed that affiliation when asked for it on registration, IAB and IESG mini-biographies, etc. Since then, I have been an independent consultant. I don't consider the way my business is organized, whether it has other employees or not, etc., to be any of the IETF's business. In order to respond to an implied part of your question, in that last decade or so, I have never been paid by a client to attend IETF or to represent that client's interests. That has been largely by choice and driven by a desire to stay absolutely independent. I have accepted travel money and waivers of registration fees on a few (very few) occasions, but never, in my post-corporate life, compensation for my time spent of IETF. So, what would you have me (and others like me) put on registration forms so that I'm not part of that undifferentiated 180 names? I objected several years ago to the Secretariat listing me as Independent because I know of multiple organizations/ enterprises with Independent in their names (including, apparently, six separate ones with second-level domain names in six popular gTLDs I checked). You tell me how to fill in that form a way that doesn't misrepresent my situation or disclose information that is irrelevant to the IETF and I will happily do it. Up through the last IETF meeting, I could most closely approximate that condition by leaving the information box blank. To pursue this a tad further, for the purposes for which you want affiliations, someone who is legally a consultant or independent contractor rather than an employee but who is being paid by a firm to attend IETF may have no less obligation to consider the interests of that firm in their IETF actions than you have to IBM. They might even have more of an obligation. If you want affiliation information in the interest of openness --and, again, I think that would be a really good idea-- than such a person is not independent or representing only themselves. If we are trying to determinate affiliation to evaluate positions, he or she is definitely affiliated with that firm and should be listing it (ideally as consultant to... or contractor to...). On of the other side of that coin, in prior professional lives, I've been in situations in which an employer or research sponsor has essentially said you are welcome to attend IETF as long as you can show (in a way that will satisfy auditors) that you did so entirely on your own time, with no portion of your salary during that time or your expenses attributable to the company. In most cases, that person is as independent of company control over positions taken as I am -- far more so than a consultant who is being paid to represent a company at IETF or to come to IETF in order to advise the company on IETF strategy. She may even be constrained to not mention the company's name in conjunction with IETF efforts for fear that mention will be taken as endorsement. What would you like to see on the registration form? Finally, do any of the answers change if the consultant or contractor either is employed directly by a consulting firm that pays a salary or is an individual but more organized as a business than I have chosen to be? Is the affiliation you want the name of the nominal employer of the organizational identity of whomever is really paying the bills and/or calling the tune? Relative to overall IETF participation, all of the above may be edge cases. For reasons similar to those of the diversity debates, I have no way to guess how many there actually are in the registrant or participant communities.
Re: call for ideas: tail-heavy IETF process
On 5/15/2013 11:08 AM, Ted Lemon wrote: On May 15, 2013, at 1:23 PM, Joe Touch to...@isi.edu wrote: You don't agree that the motivation for the difference between using 16-bit vs. 32-bit ExIDs is sufficient, even though that is already discussed in the document. I don't think this is a topic that the IETF as a whole is likely to find very interesting. However, if anyone is curious, they are welcome to read the DISCUSS here and see if they agree with your characterization of my question: http://datatracker.ietf.org/doc/draft-ietf-tcpm-experimental-options/ballot/ For those who may be interested, the last sentence of the first paragraph is the motivation for this being a DISCUSS position (as opposed to a comment). Which is I think that using a 4-byte ExID runs a real risk of overflowing the available space in the TCP header in real-world circumstances. Except that the document already describes the ExID as either 16-bit or 32-bit: All ExIDs MUST be either 16-bits or 32-bits long. Motivation for the additional two bytes is already explained in the document in several places, notably: The second two bytes serve as a magic number. ... Using the additional magic number bytes helps the option contents have the same byte alignment in the TCP header as they would have if (or when) a conventional (non-experiment) TCP option codepoint is assigned. Use of the same alignment reduces the potential for implementation errors, especially in using the same word-alignment padding, if the same software is later modified to use a conventional codepoint. Use of the longer, 32-bit ExID further decreases the probability of such a false positive compared to those using shorter, 16-bit ExIDs. ... Use of the longer, 32-bit ExID consumes more space, but provides more protection against false positives. Which is why I feel this motivation isn't sufficient for a DISCUSS. I'd be glad to hear others' view of this as well. Joe
Re: call for ideas: tail-heavy IETF process
On 05/15/2013 02:48 PM, Joe Touch wrote: On 5/15/2013 11:08 AM, Ted Lemon wrote: I don't think this is a topic that the IETF as a whole is likely to find very interesting. However, if anyone is curious, they are welcome to read the DISCUSS here and see if they agree with your characterization of my question: http://datatracker.ietf.org/doc/draft-ietf-tcpm-experimental-options/ballot/ For those who may be interested, the last sentence of the first paragraph is the motivation for this being a DISCUSS position (as opposed to a comment). Which is I think that using a 4-byte ExID runs a real risk of overflowing the available space in the TCP header in real-world circumstances. Except that the document already describes the ExID as either 16-bit or 32-bit: All ExIDs MUST be either 16-bits or 32-bits long. Motivation for the additional two bytes is already explained in the document in several places, notably: The second two bytes serve as a magic number. ... Using the additional magic number bytes helps the option contents have the same byte alignment in the TCP header as they would have if (or when) a conventional (non-experiment) TCP option codepoint is assigned. Use of the same alignment reduces the potential for implementation errors, especially in using the same word-alignment padding, if the same software is later modified to use a conventional codepoint. Use of the longer, 32-bit ExID further decreases the probability of such a false positive compared to those using shorter, 16-bit ExIDs. ... Use of the longer, 32-bit ExID consumes more space, but provides more protection against false positives. Which is why I feel this motivation isn't sufficient for a DISCUSS. It certainly seems like a valid topic for an AD to want to discuss with a WG.And that's all that DISCUSS inherently means. Keith
Re: call for ideas: tail-heavy IETF process
On 05/15/2013 11:33 AM, Yoav Nir wrote: On May 15, 2013, at 6:06 PM, Keith Moore mo...@network-heretics.com wrote: IMO, IESG should have grounds to reject any document that isn't specifically authorized in a WG's charter. - Keith Why? There's definitely a process failure there, and it should be blamed on the WG chairs and/or the AD, who should have either moved the work out of the working group or worked on updating the charter. ADs shouldn't have to micro-manage the WGs and keep track of whether every single document that a WG is working on is authorized by its charter. Fundamentally, it's the WG chair's job to stay within the charter. What I was addressing with my above statement is that there seems to be a presumption on the part of some people that a WG can produce anything it wants, and that the IESG is under an obligation to approve such work unless it can object on some very specific grounds.I can understand something resembling such a presumption for work that the WG is specifically chartered to do. We don't want WGs investing their members' time and energy to produce something that will never see the light of day, and WG members need some assurance that their efforts are likely to bear fruit at least as far as publication is concerned. But I see no reason that a WG should be able to presume that the IESG should ultimately accept something that they weren't specifically chartered to do in the first place. Though probably a better remedy than to reject the document outright, would be for IESG to treat such documents as individual submissions. Keith
Re: article on innovation and open standards
From: Thierry Moreau thierry.mor...@connotech.com Some sections of the IETF would be more vendor-heavy, e.g. the routing area. In those sections, only a serious economic study might tell to which extent the patent pool (wikipedia is your friend) excludes the permissionless inventor in those IETF sections. My impression of the presentation is that it does not focus on innovation that is part of, and extends, an existing technological area, but rather innovation that uses existing technology as a platform upon which to build new technology. This sort of innovation is less vulnerable to attack via patents, but it is vulnerable to service providers that can differentially price the use of the platform within the new application. Dale
Re: article on innovation and open standards
From: Andrew Sullivan a...@anvilwalrusden.com The critical difference is that the IETF is an organization of *buyers* rather than an organization of *sellers*. Without wishing to be nasty, I will point out that we have way more vendors than operators participating in our standards development. That is actually what I mean... By sellers I mean sellers of telecommunications services. The equipment vendors generally favor the interests of the buyers of telecommunications services, who are their customers. Dale
Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
The claim (or one of the claims) is that some ADs may place Discusses that are intended to raise a discussion with the authors/WG that could equally have been raised with a Comment or through direct email. This, it is claimed, may unnecessarily delay the document from completing the publication process. Now the dangerous bit, Suppose the AD raised her concern by writing a Comment or sending an email and balloting No Objection. That would mean that the I-D would be approved for publication. At this point either: - the discussion goes on, but the document becomes an RFC anyway or - the responsible AD holds the document pending satisfactory completion of the discussion. I suggest that the former is a bad result. Not that the authors/WG will ignore the discussion, but if they disagree on something the AD considers very important, the authors/WG have no incentive to participate in the discussion. Of course, all participants in this thread so far would never behave like that, but there is a possibility that this will happen for some authors. I also suggest that the latter introduces exactly the same amount of delay as the Discuss. Personally (but this may reflect my Discusses) I find that an active engagement by the authors and the Discussing AD on the issue and the potential resolution, always leads to speedy progression of the document either with the AD feeling stupid, or the document improved. Both are adequate results. Adrian
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
On May 15, 2013, at 4:30 PM, Adrian Farrel adr...@olddog.co.uk wrote: I suggest that the former is a bad result. Not that the authors/WG will ignore the discussion, but if they disagree on something the AD considers very important, the authors/WG have no incentive to participate in the discussion. Of course, all participants in this thread so far would never behave like that, but there is a possibility that this will happen for some authors. This can also happen purely by accident—it need not involve malice on anyone's part.
Re: call for ideas: tail-heavy IETF process
On 5/15/2013 7:49 AM, Ralph Droms wrote: The DISCUSS isn't there to make documents better - that's for COMMENTs. A DISCUSS there to catch a set of problems and to*block* the document's progress until that problem is resolved. I'll agree with you *if* you consider an unclear description of a feature of a protocol, severe enough that reader of the specification are not able to build interoperable implementations, as a problem for which a DISCUSS can be posted. In my opinion, there are many ways in which document can be unclear beyond the motivation for a particular feature of a protocol is not clear enough. - Ralph Absolutely. Note that issues interfering with interoperability or correctness are among the explicit DISCUSS criteria. Joe
Re: Accessing tools from IETF pages
Tom, There's a compatibility view button in recent versions of IE that I've found helps with some websites. See http://windows.microsoft.com/en-us/internet-explorer/products/ie-9/features/compatibility-view. You can also find it in the Tools menu. Cheers, Andy On Fri, May 10, 2013 at 4:13 AM, t.p. daedu...@btconnect.com wrote: Tom Petch - Original Message - From: Dale R. Worley wor...@ariadne.com To: t.p. daedu...@btconnect.com Cc: ietf@ietf.org Sent: Wednesday, May 08, 2013 8:37 PM Subject: Re: Accessing tools from IETF pages From: t.p. daedu...@btconnect.com I wanted to submit an I-D so I wanted to access the tools, as I have done before, so I clicked on 'IETF Tools' from http://datatracker.ietf.org/wg/ and when that failed tried again with 'Tools Team Pages' from http://www.ietf.org/iesg/ with the same result. Can anyone else get to tools from that link? It resolves to http://tools.ietf.org/ which Internet Explorer (what else?) assures me cannot be displayed, either from the link or from typing it into the Open drop down. Well, all three of those links work for me at May 8 19:33:01 UTC 2013 using Firefox 18.0.2 on Linux. (For whatever that is worth.) I'd sniff the HTTP transaction to get some information on the specific failure mode. Dale Many thanks for that; if others can get to it, then that resolves my issue, I can always go via other means, until I get myself a trace and see what is really going on. Tom Petch Dale
Re: Gather Profiles/Resumes [was Re: call for ideas: tail-heavy IETF process]
John C Klensin john dash ietf at jck dot com wrote: I think it is all very well to ask for affiliations in principle and, also in principle, I agree that it is a good idea. But, in practice, I think there are a lot of clarifications and other changes that would be required and that might or might not be practical. I used the term Consultant in RFCs 4645 and 5645, instead of revealing the name of my company (which was different each time, and neither of which contributed any time or money to my WG effort). I did this because the WG at the time included a malicious contributor who had already contacted the HR department of another contributor's employer, asking them to professionally discipline the employee, because he had supported an RFC 3683 PR-action against the first contributor. Full disclosure can be a dangerous thing. -- Doug Ewell | Thornton, CO, USA http://ewellic.org | @DougEwell
Gen-ART Telechat review of draft-ietf-netmod-ip-cfg-09
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq Please wait for direction from your document shepherd or AD before posting a new version of the draft. This draft has not been updated since my Last Call review, so the information below remains unchanged. Document: draft-ietf-netmod-ip-cfg-09 Reviewer: Peter Yee Review Date: May-03-2013 IETF LC End Date: May-03-2013 IESG Telechat date: May-16-2013 Summary: This draft is basically ready for publication as a Standards Track RFC, but has nits that should be fixed before publication. [Ready with nits] The abstract says it pretty well: This document defines a YANG data model for management of IP implementations. Major issues: Minor issues: Nits: Page 7, bottom: The code copyright date says 2012. Update it to 2013. Page 10, in leaf phys-address, the description has an incorrect spelling of neighbor. General: where a description of phys-address is given, in both cases it says The physical level address It might be more correct to state The link layer address... for most but not all cases. That's it. Everything appears consistent within the limits of my understanding of YANG. -Peter Yee
RE: Gather Profiles/Resumes [was Re: call for ideas: tail-heavy IETF process]
You want resumes? You've got linkedin for that. The sort of thing Doug describes is actually quite common. For example, I once had a group chair threaten to have me disciplined by the company I worked for, for pointing out the technical failings of his pet protocol. The IETF isn't a lovey-dovey bunch of hippies working in harmony for humanity. The IETF is hardball. Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Doug Ewell [d...@ewellic.org] Sent: 15 May 2013 22:28 To: ietf@ietf.org Subject: Re: Gather Profiles/Resumes [was Re: call for ideas: tail-heavy IETF process] John C Klensin john dash ietf at jck dot com wrote: I think it is all very well to ask for affiliations in principle and, also in principle, I agree that it is a good idea. But, in practice, I think there are a lot of clarifications and other changes that would be required and that might or might not be practical. I used the term Consultant in RFCs 4645 and 5645, instead of revealing the name of my company (which was different each time, and neither of which contributed any time or money to my WG effort). I did this because the WG at the time included a malicious contributor who had already contacted the HR department of another contributor's employer, asking them to professionally discipline the employee, because he had supported an RFC 3683 PR-action against the first contributor. Full disclosure can be a dangerous thing. -- Doug Ewell | Thornton, CO, USA http://ewellic.org | @DougEwell
Re: Gather Profiles/Resumes [was Re: call for ideas: tail-heavy IETF process]
Hi John. I agree there are a number of specific cases where there is no simple/obvious way to handle. I'd be OK with something fairly simple as unaffiliated or consultant or something more nuanced. But I'd like to think those are edge cases (but could of course be wrong in how common they are). I was specifically thinking of much more obvious cases where I'm pretty sure that their main employers is sending them. One thing I've done at times is look at the attendance figures at meetings to try to identify some of the entities that send the most attendees to meetings (e.g.,, to track trends). As a result of that, I've noticed that the number of no affiliation given seems high to me, and I've seen obvious cases where I know the person and where they were working in the past, and then when I check later, it turns out they are still working at the same place (e.g. a Cisco, Google or Huawei). Maybe its just the case that the registration form makes it to easy to leave it blank. Just loooking at the list https://www.ietf.org/registration/ietf86/attendance.py?sortkey=3login= I easily counted 20 names of folk I know that don't list an affiliation, where if any of them have changed employers, that number would likely be very small. Thomas
Re: Gather Profiles/Resumes [was Re: call for ideas: tail-heavy IETF process]
On 05/15/2013 07:38 PM, John C Klensin wrote: So, what would you have me (and others like me) put on registration forms so that I'm not part of that undifferentiated 180 names? How about 7 densely worded paragraphs? Sorry, couldn't resist:-) S.
Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC
On 5/14/13 13:32 , David Conrad wrote: Hi, On May 14, 2013, at 11:02 AM, David Farmer far...@umn.edu wrote: The third goal you refer to focuses on the need for accurate registration information ... in order to meet a variety of operational requirements. I believe this to be a valid technical concerns of the IETF, it is difficult to imagine how a global Internet can technically function without this. So, I think it is important for it to remain in the draft. I would also point out that the third goal makes no statement on whether the registration data is publicly available or not. However, issues of privacy, law enforcement access, and a myriad of other extremely important issues related to the Internet Numbers Registry System are outside the technical and operational scope of the IETF. The whole point of the draft is to document the issues that are properly the concern of the IETF towards the Internet Numbers Registry System and to pass the rest of it to the multi-stakeholder environment of ICANN and the RIRs to hash it out. Exactly. Section 4 notes that provision of public WHOIS has been a technical consideration and that it may be necessary for the Internet community to examine these and related technical and operational considerations and how best to meet them. I agree with everything you say above regarding public available of the registration data. However, at the same time Section 7, quoted below, makes a very strong argument for it to remain public. It is generally recognized that accuracy and public availability of Internet registry data is often an essential component in researching and resolving security and operational issues on the Internet. So lets play a little hypothetical here; What if an RIR or ICANN through a global policy decided Whois Data no longer should be public for overriding privacy reasons. My read of Section 5, is that would be proper path for such a change, and long as the technical guidance of the IETF is considered in the process. But then through RFC 2860 and Section 5, if the IETF objected on technical or architectural grounds, and formally through the IESG, then the IAB would essentially adjudicate the issue. And ICANN or the RIR are obligated to accept the decision of the IAB. Do I have that right? To be clear, I'm not advocating Whois should or shouldn't remain public, or that anything is wrong with the Section 5. This just seemed like a plausible hypothetical to explore how the puzzle pieces work together to make the Internet Numbers Registry System. Also, I just want to fully understand what Section 5 really means. Thanks. -- David Farmer Email: far...@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952
Re: Gather Profiles/Resumes [was Re: call for ideas: tail-heavy IETF process]
In all earnestness I don't think a resume will be necessary at all :). -- Regards, Edwin A. Opare On Wed, May 15, 2013 at 11:33 PM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: On 05/15/2013 07:38 PM, John C Klensin wrote: So, what would you have me (and others like me) put on registration forms so that I'm not part of that undifferentiated 180 names? How about 7 densely worded paragraphs? Sorry, couldn't resist:-) S.
Re: call for ideas: tail-heavy IETF process
I initially replied to address Keith's comment. But a few things on Joe's: On 5/15/13 7:41 AM, Keith Moore wrote: On 05/15/2013 10:39 AM, Joe Touch wrote: On 5/14/2013 9:54 PM, Keith Moore wrote: Publishing broken or unclear documents is not progress. Broken, agreed. Unclear, nope - please review the NON-DISCUSS criteria, notably: The motivation for a particular feature of a protocol is not clear enough. At the IESG review stage, protocols should not be blocked because they provide capabilities beyond what seems necessary to acquit their responsibilities. The DISCUSS isn't there to make documents better - that's for COMMENTs. Exactly right. Sometimes we forget; it's a good thing to remind us. A DISCUSS there to catch a set of problems and to *block* the document's progress until that problem is resolved. Mostly correct. However: - If there is only one AD who wishes to DISCUSS and no other AD agrees with the DISCUSS holder, at the next telechat the document is unblocked. (See http://www.ietf.org/iesg/voting-procedures.html.) - Even if others agree with the DISCUSS, the chair can be asked to use the alternate procedure, which requires 2/3 of non-recused ADs to agree to publication. Which is to say, if there is only a single AD blocking a document, that block is essentially a 2 week affair if you are willing to push the point. No need for negotiating; if the WG decides that the AD is totally off base, tell your sponsoring AD that you're waiting the two weeks. People (unfortunately IMO) don't push the point nearly enough. (For the record, the IESG has *never* used the latter of the two procedures.) That said, I am also of the view that there is a third way, but I have never seen a WG attempt it: DISCUSS should in fact require discussing. Assuming there was some good faith effort on the part of the WG to figure out what the AD was on about and they really assess that the AD has it wrong, a WG could say, Sorry, we got this right. You are confused (or wrong). We are not changing the document. We are done discussing. At that point, I am of the opinion that the AD cannot hold the DISCUSS any longer. The AD must move to ABSTAIN. The discussion is, for all intents and purposes, over and to continue to DISCUSS is (IMO) an appealable offense. Then it is a matter of the IESG deciding whether there are enough ADs supporting the document (YES or NO OBJECTION) to count as consensus of the IESG. We ostensibly use 2/3 of non-recused ADs to mean consensus, since (I think the theory goes) if you can't get 2/3 of ADs to agree that it's OK to publish a document, that is a sign of a lack of rough consensus in the IETF (and probably a serious problem in WG operation). Indeed, if the ADs are so off of their rockers that more than 1/3 of them are against a perfectly reasonable document, it's time for the appeals and recall procedures to be used. (This is, BTW, where I disagree with Dave Crocker: Yes, a DISCUSS can be used as an exercise in authority, but only if it is allowed to be an assertion that changes are being required. If the rest of the IETF started saying, Sorry, no change is going to be made instead of making changes simply to satisfy the AD, we'd actually be better off and the DISCUSS would stop being seen -- and used -- as authoritative.) Finally, do keep in mind that, although there have been times where the numbers have been much different, currently there are 16 documents with outstanding DISCUSSes (and I think the total number has been pretty stable for a while), and 7 of those are on tomorrow's telechat and therefore should hopefully be cleared within a few days of when the document could most quickly have been approved anyway. So I'm not sure (and we should look at the statistics) how much of a problem this is for most documents we are producing. Now, as to Keith's comments: I strongly disagree with what the NON-DISCUSS criteria say. DISCUSS isn't just for blocking documents. And document quality is as important (in the sense that poor document quality can lead to as many interoperability or other problems) as technical correctness. Why are people trying to sabotage IESG? I'm sorry Keith, but your last line is rubbish. To claim that what people in this thread are talking about amounts to an attempt to sabotage the IESG is the height of hubris. In my opinion, the IESG has 2 jobs as far as document review goes: (1) Check for serious technical problems that the WG might not have considered and make sure they get considered; and (2) Make sure that our processes have been followed to assure that the WG products are truly the product of (IETF-wide) consensus and fit within the policies of the IETF. I am *positive* that I have failed to limit my DISCUSSes on documents to one of those two reasons; I expect I will err and do so in the future. I should be corrected. We reject kings, and should. As for the rest: The IESG should be
Re: call for ideas: tail-heavy IETF process
On 05/15/2013 09:07 PM, Pete Resnick wrote: I initially replied to address Keith's comment. But a few things on Joe's: On 5/15/13 7:41 AM, Keith Moore wrote: On 05/15/2013 10:39 AM, Joe Touch wrote: On 5/14/2013 9:54 PM, Keith Moore wrote: Publishing broken or unclear documents is not progress. Broken, agreed. Unclear, nope - please review the NON-DISCUSS criteria, notably: The motivation for a particular feature of a protocol is not clear enough. At the IESG review stage, protocols should not be blocked because they provide capabilities beyond what seems necessary to acquit their responsibilities. The DISCUSS isn't there to make documents better - that's for COMMENTs. Exactly right. Sometimes we forget; it's a good thing to remind us. A DISCUSS there to catch a set of problems and to *block* the document's progress until that problem is resolved. Mostly correct. However: - If there is only one AD who wishes to DISCUSS and no other AD agrees with the DISCUSS holder, at the next telechat the document is unblocked. (See http://www.ietf.org/iesg/voting-procedures.html.) - Even if others agree with the DISCUSS, the chair can be asked to use the alternate procedure, which requires 2/3 of non-recused ADs to agree to publication. Which is to say, if there is only a single AD blocking a document, that block is essentially a 2 week affair if you are willing to push the point. No need for negotiating; if the WG decides that the AD is totally off base, tell your sponsoring AD that you're waiting the two weeks. People (unfortunately IMO) don't push the point nearly enough. I think it's very unfortunate that IESG has adopted rules that work this way. Part of IESG's job is to provide independent review of WG output. It that review can be circumvented merely by waiting two weeks, that's a bug in the process. And if an AD raises a DISCUSS about a matter of technical or document quality (or for that matter, about a process violation), and the WG isn't even willing to discuss the point, but instead relies on the two week timeout, I think that's grounds for appeal to the IAB. (For the record, the IESG has *never* used the latter of the two procedures.) That said, I am also of the view that there is a third way, but I have never seen a WG attempt it: DISCUSS should in fact require discussing. We agree on that much. Assuming there was some good faith effort on the part of the WG to figure out what the AD was on about and they really assess that the AD has it wrong, a WG could say, Sorry, we got this right. You are confused (or wrong). We are not changing the document. We are done discussing. At that point, I am of the opinion that the AD cannot hold the DISCUSS any longer. The AD must move to ABSTAIN. I disagree with this in the strongest possible terms. I believe that for IESG to have rules that insist on or encourage voting ABSTAIN when the AD really means this document is not acceptable, is both irresponsible and dishonest on the IESG's part. I also believe that it tends to mean that ADs who didn't actually review the document get more say than ADs who did. The proper thing to do in that case is for either side to appeal to the IAB. The discussion is, for all intents and purposes, over and to continue to DISCUSS is (IMO) an appealable offense. Then it is a matter of the IESG deciding whether there are enough ADs supporting the document (YES or NO OBJECTION) to count as consensus of the IESG. We ostensibly use 2/3 of non-recused ADs to mean consensus, since (I think the theory goes) if you can't get 2/3 of ADs to agree that it's OK to publish a document, that is a sign of a lack of rough consensus in the IETF (and probably a serious problem in WG operation). Indeed, if the ADs are so off of their rockers that more than 1/3 of them are against a perfectly reasonable document, it's time for the appeals and recall procedures to be used. I don't think IESG voting should be thought of as a consensus process, except perhaps in the deadlock breaking procedure. The typical number of reviewers on the IESG is too small for a consensus process to be meaningful. With so few thorough reviewers outside of the WG, you need a procedure that at least initially assumes that all review comments have to be taken seriously. Now, as to Keith's comments: I strongly disagree with what the NON-DISCUSS criteria say. DISCUSS isn't just for blocking documents. And document quality is as important (in the sense that poor document quality can lead to as many interoperability or other problems) as technical correctness. Why are people trying to sabotage IESG? I'm sorry Keith, but your last line is rubbish. To claim that what people in this thread are talking about amounts to an attempt to sabotage the IESG is the height of hubris. sabotage is probably not the best word I could have chosen. But I do have the strong impression that
Re: Gather Profiles/Resumes [was Re: call for ideas: tail-heavy IETF process]
--On Wednesday, May 15, 2013 14:28 -0700 Doug Ewell d...@ewellic.org wrote: ... I did this because the WG at the time included a malicious contributor who had already contacted the HR department of another contributor's employer, asking them to professionally discipline the employee, because he had supported an RFC 3683 PR-action against the first contributor. Full disclosure can be a dangerous thing. I know that sort of contact the employer and ask them to chew out the employee stuff goes on because I've had it tried on me at least twice although both involved technical issues and choices, not, e.g., a PR-action. In the first instance, the employer said something about academic freedom and essentially told the person complaining to kiss off. In the second, the employer laughed. I may have been luckier in my choices of employers (and clients) and I know bad stuff happens sometimes, but the sort of case you outline doesn't seem to me to be a good argument against disclosure of affiliations. It seems to me that, very rare edge cases aside, either: (i) Your employer knows what you are doing and saying in the IETF, at least to the extent that they care, and will back you should such complaints arrive. (ii) You and your employer have an agreement that you participate in the IETF as an independent activity that they don't try to control. Should a complaint arise, they presumably tell the complaining party that unless your IETF behavior is an embarrassment to the company, in which case (iii) applies. (iii) Your IETF behavior is, as far as your employer is concerned, that of a loose cannon. You regularly work against company positions or the company's best interests and haven't laid the internal foundation for that to be acceptable. A complaint associated with something you have disclosed could get you into big trouble, but complaints are equally likely from people who know where you are working, disclosure or no, such as fellow employees of the same organization. So I suggest that, if your behavior is proper and above board, disclosure will rarely create a problem. If your behavior isn't, then disclosure may be the least of your difficulties. In addition, the IETF may be in need of a mechanism for documenting and disclosing the identities of anyone who thinks that complaining to someone's employer about his or her reasonable behavior at the IETF. I imagine the community could figure out appropriate and completely informal ways to discourage that particular style of trying to influence IETF decision-making. best, john
Re: call for ideas: tail-heavy IETF process
--On Thursday, May 16, 2013 00:55 -0400 Keith Moore mo...@network-heretics.com wrote: Which is to say, if there is only a single AD blocking a document, that block is essentially a 2 week affair if you are willing to push the point. No need for negotiating; if the WG decides that the AD is totally off base, tell your sponsoring AD that you're waiting the two weeks. People (unfortunately IMO) don't push the point nearly enough. I think it's very unfortunate that IESG has adopted rules that work this way. Part of IESG's job is to provide independent review of WG output. It that review can be circumvented merely by waiting two weeks, that's a bug in the process. And if an AD raises a DISCUSS about a matter of technical or document quality (or for that matter, about a process violation), and the WG isn't even willing to discuss the point, but instead relies on the two week timeout, I think that's grounds for appeal to the IAB. Keith, I generally agree with Pete although I share your low opinion of a lot of current IETF work, but your comment above seems to call for comment from someone, like myself, who has often been critical of the IESG. I don't think the current rules are ideal, but the effect of the ones that you and Pete cite isn't really that a WG can circumvent a review by waiting two weeks. First, the dissenting AD has those same two weeks to convince others on the IESG that his or her position is reasonable or at least needs more extensive consideration. If that is possible, then there is no longer a single AD objecting and the two week rule does not apply. If it is not possible, then there is either something wrong with the objection or the AD making it and probably it is reasonable for the process to move forward. Conversely, a WG that decides to avoid actually engaging on an issue in the hope of letting the two-week clock run out is putting itself at considerable risk. The IESG still have the ability to fire WG leadership and even to close WGs. Under any reasonable circumstances, I assume that the IESG would respond very strongly if an AD pointed out the a WG had ignored an effort to discuss a substantive issue even if the rest of the IESG disagreed with that particular AD about that issue. I can't remember any instances of a WG Chair being fired, or a WG being shut down entirely, while documents were post IETF Last Call and under IESG discussion, but I presume that is because the IESG has never been provoked quite enough rather than because there is any rule that would prevent it. Firing a Chair or closing a WG on the grounds that they refused to engage on a substantive issue would, I assume, be sustained on any appeal. Similarly... I agree that we should reject kings. But we should also reject stubborn working groups and stubborn authors. We shouldn't presume that a WG knows better than the IESG. The two have different points-of-view, but neither is inherently superior to the other. I don't think we should presume that a WG knows better than the IESG either. I do think it is reasonable to assume that a WG knows better than a single AD who cannot convince others on the IESG of the merit of his or her position or even that the issue is important enough that they should read the document carefully and form their own informed opinions. best, john
Document Action: 'Problem Statement and Requirements of Peer-to-Peer Streaming Protocol (PPSP)' to Informational RFC (draft-ietf-ppsp-problem-statement-15.txt)
The IESG has approved the following document: - 'Problem Statement and Requirements of Peer-to-Peer Streaming Protocol (PPSP)' (draft-ietf-ppsp-problem-statement-15.txt) as Informational RFC This document is the product of the Peer to Peer Streaming Protocol Working Group. The IESG contact persons are Martin Stiemerling and Spencer Dawkins. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ppsp-problem-statement/ Technical Summary Peer-to-Peer (P2P for short) streaming systems show more and more popularity in current Internet with proprietary protocols. This document identifies problems of the proprietary protocols, proposes the development of Peer to Peer Streaming Protocol (PPSP) including the tracker and peer protocol, and discusses the scope, requirements and use cases of PPSP. Working Group Summary There is strong consensus on the WG process in this document. Document Quality The proposed protocols are being developed and there are already at least three implementations of the PPSP tracker and peer protocol. And there are some operators planning to implement the spec after they are finished. The draft describes the requirements and problem statements for the standardization of Peer and Tracker streaming protocols that are being specified in separate documents. The Problem Statement draft is not a protocol specification so the question about implementation does not apply. However, there are already both Peer and Trackers streaming protocol implementations. Personnel Stefano Previdi (sprev...@cisco.com) is the document shepherd, and Martin Stiemerling (martin.stiemerl...@neclab.eu) is the responsible AD.
Last Call: draft-ietf-cuss-sip-uui-10.txt (A Mechanism for Transporting User to User Call Control Information in SIP) to Proposed Standard
The IESG has received a request from the Call Control UUI Service for SIP WG (cuss) to consider the following document: - 'A Mechanism for Transporting User to User Call Control Information in SIP' draft-ietf-cuss-sip-uui-10.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2013-05-29. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract There is a class of applications which benefit from using SIP to exchange User to User Information (UUI) data during session establishment. This information, known as call control UUI data, is a small piece of data inserted by an application initiating the session, and utilized by an application accepting the session. The rules which apply for a specific application are defined by a UUI package. This UUI data is opaque to SIP and its function is unrelated to any basic SIP function. This document defines a new SIP header field, User-to-User, to transport UUI data, along with an extension mechanism. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui/ballot/ No IPR declarations have been submitted directly on this I-D.
SCIM Working Group to Close Design Team and Schedule Regular Conference Calls
Folks, The goal of the SCIM design team was to set the WG on a path towards scim 2.0 by identifying and proposing solutions to the major issues. The time has now come to close the design team and thank the contributors for all their hard work. In order to preserve the momentum and make sure the SCIM WG will complete in a timely manner we will start a schedule of bi-weekly conference calls [1] open to all. Before each call, an agenda will be posted to the list and after each call notes will be posted to the list and the WG wiki. The time of the call will be 10 AM PST every other Wednesday. The first call will be 2 weeks from next Wednesday (29/5) and this email serves as notification for this and all future calls until further notice. A separate email with the meeting details will be sent to the list shortly. Leif Morteza [1] http://www.ietf.org/iesg/statement/interim-meetings.html
HTTPBIS WG Interim Meeting, August 5-7, 2013
This is an announcement of an Interim Meeting for the HTTPbis WG. The goal of the meeting is to discuss the issues against HTTP/2 and formulate proposals to bring back to the WG. We'll be meeting in Hamburg, Germany from 5-7 August 2013. Adobe has kindly offered to host. More details are available at: https://github.com/http2/wg_materials/blob/master/interim-13-08/arrangements.md If you'd like to attend, please register as per the arrangements page. Regards, Mark Nottingham, HTTPbis Working Group Chair
