Re: DKIM Signatures now being applied to IETF Email
Nathaniel Borenstein wrote: I find it amazing how many different ways there are to criticize DKIM for not doing something it was never intended to do. DKIM is a small building block that enables new functionality, but such functionality is beyond the scope of DKIM. Note: We have an advanced implementation of DKIM as a product line so my concerns are not outsider views. My input is 100% based on implementation and field experiences. Policy was very fundamental to the understanding of DKIM, it was part of the original DomainKeys and DKIM expanded this powerful concept with a wider range of Author Domain policies. I never disputed the out of scope 3rd party trust policy model but it addressed a different problem - trust, if any, of a valid signature after the violations are filtered by author domain policies, if any. Two different layers and this was outlined in my 2006 DKIM Signer Authorization Protocol (DSAP) I-D. The problem was a conflict in different market ideas - an unrestricted resigner DKIM mail market which 1st party security controls would conflict with. They simply did not want the 1st party to override any 3rd party signers. This conflict was highlighted in the SSP requirements with the last minute addition in RFC5016: Requirements for a DKIM Signing Practices Protocol when item #10 was added in section 5.3 to appease the opponents of 1st party SSP polices: 10. SSP MUST NOT provide a mechanism that impugns the existence of non-first party signatures in a message. A corollary of this requirement is that the protocol MUST NOT link practices of first party signers with the practices of third party signers. INFORMATIVE NOTE: the main thrust of this requirement is that practices should only be published for that which the publisher has control, and should not meddle in what is ultimately the local policy of the receiver. Refs: Deployment Consideration, Section 4.3. This was unfortunate. On the one hand it suggest we should not meddle in how local receivers will behave yet it imposes a MUST NOT mandate in allowing the 1st party policy to override a 3rd party signature trust policy. DKIM does one thing, and one thing only: It uses a cryptographic signature to associate a domain with a message. It does more than that. DKIM has a fundamental requirement to hash bound the 5322.From field to the signature. Its the only header that MUST be signed. All others are optional. This 5322.FROM bind provide the only anchor possible that can be repudiated. So there are two principal domains associated with a signature: Signerd= value in signature 5322.From DKIM requirement By doing so, it creates strong evidence that the message passed through that domain at some point and has not been significantly modified since. I don't see this. The resigner can be totally opaque with no association with the original domain. The signer::author association begins with the original signature creation by the author domain selecting a signer and/or prearranged with an outsource signing service. Now, what people are looking for as well, is when there is resigner::author association when the author is participating in a resigner network. Currently we call this a 3rd party Authorization. With such an anchor, we can begin to build stronger and more robust systems for analyzing the desirability of messages, as we are now trying to do in the REPUTE work, because it allows us to push our forensic analysis upstream a bit. Heuristic wrappers are interesting but its a different problem. It doesn't adequately address what a deterministic solution can do for you. If, for example, the IETF mailing list software only allows posting by list members, but itself trusts the sender's header fields, then an IETF DKIM signature tells me only that the IETF servers think a message passed that test. There you go, you made an POLICY STATEMENT - translate it into a protocol for everyone to follow and check. That's obviously not perfect, but it's slightly stronger than what came before -- it is still possible to forge a message before sending it to the list, but much harder to forge a message to look as if it came from the list exploder. This is all besides the point. Its all about detection what YOU think is a violation of a protocol logic. Whatever you produce in REPUTE, you are producing a idea for people to follow consistency based on some baseline rules established. We've had a long history of grand plans for user authentication on the Internet. Those plans have largely failed. There are plenty of authentication protocols that works very well, and fundamental to our current network. The issue here is a DKIM signer market run wild uncontrolled and if we don't get our act together soon to put a security wrapper around it, it risk becoming yet
Re: A modest proposal for Friday meeting schedule
If we don't want to hold meetings on Friday afternoons due to conflicts, I'd much rather see us eliminate one of the plenaries and hold meetings during that time slot. I was already planning to bring this up again in the IAB, but now that you mention it here, I fully agree! Before we start to fiddle with time slots, why don't we wait before the results of the traditional survey-on-last-meeting has been published. jaap ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: A modest proposal for Friday meeting schedule
On 8/2/2011 6:35 AM, David Kessens wrote: Margaret, On Mon, Aug 01, 2011 at 07:02:22PM -0400, Margaret Wasserman wrote: If we don't want to hold meetings on Friday afternoons due to conflicts, I'd much rather see us eliminate one of the plenaries and hold meetings during that time slot. I was already planning to bring this up again in the IAB, but now that you mention it here, I fully agree! Actually, I'd like to see both plenaries moved to Friday the resulting time be delegated to more useful things. People having a deep need to attend them can stay over Friday night while others can go home. attachment: gwz.vcf___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: A modest proposal for Friday meeting schedule
Original Message - From: David Kessens david.kess...@nsn.com To: Russ Housley hous...@vigilsec.com Cc: IETF ietf@ietf.org Sent: Monday, August 01, 2011 10:49 PM Russ, On Mon, Aug 01, 2011 at 11:10:24AM -0400, Russ Housley wrote: I am discussing the possibility with the Secretariat and the IESG. I will report back to the community as soon as possible. I don't think this proposal should be pursued. The breaks fulfil an important function and there is nothing wrong with a starting time of 9am. The friday meetings are always going to be tough at the end of a week long meeting but trying to compress the friday schedule would only make it harder. Yes, and has been said, Friday is travel time; with a 17:30 flight, a time to dip into those sessions I never normally attend, with an 09:30 flight, I'm gone. Anything that matters needs to be Monday to Thursday, and that includes Plenaries. They may be boring, but that in itself is an important reflection of the various I***s. Tom Petch David Kessens --- On Jul 31, 2011, at 11:40 AM, Hadriel Kaplan wrote: Something like this: 8:30-11:00 Session I 11:15-12:15 Session II 12:30-13:30 Session III I really like it, as there are a bunch of post-IETF stuff, some of which starts in the afternoon and thus conflicts with the IETF. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Drafts Submissions cut-off
- Original Message - From: Keith Moore mo...@network-heretics.com To: Joe Touch to...@isi.edu Cc: ietf@ietf.org Sent: Tuesday, August 02, 2011 12:36 AM On Aug 1, 2011, at 6:17 PM, Joe Touch wrote: Not all IDs are discussed at the upcoming IETF. It is inconvenient to need to delay an update or new submission simply because there's an IETF coming up. And all I've seen the deadline accomplish is that people post non-posted updates on local websites for discussion anyway. Unless there's a load issue, IMO there ought not be a blackout period. Based on response time from the internet-dra...@ietf.org during that period, and also on delays in getting the I-Ds out the door, I believe there is a load issue. (no complaints about the actual response or service, but they did seem quite busy) Yes, except that I do see complaints, of I-Ds appearing after a cutoff, with the explanation being that there has been a delay of some days from submission to announcement, so the I-Ds were submitted before the cutoff but appeared after. Which suggests that the system gets overloaded And this is a minor problem. As suggested in another post, the cutoff is a good time to do a trawl, especially of unadopted I-Ds which may not have been mentioned on the list, of all announced I-Ds to catch any that I have missed. On balance, the cutoff is a good thing. Tom Petch Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
- Original Message - From: Nathaniel Borenstein n...@guppylake.com To: Hector Santos hsan...@isdg.net Cc: ietf ietf@ietf.org Sent: Monday, August 01, 2011 2:48 PM Subject: Re: DKIM Signatures now being applied to IETF Email I find it amazing how many different ways there are to criticize DKIM for not doing something it was never intended to do. DKIM is a small building block that enables new functionality, but such functionality is beyond the scope of DKIM. I agree that DKIM does exactly what it sets out to do, but am not amazed that it attracts criticism. When people have a need, and want a technical solution, and then find that what at first sight appeared to be a solution is not one, then they may be disappointed, and be critical. That is human nature. When that happens is a time to reflect, to look at the requirements that were not met. If they were captured and rejected, at least for the time being, then noone has any cause to be upset. But if the requirements were not captured, then perhaps it is a time to contemplate that, how were they missed, what else might have been missed and whether or not that should be acted upon in future. And, as I said before, my criticism is of those who have imposed this technology on the IETF lists, not of the technology itself. Tom Petch DKIM does one thing, and one thing only: It uses a cryptographic signature to associate a domain with a message. By doing so, it creates strong evidence that the message passed through that domain at some point and has not been significantly modified since. Whether that domain is good guys or bad guys, senders or resenders, Coke or Pepsi, is completely irrelevant. It is a small nugget of evidence to provide an anchor point for forensics stronger than what have come before. It tells us that the named domain considered the message reasonable to send or resend, for its own reasons -- its own forensic evidence, its nefarious intent, or the phase of the moon. With such an anchor, we can begin to build stronger and more robust systems for analyzing the desirability of messages, as we are now trying to do in the REPUTE work, because it allows us to push our forensic analysis upstream a bit. It does not relieve downstream software of the need to decide how to feel about the signing domain, whether it's a spammer, a copy-cat, or anyone else. If, for example, the IETF mailing list software only allows posting by list members, but itself trusts the sender's header fields, then an IETF DKIM signature tells me only that the IETF servers think a message passed that test. That's obviously not perfect, but it's slightly stronger than what came before -- it is still possible to forge a message before sending it to the list, but much harder to forge a message to look as if it came from the list exploder. That is progress -- very very small, slow, progress. If, at some point, the list exploder starts only passing through messages that themselves have valid DKIM signatures, it will be significantly more progress, but it won't do anything to stop a spammer from subscribing to the IETF list and DKIM-authenticating himself. For that we'll need reputation information -- another small step, which we're trying to initiate with REPUTE. We've had a long history of grand plans for user authentication on the Internet. Those plans have largely failed. I think an incremental approach like DKIM has a better chance, but it is obviously vulnerable to being dismissed by those who see a small improvement as not worth bothering with. The best is the enemy of the good. -- Nathaniel On Jul 31, 2011, at 6:12 AM, Hector Santos wrote: You continue to not comprehend (or rather ignore) what continues to plaque DKIM - the lack of fault detection. Its why it continues to have a hard time and have people who actually believe in this promising protocol bitch about it. If these big email providers (or anyone for that matter) begin to make assertions about what is good about their mail then they better be ready for the violations of such assertions to be rejected. You can't have it just one way and mandate this is the only way to process this overhead - looking for good mail only and ignoring all the violations and illogically treating it like it was never signed or compromised or attempted to be compromised. The overall difficulty is that originality is lost - the original author or dkim signer has lost or lacks any protocol guidance to tell resigners that the mail they are about the process might be bad - according to the original author domain. If the resigner is going to intentionally and neglectfully ignore all original claims about the original domain signing practice, then how do you expect the anonymous copy-cat abuse to be controlled? Murray S. Kucherawy wrote: -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of t.petch Sent: Saturday, July 30, 2011 3:26 AM
Re: A modest proposal for Friday meeting schedule
I think John has the issue nailed. I think it would be easy to try to eliminate the plenaries and then end up with a full Friday, anyway. I would offer that it would be very difficult, however, to take a compressed Friday and later add an afternoon to it. Thus, I am much more in favor of a compressed Friday, perhaps with some of the mentioned tweaks (a cookie break or a graham cracker and milk break for those who know the Montessori routine), than either leaving Friday as is or eliminating the Plenaries. BTW, has anyone noticed the trend of doing more and more on the Sunday and Saturday *before* IETF week? On Aug 1, 2011, at 10:32 PM, John C Klensin wrote: --On Monday, August 01, 2011 19:02 -0400 Margaret Wasserman m...@lilacglade.org wrote: ... If we don't want to hold meetings on Friday afternoons due to conflicts, I'd much rather see us eliminate one of the plenaries and hold meetings during that time slot. Margaret, FWIW, I personally think the plenaries have enough value, if only as potential checks on the leadership, that I'd hate to see one or both go. I even think their substantive content is occasionally helpful. However, my main purpose in responding to the above is to advise that you Be careful what you wish for. I suggest that, until we start pushing back aggressively on requests for meeting slots (or, if necessary, on new WG requests), the number of slots that are asked for will always expand to fill (or nearly fill) the number of slots available. The IESG has concluded that it is ok to have three meeting slots on Fridays. If we eliminate a plenary to open up one or two more slots and use those slots to stop using the Friday afternoon ones, I suggest that it will be only a matter of time before we have enough demand for slots that we expand back into the Friday afternoon times, retaining the slots that eliminate the plenary. If we really want to eliminate the Friday afternoon slots, then we should eliminate those slots, ratcheting up the criteria for getting meeting time to the point that we don't need them. Whether or not we need two plenaries (or one or zero or three) is almost independent of thet, even though we could get some short-term relief. Given the amount of burnout I often see by Friday, simply dropping the afternoon sessions is my personal favored solution. If we want to keep the Friday afternoon slots, or keep the number of slots that Friday afternoon gives us, then compressing the day make sense to me. Doing that compression according to the suggestion has disadvantages --both those you cite and others. But maybe modifying the proposal to include a short beverage and cookie break around 11:30 would make sense. Maybe there are other ideas too. But I think the trends are very clear and that, in the long run, eliminating a plenary would buy an extra slot or two (and another very long and exhausting day) but would not improve the Friday situation. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: A modest proposal for Friday meeting schedule
BTW, has anyone noticed the trend of doing more and more on the Sunday and Saturday *before* IETF week? Very much so. Workshops, joint meetings, design teams... In Prague, a good number of people started in Friday. Nothing wrong with that, but it does put paid to the idea that the IETF is 4.5 day meeting, and that squeezing it at one end will restrain it. Toothpaste-like, squeezing the closing Friday will only cause more spillage on the opening Sunday. OTOH, I have good reason to think that the application of more focus by WGs during their meetings *could* reduce the pressure on the whole schedule. Thus, the perennial thread on not presenting drafts at WG meetings would surely bear fruit. Adrian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: A modest proposal for Friday meeting schedule
On Aug 2, 2011, at 7:48 AM, Adrian Farrel wrote: BTW, has anyone noticed the trend of doing more and more on the Sunday and Saturday *before* IETF week? Very much so. Workshops, joint meetings, design teams... In Prague, a good number of people started in Friday. Nothing wrong with that, but it does put paid to the idea that the IETF is 4.5 day meeting, and that squeezing it at one end will restrain it. Toothpaste-like, squeezing the closing Friday will only cause more spillage on the opening Sunday. OTOH, I have good reason to think that the application of more focus by WGs during their meetings *could* reduce the pressure on the whole schedule. Thus, the perennial thread on not presenting drafts at WG meetings would surely bear fruit. Indeed. A few people were discussing this during one of the meetings last week where the agenda was packed to the gills, and the WG chairs were cutting off discussion after just 1 or 2 people at the mic. We were all wondering why we spent any time allowing for the presentation and instead should have allowed the full 5/10 minute slot for discussions/debate. Even better, what if we spent a whole 15 minutes discussing or debating?! --Tom Adrian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: A modest proposal for Friday meeting schedule
On Tue, Aug 2, 2011 at 08:05, Thomas Nadeau tnad...@lucidvision.com wrote: OTOH, I have good reason to think that the application of more focus by WGs during their meetings *could* reduce the pressure on the whole schedule. Thus, the perennial thread on not presenting drafts at WG meetings would surely bear fruit. Indeed. A few people were discussing this during one of the meetings last week where the agenda was packed to the gills, and the WG chairs were cutting off discussion after just 1 or 2 people at the mic. We were all wondering why we spent any time allowing for the presentation and instead should have allowed the full 5/10 minute slot for discussions/debate. Even better, what if we spent a whole 15 minutes discussing or debating?! See http://trac.tools.ietf.org/wg/intarea/trac/wiki/MeetingTimePrioritization for what we came up with. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
On 02/Aug/11 06:52, Hector Santos wrote: Keith Moore wrote: Repeat as needed; you can always partition the remaining part of the problem again. It was not a difficult problem. [...] how to scale the authorization of 3rd party signer. [...] But there was a fundamental mindset and marketing conflict. It was a conflict of 3rd party resigner market right to exist uncontrolled, unrestricted regardless of originating DKIM message claims. Marketing pressure on IETF protocols may be business as usual, but DKIM managed to come out pretty cleanly neutral in this respect, AFAICS[*]. IMHO, a scenario with a few big re-signers would pose more problems than it can ever solve. I wish they... resign. However, managing reputation without having recourse to a big brother of some sort is no easy problem. Since even governments are being blamed for pursuing personal interests rather than people's needs, solving that will be a major achievement in democracy. -- [*] Let's draw a veil over that somewhat confused patent disclosure https://datatracker.ietf.org/ipr/1547/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Drafts Submissions cut-off
On Mon, 1 Aug 2011 16:27:55 -0700, Paul Hoffman paul.hoff...@vpnc.org said: PH Or, (3), specify somewhere that the submission window opens at the PH beginning of the meeting and allow WG chairs to decide what they PH want to do about new drafts. In the case last week, the draft was PH turned in and posted to the mailing list on Monday ahead of the PH meeting on Friday; the chairs seemed to like that. It all comes down to how to best get information to those that need it (as fast as possible). I too, read the older version of the draft that being discussed and didn't realize there was a new one because I rarely get to *all* of my mail during IETF weeks (I'm too busy talking in the hallways to read email). That being said, I think forward progress on drafts are most likely to happen *during* IETF meetings in hallways and thus it's impossible to enter a WG meeting and assume that no thinking has changed in the 3 weeks since the last draft was published. IE, this has nothing to do with the drafts themselves. It has to do with communication of changebars. In the case where significant changes have taken place in thinking (documented or not) because of conversations or work that has commenced since the cut-off date, it should be the responsibility of the authors to give a quick summary early in the meeting about recent progress, as it's indeed unfair to assume everyone in the audience hasn't printed and read everything only an hour before the meeting and were present in every conversation that occurred over the cookie table (regardless of whether there were actually cookies or just crumbs there). It should also be up to the chairs to bug the authors about making sure that any recent changes are, in fact, at least listed or presented in detail depending on what's best for the meeting. You can't hold a discussion half the participants have only half the information. It doesn't matter who's fault it was. It only matters that it's a problem. -- Wes Hardaker SPARTA, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: DKIM Signatures now being applied to IETF Email
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Alessandro Vesely Sent: Tuesday, August 02, 2011 6:28 AM To: ietf@ietf.org Subject: Re: DKIM Signatures now being applied to IETF Email It was not a difficult problem. [...] how to scale the authorization of 3rd party signer. [...] But there was a fundamental mindset and marketing conflict. It was a conflict of 3rd party resigner market right to exist uncontrolled, unrestricted regardless of originating DKIM message claims. Marketing pressure on IETF protocols may be business as usual, but DKIM managed to come out pretty cleanly neutral in this respect, AFAICS[*]. I think the claim that marketing somehow entered into the guidance of DKIM's evolution is specious, and that's being polite. I've yet to see any evidence at all, short of unfounded assertions about the unspoken agendas of the participants, to back it up. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: A modest proposal for Friday meeting schedule
--On Monday, August 01, 2011 16:38 -0500 Adam Roach a...@nostrum.com wrote: I'd like to join the sparse voices in speaking out against this plan. By Friday, I'm pretty well on a local meal schedule. Pushing lunch back by 2 hours would pretty well on guarantee that I'd be sugar-crashed and less coherent than normal by the end of Session II. Adam, I've noticed that lots of people (myself often included) are often sufficiently wasted by Friday morning to be largely disfunctional (certainly less coherent than normal). I'm prepared to believe that pushing back lunch would make it even worse for some people, but it may be that the best solution to that problem is a better breakfast or snacks that can be brought into the meeting rooms (or eaten during a _very_ short break as distinct from 90 minutes of lunch break). With at least some facilities, getting finished earlier would also reduce costs; I assume I'm not the only one who would like to see that go straight to the registration fees. So I think this is a good idea if it is feasible... even though my preference would be to go back to ending at noon (or 11:30 or earlier) on Friday by getting more efficient about how we use time earlier in the week and more selective about who and what gets time at all. best, john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Call for Nominations: Applied Networking Research Prize (ANRP) for IETF-82
CALL FOR NOMINATIONS: APPLIED NETWORKING RESEARCH PRIZE (ANRP) http://irtf.org/anrp *** Submit nominations until August 28 for the ANRP for IETF-82, *** November 13-18, 2011 in Taipei, Taiwan: *** http://fit.nokia.com/anrp/82/ The Applied Networking Research Prize (ANRP) is awarded for recent results in applied networking research that are relevant for transitioning into shipping Internet products and related standardization efforts. Researchers with relevant, recently published results are encouraged to apply for this prize, which will offer them the opportunity to present and discuss their work with the engineers, network operators, policy makers and scientists that participate in the Internet Engineering Task Force (IETF) and its research arm, the Internet Research Task Force (IRTF). Third-party nominations for this prize are also encouraged. The goal of the Applied Networking Research Prize (ANRP) is to recognize the best new ideas in networking, and bring them to the IETF and IRTF especially in cases where they would not otherwise see much exposure or discussion. The Applied Networking Research Prize (ANRP) consists of: * cash prize of $500 (USD) * invited talk at the IRTF Open Meeting * travel grant to attend the week-long IETF meeting (airfare, hotel, registration, stipend) * recognition at the IETF plenary * invitation to related social activities * potential for additional travel grants to future IETF meetings, based on community feedback HOW TO APPLY Only a single person can be nominated based on a peer-reviewed, recently-published, original journal, conference or workshop paper they authored. The nominee must be one of the main authors of the nominated paper. Both self nominations (nominating one’s own paper) and third-party nominations (nominating someone else’s paper) are encouraged. The nominated paper should provide a scientific foundation for possible future IETF engineering work or IRTF experimentation, analyze the behavior of Internet protocols in operational deployments or realistic testbeds, make an important contribution to the understanding of Internet scalability, performance, reliability, security or capability, or otherwise be of relevance to ongoing or future IETF or IRTF activities. Applicants must briefly describe how the nominated paper relates to these goals, and are encouraged to describe how presentation of these research results will foster their transition into new IETF engineering or IRTF experimentation, or otherwise seed new activities that will have an impact on the real-world Internet. The goal of the Applied Networking Research Prize (ANRP) is to foster the transitioning of research results into real-world benefits for the Internet. Therefore, applicants must indicate that they (or the nominee, in case of third-party nominations) are available to attend the respective IETF meeting in person and in its entirety. Nominations must include: * the name and email address of the nominee * a reference to the published nominated paper * a PDF copy of the nominated paper * a statement that describes how the nominated paper fulfills the goals of the award * a statement that the nominee is available to attend the respective IETF meeting in person and in its entirety * a brief biography or CV of the nominee * optionally, any other supporting information (link to nominee's web site, etc.) *** Nominations are submitted via the submission site: *** http://fit.nokia.com/anrp/82/ SELECTION PROCESS A small selection committee comprised of individuals knowledgeable about the IRTF, IETF and the broader networking research community will evaluate the submissions against these selection criteria. The goal is to select 1-2 submissions for the Applied Networking Research Prize (ANRP) during each nomination period. All nominees will be notified by email. IMPORTANT DATES Applications open: August 1, 2011 Applications close: August 28, 2011 Notifications: September 20, 2011 IETF-82 Meeting:November 13-18, 2011 in Taipei, Taiwan SPONSORS The Applied Networking Research Prize (ANRP) is supported by the Internet Society (ISOC), as part of its Internet Research Award Programme, in coordination with the Internet Research Task Force (IRTF). smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: A modest proposal for Friday meeting schedule
On 8/1/11 3:50 PM, John C Klensin wrote: So I think this is a good idea if it is feasible... even though my preference would be to go back to ending at noon (or 11:30 or earlier) on Friday by getting more efficient about how we use time earlier in the week and more selective about who and what gets time at all. +1 to that. Work will expand to fill the time allotted. A side benefit is that the IESG/IAB could have a lunch meeting on Friday (as opposed to the current breakfast meeting) and cover all the hot topics from the week (not the week minus Friday). /psa ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: A modest proposal for Friday meeting schedule
On 01/08/2011, at 2:50 PM, John C Klensin wrote: I've noticed that lots of people (myself often included) are often sufficiently wasted by Friday morning to be largely disfunctional (certainly less coherent than normal). I'm prepared to believe that pushing back lunch would make it even worse for some people, but it may be that the best solution to that problem is a better breakfast or snacks that can be brought into the meeting rooms (or eaten during a _very_ short break as distinct from 90 minutes of lunch break). This is better. Some people will still doubtless complain. With at least some facilities, getting finished earlier would also reduce costs; I assume I'm not the only one who would like to see that go straight to the registration fees. +1 So I think this is a good idea if it is feasible... even though my preference would be to go back to ending at noon (or 11:30 or earlier) on Friday by getting more efficient about how we use time earlier in the week and more selective about who and what gets time at all. +1 -- Mark Nottingham http://www.mnot.net/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: A modest proposal for Friday meeting schedule
Peter, A side benefit is that the IESG/IAB could have a lunch meeting on Friday (as opposed to the current breakfast meeting) and cover all the hot topics from the week (not the week minus Friday). /psa I agree with your point here, and add that the joint IAB/IESG Friday session isn't only a BOF report session, it's hot spots, however defined - we've usually at least SEEN all the BOFs by Friday breakfast, but that doesn't mean we've seen all the hot spots ;-) Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Drafts Submissions cut-off
Hi Phillip, At 11:31 AM 8/1/2011, Phillip Hallam-Baker wrote: Over the weekend I attempted to determine the rules for discussion of drafts at IETF meetings and was surprised to discover that they are not actually written down anywhere (other than on the meetings page). As a result we appear to have an anomalous situation in which an author who misses the cut-off date for ID submissions is in fact entitled to sit on the draft for two weeks and then submit when the ID queue re-opens. I suggest that this is a sub-optimal state of affairs. I see two solutions: 1) Codify the requirement that materials to be discussed at the meeting must be submitted before the cut-off and that submissions made during meetings are strictly limited to revisions occurring after and between WG sessions. [Except in exceptional circumstances with AD approval] 2) Eliminate the 2 week cut off completely. I'll start by quoting Scott Brim [1]: One generation's rule of thumb becomes the next generation's dogma. The IETF should sit up and really think when someone suggests that a process has become dogma. Quoting Ned [2]: I'd much rather breach the sanctity of the rules by getting rid of some of them entirely. Quoting Russ [3]: When all of the Internet-Drafts were processed by Secretariat staff, there was a huge workload concern. Now that the Internet-Draft Submission Tool (IDST) is taking the bulk of the load, there are resources to deal with these exceptions, as was just demonstrated. Which was in response to John Klensin who said [4]: The original reason for those cutoffs -- even more important than giving people time to read drafts -- was that the submissions were overwhelming the Secretariat. Not only did they have other things to do in the weeks before the meeting, it was becoming unpredictable whether a draft submitted in advance of the meeting would be posted early enough for the relevant WG to look at it. The split between new and revised drafts was another attempt to protect the Secretariat -- notions of having to formally approve WG drafts came later. And Dave said [5]: It would seem that the right thing is to remove the cutoff and let each working group decide on what drafts will be worked on. Spencer Dawkins [6] quoted Section 7.1 of RFC 2418. Pete Resnick was of the opinion [7] that: The cutoff is an arbitrary procedure to try (poorly IMO) to enforce the 2418 rule. I suggest that WG chairs stop asking the working group whether they have read the draft as it is silly. It is an impossible task to keep up with the flood of I-D that are submitted on Meeting Monday. Regards, -sm 1. msg-id: 48821469.4050...@employees.org 2. msg-id: 01mxc0962cli000...@mauve.mrochek.com 3. msg-id: 20080719191556.567f03a6...@core3.amsl.com 4. msg-id: 2e1b2ab9703690b8e1eeb...@p3.jck.com 5. msg-id: 48826dc0.8000...@dcrocker.net 6. msg-id: 013501c8ea6a$271e28a0$6501a...@china.huawei.com 7. msg-id: p06250100c4a9226eac87@[75.145.176.242] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Ietf Digest, Vol 39, Issue 13
Maurice Zenarosa Technology Department Lynwood Unified School District ietf-requ...@ietf.org wrote: If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/ietf Click the 'Unsubscribe or edit options' button, log in, and set Get MIME or Plain Text Digests? to MIME. You can set this option globally for all the list digests you receive at this point. Send Ietf mailing list submissions to ietf@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/ietf or, via email, send a message with subject or body 'help' to ietf-requ...@ietf.org You can reach the person managing the list at ietf-ow...@ietf.org When replying, please edit your Subject line so it is more specific than Re: Contents of Ietf digest... Today's Topics: 1. Re: A modest proposal for Friday meeting schedule (Spencer Dawkins) 2. Re: Drafts Submissions cut-off (SM) -- Message: 1 Date: Tue, 2 Aug 2011 13:10:52 -0500 From: Spencer Dawkins spen...@wonderhamster.org To: Peter Saint-Andre stpe...@stpeter.im, John C Klensin j...@jck.com Cc: IETF ietf@ietf.org Subject: Re: A modest proposal for Friday meeting schedule Message-ID: fbfc03ef62e7437bb9051cb99ea1f...@china.huawei.com Content-Type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Peter, A side benefit is that the IESG/IAB could have a lunch meeting on Friday (as opposed to the current breakfast meeting) and cover all the hot topics from the week (not the week minus Friday). /psa I agree with your point here, and add that the joint IAB/IESG Friday session isn't only a BOF report session, it's hot spots, however defined - we've usually at least SEEN all the BOFs by Friday breakfast, but that doesn't mean we've seen all the hot spots ;-) Spencer -- Message: 2 Date: Mon, 01 Aug 2011 17:46:49 -0700 From: SM s...@resistor.net To: Phillip Hallam-Baker hal...@gmail.com Cc: IETF Discussion Mailing List ietf@ietf.org Subject: Re: Drafts Submissions cut-off Message-ID: 6.2.5.6.2.20110801172353.0696f...@resistor.net Content-Type: text/plain; charset=us-ascii; format=flowed Hi Phillip, At 11:31 AM 8/1/2011, Phillip Hallam-Baker wrote: Over the weekend I attempted to determine the rules for discussion of drafts at IETF meetings and was surprised to discover that they are not actually written down anywhere (other than on the meetings page). As a result we appear to have an anomalous situation in which an author who misses the cut-off date for ID submissions is in fact entitled to sit on the draft for two weeks and then submit when the ID queue re-opens. I suggest that this is a sub-optimal state of affairs. I see two solutions: 1) Codify the requirement that materials to be discussed at the meeting must be submitted before the cut-off and that submissions made during meetings are strictly limited to revisions occurring after and between WG sessions. [Except in exceptional circumstances with AD approval] 2) Eliminate the 2 week cut off completely. I'll start by quoting Scott Brim [1]: One generation's rule of thumb becomes the next generation's dogma. The IETF should sit up and really think when someone suggests that a process has become dogma. Quoting Ned [2]: I'd much rather breach the sanctity of the rules by getting rid of some of them entirely. Quoting Russ [3]: When all of the Internet-Drafts were processed by Secretariat staff, there was a huge workload concern. Now that the Internet-Draft Submission Tool (IDST) is taking the bulk of the load, there are resources to deal with these exceptions, as was just demonstrated. Which was in response to John Klensin who said [4]: The original reason for those cutoffs -- even more important than giving people time to read drafts -- was that the submissions were overwhelming the Secretariat. Not only did they have other things to do in the weeks before the meeting, it was becoming unpredictable whether a draft submitted in advance of the meeting would be posted early enough for the relevant WG to look at it. The split between new and revised drafts was another attempt to protect the Secretariat -- notions of having to formally approve WG drafts came later. And Dave said [5]: It would seem that the right thing is to remove the cutoff and let each working group decide on what drafts will be worked on. Spencer Dawkins [6] quoted Section 7.1 of RFC 2418. Pete Resnick was of the opinion [7] that: The cutoff is an arbitrary procedure to try (poorly IMO) to enforce the 2418 rule. I suggest that WG chairs stop asking the working group whether they have read the
Re: DKIM Signatures now being applied to IETF Email
On 8/1/2011 8:41 AM, Scott Kitterman wrote: In fairness to Hector, the functionality that he is complaining is missing was part of the original working group charter. please cite the text from the original charter that promises such work and, just to be safe, please cite the current text that claims it should be there. In other words, the current complaint is about something missing. Please quote the specification of that and then the part of the original charter that said we would do it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: A modest proposal for Friday meeting schedule
On 2011-08-03 05:45, Mark Nottingham wrote: snip ... Some people will still doubtless complain. /snip Could we take this as the conclusion of this discussion? I'm being serious. Tuning the schedule in the light of feedback should be a constant concern, amd it will always be a balancing act between varying preferences among participants, session chairs, and area directors, *plus* constraints from room layout, costs and availability at each venue. I expect the schedule to be a work in progress for ever. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
Dave CROCKER wrote: On 8/1/2011 8:41 AM, Scott Kitterman wrote: In fairness to Hector, the functionality that he is complaining is missing was part of the original working group charter. please cite the text from the original charter that promises such work and, just to be safe, please cite the current text that claims it should be there. In other words, the current complaint is about something missing. Please quote the specification of that and then the part of the original charter that said we would do it. We are perfectly aware you never believed in policy, never really acknowledge it, fought hard against its progress. I can respect that position. But I am bit vex as to why you are questioning its existence as an original and still current WG work item. The DKIM WG always had among its charter work items to produce a Domain Policy standard and even thought the charter was revised over the years, Policy is still today among the WG chartered item today. I personally have not seen or read of any official statement to conclude the WG and stop all remaining work, nor a change in the charter to official remain policy as a work item. Attached is 2005 copy of the charter I have on disk. Please note how reputation was declared of out of scope, yet it continued to disrupt the WG and revamped DKIM to its present condition. Two other WG RFC work items were completed; one directly related to producing the Requirements for a DKIM Signing Practices Protocol RFC5016, and a Threat Analysis RFC4686 which includes among its analysis how policy can mitigate certain security threats using Policy. You, yourself, wrote a RFC5585 called DomainKeys Identified Mail (DKIM) Service Overview with signing practices peppered over all the document as a major piece of the system. This sentence is found in the abstract: DKIM also enables a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages. And the RFC includes a spiffy process flow illustration titled DKIM Service Architecture with a Checking Signing Practice component as a major piece of this design. So I am scratching my head here wondering why you are now questioning how a framework designed over 5 years had major work productions dismissed, especially those related to security, in the pursuit of the unrestricted resigner and 3rd party trust vendor service market and now seem to suggest the DKIM WG Domain Signing Practices standardization efforts was not a work item and never existed in the first place as a charter item, when in fact, it is still today a WG charter item. Very odd. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com DRAFT IETF WORKING GROUP CHARTER 14 Oct 2005 Domain Keys Identified Message (DKIM) CHAIRS: TBD AREA DIRECTORS: Russell Housley, Sam Hartman AREA ADVISOR: Russell Housley hous...@vigilsec.com MAILING LISTS: General Discussion: ietf-d...@mipassoc.org To Subscribe: http://mipassoc.org/mailman/listinfo/ietf-dkim Archive: http://mipassoc.org/pipermail/ietf-dkim/ DESCRIPTION OF WORKING GROUP: The Internet mail protocols and infrastructure allow mail sent from one domain to purport to be from another. While there are sometimes legitimate reasons for doing this, it has become a source of general confusion, as well as a mechanism for fraud and for distribution of spam (when done illegitimately, it's called spoofing). The DKIM working group will produce standards-track specifications that allow a domain to take responsibility, using digital signatures, for having taken part in the transmission of an email message and to publish policy information about how it applies those signatures. Taken together, these will assist receiving domains in detecting (or ruling out) certain forms of spoofing as it pertains to the signing domain. The DKIM working group will produce summaries of the threats that are addressed by the standards-track specifications, while acknowledging their limitations and scope. The DKIM working group will also produce security requirements to guide their efforts, and will analyze the impact on senders and receivers who are not using DKIM, particularly any cases in which mail may be inappropriately labeled as suspicious or spoofed. While the techniques specified by the DKIM working group will not prevent fraud or spam, they will provide a valuable tool for defense against them by allowing receiving domains to detect spoofing of known domains. The standards-track specifications will not mandate any particular action by the receiving domain when spoofing is detected. The DKIM working group will not attempt to define such actions, to establish requirements for trust relationships between domains, or to specify reputation or accreditation systems.
Re: technical plenary [was: A modest proposal for Friday meeting schedule]
On Mon, Aug 1, 2011 at 4:52 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: In any case, the IRTF Report, IAB Report and RSOC Report could certainly be made in the other plenary. Or omitted entirely, since they are duplicative of data which would be better communicated in writing. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: DKIM Signatures now being applied to IETF Email
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Hector Santos Sent: Tuesday, August 02, 2011 2:33 PM To: ietf@ietf.org Subject: Re: DKIM Signatures now being applied to IETF Email We are perfectly aware you never believed in policy, never really acknowledge it, fought hard against its progress. I can respect that position. But I am bit vex as to why you are questioning its existence as an original and still current WG work item. Where I come from, personal attacks don't support your position; they degrade your credibility. The DKIM WG always had among its charter work items to produce a Domain Policy standard and even thought the charter was revised over the years, Policy is still today among the WG chartered item today. I personally have not seen or read of any official statement to conclude the WG and stop all remaining work, nor a change in the charter to official remain policy as a work item. There is no rule anywhere that I've seen requiring a working group to complete all of its chartered items if one of them turns out to be a bad or dangerous idea, especially if the sponsoring Area Director concurs. It doesn't matter what other informational documents it may have produced prior to that point. This is also true if the working group runs out of steam to keep working on something. All of those things happened here. The ongoing claims that the working group was guided by sinister designs to benefit from some specific alternate market are simply absurd. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
On 7/30/11 11:05 AM, Joel M. Halpern wrote: It seems to me that this does two things, both small but useful. 1) It makes a minor change in the advancement procedures so that they are more reasonable. They may still not be sufficiently reasonable to be used, but it improves them, and thereby improves the odds. Actually, there is no evidence that this is an improvement. I'd agree that it is a minor change, but there has been no serious analysis of whether it is an improvement or not. To the extent to which approving this lowers the odds of considering and making changes that might actually have significant effects (e.g., really sorting out what maturity levels mean in a world of increasingly complex standards), it is harmful. See long discussion below. 2) It is coupled to an intent to actually behave according to what the document says. Such an intent is obviously not feasible without some change. Well, yes and no. My sense of the discussion over the last year is that a significant fraction of the community believes that the critical path change in this area is an adjustment to the threshold for Proposed Standard. That issue is addressed in draft-bradner-restore-proposed, which requires no change to RFC 2026 or other formal procedures at all. It is not addressed in this document. It is useful to have our behavior and our documented description of how we work match because the mismatch causes confusion, at least for new participants, and sometimes even for experienced participants. I agree with this. But this document doesn't make nearly enough of a contribution in that area to justify approving it. It addresses exactly one provision of our processes in which documentation and practice don't align, a provision about which there is no subtlety or confusion within the community at all (even though new participants may be confused). If the issue is important, then let's make a serious effort to update the places where 2026, 2028, 2031, 2360, 3710, 4071, and probably several other documents have fallen at least somewhat out of line with reality. If the particular issue of the annual review is really more important than any of those other issues, I assume that a stand-along document that changed it would rapidly achieve community consensus (albeit with some complaints about wasted time). Certainly it should not be sufficient to justify approving this document... the change is almost irrelevant to it. It might be the case that it will improve the advancement percentage. It might not. I can not imagine that it will make that even worse. I can because the effects of changes like this are actually very hard to predict. It increases the requirements for the second level, however slightly. Since we have trouble getting things to the second level now, that increased requirement might reduce incentives to bring things off Proposed at a least as much as a theoretical just one more level and then you are finished change would increase those incentives. By changing Proposed from 1/3 of the way to 1/2 way or a bit more, it might remove a small incentive to take the additional step. In addition, the publication without a new RFC provision may actually further increase the de facto requirements for Proposed Standards by requiring that those documents be edited to a high standard of clear English and specification precision. While, IMO, we have taken too little advantage of it, the current provisions of RFC 2026 permit publishing a Proposed Standard as soon as the WG understands it, leaving language cleanup (and refined translation from the writing styles of many people in the community whether native speakers of English or not) for Draft Standard versions. More important, for those of us who believe that a maturity system based on rigid named categories that apply to entire documents has outlived its usefulness as our specifications have become more complex, approval of this document is almost certain to cause consideration of such approaches to be postponed by some years as people complain that the changes made in this draft must have time to take effect and be evaluated. --- A more extended analysis of other aspects of the situation with this document follows. Those who don't like extended analyses might want to stop reading at some point. A very long time ago, a then-professor of mine observed that one of the most common sources of failures in engineering, especially computer engineering, was to look at a problem that seemed too large or too intractable, find some easily-changed and tractable part of the problem, do something with it (almost anything), and then claim that significant progress had been made on the original/ real problem because one had started on it. In many cases, the approach actually makes the real problem harder: systems become more complex, applying remedies later turns out to be more complicated, and so on. The narrow solution may also use up
Re: A modest proposal for Friday meeting schedule
On Aug 2, 2011, at 5:08 PM, Brian E Carpenter wrote: Could we take this as the conclusion of this discussion? +1 I'm being serious. Tuning the schedule in the light of feedback should be a constant concern, amd it will always be a balancing act between varying preferences among participants, session chairs, and area directors, *plus* constraints from room layout, costs and availability at each venue. I expect the schedule to be a work in progress for ever. +1 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: A modest proposal...
On Aug 1, 2011, at 12:57 PM, Mark Atwood wrote: On Mon, Aug 1, 2011 at 10:08 AM, Hadriel Kaplan hkap...@acmepacket.com wrote: Fascinating. I had no idea that there even *was* such a phrase in common usage, let alone that there was known etymology for it. One learns something new every day. But I meant it quite literally: a moderate/humble/etc. proposal for Friday meeting schedule. English is funny that way, and it's one of the things that make it such a difficult language to learn. 草泥马 ... 河蟹 idiom isn't a new concept. A great deal of the meaning is not in the literal meaning of a given chain of words, but is also contained in the historical and literary allusions that given phrases may have, which often have the direct opposite or at least very different meaning than the literal words. ..m ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
With mild apologies, I have retained John's text below because, even though I come to a different conclusion, I thought it important to retain for now. If folks choose to follow up on this, significant trimming is recommended. John, as far as I can tell there are three problems which various folks have wanted this document or its predecessor to address: 1) That the bar for PS is too high 2) That not enough documents are advancing up the standards track 3) That what we do and what we say we do do not match. Clearly, these problems are related. We could try to adopt a change that would address all three. I dobut we would accomplish anything. As far as I can tell, this document sensible tries to address one of these, namely item 3. It tries to align what we document with what we do. In order to do so, it also makes a change which may help item 2. It may not. Now, you can argue that it is taking up energy that should go to item 1. That is not unreasonable. Except that I consider all the proposals I have seen for item 1 to be failures. They fail in different ways, but they all have appeared to me to be bad ideas. (I think, based on conversations, some folks were supporting the previous version of this document in the mistaken believe that it did more to address that than it actually provided.) As such, we can either do nothing, or take this step that in my personal opinion addresses item 3, might turn out to help item 2, and does not hurt item 1. I believe I understand your point below that without understanding how we ought to address problem 1, it is hard to be confident we are not making it worse rather than better. Yours, Joel On 8/2/2011 6:51 PM, John C Klensin wrote: On 7/30/11 11:05 AM, Joel M. Halpern wrote: It seems to me that this does two things, both small but useful. 1) It makes a minor change in the advancement procedures so that they are more reasonable. They may still not be sufficiently reasonable to be used, but it improves them, and thereby improves the odds. Actually, there is no evidence that this is an improvement. I'd agree that it is a minor change, but there has been no serious analysis of whether it is an improvement or not. To the extent to which approving this lowers the odds of considering and making changes that might actually have significant effects (e.g., really sorting out what maturity levels mean in a world of increasingly complex standards), it is harmful. See long discussion below. 2) It is coupled to an intent to actually behave according to what the document says. Such an intent is obviously not feasible without some change. Well, yes and no. My sense of the discussion over the last year is that a significant fraction of the community believes that the critical path change in this area is an adjustment to the threshold for Proposed Standard. That issue is addressed in draft-bradner-restore-proposed, which requires no change to RFC 2026 or other formal procedures at all. It is not addressed in this document. It is useful to have our behavior and our documented description of how we work match because the mismatch causes confusion, at least for new participants, and sometimes even for experienced participants. I agree with this. But this document doesn't make nearly enough of a contribution in that area to justify approving it. It addresses exactly one provision of our processes in which documentation and practice don't align, a provision about which there is no subtlety or confusion within the community at all (even though new participants may be confused). If the issue is important, then let's make a serious effort to update the places where 2026, 2028, 2031, 2360, 3710, 4071, and probably several other documents have fallen at least somewhat out of line with reality. If the particular issue of the annual review is really more important than any of those other issues, I assume that a stand-along document that changed it would rapidly achieve community consensus (albeit with some complaints about wasted time). Certainly it should not be sufficient to justify approving this document... the change is almost irrelevant to it. It might be the case that it will improve the advancement percentage. It might not. I can not imagine that it will make that even worse. I can because the effects of changes like this are actually very hard to predict. It increases the requirements for the second level, however slightly. Since we have trouble getting things to the second level now, that increased requirement might reduce incentives to bring things off Proposed at a least as much as a theoretical just one more level and then you are finished change would increase those incentives. By changing Proposed from 1/3 of the way to 1/2 way or a bit more, it might remove a small incentive to take the additional step. In addition, the publication without a new RFC provision may actually further increase the de facto
Re: Languages, idiom, reference, subtext, ...
It was once explained to me that a government agency that takes information extraction seriously has several levels of testing for language proficiency. For all (okay, maybe almost all, I do not have the details) the languages they care about, the higher level testing focuses on knowledge of culture, literature, and similar context for actually understanding what is being said. Yours, Joel (Halpern) On 8/2/2011 8:21 PM, Joel Jaeggli wrote: On Aug 1, 2011, at 12:57 PM, Mark Atwood wrote: On Mon, Aug 1, 2011 at 10:08 AM, Hadriel Kaplanhkap...@acmepacket.com wrote: Fascinating. I had no idea that there even *was* such a phrase in common usage, let alone that there was known etymology for it. One learns something new every day. But I meant it quite literally: a moderate/humble/etc. proposal for Friday meeting schedule. English is funny that way, and it's one of the things that make it such a difficult language to learn. 草泥马 ... 河蟹 idiom isn't a new concept. A great deal of the meaning is not in the literal meaning of a given chain of words, but is also contained in the historical and literary allusions that given phrases may have, which often have the direct opposite or at least very different meaning than the literal words. ..m ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Drafts Submissions cut-off
Well here we have a rule that seems to be codified so it has the exact opposite of any rational effect. Either don't have a cutoff at all or make it a requirement that all materials be submitted in advance of the meeting. On Mon, Aug 1, 2011 at 8:46 PM, SM s...@resistor.net wrote: Hi Phillip, At 11:31 AM 8/1/2011, Phillip Hallam-Baker wrote: Over the weekend I attempted to determine the rules for discussion of drafts at IETF meetings and was surprised to discover that they are not actually written down anywhere (other than on the meetings page). As a result we appear to have an anomalous situation in which an author who misses the cut-off date for ID submissions is in fact entitled to sit on the draft for two weeks and then submit when the ID queue re-opens. I suggest that this is a sub-optimal state of affairs. I see two solutions: 1) Codify the requirement that materials to be discussed at the meeting must be submitted before the cut-off and that submissions made during meetings are strictly limited to revisions occurring after and between WG sessions. [Except in exceptional circumstances with AD approval] 2) Eliminate the 2 week cut off completely. I'll start by quoting Scott Brim [1]: One generation's rule of thumb becomes the next generation's dogma. The IETF should sit up and really think when someone suggests that a process has become dogma. Quoting Ned [2]: I'd much rather breach the sanctity of the rules by getting rid of some of them entirely. Quoting Russ [3]: When all of the Internet-Drafts were processed by Secretariat staff, there was a huge workload concern. Now that the Internet-Draft Submission Tool (IDST) is taking the bulk of the load, there are resources to deal with these exceptions, as was just demonstrated. Which was in response to John Klensin who said [4]: The original reason for those cutoffs -- even more important than giving people time to read drafts -- was that the submissions were overwhelming the Secretariat. Not only did they have other things to do in the weeks before the meeting, it was becoming unpredictable whether a draft submitted in advance of the meeting would be posted early enough for the relevant WG to look at it. The split between new and revised drafts was another attempt to protect the Secretariat -- notions of having to formally approve WG drafts came later. And Dave said [5]: It would seem that the right thing is to remove the cutoff and let each working group decide on what drafts will be worked on. Spencer Dawkins [6] quoted Section 7.1 of RFC 2418. Pete Resnick was of the opinion [7] that: The cutoff is an arbitrary procedure to try (poorly IMO) to enforce the 2418 rule. I suggest that WG chairs stop asking the working group whether they have read the draft as it is silly. It is an impossible task to keep up with the flood of I-D that are submitted on Meeting Monday. Regards, -sm 1. msg-id: 48821469.4050...@employees.org 2. msg-id: 01MXC0962CLI7A@mauve.**mrochek.com01mxc0962cli000...@mauve.mrochek.com 3. msg-id: 20080719191556.567F03A6A32@**core3.amsl.com20080719191556.567f03a6...@core3.amsl.com 4. msg-id: 2E1B2AB9703690B8E1EEBE90@p3.**JCK.COM2e1b2ab9703690b8e1eeb...@p3.jck.com 5. msg-id: 48826dc0.8000...@dcrocker.net 6. msg-id: 013501c8ea6a$271e28a0$6501a8c0**@china.huawei.com6501a...@china.huawei.com 7. msg-id: p06250100c4a9226eac87@[75.145.**176.242] -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Drafts Submissions cut-off
On 8/2/11 8:03 PM, Phillip Hallam-Baker wrote: Either don't have a cutoff at all or make it a requirement that all materials be submitted in advance of the meeting. Personally, I think chairs should have the discretion to allow or disallow discussion of documents submitted at any time, that they should be tougher about what they disallow, and that they should face the wrath of their WG members and their AD if they aren't. Right now, we have a deadline, but also allow for special dispensation to let drafts through. If chairs feel that they need *some* deadline written down somewhere in order to push back on things, I have an alternate suggestion: Right now, all -00 submissions of WG drafts are gated on chair approval (I believe in an automated fashion). We could simply make the tool gate *all* WG submissions from some time before the meeting through the meeting week. That way, chairs can decide whether they will enforce the deadline and not let the draft through, or make exceptions and let the drafts through. See above statement regarding wrath if the chairs abuse this authority in either direction. (If we had the resources, we could make the tool settable on a per-WG basis: One chair could say, I want to gate all drafts, another could say, I want to gate none, and others could put in a date range for gating.) Again, I don't think there needs to be a cutoff or a gating function. Chairs already have the authority to tell folks to go jump in a lake. But I'm not against a tool if chairs feel like they need some sort of official pushback mechanism. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Drafts Submissions cut-off
Several years ago, when submitting drafts became automated, we used to have a hard cut-off and be unable to submit new drafts until after IETF. That caused issues if discussions caused the desire to change/update drafts during the meeting, then there was no way of having an easily accessible version. The current situation is a compromise where drafts can be updated during the meeting - and WG chairs have discretion. I think we've tweaked this one enough - not all WGs are the same. Alia On Tue, Aug 2, 2011 at 9:52 PM, Pete Resnick presn...@qualcomm.com wrote: On 8/2/11 8:03 PM, Phillip Hallam-Baker wrote: Either don't have a cutoff at all or make it a requirement that all materials be submitted in advance of the meeting. Personally, I think chairs should have the discretion to allow or disallow discussion of documents submitted at any time, that they should be tougher about what they disallow, and that they should face the wrath of their WG members and their AD if they aren't. Right now, we have a deadline, but also allow for special dispensation to let drafts through. If chairs feel that they need *some* deadline written down somewhere in order to push back on things, I have an alternate suggestion: Right now, all -00 submissions of WG drafts are gated on chair approval (I believe in an automated fashion). We could simply make the tool gate *all* WG submissions from some time before the meeting through the meeting week. That way, chairs can decide whether they will enforce the deadline and not let the draft through, or make exceptions and let the drafts through. See above statement regarding wrath if the chairs abuse this authority in either direction. (If we had the resources, we could make the tool settable on a per-WG basis: One chair could say, I want to gate all drafts, another could say, I want to gate none, and others could put in a date range for gating.) Again, I don't think there needs to be a cutoff or a gating function. Chairs already have the authority to tell folks to go jump in a lake. But I'm not against a tool if chairs feel like they need some sort of official pushback mechanism. pr -- Pete Resnickhttp://www.qualcomm.**com/~presnick/http://www.qualcomm.com/%7Epresnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 __**_ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/**listinfo/ietfhttps://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: A modest proposal...
On 8/1/2011 10:08 AM, Hadriel Kaplan wrote: Fascinating. I had no idea that there even*was* such a phrase in common usage, let alone that there was known etymology for it. One learns something new every day. But I meant it quite literally: a moderate/humble/etc. proposal for Friday meeting schedule. Hadriel, Your proposal looked entirely serious to me and the only cultural import I saw was one of respecting people's desires to get home, perhaps a bit more than our desire for lunch at a reasonable hour (except for Spain)... I've seen the phrase used frequently for just the sort of thing you offered, namely something of limited scope and intent, seeking a narrow, pragmatic improvement. And it seems pretty clear from the multiple responses that other folks interpreted your posting similarly. Some phrases do indeed become cultural and linguistic icons, but it never occurred to me that anyone saw this phrase that way. Given a couple of thousand regular participants in IETF lists, I suspect the list of such latent sensitivities is quite long. My own concern about this is that I never enjoy being reminded, once again, about just how poorly educated I am, since I hadn't heard of Swift's essay... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
WG Action: Conclusion of IP over DVB (ipdvb)
The IP over DVB (ipdvb) working group in the Internet Area is closed. The group has published the specifications that it intended to develop, and additional topics have not been found sufficiently interesting to initiate new work. The mailing list will be kept open in case there is a need to discuss the existing specifications. Updates or small extensions of these RFCs can be sponsored through the ADs as individual submissions, and substantial new work can be started in the usual way in the IETF, i.e., through a BOF. The ADs would also like to thank everyone for the hard work over the years in producing the five RFCs from this group. Jari Arkko and Ralph Droms ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: Conclusion of Site Multihoming by IPv6 Intermediation (shim6)
The Site Multihoming by IPv6 Intermediation (shim6) working group in the Internet Area has concluded. The IESG contact persons are Jari Arkko and Ralph Droms. The mailing list will remain active. The SHIM6 working group has published its core set of specifications some years ago, and recently published an API specification as an RFC. The working group is therefore concluded, and the ADs would like to thank all the contributors for their hard work over the years. It is now time to close the working group and see when or if there will be deployment of these specifications that would warrant further IETF work. At least one additional document, the applicability statement, has been discussed by the group, but there has not been enough activity to complete it. It would have been a useful contribution. If the authors are interested in completing it, the ADs would be happy to sponsor them through the process as individual submissions. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
