Re: Admission Control to the IETF 78 and IETF 79 Networks
On 30 jun 2010, at 23:55, IETF Chair wrote: > To gain access to the IETF network, you will need to provide a > credential. Your primary credential will be your registration ID. You > can find your registration ID on the registration web page, in the > response email confirmation you received from the Secretariat, on your > payment receipt, and on the back of your IETF meeting badge. Your > Registration ID will be your user name, and it will be used with a > password that will be provided at a later date. This same password will > be used by all attendees. When and how will this password be distributed? I'll be arriving on saturday (to attend a workshop at the venue), it would be helpful if those who arrive early don't have to wait to get on the network until registration opens sunday at 11. (It occurs to me that a good way to give out this information pre-meeting is through inclusion on the payment receipt.) Also see Mark Andrews' message, on some systems it's useful or necessary to know the exact authtentication type that will be used. Thanks, Iljitsch ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-saintandre-tls-server-id-check
On Sun, Jul 18, 2010 at 08:02:52PM -0400, John C Klensin wrote: > Jeff, this works for me, but I don't think you really do the > spec's readers any favors by trying to reiterate the entire > history of terminology in this area (and, incidentally, leaving > things out that some folks might consider important like the > leading digit exception in 1123). Someday, someone should > produce a definitive DNS terminology document, but this spec > shouldn't try to be it. I think this is sound advice, and I think the rest of John's suggestion is also a good one. There are enough confusing interpretations of DNS terminology around without adding to them. (As to John's suggestion for a "definitive" DNS terminology document, all I can say is that it's hard enough to herd the DNS cats on topics where everyone seems roughly in agreement. Getting consensus on such a definitive document strikes me as more like trying to herd Schrödinger's cats.) A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Nomcom Enhancements: Improving the IETF leadership selection process
Looking at the numbers, and trying to estimate (because there are not clear records to make it easy to verify whether person X has ever been a WG chair, what I found was that typically, about 40% of the pool was "experienced by the conditions we were using. Assuming 100 volunteers (which has been about the rate recently), while this gives an expected value of 4 experienced members, it gave a significant probability of 1 or 2 experienced members. Conversely, with that same base, if one had a minimum of 4 experience members, since that removed only 4 people from the pool, it meant that the expected value would become about 6.4 experienced members, with a very high probability of getting 7 experienced members. I at least, and I believe others, felt this was too close to packing the committee. The goal is not to give experienced people control, but to make sure that there are enough experienced participants to inform the process. Hence, after debating, we settled on 3 for the first draw. This gives obviously a minimum of 3, and an expected value of almost 5.8, with a corresponding reduction in the odds of getting 7 or more experienced members. In some ways this still seemed to me to be uncomfortably high. But the other concern was that if we ever actually got a good turnout for the pool, such that experienced volunteers made up only 15 or 20 percent of the pool, the three minimum would still ensure that there were 3 experienced people on the committee. (The most inexperienced committee on record, as far as we could tell, occurred when we had a very good turnout for the nomcom volunteer pool, something I at least really appreciate, and not an especially high turnout of experienced people.) Yours, Joel M. Halpern PS: When we updated the nomcom eligibility for 2 out of 3 to 34 out of 5, there was much discussion of what the right balance was. The concern at the time, which I share, is that if we increase the window too much, folks who are not currently involved, but are coming back, would be eligible. And it seemed to the working group that it was important that folks experience be relatively recent. If the attendance condition has any meaning, someone who has skipped the last 5 meetings would seem to be lacking in currency. (It can be argued that the attendance condition doesn't work, but that is a very different debate.) Lixia Zhang wrote: On Jul 18, 2010, at 2:06 PM, Dave CROCKER wrote: Lixia, On 7/18/2010 1:14 PM, Lixia Zhang wrote: The comment: I support the idea of having a second 'expertise' pool of volunteers, but I wonder where comes this suggestion of selecting *3* members from this pool. A few random questions: - Do we know what is this number for the last several NOMCOMs? The last two Nomcom Chairs were part of the design team for the proposal. As I recall, Joel actually ran some of these kinds of numbers. I don't remember the details he produced, but they were part of our consideration and we definitely all haggled quite a bit about the number to recommend. If Joel already got the numbers, it seems useful to know. What about my other question, what percentage of volunteers over the last few years that would fall into this second pool? This would help understand the feasibility of the idea (i.e. the 2nd pool still needs to be large enough) There was a remarkable amount of support for 3, bordering on unanimity. (Exercise to the reader: take a guess who was the odd one out...) The reason for preferring 3 was balancing a desire to ensure a /minimum/ level of knowledge but also to limit the amouont of /dominance/ of old-timers. So the feeling was that two was not enough to meet the minimum, but requiring four would start feeling like dominance among the voting members. four is still less than half of voting members, not "dominance"? Take into account the fact that many people probably do not attend all IETF meetings, as a strawman for a longer IETF experience, what about attending 5 of the last 8 or 10 meetings? Speaking only for myself, I'll say that it's quite easy to go to many IETF meetings, but never learn anything about IETF process. the above statement applies in general, independent from the NOMCOM eligibility criteria. When someone has the responsibility for choosing the people who manage the process, we ought to focus on ensuring that level of knowledge. Hence the second pool. and I support the second pool idea I've been on 3 Nomcoms. Some of the folk who did not know much IETF process were nonetheless very strong contributors. Some weren't. The key argument for retaining this "less experienced" criterion is that it tends to add some fresh perspective (along with the naivete... so it's a mixed benefit.) - definitely people can all be strong contributors, with or without much IETF knowledge. - I think an effective NOMCOM does require some minimal IETF knowledge from its members. - fresh blood
Re: Nomcom Enhancements: Improving the IETF leadership selectionprocess
"Fred Baker" wrote: Generally speaking, I think people fall into broad classes - those who have followed a mailing list, those who have followed a mailing list and shown up for meetings, those who have written an internet draft, those who have pushed one through to RFC, those who have chaired a working group, and those who have served in some capacity on the I*. There might be another class. But those general groups, in sequence, will have a monotonically increasing experience with the processes and with the performance of people that are in those groups - someone who has pushed an ID through a working group probably has a better educated view of the chair than someone who has simply sat in the audience, and so on. Apparently by design, this sequence places meeting attendance at a very low level compared to other activities. Some people may have written one or more WG Internet-Drafts that went through to RFC, but have had neither corporate sponsorship nor independent wealth necessary to attend meetings. This situation is likely to continue, as people attending meetings at reduced day-pass fees are excluded from Nomcom eligibility. -- Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Nomcom Enhancements: Improving the IETF leadership selection process
On Sun, Jul 18, 2010 at 02:06:33PM -0700, Dave CROCKER wrote: > Speaking only for myself, I'll say that it's quite easy to go to many > IETF meetings, but never learn anything about IETF process. When someone > has the responsibility for choosing the people who manage the process, we > ought to focus on ensuring that level of knowledge. Hence the second > pool. I read the draft very quickly, and haven't absorbed it, but I have grave doubts about the premise above, which seems to be very important in justifying much of the additional process being proposed. To begin with, I have doubts that people who really haven't learned _anything_ about IETF process are going to be the ones who volunteer for Nomcom. They might not have the background that someone who has been involved since IETF 1 does. On the other hand, they're not likely to hanker for the old days of a teeny club where everyone knew every area, either. Second, let us suppose that we do eventually get a Nomcom that is in fact completely ignorant in the way the document suggests is possible (noting, of course, that it has actually never happened, and so we're fixing a theoretical problem). Why is that a disaster? It's not like the entire leadership of the IETF is replaced by a given Nomcom. In the worst case, what will happen is that we have a bad year. But there is nothing about the involvement of long-term participants that guarantees a non-bad year. They've in fact happened when we did not have a naive Nomcom. Moreover, perhaps such a Nomcom will cause more feedback to the Nomcom, as nervous experienced IETF participants realise that things they consider important are just not even things to think about for the Nomcom members. I think there are two things at work that undergird this proposal, and many of the other IETF process discussions I've observed. First of all, as protocol geeks we are prone to see any sub-optimal outcome as something that just needs better protocol design, so we are tempted to try to come up with a better specification. Moreover, a large number of IETF participants come from a culture founded around a written constitution, and so the assumption that more specific written rules is a natural one. I believe, however, that these process discussions are mostly harmful to the IETF. They lead to larger numbers of increasingly specific rules that later turn out to need exceptions, which exceptions cause another convulsion of the IETF consensus-forging machinery. Moreover, I think endless talk about how one operates is bad for any organization. (I grew up in Canada, and starting in the 1960s and extending well into the 1990s, we spent almost all our political energy talking about the Constitution.) Despite the claim in the draft that there are "serious problems" affecting the operation of Nomcoms, I'm not seeing what they are. The report from the 2009 chair suggested that there were some things that happened that made some people uncomfortable (and that's the only citation for the "serious problems" claim), but every one of them seemed to be addressable by action by the chair. We don't need more rules for this: we need the chair to do that work, as he or she apparently does year after year. In short, I don't think it is true that there is anything wrong with the current (admittedly low) experience requirements for the Nomcom, I don't see any evidence that someone more schooled in the ways of the IETF will necessarily benefit the Nomcom, and I don't see the evidence that the Nomcom needs more rules anyway. I also think that more process discussion is harmful to the IETF, and therefore I don't think this draft should be pursued. This is not to denigrate the contributions of the people who undertook it in the first place; but having uncovered that the arguments for more rules are weak, we should conclude that more work is not needed and stop doing the work, in exactly the way we would if we discovered that more protocol work would not help. Best regards, Andrew -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSV-DIR review of draft-daboo-srv-caldav-05
Hi Patrik, --On July 19, 2010 4:42:51 AM +0200 Patrik Fältström wrote: From my point of view, adding additional RR types with those properties (to MX, SRV, NAPTR, and arguably CNAME and DNAME) does increase the security risks -- not by adding risks that were not there before, but by making it harder to keep track of and analyze the various risk vectors, especially when these various RR types can have data that points to others of them. YMMD. Ok. I think the current resolution mechanism in the daboo-srv-caldav draft also have a very "interesting" security mechanism as that is relying on a correct SRV plus a redirect in HTTP that can redirect to anything...and in this second step you rely on both the SRV and the HTTP redirect actually refer you to the correct resource. This can be tied down of course if the HTTP redirect and the SRV are bound to: - The SRV not do a referral outside the domain in question - The http redirect is on the same server the SRV referred to But that also removes some "interesting" flexibility that one might want to do. Like hosting virtual domains at some hosting company. So the security in draft-daboo-srv-caldav is mostly addressed by reference to draft-saintandre-tls-server-id-check. In particular that draft describes use of the X509 SRVName attribute as a means for a client to determine that the SRV lookup results they got are valid (in addition to doing normal hostname checks on the actual host). I would suggest that your draft reference draft-saintandre-tls-server-id-check too, and perhaps suggest the same use of SRVName verification but in this case applied to the URI RR. (2) It seems to me that "we" may be creating very high expectations in the community for the security and integrity of information in DNSSEC-signed zones that can be validated with a root trust anchor (look at almost any of the recent announcements for examples). While I understand the "DNSSEC for the URI RR; TLS/SSL cert for the URI's hostname" model mentioned above and described in the I-D, the reality is that many, perhaps most, of the TLS/SSL certs in the world are nearly useless or, to put it more politely, offer a very low level of assurance relative to what people have been encouraged to believe about root-anchored DNSSEC. No luser is going to understand the difference between the two elements of the validation mechanism. Far more likely, the "weakest link" principle will apply and the expectation of security from DNSSEC will drop to that of the quality of the typical self-signed or "prove that you own the domain name by receiving mail" TLS/SSL cert. Again, at a minimum, I think your Security Considerations section should analyze and warn about the fragility in practice of the approach you suggest. What I think might be needed is that IETF comes up with a proper architecture for the following: "An application do have the need to contact a service. The service is identified by a unique identifier that is registered by IANA (that identifies a service) and a domain name. On top of that, there might be a sub-identifier in the form of a unique identifier for a user (i.e. local part in an email address etc). What are the steps the application should go through before it actually opens some connections over IP, and what should it do then to secure the whole thing." We have a number of alternatives: 1. Use MX 2. Use SRV and well known algorithm for the service, using prefixes of the owner 3. Use A and and well known algorithm 4. We have DDDS, using NAPTR with service selection in RDATA if DNS is used as the base database (of various flavours, UNAPTR etc) 5. We have the daboo-srv-caldav that uses SRV plus http redirect from a .well-known path that is used in the HTTP transaction 6. We have TXT records with well known syntax in the RDATA 7. I propose using a SRV-like prefix naming that give back full URIs, and the rest of the resolution have to do with URI resolution Bear in mind that the web folks are also looking at a solution in their domain - in particular proposals such as webfinger are a way to map an identifier (in this case based on a new acct: URI scheme) to various services. Let me state that I do not think we should delay the draft-daboo-srv-caldav IF a work like this is started. If we get some work like this, I suggest letting draft-daboo-srv-caldav pass, given people do not think the solution with an http redirect is too weird. So Alexey did ask the authors of .well-known about this use and we have a little side-thread going on that. I am certainly willingly to be persuaded that draft-daboo-srv-caldav is stretching the use too far, in which case I would suggest a "TXT path='/xyz'" solution. So one question I have with URI is whether additional "metadata" is likely to be needed? In which case TXT is likely to be used at provide that. If that is the case, then I don't see why URI is needed, vs SRV/TXT (with a path= in the TXT). I do not like th
Re: TSV-DIR review of draft-daboo-srv-caldav-05
--On Monday, July 19, 2010 04:42 +0200 Patrik Fältström wrote: >... >> No luser is going to understand the difference between the two >> elements of the validation mechanism. Far more likely, the >> "weakest link" principle will apply and the expectation of >> security from DNSSEC will drop to that of the quality of the >> typical self-signed or "prove that you own the domain name by >> receiving mail" TLS/SSL cert. Again, at a minimum, I think >> your Security Considerations section should analyze and warn >> about the fragility in practice of the approach you suggest. > > What I think might be needed is that IETF comes up with a > proper architecture for the following: > > "An application do have the need to contact a service. The > service is identified by a unique identifier that is > registered by IANA (that identifies a service) and a domain > name. On top of that, there might be a sub-identifier in the > form of a unique identifier for a user (i.e. local part in an > email address etc). What are the steps the application should > go through before it actually opens some connections over IP, > and what should it do then to secure the whole thing." > > We have a number of alternatives: > > 1. Use MX > 2. Use SRV and well known algorithm for the service, using > prefixes of the owner > 3. Use A and and well known algorithm > 4. We have DDDS, using NAPTR with service selection in RDATA > if DNS is used as the base database (of various flavours, > UNAPTR etc) > 5. We have the daboo-srv-caldav that uses SRV plus > http redirect from a .well-known path that is used in the HTTP > transaction > 6. We have TXT records with well known syntax in the RDATA > 7. I propose using a SRV-like prefix naming that > give back full URIs, and the rest of the resolution have to do > with URI resolution Part of the question I'd asking is whether, given the rate of growth, we will have 20 of those options a few years from now. If we do, what will that do to implementer confusion, interoperability, and security? The assumption that new RR types are fairly cheap does not imply that adding more and more nearly-equivalent (or at least functionally-overlapping) ones is desirable. So, yes, I think it may be time to do some serious architectural work here that comes up with specific guidelines, both about new RRs in this general area and about what should be used when. If we can't give crisp answers to the latter question, it may be time to start deprecating options, not just adding more of them. > Let me state that I do not think we should delay the > draft-daboo-srv-caldav IF a work like this is started. If we > get some work like this, I suggest letting > draft-daboo-srv-caldav pass, given people do not think the > solution with an http redirect is too weird. Agreed. I would not have stepped into this discussion at all had the possibility of substituting a still-unapproved new RR type not come up. I think the discussion has been very useful, but don't believe that we should hold the present draft up as a result. > I do not like the mechanism proposed in > draft-daboo-srv-caldav. Definitely not. But that is a > different thing than requiring rough consensus on a generic > way of finding an endpoint of a connection for a service. Agree with that too, including not liking the mechanism. > Luckily, Maastricht is a week from now and we can talk about > it. In our collective copious spare time. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSV-DIR review of draft-daboo-srv-caldav-05
On 19 jul 2010, at 16.07, Cyrus Daboo wrote: >> Let me state that I do not think we should delay the >> draft-daboo-srv-caldav IF a work like this is started. If we get some >> work like this, I suggest letting draft-daboo-srv-caldav pass, given >> people do not think the solution with an http redirect is too weird. > > So Alexey did ask the authors of .well-known about this use and we have a > little side-thread going on that. I am certainly willingly to be persuaded > that draft-daboo-srv-caldav is stretching the use too far, in which case I > would suggest a "TXT path='/xyz'" solution. > > So one question I have with URI is whether additional "metadata" is likely to > be needed? In which case TXT is likely to be used at provide that. If that is > the case, then I don't see why URI is needed, vs SRV/TXT (with a path= in the > TXT). Use of TXT RR? Arg... Not better. Why, why, why? >> I do not like the mechanism proposed in draft-daboo-srv-caldav. >> Definitely not. But that is a different thing than requiring rough >> consensus on a generic way of finding an endpoint of a connection for a >> service. >> >> Luckily, Maastricht is a week from now and we can talk about it. > > I'm up for that. Excellent. Interested parties should try to meet. Patrik PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSV-DIR review of draft-daboo-srv-caldav-05
On 7/18/2010 11:05 AM, Patrik Faltstrom (pfaltstr) wrote: On 18 jul 2010, at 19:18, "Joe Touch" wrote: That seems to means you use one of two different RRs, depending on the response. I don't see that as a step forward. No, the other way around. You, in a protocol, use either srv or uri depending on wether you need more than hostname and port or a uri. The point of SRVs is to provide a single way to find a service. When additional information is needed, it ought to be in an associated record (TXT or maybe a special URI one), but the host/port ought to remain in the SRV. We can discuss this further next week. Note that I consider addressing this important but not a show-stopper on this doc. The only showstopper was the "alias" issue (i.e., that, IMO, the names need to be registered in the informal SRV registry, and that IANA ports aliases are not appropriate as a stop-gap until that registry is integrated as per the iana-ports doc). Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Nomcom Enhancements: Improving the IETF leadership selection process
Andrew Sullivan wrote: > To begin with, I have doubts that people who really haven't learned > _anything_ about IETF process are going to be the ones who volunteer > for Nomcom. I have no doubts about that. A NomCom position is often considered a "leadership position" by one's sponsor or manager -- it is, after all, an HR job. To get into other leadership positions in the IETF, one has to build up reputation over time, and then be selected for it. To get a NomCom position, one need only volunteer, and -- these days, with 100 volunteers -- one has a 10% chance, more or less, of getting it. If one is in an organization that considers it a feather in one's cap to be on the NomCom, you'd better believe that one will volunteer, whether or not you think that's a bad thing. And to be clear, here, again: none of us think it's a bad thing to have some inexperienced people on the NomCom. We just think it's a good thing to ensure some critical mass of experienced ones, and we had a desire to be restrained about pushing the level of that critical mass. > Second, let us suppose that we do eventually get a Nomcom that is in > fact completely ignorant [...] Why is that a disaster? It's not like > the entire leadership of the IETF is replaced by a given Nomcom. Without trying to define "disaster", I'll remind you that, while the NomCom is not replacing the *entire* leadership, it is selecting *half* the leadership (and the overall char, in alternate years). That's a lot. And each of those appointees is in for two years, barring such severe problems as to cause a recall -- a very expensive and disruptive process that we'd like to avoid. It would certainly be, if not a "disaster", decidedly difficult and disruptive to have one of the two ADs from each of, say, three or four area... be poorly suited to the job. The same goes for the IETF general chair. There's no guarantee that a NomCom with "enough" experienced people will not choose some poorly suited persons for leadership roles, but we think it's unlikely for such a NomCom to go *too* far wrong with too many of their selections. > Despite the claim in the > draft that there are "serious problems" affecting the operation of > Nomcoms, I'm not seeing what they are. The report from the 2009 chair > suggested that there were some things that happened that made some > people uncomfortable (and that's the only citation for the "serious > problems" claim), but every one of them seemed to be addressable by > action by the chair. The selection process is, of course, not controlled by the NomCom chair, so the part above is not addressable by the chair. Some of the "uncomfortable" bits apparently involved people being unwilling to be candid because one particular liaison or other was in the room. That's addressed by another of our recommendations, which gives the chair a way to address that, which s/he doesn't have now. In general, the document suggests a combination of minor process changes and suggestions that can be implemented at the will of the NomCom. Remember that the chair can't decide what the NomCom as a whole will do. The chair runs the *process*, and facilitates the meetings. The voting members are who make the decisions. Lots of people have lots of ideas about how we ought to change the NomCom process, putting more rules in or fewer. This document represents the consensus of a relatively small but significant and experienced group of people... about a minimal set of changes that we think are important. We're not proposing vast changes and cumbersome new processes. We're going for simplicity, in order to address some of the points of most concern. Barry Leiba ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Historic Moment - Root zone of the Internet was just signed minutes ago!!!
Being able to verify signatures is of no value. The system only has value when you can act differently according to whether the signature verifies or not. I keep asking, but nobody will tell me how I get the keys for my domains into the TLD. This is not a trivial issue. There is a question of liability to be addressed. So far ICANN and VeriSign Registry Services have addressed the issue by booting it down the chain. But the system as a whole cannot work until there is someone willing to accept the liability and for that to happen they are going to require tools to manage their litigation risk. Does anyone know of a dotcom registrar offering key signing? Or is the big plan here that everyone who is not going to accept liability keep complaining about how far behind the registrars are until they are forced to act? On Fri, Jul 16, 2010 at 2:13 PM, Iljitsch van Beijnum wrote: > On 16 jul 2010, at 19:56, Ronald van der Pol wrote: > >>> http://fanf.livejournal.com/107310.html > >> Thanks! That was very useful. I finally got it working. > > Yes, me too. > >> I would also like to check the output for a zone that is verifyable not >> correct. Any examples of signed RRs with an incorrect signature? > > I skipped this step: > > In the options section of named.conf you should have the directive > dnssec-lookaside auto; > This enables DNSSEC lookaside validation, which is necessary to bridge gaps > (such as ac.uk) in the chain of trust between the root and lower-level signed > zones > > with the result that www.ietf.org, www.iab.org, www.isc.org, all fail to > validate. Not sure what the deal is there. Only www.nic.cat works. BTW, this > is great: > > https://addons.mozilla.org/en-US/firefox/addon/64247/ > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSV-DIR review of draft-daboo-srv-caldav-05
On 18 jul 2010, at 19:18, "Joe Touch" wrote: > That seems to means you use one of two different RRs, depending on the > response. > > I don't see that as a step forward. No, the other way around. You, in a protocol, use either srv or uri depending on wether you need more than hostname and port or a uri. Patrik ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSV-DIR review of draft-daboo-srv-caldav-05
On 19 jul 2010, at 17.34, Joe Touch wrote: >> No, the other way around. You, in a protocol, use either srv or uri >> depending on wether you need more than hostname and port or a uri. > > The point of SRVs is to provide a single way to find a service. For me, there should be a single way of finding a service, given the service you use. I.e. we already have (as I listed in a separate message) several ways of finding a service. Too many I claim. And it might get worse if we do not take care of this. I am not nervous over having multiple ways of finding a service, as long as one know that "for email, you do like this", or "for ssh, you do like this". > When additional information is needed, it ought to be in an associated record > (TXT or maybe a special URI one), but the host/port ought to remain in the > SRV. I am not happy about such solutions as they require multiple lookups in DNS. And if one is not very careful the two records might have overlapping and therefore conflicting information in them. > We can discuss this further next week. Yes please. > Note that I consider addressing this important but not a show-stopper on this > doc. Agree. If whatever IETF comes up with will be A Very Successful Mechanism, then this caldav work and other protocols can migrate over to the New And Improved way of doing things. > The only showstopper was the "alias" issue (i.e., that, IMO, the names need > to be registered in the informal SRV registry, and that IANA ports aliases > are not appropriate as a stop-gap until that registry is integrated as per > the iana-ports doc). Agree. The discussion about where to register names used for example for SRV has been going on since SRV RR was defined... Patrik ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Nomcom Enhancements: Improving the IETF leadership selection process
On Mon, Jul 19, 2010 at 11:42:00AM -0400, Barry Leiba wrote: > I have no doubts about that. A NomCom position is often considered a > "leadership position" by one's sponsor or manager -- it is, after all, > an HR job. To get into other leadership positions in the IETF, one > has to build up reputation over time, and then be selected for it. To > get a NomCom position, one need only volunteer, and -- these days, > with 100 volunteers -- one has a 10% chance, more or less, of getting > it. This sounds to me like a claim that there are organizations out there that are measuring one's career progress in terms of getting "leadership positions" in the IETF. Is the real worry here that the IETF is gradually being taken over by professional standards people as opposed to those who happen to be working on standards as a side effect of the "real" work they're doing? If so, I confess that I think this is so much windmill-tilting. The Internet is a much more mature technology than it once was, and therefore much greater conservatism creeps in. With such conservatism naturally comes additional specialization, which means that there will be increased involvement from a kind of specialist standardizer that was historically in the minority. I doubt we can really prevent this happening if, as you say, there are workplaces out there where getting a position on the Nomcom is an important career milestone. As an aside, I'll note that IETF activities were always regarded in any job I had (including the present) as a kind of side project, tangential to the main tasks (i.e. the ones that actually make the employer money). From experience in attempting to wring reviews and updated I-D text out of working group participants, I'd say that the same is mostly true of other IETF participants in the DNSEXT WG. Whether DNS is unusual in this regard, I don't know. > general chair. There's no guarantee that a NomCom with "enough" > experienced people will not choose some poorly suited persons for > leadership roles, but we think it's unlikely for such a NomCom to go > *too* far wrong with too many of their selections. I've heard this off-list, too. I want evidence. In my opinion, some past Nomcoms made some clanger bad decisions. (I'm sure we all have our favourite examples.) On what basis would we say that it would have turned out worse or better had the Nomcom been constituted differently? Even supposing that the semantics of counterfactuals were the sort of thing about which everyone agreed, there are so many variables that I'm not even sure where to start telling the alternate-universe story. It is entirely natural, I think, that people who have experience with the IETF think that their insights into how the IETF works will necessarily lead to better leadership selection. I also believe that my observations of the past would be helpful in making the right decisions in the future. In point of fact, however, I make bad decisions all the time. Maybe I'm just especially bad a this sort of thing, and others are more likely to apply correctly the lessons they've learned. In addition, there are surely going to be second-order effects of dividing the Nomcom into two classes. Once someone is designated as one of the "experienced" seats, won't it be natural for that person to start dismissing objections from the "less experienced" as simply the foolish objections of the naive? (Anyone even casually acquainted with the operation of any university department will be familiar with this effect.) Moreover, if the goal is to dilute the influence of the professional IETF wonk (see above), this policy will have the opposite effect: it will encourage people to do more of the things to meet the "checklist" for being "experienced", thereby pervesely actually undermining the absorbtion of IETF culture (whatever that is). Indeed, it will make marks of experience more valuable, which means that it will have the effect of _encouraging_ people to "run for office". The latter seems to be another thing the draft is aiming at preventing, and this plan will make the aim even harder to achieve. More rules -- even simple ones -- are always a greater favour to bureaucrats and professional wonks than to everyone else. Sometimes (even often), that cost is worth paying. But I am not convinced even a little that it is worth it in this case. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Follow up: Audio Streaming Info - IETF 78 July 25-30, 2010
Greetings again, For those interested in monitoring sessions or participating remotely at IETF 78 the following information may prove useful next monday. -Audio Streaming- All 8 parallel tracks at the IETF 78 meeting will be broadcast starting with the commencement of working group sessions on Monday, July 26th, 2010 at 0900 CEST (UTC+2) and continue until Friday the 30th at 1515 CEST. Additionally it is our intention to broadcast the IEPG meeting occurring on Sunday the 25st starting at 1000 CEST. Because I have been asked several times in the past, note that if you wish to use the rooms that are being recorded for impromptu meeting during unscheduled sessions or lunch breaks that you can invite remote participants to tune in to the appropriate stream. Recording cannot be guaranteed for unscheduled sessions. Conversely, it should never be assumed that recording or observation is not occurring on open microphones, they are after all connected to the Internet. The links for streaming sources and the schedule are best retrieved from the IETF tools agenda, which as per Standard operating procedure is located here: http://tools.ietf.org/agenda/78/ A page in the legacy style with links to the archives will is available here: http://videolab.uoregon.edu/events/ietf/ The links and associated playlist channel bindings (in place during the meeting) will be as follows: http://videolab.uoregon.edu/events/ietf/ietf781.m3u 0.1 London http://videolab.uoregon.edu/events/ietf/ietf782.m3u 0.2 Berlin http://videolab.uoregon.edu/events/ietf/ietf783.m3u 0.4 Brussels http://videolab.uoregon.edu/events/ietf/ietf784.m3u 0.8 Rome http://videolab.uoregon.edu/events/ietf/ietf785.m3u 0.9 Athens http://videolab.uoregon.edu/events/ietf/ietf786.m3u 2.1 Colorado http://videolab.uoregon.edu/events/ietf/ietf787.m3u Auditorium 1 http://videolab.uoregon.edu/events/ietf/ietf788.m3u Auditorium 2 http://videolab.uoregon.edu/events/ietf/ietf78.m3u All -Jabber/XMPP- For information on IETF Jabber participation see: http://www.ietf.org/jabber/index.html or click on the Jabber links in the tools team agenda once you have a properly configured jabber/xmpp messaging client. -Webex- Webex screen sharing in support of remote participation is possible for a limited number of sessions. Bi-directional audio is not supported for IETF 78. Consult with your working-group chair or the secretariate for more information. -Trouble Ticketing- For prompt access to the meeting trouble desk, the email address is: m...@ietf.org for streaming related issues please consider Jabber IM to joe...@gmail.com with info including the current time, channel and a succinct description of the problem as the fastest communications channel. I look forward to seeing many of you in Maastricht and still more online during IETF 78. Thanks Joel Jaeggli ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security) to Proposed Standa
On Sun, Jul 18, 2010 at 03:04:55PM -0700, Paul Hoffman wrote: > At 1:59 PM -0400 7/18/10, Shumon Huque wrote: > >Well, one reason would be to reduce the number of verification > >steps imposed on a client by a certificate with a more preferred > >or more specific identity type. > > Is there something more than just a non-mandatory optimization? The > three bullet points in the list all have MUSTs, and it sounds like > these MUSTs, and the statement that "The client then orders the list > in accordance with the following rules" passes muster with RFC 2119. > --Paul Hoffman, Director > --VPN Consortium Right, I agree with that. I'm not clear on whether you're objecting to an ordering rule. Or saying that the additional text in 4.3 about ordering is unnecessary. I'm not sure I really have a strong opinion on ordering per-se, but .. There are multiple possible identity types. Clients will presumably search for them in some order. Should we just tell them to try in whatever order they want, including random? Or should we tell them to try in the order of identities that we preferred application services to use, and move the deprecated ones (CN-ID) to the bottom of that list? Optimizing for the preferred use cases sounds to me like a reasonable thing to do. I do have a stronger opinion on the following point: I think there is a longer term security goal here, of nudging application protocols to use application specific identity types -- so that we avoid situations where a certificate with a generic domain name identity, if compromised for a particular service, can be used to impersonate other unrelated services at that domain name. As a general rule, different application services running at the same domain name should not be using the same certificates, unless by conscious choice of the deployer. Having a preferred ordering consistent with that goal is probably a good thing. I might be wandering too far away from your specific question now, so I'll stop. -- Shumon Huque University of Pennsylvania. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security) to Proposed Stand
At 7:16 PM -0400 7/19/10, Shumon Huque wrote: >On Sun, Jul 18, 2010 at 03:04:55PM -0700, Paul Hoffman wrote: >> At 1:59 PM -0400 7/18/10, Shumon Huque wrote: >> >Well, one reason would be to reduce the number of verification >> >steps imposed on a client by a certificate with a more preferred >> >or more specific identity type. >> >> Is there something more than just a non-mandatory optimization? The >> three bullet points in the list all have MUSTs, and it sounds like >> these MUSTs, and the statement that "The client then orders the list >> in accordance with the following rules" passes muster with RFC 2119. >> --Paul Hoffman, Director >> --VPN Consortium > >Right, I agree with that. > >I'm not clear on whether you're objecting to an ordering rule. Or >saying that the additional text in 4.3 about ordering is unnecessary. I am objecting to a MUST- or SHOULD-level ordering rule where it does not affect interoperability or security. I am still open to someone showing why this particular rule might affect those, but after many rounds, none has come forth, so I am suggesting dropping the rule altogether or making it MAY-level (with some reasoning as to why it is even worth the effort). >There are multiple possible identity types. Clients will presumably >search for them in some order. Should we just tell them to try in whatever >order they want, including random? Or should we tell them to try in >the order of identities that we preferred application services to use, >and move the deprecated ones (CN-ID) to the bottom of that list? >Optimizing for the preferred use cases sounds to me like a reasonable >thing to do. Why is it reasonable? It is *we* who are preferring the order, not them, even though we admit that any value returned from the order is secure enough. >I do have a stronger opinion on the following point: I think there is >a longer term security goal here, of nudging application protocols to >use application specific identity types -- so that we avoid situations >where a certificate with a generic domain name identity, if compromised >for a particular service, can be used to impersonate other unrelated >services at that domain name. As a general rule, different application >services running at the same domain name should not be using the same >certificates, unless by conscious choice of the deployer. Fully agree, and that is correctly addressed, repeatedly, in the rest of the document. >Having a preferred ordering consistent with that goal is probably >a good thing. Arrrgh. Why? >I might be wandering too far away from your specific question now, >so I'll stop. No, please continue. I truly would be happy if you could show why forcing them to order their search would help even though any match would do. I just am not seeing it. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Huge number of subscriptions disabled on ietf lists
Yesterday a roughly 50 people seem to have been unsubscribed from of the ip...@ietf list - It's possible this is perfectly normal but it struck me as sort of weird. Are others seems stuff like this on other lists? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security) to Proposed Standa
On Mon, Jul 19, 2010 at 05:50:39PM -0700, Paul Hoffman wrote: > At 7:16 PM -0400 7/19/10, Shumon Huque wrote: > > > >Right, I agree with that. > > > >I'm not clear on whether you're objecting to an ordering rule. Or > >saying that the additional text in 4.3 about ordering is unnecessary. > > I am objecting to a MUST- or SHOULD-level ordering rule where it does not > affect interoperability or security. I am still open to someone showing why > this particular rule might affect those, but after many rounds, none has come > forth, so I am suggesting dropping the rule altogether or making it MAY-level > (with some reasoning as to why it is even worth the effort). Fair enough. I don't have a reason to offer beyond the already mentioned optimization. And as a possible hint to folks about what the preferred types are. And as I mentioned earlier, I don't have a strong opinion on this. This draft is all about matching identities. It should sketch out the explicit details of some matching algorithm. Is your proposal to match identities in the order of their appearance in the certificate? Something else? Or leave this unspecified? [...] > >I do have a stronger opinion on the following point: I think there is > >a longer term security goal here, of nudging application protocols to > >use application specific identity types -- so that we avoid situations > >where a certificate with a generic domain name identity, if compromised > >for a particular service, can be used to impersonate other unrelated > >services at that domain name. As a general rule, different application > >services running at the same domain name should not be using the same > >certificates, unless by conscious choice of the deployer. > > Fully agree, and that is correctly addressed, repeatedly, in the rest of the > document. Oh, good. I was beginning to feel after several revisions of text, that the draft was not making this point (and the rationale behind it) strongly enough! [...] -- Shumon Huque University of Pennsylvania. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Historic Moment - Root zone of the Internet was just signed minutes ago!!!
In message , Phil lip Hallam-Baker writes: > Being able to verify signatures is of no value. > > The system only has value when you can act differently according to > whether the signature verifies or not. > > I keep asking, but nobody will tell me how I get the keys for my > domains into the TLD. Firstly you get DS records into the TLD not DNSKEY records. Secondly it is/will be by a mechanism similar to how you get NS records into the TLD. In other words go ask your registrar when they are going to support adding DS records and stop complaining here. This is not a technological problem. It is a business problem between you, your registrar and the registry. > This is not a trivial issue. There is a question of liability to be > addressed. So far ICANN and VeriSign Registry Services have addressed > the issue by booting it down the chain. But the system as a whole > cannot work until there is someone willing to accept the liability and > for that to happen they are going to require tools to manage their > litigation risk. How is the liability different from that of accepting NS records? DS records don't magically change the liability. Stuffing up either NS or DS records will break the delegation. > Does anyone know of a dotcom registrar offering key signing? > > Or is the big plan here that everyone who is not going to accept > liability keep complaining about how far behind the registrars are > until they are forced to act? Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
