Re: Comments surrounding draft-iab-dns-applications-01
In message alpine.bsf.2.00.1107042329060.89...@joyce.lan, John R. Levine wri tes: The naive approach of reversing the address, converting to nibbles and appending a suffix won't scale. For IPv6 if you did the reverse of /48, /52, /56, /60 and /64 prefixes, which matches delegation patterns along with NXDOMAIN synthesis, you would still be fine. You stop the search on NXDOMAIN or data with perhaps a new value which says to continue searching for white listed records. One could even start with /32 if one is worried about spammers pretending to be ISPs. I don't necessarily disagree, but now you've just upgraded the DNS (NXDOMAIN synthesis is far from universal) No, just application smarts is needed. The DNS already supports this and it has been used for over 1/2 a decade now. and layered a probing protocol on top of it. We can have a theological argument about whether that counts as using the DNS. R's, John -- 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
Re: Comments surrounding draft-iab-dns-applications-01
John R. Levine jo...@iecc.com wrote: DNSBLs already set the min pretty low, e.g. 150 sec for Spamhaus. Doesn't really matter how low it is if you have so many entries that they force out the useful ones. The really important records are the delegation chain NS records. It is not so necessary to keep leaf records in the cache. http://nms.csail.mit.edu/projects/dns/ Modern spam filters don't usually look up the author domain, since it's usually a genuine address taken from the spam list so it's unrelated to the real sender. I think it's still useful to reject mail with an unresolvable return path domain. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Lundy, Fastnet: Southwest 4 or 5, increasing 6 or 7 later. Moderate or rough, occasionally very rough later in Fastnet. Showers. Good. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments surrounding draft-iab-dns-applications-01
Mark Andrews ma...@isc.org wrote: DNS[WB]L's have never been a good fit to the DNS, rather they have not been a bad enough fit to require something better to be done. Oh come off it, they are just as good a fit to the DNS as reverse DNS is. The naive approach of reversing the address, converting to nibbles and appending a suffix won't scale. I don't understand why the setup is OK for reverse DNS but not blacklists. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Hebrides, Bailey, Fair Isle, Faeroes: Southeast 5 to 7, backing east or northeast 4 or 5, occasionally 6 in north Bailey. Moderate or rough. Occasional rain. Moderate or good, occasionally poor. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments surrounding draft-iab-dns-applications-01
Keith Moore mo...@network-heretics.com wrote: Yes, but rDNS PTR lookups always have been pretty much meaningless anyway, and will only get worse in IPv4 due to LSN. Reverse DNS for an LSN is just as informative as automatically populated reverse DNS (and much more convenient than a whois lookup). Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Portland, Plymouth, Biscay: South 4 or 5, veering west or southwest 5 or 6. Slight or moderate, occasionally rough later. Rain then showers. Moderate or good. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments surrounding draft-iab-dns-applications-01
On Jul 5, 2011, at 6:58 AM, Tony Finch wrote: Keith Moore mo...@network-heretics.com wrote: Yes, but rDNS PTR lookups always have been pretty much meaningless anyway, and will only get worse in IPv4 due to LSN. Reverse DNS for an LSN is just as informative as automatically populated reverse DNS (and much more convenient than a whois lookup). correct, in that both are meaningless. but I think the percentage of lookups that return meaningful information will decrease - though more due to address space exhaustion than LSN, I suppose. what LSN will decrease is the correlation between source IP address and source host, making any effort to associate a reputation with said addresses less valid. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: draft-ietf-v6ops-6to4-to-historic
From: Ronald Bonica rbon...@juniper.net I think that I get it. There is no IETF consensus regarding the compromise proposed below. ... But there is no rough consensus to do that either. That is the claim of an appeal on the table. Let's run the appeal process and figure out whether that claim is valid. Sorry, this makes no sense. You can't go ahead with draft-ietf-v6ops-6to4-to-historic if there is no basic consensus in the IETF as a whole to do so - and your previous declaration (on Saturday) basically accepted that there was no such basic consensus (otherwise why withdraw the ID). So now there is going to be a reversal, and the document is going to go ahead - i.e. you must now be taking the position that there _is_ basic consensus in the IETF (without which you could not proceed the ID). The effect of this sort of thing on the reputation of I* should be obvious to all. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sat, Jul 2, 2011 at 6:36 PM, Ronald Bonica rbon...@juniper.net wrote: - In order for the new draft to be published, it must achieve both V6OPS WG and IETF consensus If anyone objects to this course of action, please speak up soon. Great, back to square one. Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus. But perhaps I missed some discussion. Also, why do the author and the chairs think that the new draft will do any better than 6to4-historic? I would assume that the same people who spoke up against 6to4-historic will speak up against the new document, and since that level of opposition was sufficient to prevent the publication of 6to4-historic, it may be sufficient to prevent publication of the new document as well. If so, we will have spent 3-6 months arguing about it for naught. Please, nobody answer this question with welcome to the IETF :-) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
Very well said Lorenzo. +1 Unless Ron describes exactly one by one real reasons to give up on draft-ietf-v6ops-6to4-to-historic and majority of v6ops WG agrees with those reasons IMHO the document should proceed as is. It will say that if 6-to-4 is implemented, it must be turned off by default. Last ... if something is turned on or off by default is an implementation choice and last time I checked IETF was not in business to mandate any implementation choice. Thx, R. On Sat, Jul 2, 2011 at 6:36 PM, Ronald Bonica rbon...@juniper.net mailto:rbon...@juniper.net wrote: - In order for the new draft to be published, it must achieve both V6OPS WG and IETF consensus If anyone objects to this course of action, please speak up soon. Great, back to square one. Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus. But perhaps I missed some discussion. Also, why do the author and the chairs think that the new draft will do any better than 6to4-historic? I would assume that the same people who spoke up against 6to4-historic will speak up against the new document, and since that level of opposition was sufficient to prevent the publication of 6to4-historic, it may be sufficient to prevent publication of the new document as well. If so, we will have spent 3-6 months arguing about it for naught. Please, nobody answer this question with welcome to the IETF :-) ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
Hi Keith, I personally don't have any objection to the notion that 6to4 should be off by default and should require explicit configuration to enable it. Is there any feature (perhaps other then netboot) on commercial or open source routers which is not off by default and which would require explicit configuration to enable it ? Thx, R. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
In your letter dated Sat, 2 Jul 2011 16:02:47 -0400 you wrote: Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus. Even if there was rough consensus within v6ops, rough consensus of v6ops does not equate to rough consensus of the entire IETF community. Is there any summary of the IETF community consensus? I sort of can't imagine that ISPs want to continue operating 6to4 relays longer than strictly necessary. So I'm curious what the IETF community at large considers the future of 6to4 in it's default-disabled mode. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
If anyone objects to this course of action, please speak up soon. i object. as measured on the real internet, not the ietf bar, 6to4 sucks caterpillar snot. it is damaging to the users and to the users' view of ipv6. Great, back to square one. Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus. perhaps that minority was also vocal in the back room But perhaps I missed some discussion. Also, why do the author and the chairs think that the new draft will do any better than 6to4-historic? I would assume that the same people who spoke up against 6to4-historic will speak up against the new document, yes, but that will be a year from now. in the ietf, delay is one form of death. and since that level of opposition was sufficient to prevent the publication of 6to4-historic, it may be sufficient to prevent publication of the new document as well. If so, we will have spent 3-6 months arguing about it for naught. Please, nobody answer this question with welcome to the IETF :-) this is nutso. but this is normal. welcome to the ietf randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sun, Jul 3, 2011 at 2:38 AM, Mark Smith i...@69706e6720323030352d30312d31340a.nosense.org wrote: We know it can operate correctly and reliably if it is configured correctly. ... and in networks where there are public IP addresses and no firewalling, and... etc. etc. But we already had this discussion on v6ops, and since the consensus of the WG was that the draft should be published, there's no point having it again. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
All,
Perhaps declaring 6to4 deprecated rather than historic would have a
better chance of consensus.
Pardon my ignorance, but where is the document describing the
implications of historic{,al} vs deprecated?
This (http://tools.ietf.org/html/rfc2026#section-4.2.4) is well known:
A specification that has been superseded by a more recent
specification or is for any other reason considered to be obsolete is
assigned to the Historic level. (Purists have suggested that the
word should be Historical; however, at this point the use of
Historic is historical.)
Note: Standards track specifications normally must not depend on
other standards track specifications which are at a lower maturity
level or on non standards track specifications other than referenced
specifications from other standards bodies. (See Section 7.)
I don't know where similar explanatory language about Deprecated
might be (I'm sure I just didn't search correctly or long enough).
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sat, Jul 2, 2011 at 10:02 PM, Keith Moore mo...@network-heretics.comwrote: Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus. Even if there was rough consensus within v6ops, rough consensus of v6ops does not equate to rough consensus of the entire IETF community. And who says that rough consensus of the entire IETF community is that this draft should not be published? Were there public discussions to that effect that came to this conclusion? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
And who says that rough consensus of the entire IETF community is that this draft should not be published? Were there public discussions to that effect that came to this conclusion? that is usually determined when the iesg last calls the document after the wg has passed it to the iesg. the ipv6 heads are amazingly immune to reality. 6to4 has been measured and clearly demonstrated to have failed in the field. yes, it could work. but it doesn't. we need to get over it. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
Perhaps declaring 6to4 deprecated rather than historic would have a
better chance of consensus.
Pardon my ignorance, but where is the document describing the
implications of historic{,al} vs deprecated?
This (http://tools.ietf.org/html/rfc2026#section-4.2.4) is well known:
A specification that has been superseded by a more recent
specification or is for any other reason considered to be obsolete is
assigned to the Historic level. (Purists have suggested that the
word should be Historical; however, at this point the use of
Historic is historical.)
Note: Standards track specifications normally must not depend on
other standards track specifications which are at a lower maturity
level or on non standards track specifications other than referenced
specifications from other standards bodies. (See Section 7.)
I don't know where similar explanatory language about Deprecated
might be (I'm sure I just didn't search correctly or long enough).
Since 6rd depends on 6to4, as it is a variant of it, would 6to4 being
declared historic also mean that 6rd needs to become historic as well?
http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-05
Section 1, in which the draft clarifies that 6rd supersedes 6to4,
which meets the qualification in the first paragraph of the Historic
term. With 6rd we clearly don't need to have anything built on top of
6to4 in the future, addressing the 2nd paragraph.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
RE: [v6ops] draft-ietf-v6ops-6to4-to-historic
Yes, the Linksys E2000, E3000, E4200, WRT610N, and a small batch of Apple Airports had 6to4 on by default, but the latest firmware versions turn that off. Frank -Original Message- From: v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] On Behalf Of Keith Moore Sent: Saturday, July 02, 2011 3:26 PM To: rob...@raszuk.net Cc: v6...@ietf.org; IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic On Jul 2, 2011, at 4:22 PM, Robert Raszuk wrote: Hi Keith, I personally don't have any objection to the notion that 6to4 should be off by default and should require explicit configuration to enable it. Is there any feature (perhaps other then netboot) on commercial or open source routers which is not off by default and which would require explicit configuration to enable it ? I have understood that in the past there were a few routers that enabled 6to4 by default, though I don't know whether this is the case any longer. I also believe that there are currently hosts that enable 6to4 by default if there is no native v6 connectivity and the host has a public IPv4 address. Keith ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
1) as measured on the real internet, not the ietf bar, 6to4 sucks caterpillar snot 2) perhaps that minority was also vocal in the back room 3) yes, but that will be a year from now. in the ietf, delay is one form of death Responses follow: 1) While not stated so colorfully, draft-ietf-v6ops-6to4-advisory made this point. It has been approved for publication. but then do we not draw the conclusion that therefore publishing draft-ietf-v6ops-6to4-to-disgusting is the correct approach? 2) While there was no back-room activity, an appeal had been filed at the WG level. Since WG consensus was stronger than IETF consensus, it is reasonable to assume that the appeal would be escalated to the IESG level if it was not approved at the WG level. so these days people who do not get their way use the nuclear option? we raised kids. when those tactics resulted in we are so sorry you do not like the result, but that's the result they soon stopped. So, any way you look at it, there would be delays. welcome to the ietf, where process is our most important product. 3) The new document may not take a year to publish. Since it is a short draft, it could be produced in a few days. Once it is produced, we could immediately initiate a WG last call and an IETF last call immediately after that. So, we might be talking about a six-week delay. so process this one in six weeks, please. Now, I have a question for you, Lorenzo and Doug. If our goal is to take 6-to-4 off of the Internet, does not disabling it by default solve most of the problem? AFAIKS, very few users would enable it and service providers would not be economically incented to support 6-to-4 relay routers. the economic incentive to half-assed service providers is that it gives an excuse not to deploy ipv6. the response of these folk will be web pages instructing their users how to turn 6to4 on. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sun, Jul 3, 2011 at 5:05 AM, Noel Chiappa j...@mercury.lcs.mit.eduwrote: I think there is pretty much complete consensus that i) 6to4 doesn't work in several very common environments (behind a NAT, etc, etc), and that therefore, ii) at the very least, it should be disabled by default (and therefore only turned on by knowledgeable users who know they are not in one of those situations). Given and assuming a document that makes all that formal, _what else_ does the _additional_ step of making 6to4 historic buy? Compared to the alternative of publishing 6to4-historic now, it: a) Delays the time of any statement made by the IETF on the question by at least a number of months, while vendors and home gateways are *still shipping* products that implement 6to4 and enable it by default. I have personally seen this in beta home gateway products with new IPv6 firmware that aren't even released yet. b) Even assuming it were to gain consensus in any sort of reasonable timescale, it would provide a less clear statement, and thus be less of an incentive for implementors such as home gateway manufacturers to do the right thing and remove it. We have heard in the working group from real implementors like Apple, who have said that even 6to4-historic may not go far enough for them to justify actions such as removing support from their products. We have heard, also, that when implementors such as home gateway manufacturers are asked to remove 6to4 or disable it because it harms user experience, they say that they don't see why they should do work to remove a feature, in the absence of any guidance from the IETF. Time is important, because over time, 6to4's reliability will get worse, not better, as ISPs do things like use bogon IPv4 space plus carrier-grade NAT for their users, because implementations will think they have public IPv4 addresses and thus turn on 6to4 (which will never work, because it's behind a NAT). Or perhaps the concept is that nuking 6to4 will help force ISPs to deploy native IPv6, since it removes one way for users to get IPv6 if their provider doesn't supply it? If so, why not ditch Teredo, too? (Not to mention that 'mandate it and they will come' hasn't worked to well so far.) Normal users will not get IPv6 unless their ISP gives it to them. Period, end of story. I think it's clear by now that the vast majority of users don't know what IPv6 is, and that they do not ask for it. For a normal user, having 6to4 is more a liability than an asset. Normal users don't rely on 6to4 to give them IPv6 connectivity, because they don't use or need IPv6; everything they do today can be done with higher performance and higher reliability using IPv4 and NAT traversal. However, if they get it for free in the form of 6to4, then far from gaining a benefit (reliable IPv6 connectivity), they get something that only works 80% of the time, and 20% of the time breaks dual-stack websites. By users I explicitly do not include the tiny percentage of users on this list who are technical enough to know that 6to4 exists and rely on it to get IPv6 connectivity. Compared to the overwhelming number of users who have no idea what IPv6 even is, they are so far away from the mainstream that they don't matter at all, and they are knowledgeable enough to deploy other solutions, such as managed tunnels, which in my experience are typically lower latency and higher reliability (pretty much everything is higher reliability than a 20% failure rate). The only way you can incentivize ISPs to deploy IPv6 is to provide IPv6 content that they can use to justify the investment (for example, reduce the load on the NATs that they will be deploying). ISPs have been saying for years, and are still saying, that one of the reasons tha they are not deploying IPv6 because there is no point, since so little content is available over IPv6. Now we are hearing clearly from content providers that they *do not want* 6to4, because its 80% failure rate is a concern for them, and that in fact, its existence is one of the major barriers to lack of adoption on the part of content providers. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sun, Jul 3, 2011 at 5:11 AM, Keith Moore mo...@network-heretics.comwrote: And who says that rough consensus of the entire IETF community is that this draft should not be published? Were there public discussions to that effect that came to this conclusion? There's clearly a lack of consensus to support it. Nope. The v6ops chairs saw consensus in v6ops to support it. Can you point to significant strength of opinion of the wider IETF community, but not in v6ops, that has reason to oppose it? If all you can point to is the same people that were opposing it in v6ops, then I think they don't count, because the rough consensus in v6ops was that the document should be published. So, I ask again: where are the statements made in opposition of this proposal made outside of v6ops? Can you point to them? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sun, Jul 3, 2011 at 5:49 AM, Mark Smith i...@69706e6720323030352d30312d31340a.nosense.org wrote: Declaring 6to4 to be historic might encourage native IPv6 deployment, but I think it will also make trialing IPv6 much harder. We don't need to trial the IPv6 protocol. There are hundreds of thousands of native users accessing production-grade IPv6 services, like Google's, every day. We know the IPv6 protocol works. ISPs do need to trial IPv6 deployment. But 6to4 does not help there, because 6to4 is not deployed by ISPs. They will need to trial native deployments, or 6rd. If *users* want to trial IPv6 until native IPv6 is available, then they can use configured tunnels. The involvement in World IPv6 day by large content providers and the apparent lack of significant problems would be suggest the opposite is now the case. Google continuing to provide youtube video content to 6to4 tunnel users (such as myself), nearly a month later, suggests that any problems with it are tractable. I would assert that the problems with 6to4 are not tractable without disabling 6to4. Our IPv6 brokenness statistics for before and after World IPv6 Day are very similar. 6to4 users are easy to spot by the 2002::/16 prefix, so if Google needed to they could probably quite easily limit their IPv6 content delivery to native only IPv6 users. No, that's not how it works. There is no problem with 6to4 when it works as well as IPv4. The problem is that 6to4 only works *at all* (never mind works as well as IPv4) 80% of the time. Unfortunately, in the 20% of the time that it's not working, Google has no idea that the user has a 2002::/16 address. Google only knows, after the fact, that the user suffered a 20 or 75-second timeout and was not happy. So it would serve no purpose to avoid serving users that successfully connect from 2002::/16 addresses; once the record is handed out, the damage is done. What Google could do, however, is stop handing out records to networks that have significant number of 6to4 users in the future. We're considering this. An update on that data would be useful. As I said before, our data on IPv6 brokenness did not change significantly after World IPv6 Day. Can you take that as a proxy that 6to4 has not improved? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sun, Jul 3, 2011 at 2:38 AM, Mark Smith i...@69706e6720323030352d30312d31340a.nosense.org wrote: I don't object to what has been proposed, yet I object to 6to4-historic because I'm an extremely happy anycast 6to4 user It works for me, so there's obviously no problem. When you think of 6to4-historic, please think of the 20% of anycast 6to4 users that are broken. We know it can operate correctly and reliably if it is configured correctly. But we also know that it's not configured correctly, to such an extent that it does not work at all in 20% of cases (Geoff's data). And we know of no reason why that would improve, though we do know of reasons why it would get worse (e.g., due to ISPs giving bogon public space to their users). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic From: Keith Moore mo...@network-heretics.com Date: Sat, 2 Jul 2011 23:10:47 -0400 To: Cameron Byrne cb.li...@gmail.com CC: v6...@ietf.org v6...@ietf.org, IETF Discussion ietf@ietf.org Precedence: list MIME-Version: 1.0 (Apple Message framework v1084) References: 13205c286662de4387d9af3ac30ef456d3f3507...@embx01-wf.jnpr.net CAKD1Yr2Smvm0RY5iV2y06wD=rrz-uw4vbaaairnoaksr7zl...@mail.gmail.com banlktimprdnqkc1xtafskkoo5dcx3gc...@mail.gmail.com In-Reply-To: banlktimprdnqkc1xtafskkoo5dcx3gc...@mail.gmail.com Message-ID: e817a524-9db7-4553-a76f-25a9907e7...@network-heretics.com Content-Type: multipart/alternative; boundary=Apple-Mail-111-642965515 Message: 2 I find myself wondering what you mean by REAL IPv6. For me, REAL IPv6 is code that uses the IPv6 programming model, 128 bit addresses, end-to-end transparency, no NATs. 6to4 certainly qualifies. Keith Many people have many more requirements. For example, an SLA for availability and latency, low support costs, firewall security, DSCP quality of service, ability to log end point communications, intrusion detection, WAN acceleration, a deployment model that does not rely on allocating even more IPv4 addresses (that many don't have or won't have) or the good nature of other providers to provide a working relay ... 6to4 fails to meet many of those requirements. Granted, it isn't the only transition mechanism that fails to do so. IMHO Right now, we need services with native IPv6 based interfaces, with equivalent performance and equivalent features and equivalent price that we have today with IPv4. Anything that detracts from the roll out of native IPv6 based service interfaces at this time is a bad move IMVHO and hastens the day that the Internet fragments into a bunch of CGN zones, that is dominated by businesses that can afford to buy public IPv4 addresses for their servers or services, or whose business model relies on NAT traversal being difficult. I personally don't want that sort of Internet. Given that development and engineering support time is finite, I'd much rather that 6to4 was declared historic so that developers and engineers could spend more time on deployment of native IPv6 service interfaces. Having said all that, 6to4 has also caused me issues with traffic predictability, and cost significant engineering time. Turning 6to4 off by default would not be the ideal solution in my view, but it should address many if not all of my own particular issues. If that's all that's on offer, I'll take it. regards, RayH ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
Nope. The v6ops chairs saw consensus in v6ops to support it. Can you point to significant strength of opinion of the wider IETF community, but not in v6ops, that has reason to oppose it? That's not how it works. You have to get consensus in IETF, not in v6ops. when it is last called. and you can dos that mailing list then, and threaten, and bluster. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 3, 2011, at 1:47 AM, Keith Moore wrote: Some of them were posted to the IETF list. IESG may have received others privately. That is permitted by our process. This is a frustrating conversation. Everybody who supported the consensus in v6ops is an IETF participant, and their wishes count toward the IETF consensus. The draft is good. It encourages people to do the right things: keep 6to4 relays active, but not ship products with 6to4 enabled by default. This works for everyone—for people like me who are using 6to4 for our IPv6 connectivity, it works because the relays stay up. For people who do not have global IPv4 addresses, they do not wind up with IPv6 routes that go nowhere. It certainly serves Keith Moore's needs, no matter how vehemently, nor how often, he may insist that it does not. So this really does look like another IETF night of long knives, where a good draft gets scuttled in secret because a few very loud people manage to create enough of a fuss to make the person or persons calling the consensus feel like they're going to get fricasseed if they call the consensus in favor of the draft. Have we actually had a formal consensus call for the IETF? Who called the consensus? Can we have a summary? I haven't seen one. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
Keith Moore wrote: On Jul 3, 2011, at 2:23 AM, Ray Hunter wrote: IMHO Right now, we need services with native IPv6 based interfaces, with equivalent performance and equivalent features and equivalent price that we have today with IPv4. Anything that detracts from the roll out of native IPv6 based service interfaces at this time is a bad move IMVHO and hastens the day that the Internet fragments into a bunch of CGN zones, that is dominated by businesses that can afford to buy public IPv4 addresses for their servers or services, or whose business model relies on NAT traversal being difficult. I personally don't want that sort of Internet. Right now, applications developers need to be able to write and ship code that uses IPv6 and can talk to other application instances using IPv6. Anything that detracts from the ability of applications to use IPv6 at this time is a bad move IMHO and decreases the chance that there will ever be sufficient use of IPv6 (of any kind) to justify widespread deployment of native IPv6. Given that development and engineering support time is finite, I'd much rather that 6to4 was declared historic so that developers and engineers could spend more time on deployment of native IPv6 service interfaces. I have a better suggestion: let's declare NAT historic. That would free up lots of developers and engineers to spend time on both native v6 and better v6 transition mechanisms. Not only would they not need to engineer new NATs, applications developers wouldn't need to engineer new workarounds for new NATs. Everybody would win. Keith I'm presuming your second comment was facetious. I'm also presuming from your first comment that you will thus oppose the proposal to turn off 6to4 by default. Am I correct? regards RayH, ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
Discussion isn't evidence, as people usually don't post any data to support their assertions. And yet, they did. This whole thing is getting silly, and I'm tired of repeating myself. I think Lorenzo did a great job of explaining some more of the downsides of 6to4 and I don't have anything useful to add beyond what I've already said. geoff's presos show the 6to4 train wreck pretty clearly. and it ain't pretty. yes, a few geeks such as rob austein, keith moore, ... who desperately want to test ipv6 can manage to get it working. big whoopie doo. it is a disaster for a significant percentage of the end users. it needs to be stopped. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
Hi, On Sat, Jul 02, 2011 at 11:11:43PM -0400, Keith Moore wrote: There's clearly a lack of consensus to support it. There's two very vocal persons opposing it and a much larger number of people that support it, but have not the time to write a similarily large amount of e-mails. For me, this is enough for rough consensus. (And I second everything Lorenzo, Randy and Cameron said - there's theoretical possibilities, and real world. 6to4 fails the real-world test. Get over it, instead of attacking people that run real-world networks for the decisions they need to do to keep the networks running in a world without enough IPv4 addresses). Gert Doering -- Operator -- did you enable IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
In your letter dated Sun, 3 Jul 2011 07:53:46 +0200 you wrote: Unfortunately, in the 20% of the time that it's not working, Google has no idea that the user has a 2002::/16 address. Google only knows, after the fact, that the user suffered a 20 or 75-second timeout and was not happy. So it would serve no purpose to avoid serving users that successfully connect from 2002::/16 addresses; once the record is handed out, the damage is done. What Google could do, however, is stop handing out records to networks that have significant number of 6to4 users in the future. We're considering this. I think this clearly illustrates why the IETF should issue a strong statement that no new 6to4 installation should be deplayed and the existing 6to4 users should migrate to other tunneling techniques (if native is not available). The problem with 6to4 is it was rolled out on a relatively large scale when there was essentially no IPv6 content. As a result, the people who had a broken 6to4 setup would only find out when content providers would start adding records. In other words, it was ticking time bomb. This time bomb has been defused mostly because most operating system now prefer any kind of IPv4 over a 6to4 address. So once again people can have a broken 6to4 setup without noticing it. What worries me is that people will start using 6to4 for bittorrent. Bittorrent will of course completely hide broken setups and worse, it will also hide broken 6to4 relays. So we may end up with a sizable group people who have an IPv6 setup that completely doesn't work. And they don't know it. Which will create all kinds of headaches for IPv6-only content because you have to explain to users that yes, they have an IPv6 address and no, it is not going to work. And all of this, because a few hobbyists are afraid that declaring 6to4 as historic will require them to search a bit harder in the furture for a router that supports 6to4. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
And b. And probably it is too much effort for something that will go away (probably sooner that we expect) with the exhaustion of IPv4 addresses for each ISP's customer (6to4 does not work with NATs, and they are here). -as On 3 Jul 2011, at 11:40, Keith Moore wrote: I think this clearly illustrates why IETF should issue a strong statement that a) operators of 6to4 relays should not advertise those relays via BGP unless they're routing traffic for all of 2002://16 or native v6, respectively b) operators should not filter protocol 41traffic c) (maybe) operators using LSN should use RFC 1918 addresses behind those NATs unless/until there's another address range that 6to4 host implementations know about d) 6to4 should be disabled by default in both hosts and routers e) host implementations should prefer native v4 destinations over 6to4 destinations when both are available and the application can use either IPv4 or IPv6 You will not get consensus on these statements in the IETF or by the various companies that implement gear and networks in the REAL world. why not? all of those recommendations are clearly appropriate and desirable, with the possible exception of (c) because ISP use of RFC 1918 addresses is likely to conflict with customer user of the same address ranges. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Second Last Call: draft-hammer-hostmeta-16.txt (Web Host Metadata) to Proposed Standard -- feedback
Hannes, None of the current OAuth WG document address discovery in any way, so clearly there will be no use of XRD. But the OAuth community predating the IETF had multiple proposals for it. In addition, multiple times on the IETF OAuth WG list, people have suggested using host-meta and XRD for discovery purposes. The idea that XRD was reused without merit is both misleading and mean-spirited. Personally, I'm sick of it, especially coming from standards professionals. XRD was largely developed by the same people who worked on host-meta. XRD predated host-meta and was designed to cover the wider use case. Host-meta was an important use case when developing XRD in its final few months. It was done in OASIS out of respect to proper standards process in which the body that originated a work (XRDS) gets to keep it. I challenge anyone to find any faults with the IPR policy or process used to develop host-meta in OASIS. XRD is one of the simplest XML formats I have seen. I bet most of the people bashing it now have never bothered to read it. At least some of these people have been personally invited by me to comment on XRD while it was still in development and chose to dismiss it. XRD was designed in a very open process with plenty of community feedback and it was significantly simplified based on that feedback. In addition, host-meta further simplifies it by profiling it down, removing some of the more complex elements like Subject and Alias (which are very useful in other contexts). XRD is nothing more than a cleaner version of HTML LINK elements with literally a handful of new elements based on well defined and widely supported requirements. It's entire semantic meaning is based on the IETF Link relation registry RFC. There is something very disturbing going on these days in how people treat XML-based formats, especially form OASIS. When host-meta's predecessor - side–meta – was originally proposed a few years ago, Mark Nottingham proposed an XML format not that different from XRD. There is nothing wrong with JSON taking over as a simpler alternative. I personally prefer JSON much better. But it would be reckless and counter productive to ignore a decade of work on XML formats just because it is no longer cool. Feels like we back in high school. If you have technical arguments against host-meta, please share. But if your objections are based on changing trends, dislike of XML or anything OASIS, grow up. EHL From: Hannes Tschofenig hannes.tschofe...@gmx.netmailto:hannes.tschofe...@gmx.net Date: Sun, 3 Jul 2011 00:36:29 -0700 To: Mark Nottingham m...@mnot.netmailto:m...@mnot.net Cc: Hannes Tschofenig hannes.tschofe...@gmx.netmailto:hannes.tschofe...@gmx.net, ietf@ietf.orgmailto:ietf@ietf.org IETF ietf@ietf.orgmailto:ietf@ietf.org, Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com, oauth WG oa...@ietf.orgmailto:oa...@ietf.org Subject: Re: Second Last Call: draft-hammer-hostmeta-16.txt (Web Host Metadata) to Proposed Standard -- feedback I also never really understood why XRD was re-used. Btw, XRD is not used by any of the current OAuth WG documents, see http://datatracker.ietf.org/wg/oauth/ On Jun 22, 2011, at 8:08 AM, Mark Nottingham wrote: * XRD -- XRD is an OASIS spec that's used by OpenID and OAuth. Maybe I'm just scarred by WS-*, but it seems very over-engineered for what it does. I understand that the communities had reasons for using it to leverage an existing user base for their specific user cases, but I don't see any reason to generalise such a beast into a generic mechanism. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [OAUTH-WG] Second Last Call: draft-hammer-hostmeta-16.txt (Web Host Metadata) to Proposed Standard -- feedback
FYI there is a form of discovery for OAuth defined in http://tools.ietf.org/html/draft-mills-kitten-sasl-oauth-02 which uses LINK headers. From: Eran Hammer-Lahav e...@hueniverse.com To: Hannes Tschofenig hannes.tschofe...@gmx.net; Mark Nottingham m...@mnot.net Cc: ietf@ietf.org IETF ietf@ietf.org; oauth WG oa...@ietf.org Sent: Sunday, July 3, 2011 9:50 AM Subject: Re: [OAUTH-WG] Second Last Call: draft-hammer-hostmeta-16.txt (Web Host Metadata) to Proposed Standard -- feedback Hannes, None of the current OAuth WG document address discovery in any way, so clearly there will be no use of XRD. But the OAuth community predating the IETF had multiple proposals for it. In addition, multiple times on the IETF OAuth WG list, people have suggested using host-meta and XRD for discovery purposes. The idea that XRD was reused without merit is both misleading and mean-spirited. Personally, I'm sick of it, especially coming from standards professionals. XRD was largely developed by the same people who worked on host-meta. XRD predated host-meta and was designed to cover the wider use case. Host-meta was an important use case when developing XRD in its final few months. It was done in OASIS out of respect to proper standards process in which the body that originated a work (XRDS) gets to keep it. I challenge anyone to find any faults with the IPR policy or process used to develop host-meta in OASIS. XRD is one of the simplest XML formats I have seen. I bet most of the people bashing it now have never bothered to read it. At least some of these people have been personally invited by me to comment on XRD while it was still in development and chose to dismiss it. XRD was designed in a very open process with plenty of community feedback and it was significantly simplified based on that feedback. In addition, host-meta further simplifies it by profiling it down, removing some of the more complex elements like Subject and Alias (which are very useful in other contexts). XRD is nothing more than a cleaner version of HTML LINK elements with literally a handful of new elements based on well defined and widely supported requirements. It's entire semantic meaning is based on the IETF Link relation registry RFC. There is something very disturbing going on these days in how people treat XML-based formats, especially form OASIS. When host-meta's predecessor - side–meta – was originally proposed a few years ago, Mark Nottingham proposed an XML format not that different from XRD. There is nothing wrong with JSON taking over as a simpler alternative. I personally prefer JSON much better. But it would be reckless and counter productive to ignore a decade of work on XML formats just because it is no longer cool. Feels like we back in high school. If you have technical arguments against host-meta, please share. But if your objections are based on changing trends, dislike of XML or anything OASIS, grow up. EHL From: Hannes Tschofenig hannes.tschofe...@gmx.net Date: Sun, 3 Jul 2011 00:36:29 -0700 To: Mark Nottingham m...@mnot.net Cc: Hannes Tschofenig hannes.tschofe...@gmx.net, ietf@ietf.org IETF ietf@ietf.org, Eran Hammer-lahav e...@hueniverse.com, oauth WG oa...@ietf.org Subject: Re: Second Last Call: draft-hammer-hostmeta-16.txt (Web Host Metadata) to Proposed Standard -- feedback I also never really understood why XRD was re-used. Btw, XRD is not used by any of the current OAuth WG documents, see http://datatracker.ietf.org/wg/oauth/ On Jun 22, 2011, at 8:08 AM, Mark Nottingham wrote: * XRD -- XRD is an OASIS spec that's used by OpenID and OAuth. Maybe I'm just scarred by WS-*, but it seems very over-engineered for what it does. I understand that the communities had reasons for using it to leverage an existing user base for their specific user cases, but I don't see any reason to generalise such a beast into a generic mechanism. ___ OAuth mailing list oa...@ietf.org https://www.ietf.org/mailman/listinfo/oauth___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
And b. And probably it is too much effort for something that will go away (probably sooner that we expect) with the exhaustion of IPv4 addresses for each ISP's customer (6to4 does not work with NATs, and they are here). It's clearly inappropriate for operators to be filtering protocol 41. Not only does this break 6to4, it also breaks other tunneling mechanisms. More generally, it's inappropriate for operators to be favoring one kind of traffic over another. Many corporate networks filter them because security concerns (I am not saying that is right or wrong, it just happens and it breaks 6to4). They won't change their mind because 6to4. The ISPs I've talked to tell me that they see no reason why static, public IPv4 addresses cannot continue to be given to those that request them, indefinitely, as long as they're paying for business service. Call one not in the USA. China or India perhaps. -as ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Nomcom 2011-2012: Third Call for Volunteers
This is the Third call for Volunteers for the 2011-12 Nomcom. We are almost through the volunteer period so if you are considering volunteering, please do so very soon. We have had a very good response to the initial call for volunteers and I am pleased to report that we have 84 volunteers thus far whose qualifications have been confirmed by the secretariat. I have notified each of these volunteers by email. However, we would like to have many more volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. You have until 11:59 pm EDT July 10, 2011 to volunteer for Nomcom but it would be much better if you can volunteer as early as possible. If you volunteered before 09:00 EDT on June 29 to serve as a voting member and have not received a confirmation email from me, please re-submit and bring to my attention right away! Details about the process for volunteering for the Nomcom and the list of open positions for which the nominating committee is responsible are summarized in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2938/ The 84 volunteers who have thus far been qualified by the secretariat are: Alia Atlas,Juniper Networks Lixia Zhang,UCLA Wassim Haddad ,Ericsson Glen Zorn,Network Zen Richard Barnes,BBN Technologies Stephen Kent,BBN Technologies Scott Mansfield,Ericsson Tina TSOU (Ting ZOU),FutureWei Technologies Fernando Gont,UTN/FRH Karen Seo,BBN Technologies Jie Dong,Huawei Technologies Mach Chen,Huawei Technologies Co. Ltd. Sheng Jiang,Huawei Technologies Co. Ltd. Dimitri Papadimitriou,Alcatel-Lucent Thomas D. Nadeau,CA Technologies David Meyer,Cisco Systems/University of Oregon Wesley George,Time Warner Cable Cullen Jennings,Cisco Stephen Hanna,Juniper Networks Stephan Wenger,Bidyo Inc. Keyur Patel,Cisco Systems Michael (Mike) Hamilton,BreakingPoint Systems Behcet Sarikaya,Huawei USA Mark Townsley,Cisco Systems Fred Baker,Cisco Systems Brian Trammell,ETH Z�rich Sam Hartman,Painless Security Chris Griffiths,Comcast George Michaelson,APNIC Jiankang Yao,CNNIC Sohel Khan,Comcast Dacheng Zhang,Huawei Lianshu Zheng,Huawei Technologies Hui Deng,China Mobile Gang Chen,China Mobile Mirja K�hlewind,University of Stuttgart IKR John E Drake,Juniper Networks Matt Lepinski,BBN Technologies Subir Das,Telcordia Technologies Inc Yi Zhao,Huawei John Scudder,Juniper Networks Christer Holmberg,LM Ericsson Teemu Savolainen,Nokia Samita Chakrabarti,Ericsson Jaap Akkerhuis,NLnet labs Jason Weil,Time Warner Cable Randy Bush,Internet Initiative Japan Christian Schmidt,Nokia Siemens Networks Sean Shen,CNNIC Lou Berger,LabN Consulting L.L.C. Donald Eastlake,Huawei Xiaohu Xu,Huawei Technologies co. Ltd. B�rje Ohlman,Ericsson Deborah Brungard,ATT Magnus Westerlund,Ericsson Zhen Cao,China Mobile Hadriel Kaplan,Acme Packet Lilla Dovner,Ericsson John Jason Brzozowski,Comcast Jonne Soininen,Renesas Mobile Javier Ubillos,Swedish Institute of Computer Science Eric Gray,Ericsson Thomas Herbst,Silver Spring Networks Ning Zong,Huawei Technologies Haibin Song,Huawei Technologies Yingjie Gu,Huawei Technologies Hongyu Li,Huawei Technologies Terry Manderson,ICANN Ari Keranen,Ericsson Jouni Korhonen,Nokia Siemens Networks Bhumip Khasnabish,ZTE USA Inc. Dapeng Liu,China Mobile Fangwei Hu,ZTE Corporation Ole Troan,Cisco Pascal Thubert,Cisco Wojciech Dec,Cisco Gunter Van de Velde,Cisco Ning So,Verizon Inc./University of Texas at Dallas Guoman liu,ZTE Simon Pietro Romano,Meetecho/University of Napoli Luca Martini,Cisco Bill VerSteeg,Cisco Toerless Eckert,Cisco Systems Joseph Salowey,Cisco Systems The primary activity for this nomcom will begin during IETF-81 in Quebec City and should be completed by January 2012. The nomcom will be collecting requirements from the community, as well as talking to candidates and to community members about candidates. There will be regularly scheduled conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. Please volunteer by sending an email to me before 11:59 pm EDT July 10, 2011 as follows: To: suresh.krish...@ericsson.com Subject: Nomcom 2011-12 Volunteer Please include the following information in the body of the mail: Full Name: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name Current Primary Affiliation: // typically what goes in the Company // field in the IETF Registration Form Email Address(es): // all email addresses used to Register for the // past 5 IETF meetings // Please designate a Preferred email address for // contact if there is more than one email address Telephone number: // With country code (for confirmation if selected) Please expect an email response from me within 3 business days stating whether or not you are qualified. If you do not receive a response in this
Re: [OAUTH-WG] Second Last Call: draft-hammer-hostmeta-16.txt (Web Host Metadata) to Proposed Standard -- feedback
The OpenID Connect folks have been using Simple Web Discovery, which is as I understand it a rough translation of XRD into JSON, with a couple of simplifying changes. (Mike, want to throw your hat in on this one?) http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 -- Justin On Mon, 2011-07-04 at 00:27 -0400, Eve Maler wrote: FWIW, the Dynamic OAuth Client Registration proposal made by the User-Managed Access folks: http://tools.ietf.org/html/draft-hardjono-oauth-dynreg-00 ...makes use of XRD, hostmeta, and discovery, as does the OAuth-based UMA protocol itself: http://www.ietf.org/internet-drafts/draft-hardjono-oauth-umacore-00.txt We'd be just as happy to use a JSON-based version of XRD if it can be standardized, and we did do some experimentation with this early on. But because XRD 1.0 is now stable and is straightforward enough to use for our needs, we decided to use it normatively for now. The UMA implementation used by http://smartam.net implements this today and it works fine. Eve On 3 Jul 2011, at 9:50 AM, Eran Hammer-Lahav wrote: Hannes, None of the current OAuth WG document address discovery in any way, so clearly there will be no use of XRD. But the OAuth community predating the IETF had multiple proposals for it. In addition, multiple times on the IETF OAuth WG list, people have suggested using host-meta and XRD for discovery purposes. The idea that XRD was reused without merit is both misleading and mean-spirited. Personally, I'm sick of it, especially coming from standards professionals. XRD was largely developed by the same people who worked on host-meta. XRD predated host-meta and was designed to cover the wider use case. Host-meta was an important use case when developing XRD in its final few months. It was done in OASIS out of respect to proper standards process in which the body that originated a work (XRDS) gets to keep it. I challenge anyone to find any faults with the IPR policy or process used to develop host-meta in OASIS. XRD is one of the simplest XML formats I have seen. I bet most of the people bashing it now have never bothered to read it. At least some of these people have been personally invited by me to comment on XRD while it was still in development and chose to dismiss it. XRD was designed in a very open process with plenty of community feedback and it was significantly simplified based on that feedback. In addition, host-meta further simplifies it by profiling it down, removing some of the more complex elements like Subject and Alias (which are very useful in other contexts). XRD is nothing more than a cleaner version of HTML LINK elements with literally a handful of new elements based on well defined and widely supported requirements. It's entire semantic meaning is based on the IETF Link relation registry RFC. There is something very disturbing going on these days in how people treat XML-based formats, especially form OASIS. When host-meta's predecessor - side–meta – was originally proposed a few years ago, Mark Nottingham proposed an XML format not that different from XRD. There is nothing wrong with JSON taking over as a simpler alternative. I personally prefer JSON much better. But it would be reckless and counter productive to ignore a decade of work on XML formats just because it is no longer cool. Feels like we back in high school. If you have technical arguments against host-meta, please share. But if your objections are based on changing trends, dislike of XML or anything OASIS, grow up. EHL From: Hannes Tschofenig hannes.tschofe...@gmx.net Date: Sun, 3 Jul 2011 00:36:29 -0700 To: Mark Nottingham m...@mnot.net Cc: Hannes Tschofenig hannes.tschofe...@gmx.net, ietf@ietf.org IETF ietf@ietf.org, Eran Hammer-lahav e...@hueniverse.com, oauth WG oa...@ietf.org Subject: Re: Second Last Call: draft-hammer-hostmeta-16.txt (Web Host Metadata) to Proposed Standard -- feedback I also never really understood why XRD was re-used. Btw, XRD is not used by any of the current OAuth WG documents, see http://datatracker.ietf.org/wg/oauth/ On Jun 22, 2011, at 8:08 AM, Mark Nottingham wrote: * XRD -- XRD is an OASIS spec that's used by OpenID and OAuth. Maybe I'm just scarred by WS-*, but it seems very over-engineered for what it does. I understand that the communities had reasons for using it to leverage an existing user base for their specific user cases, but I don't see any reason to generalise such a beast into a generic mechanism. ___ OAuth mailing list oa...@ietf.org https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756
tsv-dir review of draft-ietf-mptcp-congestion-05
I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC: tsv-...@ietf.org if you reply to or forward this review. Summary: This draft is on the right track but has open issues, described in the review. Comments: This draft specifies the congestion control modifications for multi-path TCP. Major: I have one open issue - the first two goals (in the Introduction) are to have multipath TCP connections behave somewhat like single-path connections in terms of effects on (fairness to) other traffic. The algorithm specified accomplishes this solely by coupling the additive increase functionality across the flows, but allowing each flow to react to drops and congestion separately (no decrease coupling). The draft does not explain why increase coupling along is sufficient to achieve these goals or what compromise to the goals results from only coupling increases. Section 5 is a good start on this discussion, but it's not clear about what compromises to the goals results from increase coupling only. Section 5 criticizes an alternative that couples both increases and decreases for failing to achieve Goal 1, but doesn't say what this approach achieves. At most a few additional sentences in Section 5 should suffice to address this concern, and Section 2 should be edited to align with the changes to Section 5. Minor: While the [NSDI] paper is a fine place to reference work published in conferences and/or journals, RFC 3124 on the Congestion Manager is related IETF work and should be cited here as an Informative Reference. idnits 2.12.12 didn't find any nits. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.com Mobile: +1 (978) 394-7754 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [OAUTH-WG] Second Last Call: draft-hammer-hostmeta-16.txt (Web Host Metadata) to Proposed Standard -- feedback
FWIW, the Dynamic OAuth Client Registration proposal made by the User-Managed Access folks: http://tools.ietf.org/html/draft-hardjono-oauth-dynreg-00 ...makes use of XRD, hostmeta, and discovery, as does the OAuth-based UMA protocol itself: http://www.ietf.org/internet-drafts/draft-hardjono-oauth-umacore-00.txt We'd be just as happy to use a JSON-based version of XRD if it can be standardized, and we did do some experimentation with this early on. But because XRD 1.0 is now stable and is straightforward enough to use for our needs, we decided to use it normatively for now. The UMA implementation used by http://smartam.net implements this today and it works fine. Eve On 3 Jul 2011, at 9:50 AM, Eran Hammer-Lahav wrote: Hannes, None of the current OAuth WG document address discovery in any way, so clearly there will be no use of XRD. But the OAuth community predating the IETF had multiple proposals for it. In addition, multiple times on the IETF OAuth WG list, people have suggested using host-meta and XRD for discovery purposes. The idea that XRD was reused without merit is both misleading and mean-spirited. Personally, I'm sick of it, especially coming from standards professionals. XRD was largely developed by the same people who worked on host-meta. XRD predated host-meta and was designed to cover the wider use case. Host-meta was an important use case when developing XRD in its final few months. It was done in OASIS out of respect to proper standards process in which the body that originated a work (XRDS) gets to keep it. I challenge anyone to find any faults with the IPR policy or process used to develop host-meta in OASIS. XRD is one of the simplest XML formats I have seen. I bet most of the people bashing it now have never bothered to read it. At least some of these people have been personally invited by me to comment on XRD while it was still in development and chose to dismiss it. XRD was designed in a very open process with plenty of community feedback and it was significantly simplified based on that feedback. In addition, host-meta further simplifies it by profiling it down, removing some of the more complex elements like Subject and Alias (which are very useful in other contexts). XRD is nothing more than a cleaner version of HTML LINK elements with literally a handful of new elements based on well defined and widely supported requirements. It's entire semantic meaning is based on the IETF Link relation registry RFC. There is something very disturbing going on these days in how people treat XML-based formats, especially form OASIS. When host-meta's predecessor - side–meta – was originally proposed a few years ago, Mark Nottingham proposed an XML format not that different from XRD. There is nothing wrong with JSON taking over as a simpler alternative. I personally prefer JSON much better. But it would be reckless and counter productive to ignore a decade of work on XML formats just because it is no longer cool. Feels like we back in high school. If you have technical arguments against host-meta, please share. But if your objections are based on changing trends, dislike of XML or anything OASIS, grow up. EHL From: Hannes Tschofenig hannes.tschofe...@gmx.net Date: Sun, 3 Jul 2011 00:36:29 -0700 To: Mark Nottingham m...@mnot.net Cc: Hannes Tschofenig hannes.tschofe...@gmx.net, ietf@ietf.org IETF ietf@ietf.org, Eran Hammer-lahav e...@hueniverse.com, oauth WG oa...@ietf.org Subject: Re: Second Last Call: draft-hammer-hostmeta-16.txt (Web Host Metadata) to Proposed Standard -- feedback I also never really understood why XRD was re-used. Btw, XRD is not used by any of the current OAuth WG documents, see http://datatracker.ietf.org/wg/oauth/ On Jun 22, 2011, at 8:08 AM, Mark Nottingham wrote: * XRD -- XRD is an OASIS spec that's used by OpenID and OAuth. Maybe I'm just scarred by WS-*, but it seems very over-engineered for what it does. I understand that the communities had reasons for using it to leverage an existing user base for their specific user cases, but I don't see any reason to generalise such a beast into a generic mechanism. ___ OAuth mailing list oa...@ietf.org https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sat, 2 Jul 2011 20:54:50 +0200 Lorenzo Colitti lore...@google.com wrote: On Sat, Jul 2, 2011 at 6:36 PM, Ronald Bonica rbon...@juniper.net wrote: - In order for the new draft to be published, it must achieve both V6OPS WG and IETF consensus If anyone objects to this course of action, please speak up soon. Great, back to square one. Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus. But perhaps I missed some discussion. Also, why do the author and the chairs think that the new draft will do any better than 6to4-historic? I would assume that the same people who spoke up against 6to4-historic will speak up against the new document, and since that level of opposition was sufficient to prevent the publication of 6to4-historic, it may be sufficient to prevent publication of the new document as well. If so, we will have spent 3-6 months arguing about it for naught. I don't object to what has been proposed, yet I object to 6to4-historic because I'm an extremely happy anycast 6to4 user and have been for many years (I just recently looked at the date in the script I wrote to bring it up, and was quite surprised it was dated 2002). Unfortunately people do judge books by their cover - if there is an RFC that says 6to4 is historic, people would likely consider it something that can't be used. We know it can operate correctly and reliably if it is configured correctly. If the criteria for declaring a technology historic is that some people can't operate it correctly and reliably, then they'll have to be plenty of other -historic RFCs. Perhaps declaring 6to4 deprecated rather than historic would have a better chance of consensus. Please, nobody answer this question with welcome to the IETF :-) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sat, 2 Jul 2011 12:21:36 -0700 Cameron Byrne cb.li...@gmail.com wrote: On Jul 2, 2011 11:55 AM, Lorenzo Colitti lore...@google.com wrote: On Sat, Jul 2, 2011 at 6:36 PM, Ronald Bonica rbon...@juniper.net wrote: - In order for the new draft to be published, it must achieve both V6OPS WG and IETF consensus If anyone objects to this course of action, please speak up soon. Great, back to square one. Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus. But perhaps I missed some discussion. I saw the same thing. It is a shame that work that directly removes barriers to REAL ipv6 deployment Where is the evidence that 6to4 is holding back native IPv6 deployment? gets shouted down by a few people not involved in REAL ipv6 deployment. How do you know that? Welcome to the ietf indeed. Cb Also, why do the author and the chairs think that the new draft will do any better than 6to4-historic? I would assume that the same people who spoke up against 6to4-historic will speak up against the new document, and since that level of opposition was sufficient to prevent the publication of 6to4-historic, it may be sufficient to prevent publication of the new document as well. If so, we will have spent 3-6 months arguing about it for naught. Please, nobody answer this question with welcome to the IETF :-) ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sun, 3 Jul 2011 10:10:03 +0900
Erik Kline e...@google.com wrote:
All,
Perhaps declaring 6to4 deprecated rather than historic would have a
better chance of consensus.
Pardon my ignorance, but where is the document describing the
implications of historic{,al} vs deprecated?
This (http://tools.ietf.org/html/rfc2026#section-4.2.4) is well known:
A specification that has been superseded by a more recent
specification or is for any other reason considered to be obsolete is
assigned to the Historic level. (Purists have suggested that the
word should be Historical; however, at this point the use of
Historic is historical.)
Note: Standards track specifications normally must not depend on
other standards track specifications which are at a lower maturity
level or on non standards track specifications other than referenced
specifications from other standards bodies. (See Section 7.)
I don't know where similar explanatory language about Deprecated
might be (I'm sure I just didn't search correctly or long enough).
Since 6rd depends on 6to4, as it is a variant of it, would 6to4 being
declared historic also mean that 6rd needs to become historic as well?
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sat, 02 Jul 2011 19:44:24 -0700 Doug Barton do...@dougbarton.us wrote: On 07/02/2011 18:50, Mark Smith wrote: Where is the evidence that 6to4 is holding back native IPv6 deployment? It's been discussed ad nauseum in numerous fora. Discussion isn't evidence, as people usually don't post any data to support their assertions. Since posting that question I remembered RFC6036 - Emerging Service Provider Scenarios for IPv6 Deployment. Here's what is says about ISPs' views on 6to4. I don't think it supports the assertion that 6to4 is holding back native deployment - 2.5. IPv6 Technologies Turning to technology choices, the overwhelming choice of approach (94%) is a dual-stack routing backbone, and the reason given is simplicity and cost. 39% run, or plan to run, a 6to4 relay as well, and 16% run or plan a Teredo server. Diffusions of Innovations discusses attributes of innovations that influence their adoption. One of those attributes is trialability, meaning how hard or easy is it to trial the innovation. If a innovation requires a high level of commitment to trial, then it is less likely to be trialed and therefore adopted. Once an residential ISP as IPv6 transit, 6to4 is a simple and much lower cost way of trialing IPv6 services and gaining experience with IPv6, before and during the development and deployment of native IPv6 services and the required supporting infrastructure, such as AAA, helpdesk training etc. Declaring 6to4 to be historic might encourage native IPv6 deployment, but I think it will also make trialing IPv6 much harder. Bad 6to4 (which almost all of it is) results in a poor user experience when the largest content providers enable records. Thus, they are less inclined to enable them. The involvement in World IPv6 day by large content providers and the apparent lack of significant problems would be suggest the opposite is now the case. Google continuing to provide youtube video content to 6to4 tunnel users (such as myself), nearly a month later, suggests that any problems with it are tractable. 6to4 users are easy to spot by the 2002::/16 prefix, so if Google needed to they could probably quite easily limit their IPv6 content delivery to native only IPv6 users. So, in other words, Google now consider 6to4 to be reliable enough to continue to deliver content using it for one of their high profile content sites. I realize that there are a lot of people that dismiss both the evidence that's been put forward and the rationale, but it's been presented and discussed pretty thoroughly. In Geoff Huston's report (Dec 2010), he says that he measured a 13% failure rate with 6to4. A number of things have happened since then - IANA has run out of IPv4 addresses, and World IPv6 day. Those two events have increased the interest in IPv6 (the residential IPv6 trial I was working on gained more participants due to these events), which would have created an incentive for people to improve the quality of their 6to4 operation, or possibly deploy a trial 6to4 relay. An update on that data would be useful. Regards, Mark. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sat, 2 Jul 2011 21:02:02 -0700 Cameron Byrne cb.li...@gmail.com wrote: snip In the meantime, i null route the 6to4 anycast address because it creates half open state in my CGN. Been doing that for at least 5 years. So, to be clear, you're not making an observation that 6to4 is broken, based on measurement or actual use, you're actively breaking it. My next step is filtering over IPv4 access because 6to4 client brokeness won't die on its own, that will be rolled out in a few months. Operating a network means making the tweeks that keep the wheels rolling, and we don't find many technology purist in my line of work. I think the root cause of your issues is the deployment of IPv4 CGN in the first place before IANA and the RIRs ran out of IPv4 addresses by the sounds of it. I think then means that any protocol that your customers try to use that would create unwanted state in your IPv4 CGN should be, by your definition, declared historic, not just 6to4. When a customer signs up to your service, are they informed as to which protocols and applications they are allowed to use? My opinion is that if there are restrictions on what protocols and applications customers can operate then their service is not a real Internet service. The majority of, if not all, residential broadband service providers in my market hold the same belief - it seems to be the pure mobile carriers that commonly don't. Other access providers like 6to4 so much that they want to NAT it. This is the reason why historic is the proper term. http://tools.ietf.org/html/draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-02 I look forward to that discussion on ietf@ Cameron Keith ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sat, 2 Jul 2011 21:59:24 -0700 Joel Jaeggli joe...@bogus.com wrote: This line of discussion is not productive... Between them the 4 largest north american wireless carriers need ~18 /8s to assign public ipv4 addresses to their wireless cpe... they don't have that and there's no-where to get it, then there's the rest of the world. That's now, but what about when they chose to implement IPv4 CGN, likely to be years ago. Cameron is choosing to blame 6to4 for a problem that any of the stateless and/or unidirectional Internet protocols could cause on a IPv4 CGN. His arguments to make 6to4 historic are not based on issues specific to 6to4. If 6to4 is made historic, does he then start lobbying for UDP-historic? On Jul 2, 2011, at 9:45 PM, Mark Smith wrote: On Sat, 2 Jul 2011 21:02:02 -0700 Cameron Byrne cb.li...@gmail.com wrote: snip In the meantime, i null route the 6to4 anycast address because it creates half open state in my CGN. Been doing that for at least 5 years. So, to be clear, you're not making an observation that 6to4 is broken, based on measurement or actual use, you're actively breaking it. My next step is filtering over IPv4 access because 6to4 client brokeness won't die on its own, that will be rolled out in a few months. Operating a network means making the tweeks that keep the wheels rolling, and we don't find many technology purist in my line of work. I think the root cause of your issues is the deployment of IPv4 CGN in the first place before IANA and the RIRs ran out of IPv4 addresses by the sounds of it. I think then means that any protocol that your customers try to use that would create unwanted state in your IPv4 CGN should be, by your definition, declared historic, not just 6to4. When a customer signs up to your service, are they informed as to which protocols and applications they are allowed to use? My opinion is that if there are restrictions on what protocols and applications customers can operate then their service is not a real Internet service. The majority of, if not all, residential broadband service providers in my market hold the same belief - it seems to be the pure mobile carriers that commonly don't. Other access providers like 6to4 so much that they want to NAT it. This is the reason why historic is the proper term. http://tools.ietf.org/html/draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-02 I look forward to that discussion on ietf@ Cameron Keith ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
Totally agree. Regardless of my position on this specific draft, if it has been declared no consensus, now it not wise to go forward, declare consensus and accept the appeal. Credibility is first. Regards, Jordi -Mensaje original- De: Noel Chiappa j...@mercury.lcs.mit.edu Responder a: j...@mercury.lcs.mit.edu Fecha: Tue, 5 Jul 2011 10:44:29 -0400 (EDT) Para: ietf@ietf.org, v6...@ietf.org CC: j...@mercury.lcs.mit.edu Asunto: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic From: Ronald Bonica rbon...@juniper.net I think that I get it. There is no IETF consensus regarding the compromise proposed below. ... But there is no rough consensus to do that either. That is the claim of an appeal on the table. Let's run the appeal process and figure out whether that claim is valid. Sorry, this makes no sense. You can't go ahead with draft-ietf-v6ops-6to4-to-historic if there is no basic consensus in the IETF as a whole to do so - and your previous declaration (on Saturday) basically accepted that there was no such basic consensus (otherwise why withdraw the ID). So now there is going to be a reversal, and the document is going to go ahead - i.e. you must now be taking the position that there _is_ basic consensus in the IETF (without which you could not proceed the ID). The effect of this sort of thing on the reputation of I* should be obvious to all. Noel ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments surrounding draft-iab-dns-applications-01
The naive approach of reversing the address, converting to nibbles and appending a suffix won't scale. I don't understand why the setup is OK for reverse DNS but not blacklists. One obvious reason is that the most widely used DNSBL server doesn't return NODATA vs. NXDOMAIN according to current standards, so probing and NXDOMAIN synthesis doesn't work. I'm planning to fix it, but it'll take a while. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: draft-ietf-v6ops-6to4-to-historic
Noel, I didn't say that I was going to push draft-ietf-v6ops-6to4-to-historic through without running the process. I said that draft-ietf-v6ops-6to4-to-historic has made it all the way past IESG approval. There is an appeal on the table (at the WG level) questioning whether draft-ietf-v6ops-6to4-to-historic ever had WG consensus. We will run the appeal process. If the WG chairs cannot justify WG consensus, draft-ietf-v6ops-6to4-to-historic stops dead in its tracks. If they can justify WG consensus, the appellant can escalate the appeal to the IESG (and to the IAB after that). If the appeal succeeds at any level, draft-ietf-v6ops-6to4-to-historic is not published. Ron -Original Message- From: Noel Chiappa [mailto:j...@mercury.lcs.mit.edu] Sent: Tuesday, July 05, 2011 10:44 AM To: ietf@ietf.org; v6...@ietf.org Cc: j...@mercury.lcs.mit.edu Subject: RE: draft-ietf-v6ops-6to4-to-historic From: Ronald Bonica rbon...@juniper.net I think that I get it. There is no IETF consensus regarding the compromise proposed below. ... But there is no rough consensus to do that either. That is the claim of an appeal on the table. Let's run the appeal process and figure out whether that claim is valid. Sorry, this makes no sense. You can't go ahead with draft-ietf-v6ops-6to4-to-historic if there is no basic consensus in the IETF as a whole to do so - and your previous declaration (on Saturday) basically accepted that there was no such basic consensus (otherwise why withdraw the ID). So now there is going to be a reversal, and the document is going to go ahead - i.e. you must now be taking the position that there _is_ basic consensus in the IETF (without which you could not proceed the ID). The effect of this sort of thing on the reputation of I* should be obvious to all. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments surrounding draft-iab-dns-applications-01
On 7/5/2011 3:56 AM, Tony Finch wrote: Mark Andrewsma...@isc.org wrote: DNS[WB]L's have never been a good fit to the DNS, rather they have not been a bad enough fit to require something better to be done. Oh come off it, they are just as good a fit to the DNS as reverse DNS is. The naive approach of reversing the address, converting to nibbles and appending a suffix won't scale. I don't understand why the setup is OK for reverse DNS but not blacklists. +1 This has been an on-going issue, with a kind of 'purity' argument from some folk. While concern for the stability of end-to-end DNS operations certainly is essential, the degree of resistance to these added uses of the service often is, indeed, inconsistent. In general, the problematic logic requires a devotion to the narrow usage that has dominated the DNS, rather than what the design of DNS was intended to support. (Reading the original RFCs is instructive for this broader view.) However for the current thread, there really does appear to be an impending problem. It seems pretty clear that DNS caching needs to be tailored to the types of applications making the queries and that mixed traffic could well mess with caching behavior. (I think it uncontroversial to note that that having DNS caching functioning well is an important requirement for stable and efficient DNS use.) For an application that is likely to encounter a different IP address for essentially every query, across a very large number of queries, the only solution I see available is to use a different cache. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments surrounding draft-iab-dns-applications-01
For an application that is likely to encounter a different IP address for essentially every query, across a very large number of queries, the only solution I see available is to use a different cache. Seems reasonable. I gather that there are already caches with the ability to partition themselves so that records from different subtrees compete for different pools of cache entries. I'm also sort of surprised that we don't seem to have all that much experimental data about cache behavior. The MIT papers that Tony cited are interesting, but they're also ten years old. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments surrounding draft-iab-dns-applications-01
On 7/5/2011 10:31 AM, John Levine wrote: For an application that is likely to encounter a different IP address for essentially every query, across a very large number of queries, the only solution I see available is to use a different cache. Seems reasonable. I gather that there are already caches with the ability to partition themselves so that records from different subtrees compete for different pools of cache entries. I'm also sort of surprised that we don't seem to have all that much experimental data about cache behavior. The MIT papers that Tony cited are interesting, but they're also ten years old. I doubt that partitioning according to DNS structure will work for this, since the DNS has no formal semantics to different parts. Hard-coding knowledge of particular tree segments can work for specific examples, in small scale, but won't work for the constantly-changing IP Address behavior cited in this thread. I believe that the solution is to have the applications, themselves, distinguish the cache they are using (or the containing library). A blocklist app needs to use a different library/cache than a web browser. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments surrounding draft-iab-dns-applications-01
Dave CROCKER d...@dcrocker.net wrote: For an application that is likely to encounter a different IP address for essentially every query, across a very large number of queries, the only solution I see available is to use a different cache. This has been operational common sense for many years. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Trafalgar: Northerly 5 or 6 in southeast, otherwise variable mainly westerly veering northerly, 3 or 4. Moderate or rough. Fair. Moderate or good. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments surrounding draft-iab-dns-applications-01
On 7/5/2011 10:59 AM, Tony Finch wrote: Dave CROCKERd...@dcrocker.net wrote: For an application that is likely to encounter a different IP address for essentially every query, across a very large number of queries, the only solution I see available is to use a different cache. This has been operational common sense for many years. In theory, practice is not much different from theory. In practice... http://thinkexist.com/quotation/common_sense_is_very/193303.html d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSBLSs and caches, was Comments surrounding draft-iab-dns-applications-01
I believe that the solution is to have the applications, themselves, distinguish the cache they are using (or the containing library). A blocklist app needs to use a different library/cache than a web browser. You could do it either way. Either you could adjust the MTAs to have a new parameter for the address of the cache to use for DNSBLs vs. the cache to use for MX, A, and , or you could tell the cache about the list of DNSBLs that the local MTAs use (a list which in my experience is rarely very long.) Pick your poison, depends which software is older and cruddier. Or there's the pessimal approach, add a new EDNS parameter so the MTA can tell the cache what kind of lookup it's making, so you have to upgrade and debug both of them! R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [v6ops] draft-ietf-v6ops-6to4-to-historic
I shudder to think that this is a prerequisite for declaring something Historic. If some RFC meant to solve some problem turns out not only to be a bad idea but also shows that the problem itself is essentially intractable, I don't think it's practical at all to require a replacement before declaring the RFC Historic. From: v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] On Behalf Of Keith Moore Sent: Sunday, July 03, 2011 12:31 PM To: Arturo Servin Cc: IPv6 Operations; IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic Honestly I'd be happy to declare 6to4 Historic if we had a suitable replacement - one that could be automatically configured by hosts, used by applications, and worked better than 6to4 in most cases. I don't think it exists yet. [...] Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-mboned-ssmping-08.txt (Multicast Ping Protocol) to Proposed Standard
I think this draft specifies a very useful protocol, which we have used at our site and which has been a valuable multicast debugging tool. The specification and implementations have evolved over maybe 5-6 years or so. The implementations we've used have been of various stages of the protocol's development. A student at our site implemented an earlier version of the protocol successfully. I don't believe we've used a version at our site based on the spec in the final version of the text, so I can't comment on that specifically. There are some parts of the text that I think indicate the protocol has evolved over a length of time; if it were rewritten from scratch it would probably be somewhat more compact, due to some level of repetition of aspects of the protocol. However, I think it's more important to get the protocol published now, so I would support publishing it as is. The protocol is defined in a fairly loose way, but the core elements are tight enough for implementation. This is reflected in the text at the start of Section 6. I noticed one nit in terms of the client ID. In Section 2 the text says: At runtime, a client generates a client ID that is unique for the ping test. This ID is included in all messages sent by the client. Then later in the more detailed spec, the text says: A client SHOULD always include this option in all messages (both Init and Echo Request). I would have expected the inclusion of the Client ID to be a MUST, based on the earlier explanation. If it is a SHOULD, the introduction text should say this ID is usually included in all messages sent by the client. It would be nice to consider mechanisms to discover 'public' ssmping test servers, but that's a separate text :) Tim On 20 Jun 2011, at 18:51, The IESG wrote: The IESG has received a request from the MBONE Deployment WG (mboned) to consider the following document: - 'Multicast Ping Protocol' draft-ietf-mboned-ssmping-08.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-07-04. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Multicast Ping Protocol specified in this document allows for checking whether an endpoint can receive multicast, both Source- Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also be used to obtain additional multicast-related information such as multicast tree setup time. This protocol is based on an implementation of tools called ssmping and asmping. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mboned-ssmping/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mboned-ssmping/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
extra room avail IETF hotel at IETF rate
I found that I have an extra reservation at the IETF rate ($229/night)for Sunday to Friday at the Hilton. If anyone is interested I can transfer the reservation. geoff ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [MBONED] Last Call: draft-ietf-mboned-ssmping-08.txt (Multicast Ping Protocol) to Proposed Standard
On 7/5/2011 2:10 PM, Tim Chown wrote: I think this draft specifies a very useful protocol, which we have used at our site and which has been a valuable multicast debugging tool. The specification and implementations have evolved over maybe 5-6 years or so. The implementations we've used have been of various stages of the protocol's development. A student at our site implemented an earlier version of the protocol successfully. I don't believe we've used a version at our site based on the spec in the final version of the text, so I can't comment on that specifically. There are some parts of the text that I think indicate the protocol has evolved over a length of time; if it were rewritten from scratch it would probably be somewhat more compact, due to some level of repetition of aspects of the protocol. However, I think it's more important to get the protocol published now, so I would support publishing it as is. The protocol is defined in a fairly loose way, but the core elements are tight enough for implementation. This is reflected in the text at the start of Section 6. I noticed one nit in terms of the client ID. In Section 2 the text says: At runtime, a client generates a client ID that is unique for the ping test. This ID is included in all messages sent by the client. Then later in the more detailed spec, the text says: A client SHOULD always include this option in all messages (both Init and Echo Request). I would have expected the inclusion of the Client ID to be a MUST, based on the earlier explanation. If it is a SHOULD, the introduction text should say this ID is usually included in all messages sent by the client. Yes, I think it should be changed to say usually. A basic client could work without including the ID. But there are good reasons to include it as listed in the draft. Stig It would be nice to consider mechanisms to discover 'public' ssmping test servers, but that's a separate text :) Tim On 20 Jun 2011, at 18:51, The IESG wrote: The IESG has received a request from the MBONE Deployment WG (mboned) to consider the following document: - 'Multicast Ping Protocol' draft-ietf-mboned-ssmping-08.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-07-04. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Multicast Ping Protocol specified in this document allows for checking whether an endpoint can receive multicast, both Source- Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also be used to obtain additional multicast-related information such as multicast tree setup time. This protocol is based on an implementation of tools called ssmping and asmping. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mboned-ssmping/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mboned-ssmping/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ MBONED mailing list mbo...@ietf.org https://www.ietf.org/mailman/listinfo/mboned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments surrounding draft-iab-dns-applications-01
Hi, all, This doc also claims that: The SRV record allows DNS resolvers to search for particular applications and underlying transports (for example, HTTP running over TLS, see [RFC2818]) and to learn the domain name and port where that service resides in a given administrative domain. The transports should be TCP, UDP, or (arguably or not) other transport protocols. TLS is not a transport. Currently http is distinguished from https using the service names string, not the transport. I.e., IMO, in SRV records: service name = layers 5-7 transport = layer 4 TLS is above layer 4. --- Additionally, it's useful to distinguish The DNS (i.e., with the existing well-know roots) from A DNS -- the latter using the same protocols and records, but not sharing the same initial roots. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
Gert Doering wrote: On Sat, Jul 02, 2011 at 11:11:43PM -0400, Keith Moore wrote: There's clearly a lack of consensus to support it. There's two very vocal persons opposing it There were more than two clearly opposing, and there is no need to further fuel the heated discussion by everyone becoming as vocal as Keith. The pain point is really the unnecessarily aggressive kill what we don't like move-to-historic action. This is a procedural issue, not a matter of personal taste. There was an alternative reclassification suggested, that could gather rough consensus. I'm still waiting for a *clean* resolution of the procedural issue (that means serious consideration of suggested alternatives). -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments surrounding draft-iab-dns-applications-01
On 7/5/2011 3:12 PM, Joe Touch wrote: The SRV record allows DNS resolvers to search for particular applications and underlying transports (for example, HTTP running over TLS, see [RFC2818]) and to learn the domain name and port where that service resides in a given administrative domain. The transports should be TCP, UDP, or (arguably or not) other transport protocols. TLS is not a transport. Also, strictly speaking, the function that is performed is lookup or mapping, not search. The difference is large. Additionally, it's useful to distinguish The DNS (i.e., with the existing well-know roots) from A DNS -- the latter using the same protocols and records, but not sharing the same initial roots. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
draft-ietf-v6ops-6to4-advisory dependency on draft-ietf-v6ops-6to4-to-historic
Greetings, I note that draft-ietf-v6ops-6to4-advisory-02, now approved for publication and in the RFC Editor's queue, has a minor dependency on draft-ietf-v6ops-6to4-to-historic, specifically at the end of Section 1 (bottom of p. 3): A companion document [I-D.ietf-v6ops-6to4-to-historic] proposes to reclassify 6to4 as Historic. However, this will not remove the millions of existing hosts and customer premises equipments that implement 6to4. Hence, the advice in this document remains necessary. That may need to be changed (e.g., in AUTH48), depending on the outcome of the pending appeal against draft-ietf-v6ops-6to4-to-historic. //cmh On Tue, 5 Jul 2011, Ronald Bonica wrote: Noel, I didn't say that I was going to push draft-ietf-v6ops-6to4-to-historic through without running the process. I said that draft-ietf-v6ops-6to4-to-historic has made it all the way past IESG approval. There is an appeal on the table (at the WG level) questioning whether draft-ietf-v6ops-6to4-to-historic ever had WG consensus. We will run the appeal process. If the WG chairs cannot justify WG consensus, draft-ietf-v6ops-6to4-to-historic stops dead in its tracks. If they can justify WG consensus, the appellant can escalate the appeal to the IESG (and to the IAB after that). If the appeal succeeds at any level, draft-ietf-v6ops-6to4-to-historic is not published. Ron -Original Message- From: Noel Chiappa [mailto:j...@mercury.lcs.mit.edu] Sent: Tuesday, July 05, 2011 10:44 AM To: ietf@ietf.org; v6...@ietf.org Cc: j...@mercury.lcs.mit.edu Subject: RE: draft-ietf-v6ops-6to4-to-historic From: Ronald Bonica rbon...@juniper.net I think that I get it. There is no IETF consensus regarding the compromise proposed below. ... But there is no rough consensus to do that either. That is the claim of an appeal on the table. Let's run the appeal process and figure out whether that claim is valid. Sorry, this makes no sense. You can't go ahead with draft-ietf-v6ops-6to4-to-historic if there is no basic consensus in the IETF as a whole to do so - and your previous declaration (on Saturday) basically accepted that there was no such basic consensus (otherwise why withdraw the ID). So now there is going to be a reversal, and the document is going to go ahead - i.e. you must now be taking the position that there _is_ basic consensus in the IETF (without which you could not proceed the ID). The effect of this sort of thing on the reputation of I* should be obvious to all. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-dane-use-cases-04.txt (Use Cases and Requirements for DNS-based Authentication of Named Entities (DANE)) to Informational RFC
The IESG has received a request from the DNS-based Authentication of Named Entities WG (dane) to consider the following document: - 'Use Cases and Requirements for DNS-based Authentication of Named Entities (DANE)' draft-ietf-dane-use-cases-04.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-07-19. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Many current applications use the certificate-based authentication features in TLS to allow clients to verify that a connected server properly represents a desired domain name. Traditionally, this authentication has been based on PKIX trust hierarchies, rooted in well-known CAs, but additional information can be provided via the DNS itself. This document describes a set of use cases in which the DNS and DNSSEC could be used to make assertions that support the TLS authentication process. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dane-use-cases/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dane-use-cases/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)' to Informational RFC (draft-kanno-tls-camellia-03.txt)
The IESG has approved the following document: - 'Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)' (draft-kanno-tls-camellia-03.txt) as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-kanno-tls-camellia/ Technical Summary This document specifies forty-two cipher suites for the Transport Security Layer (TLS) protocol to additional support the Camellia encryption algorithm as a block cipher. Working Group Summary This is individual submission. Document Quality The TLS-WG was consulted for input. Technical as well as editorial comments were addressed. Personnel Satoru Kanno (kanno.sat...@po.ntts.co.jp) is the document shepherd. Sean Turner (turn...@ieca.com) is the Responsible AD. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Review: Home Networks (homenet)
A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by Tuesday, July 12, 2011. Home Networks (homenet) --- Current Status: Proposed Working Group Last Edit: Thursday, June 30th, 2011 Chairs: TBD Internet Area Directors: Ralph Droms rdroms.i...@gmail.com Jari Arkko jari.ar...@piuha.net Internet Area Advisor: Jari Arkko jari.ar...@piuha.net Routing Area Technical Advisor: TBD Security Area Technical Advisor: TBD Mailing Lists: General Discussion: f...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/fun Archive: http://www.ietf.org/mail-archive/web/fun Description of Working Group: This working group focuses on the evolving networking technology within and among relatively small �residential home� networks. For example, an obvious trend in home networking is the proliferation of networking technology in an increasingly broad range and number of devices. This evolution in scale and diversity sets some requirements on IETF protocols. Some of the relevant trends include: o Multiple segments: While less complex L3-toplogies involving as few subnets as possible are preferred in home networks for a variety of reasons including simpler management and service discovery, the introduction of more than one subnet into a home network is enough to add complexity that needs to be addressed, and multiple dedicated segments are necessary for some cases. For instance, a common feature in modern home routers in the ability to support both guest and private network segments. Also, link layer networking technology is poised to become more heterogeneous, as networks begin to employ both traditional Ethernet technology and link layers designed for low-powered sensor networks. Finally, similar needs for segmentation may occur in other cases, such as separating building control or corporate extensions from the Internet access network. Different segments may be associated with subnets that have different routing and security policies. o Service providers are deploying IPv6, and support for IPv6 is increasingly available in home gateway devices. While IPv6 resembles IPv4 in many ways, it changes address allocation principles and allows direct IP addressability and routing to devices in the home from the Internet. This is a promising area in IPv6 that has proved challenging in IPv4 with the proliferation of NAT. o End-to-end communication is both an opportunity and a concern as it enables new applications but also exposes nodes in the internal networks to receipt of unwanted traffic from the Internet. Firewalls that restrict incoming connections may be used to prevent exposure, however, this reduces the efficacy of end-to-end connectivity that IPv6 has the potential to restore. Home networks need to provide the tools to handle these situations in a manner accessible to all users of home networks. Manual configuration is rarely, if at all, possible, as the necessary skills and in some cases even suitable management interfaces are missing. The purpose of this working group is to focus on this evolution, in particular as it addresses the introduction of IPv6, by developing an architecture addressing this full scope of requirements: o prefix configuration for routers o managing routing o name resolution o service discovery o network security The task of the group is to produce an architecture document that outlines how to construct home networks involving multiple routers and subnets. This document is expected to apply the IPv6 addressing architecture, prefix delegation, global and ULA addresses, source address selection rules and other existing components of the IPv6 architecture. The architecture document should drive what protocols changes, if any, are necessary. Specific protocol work described below is expected to be within the scope of the working group once the architecture work is complete. However, the group is required to review its charter and milestones with the IESG and IETF community before submitting documents that make protocol changes. It is expected that the group has to discuss some of the below solutions, however, in order to complete the architecture work. The group will apply existing protocols to handle the five requirements above. For prefix configuration, existing protocols are likely sufficient, and at worst may need some small enhancements, such as new options. For automatic routing, it is expected that existing routing protocols can be used as is, however, a new mechanism may be needed in order to turn a selected protocol on by default. For name resolution and service discovery, extensions to existing multicast-based name resolution protocols
WG Review: Recharter of Protocol Independent Multicast (pim)
A modified charter has been submitted for the Protocol Independent Multicast (pim) working group in the Routing Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by Tuesday, July 12, 2011. Protocol Independent Multicast (pim) --- Current Status: Active Working Group Last updated: 2011-07-01 Chairs: Mike McBride mmcbr...@cisco.com Stig Venaas s...@venaas.com Routing Area Directors: Stewart Bryant stbry...@cisco.com Adrian Farrel adr...@olddog.co.uk Routing Area Advisor: Adrian Farrel adr...@olddog.co.uk Mailing Lists: General Discussion: p...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/pim/ Archive: http://www.ietf.org/mail-archive/web/pim/ Description of Working Group The Protocol Independent Multicast (PIM) Working Group has completed the standardization of PIM with RFC 4601. The WG has determined there is additional work to be accomplished and is chartered to standardize extensions to RFC 4601 - Protocol Independent Multicast Version 2 - Sparse Mode. These PIM extensions will involve reliability, resiliency, scalability, management, and security. If L2VPN or L3VPN WGs determine that support for multicast in L2VPNs and/or L3VPNs requires extensions to PIM, then such extensions will be developed within the PIM WG. Additional work on the PIM-BIDIR and BSR drafts may also be necessary by the WG as these drafts progress through Standards Track. The working group has produced MIB modules for PIM in RFC 5060 and RFC 5240. The working group currently has no plans to do further work on management for PIM. If proposals are brought forward to update or extend the existing MIB modules or to develop YANG modules, the working group will be rechartered. The PIM WG will further enhance RFC4601 as an even more scalable, efficient and robust multicast routing protocol, which is capable of supporting thousands of groups, different types of multicast applications, and all major underlying layer-2 subnetwork technologies. We will accomplish these enhancements by submitting drafts, to the IESG, involving reliable pim, pim join attributes and pim authentication. The working group primarily works on extensions to PIM, but may take on work related to IGMP/MLD. There is a significant number of errata that need to be addressed in order to advance RFC4601 to Draft Standard. The PIM WG will correct the errata, as necessary, and update RFC4601. The working group will initiate a new re-chartering effort if it is determined that a Version 3 of PIM is required. Goals and Milestones: Done Hold the first Working Group meeting and discuss the charter and the state of progress on the chartered items. Done Update the PIM-DM version 2 Internet-draft. Go to WG last call. Submision to IESG for considerations as proposed standard. Done Resubmit the latest PIM-SM version 2 specification to IESG for consideration as a proposed standard RFC Done Submit PIM-SM Applicability Statements Done Submit PIMv2 MIB to IESG for consideration as proposed standard. Done Submit updated PIM-SM and PIM-DM internet-drafts, clarifying any inconsistencies or ambiguities in the previous drafts. Done Submit PIM-SM version 2 and PIM-DM version 2 specifications to IESG for consideration as Draft Standards. Done Submit PIMv2 MIB to IESG for consideration as draft standard. Done Ratify new WG charter and milestones Done Submit the BSR spec as a Proposed Standard to the IESG Done Submit the BSR MIB as a Proposed Standard to the IESG Done Submit a generic TLV PIM Join Attribute PS draft to the IESG Done Submit RPF Vector (use of PIM Join Attribute) as PS to the IESG Done Submit a way to authenticate PIM link local messages as PS to the IESG Done Submit an Informational PIM last hop threats document to the IESG Aug 2011 First WG version of udated RFC 4601 Aug 2011 Submit a more reliable PIM solution (refresh reduction) to the IESG Nov 2011 Submit a population count extension to PIM to the IESG Dec 2011 Submit update of RFC 4601 to IESG for advancement to Draft Standard ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6274 on Security Assessment of the Internet Protocol Version 4
A new Request for Comments is now available in online RFC libraries. RFC 6274 Title: Security Assessment of the Internet Protocol Version 4 Author: F. Gont Status: Informational Stream: IETF Date: July 2011 Mailbox:ferna...@gont.com.ar Pages: 75 Characters: 179909 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-opsec-ip-security-07.txt URL:http://www.rfc-editor.org/rfc/rfc6274.txt This document contains a security assessment of the IETF specifications of the Internet Protocol version 4 and of a number of mechanisms and policies in use by popular IPv4 implementations. It is based on the results of a project carried out by the UK's Centre for the Protection of National Infrastructure (CPNI). This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-mboned-mtrace-v2-08.txt (Mtrace Version 2: Traceroute Facility for IP Multicast) to Proposed Standard
The IESG has received a request from the MBONE Deployment WG (mboned) to consider the following document: - 'Mtrace Version 2: Traceroute Facility for IP Multicast' draft-ietf-mboned-mtrace-v2-08.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-07-19. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the IP multicast traceroute facility. Unlike unicast traceroute, multicast traceroute requires special implementations on the part of routers. This specification describes the required functionality in multicast routers, as well as how management applications can use the router functionality. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mboned-mtrace-v2/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mboned-mtrace-v2/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-msec-gdoi-update-09.txt (The Group Domain of Interpretation) to Proposed Standard
The IESG has received a request from the Multicast Security WG (msec) to consider the following document: - 'The Group Domain of Interpretation' draft-ietf-msec-gdoi-update-09.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-07-19. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes an updated version of the Group Domain of Interpretation (GDOI) protocol specified in RFC 3547. The GDOI provides group key management to support secure group communications according to the architecture specified in RFC 4046. The GDOI manages group security associations, which are used by IPsec and potentially other data security protocols. DOWNREFs This specification contains three normative references to obsoleted RFCs: RFC 2407, RFC 2408, and RFC 2409. This specification contains three normative references to informational RFCs: RFC 2627, RFC 3447, and RFC 5093. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-msec-gdoi-update/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-msec-gdoi-update/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
