Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 01/30/2012 15:03, The IESG wrote: > > The IESG has received a request from an individual submitter to consider the > following document: > - 'IANA Reserved IPv4 Prefix for Shared CGN Space' > as a BCP > > On its December 15, 2011 telechat, the IESG reviewed version 10 of this > document and requested various changes. These changes are reflected in > the draft version 14 and the IESG now solicits community input on the > changed text only. As I (and many others) remain opposed to this entire concept I think it's incredibly unfortunate that the IESG has decided to shift the topic of conversation from "whether" this should happen to "how" it should happen. But comments more to the point below > Please send substantive comments to the ietf@ietf.org > mailing lists by 2012-02-16. 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 requests the allocation of an IPv4 /10 address block to > be used as Shared Address Space to accommodate the needs of Carrier > Grade Network Address Translation (CGN) devices. It is anticipated > that Service Providers will use this Shared Address Space to number > the interfaces that connect CGN devices to Customer Premise Equipment > (CPE). > > Shared Address Space is distinct from RFC1918 private address space > because it is intended for use on Service Provider networks. > However, it may be used as RFC 1918 private address space in certain > circumstances. Details are provided in the text of this document. > > As this document proposes the allocation of an additional special-use > IPv4 address block, it updates RFC 5735. > > The following text captures the most salient change between version 10 and 14 > of this document: > > Shared Address Space is IPv4 address space designated for Service > Provider use with the purpose of facilitating CGN deployment. Also, > Shared Address Space can be used as additional [RFC1918] space I think it's a feature that we're finally willing to admit that this new block is going to be used as 1918 space. Given that previous requests for new 1918 space have been (rightly) denied, I think this document should describe why this request is better/more important than previous requests, and what the bar will be for future requests for new 1918 space. > when > at least one of the following conditions is true: > > o Shared Address Space is not also used on the Service Provider side > of the CPE. > > o CPE routers behave correctly when using the same address block on > both the internal and external interfaces. When I previously proposed this as *the* proper solution I was told that it wasn't in any way practical. Now that we're apparently willing to discuss it as *a* possible solution one wonders why a new block is necessary at all. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Weekly posting summary for ietf@ietf.org
Total of 48 messages in the last 7 days. script run at: Fri Feb 10 00:53:02 EST 2012 Messages | Bytes| Who +--++--+ 6.25% |3 | 5.36% |21229 | cgrundem...@gmail.com 6.25% |3 | 5.16% |20447 | s...@resistor.net 4.17% |2 | 5.30% |20983 | b...@nostrum.com 4.17% |2 | 5.09% |20153 | lore...@google.com 4.17% |2 | 4.92% |19502 | f...@cisco.com 4.17% |2 | 4.58% |18133 | stephen.farr...@cs.tcd.ie 4.17% |2 | 3.93% |15574 | e...@google.com 2.08% |1 | 5.92% |23447 | tina.tsou.zout...@huawei.com 4.17% |2 | 3.66% |14515 | ma...@isc.org 4.17% |2 | 3.66% |14502 | j...@apple.com 4.17% |2 | 3.60% |14285 | rog...@gmail.com 4.17% |2 | 3.41% |13525 | fg...@si6networks.com 4.17% |2 | 3.03% |12010 | john-i...@jck.com 2.08% |1 | 3.38% |13396 | ve7...@ve7jtb.com 2.08% |1 | 2.95% |11706 | david.bl...@emc.com 2.08% |1 | 2.58% |10239 | yaacov.weingar...@nsn.com 2.08% |1 | 2.41% | 9545 | rcal...@juniper.net 2.08% |1 | 2.37% | 9393 | sakim...@gmail.com 2.08% |1 | 2.35% | 9302 | alexey.melni...@isode.com 2.08% |1 | 2.25% | 8913 | daedu...@btconnect.com 2.08% |1 | 2.23% | 8836 | nar...@us.ibm.com 2.08% |1 | 2.22% | 8800 | jeff_do...@partech.com 2.08% |1 | 2.04% | 8096 | rbon...@juniper.net 2.08% |1 | 1.99% | 7886 | afar...@juniper.net 2.08% |1 | 1.86% | 7359 | brian.e.carpen...@gmail.com 2.08% |1 | 1.81% | 7166 | joe...@bogus.com 2.08% |1 | 1.66% | 6584 | bortzme...@nic.fr 2.08% |1 | 1.59% | 6284 | dwor...@avaya.com 2.08% |1 | 1.57% | 6227 | d...@dotat.at 2.08% |1 | 1.57% | 6210 | s...@cs.columbia.edu 2.08% |1 | 1.52% | 6039 | do...@dougbarton.us 2.08% |1 | 1.45% | 5761 | d...@virtualized.org 2.08% |1 | 1.31% | 5202 | adr...@olddog.co.uk 2.08% |1 | 1.27% | 5018 | ra...@psg.com +--++--+ 100.00% | 48 |100.00% | 396267 | Total ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
--On Thursday, February 09, 2012 15:40 -0500 Ronald Bonica wrote: > SM, > > At NANOG 54, ARIN reported that they are down to 5.6 /8s. If > just four ISPs ask for a /10 for CGN, we burn one of those /8s. > > Is that really a good idea? Ron, I've mostly been staying out of this since an earlier round, but that question/ scenario seems pretty irrelevant to me.If four ISPs ask for (and can justify) /10s to serve customers, or a larger number asks for smaller allocations that add up to the same thing, we burn a /10 equally quickly. I think the real answer to questions like the one you ask is another question: Suppose there is a strategy that delays, by (say) six months or a year, the date that ARIN (for example) runs out of useful-sized blocks to allocate, it is worth doing something strange or pathological just to gain that extra time? I think the answer to that question is "no", regardless of how one defines "strange or pathological", because a year of traditional IPv4 allocations from the RIRs one way or the other is quite unlikely to make a major different to the Internet. I'm not claiming this proposal is either strange or pathological (or that it is not). But I suggest that the decision be made on the same basis that other allocation decisions are made, not by trying to save a few months or by deciding that some types of applications or applicants are inherently more privileged than others regardless of their actual merits. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ITC copped out on UTC again
On Feb 7, 2012, at 11:03 , Tony Finch wrote: > > Actually TAI depends a lot on relativity as well as quantum physics. For > example, it is supposed to match the rate of the SI second on the geoid > (which is roughly mean sea level). NIST's lab in Colorado is about a mile > high, so they have to apply a general relativistic rate correction to > their atomic clocks because of their gravitational potential. I'm aware of that. The point I was trying to make so clumsily is that, outside of the physical contexts where relativity and quantum effects are significant, TAI is a comparatively stable and predictable timescale next to the UTC and the NTP timescales. It would be a perfectly good replacement as The Internet Timescale. >> so it should be good enough for most running code on the Internet. > > Except where that code needs UTC. ...or awareness any other timezone, for that matter. On Feb 7, 2012, at 11:12 , John C Klensin wrote: > > You obviously have not been in enough meetings in which proposals were put > forth, by political types with the best of intentions, for regulations to > improve the Internet... I said "somewhat resistant" not "impervious" didn't I? [I'm not going to recount any of the stories I know about various famous technology sector executives and their unhappy encounters with the laws of physics.] -- james woodyatt member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Hi Ron, At 12:40 PM 2/9/2012, Ronald Bonica wrote: At NANOG 54, ARIN reported that they are down to 5.6 /8s. If just four ISPs ask for a /10 for CGN, we burn one of those /8s. Is that really a good idea? The short answer is no. The long answer is a bit complicated as it would be difficult to justify efficient utilization of a /10 within a three-month time frame. There are also specific policies which can be used to get a /10. From an IETF perspective, I understand that the IESG is faced with a difficult decision and I respect its decision. I note that Chris Grundemann has been fair when we interacted in a non-IETF venue. Based on the above, I'll keep the -1 for the determination of consensus. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
In message <6.2.5.6.2.20120209091221.082cb...@resistor.net>, SM writes: > Hi Chris, > At 08:57 AM 2/9/2012, Chris Grundemann wrote: > >http://www.apnic.net/publications/news/2011/final-8 > > I am aware of the APNIC announcement. That's one out of five regions. > > >Are you proposing that every ISP on the planet be given a /10 for > >inside CGN use, rather than one single /10 being reserved for this > >purpose? > > No. > > If I am not mistaken, IPv4 assignments are on a needs basis. In my > previous comment, I mentioned that RIRs are still providing unique > IPv4 assignments to service providers that request IPv4 > addresses. Even if the IANA pool was not exhausted, it is unlikely > that an ISP would get a /20 due to the slow-start mechanism. > > Regards, > -sm In none of the discussions I've seen has anyone proposed forcing ISP's to use this space. It is being provided as a alternative, the same away RFC 1918 space is offered as a alternative. Today you get ask "have you considered RFC 1918 space?" You can still get space even if RFC 1918 space would have worked. I suspect a similar question, will be part of allocation proceedures, for this space in the future. You need to know that the applicant is aware of this space. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC
On 2/9/2012 10:02 AM, Roger Jørgensen wrote: > Or, the way I read you, you tell us that this entire document isn't > relevant anymore. > > It cover something called whitelisting that were in use for a short > periode of time for reason no one in a few year can understand as > relevant? +1 -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Thu, Feb 9, 2012 at 13:59, David Conrad wrote: > Ron, > > On Feb 9, 2012, at 12:40 PM, Ronald Bonica wrote: >> At NANOG 54, ARIN reported that they are down to 5.6 /8s. If just four ISPs >> ask for a /10 for CGN, we burn one of those /8s. >> >> Is that really a good idea? > > Long ago, I once proposed a policy at ARIN to try to extend the IPv4 runway. > One of the most common responses I received (including from several members > of ARIN's AC) was "let it run out naturally", with the rationale being either: > > a) "it'll force people to move to IPv6" > b) "we spent a lot of money to prepare for IPv6 because we knew it was coming > soon, we don't want to give our competitors who fiddled the summer away more > time" > > I suspect those people would answer "yes" (well, unless their opinions have > changed as reality starts biting). Being one of the people who believe that IPv4 should run out naturally, I can tell you that my answer is "no." Natural-run-out and waste are not synonymous. Cheers, ~Chris > Regards, > -drc > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Thu, Feb 9, 2012 at 9:40 PM, Ronald Bonica wrote: > SM, > > At NANOG 54, ARIN reported that they are down to 5.6 /8s. If just four ISPs > ask for a /10 for CGN, we burn one of those /8s. > > Is that really a good idea? It's not about good or bad idea, it should be more about; If they can justify having a /10 each then they should get it. And yes, that will hurt. ... wish people could use more time to move on instead of trying to squeeze even more out of the good old, dry and dead dog called IPv4. With all of that said, giving out this shared address space is a horrible idea, but it just a little bit less horrible than the alternates. And yes it will be abused and be counted as yet another RFC1918 space anyway. I know of plenty of people that will be trilled for this space... "woho, no more address collision" while they quiet think "I hope no one else know about this address space" in other word, move on, give out this space, it'll hurt just a little bit less than the other options. -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Ron, On Feb 9, 2012, at 12:40 PM, Ronald Bonica wrote: > At NANOG 54, ARIN reported that they are down to 5.6 /8s. If just four ISPs > ask for a /10 for CGN, we burn one of those /8s. > > Is that really a good idea? Long ago, I once proposed a policy at ARIN to try to extend the IPv4 runway. One of the most common responses I received (including from several members of ARIN's AC) was "let it run out naturally", with the rationale being either: a) "it'll force people to move to IPv6" b) "we spent a lot of money to prepare for IPv6 because we knew it was coming soon, we don't want to give our competitors who fiddled the summer away more time" I suspect those people would answer "yes" (well, unless their opinions have changed as reality starts biting). Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
SM, At NANOG 54, ARIN reported that they are down to 5.6 /8s. If just four ISPs ask for a /10 for CGN, we burn one of those /8s. Is that really a good idea? Ron > -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of > SM > Sent: Thursday, February 09, 2012 10:45 AM > To: ietf@ietf.org > Subject: Re: Last Call: 14.txt> (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP > > At 03:03 PM 1/30/2012, The IESG wrote: > >The IESG has received a request from an individual submitter to > >consider the following document: > >- 'IANA Reserved IPv4 Prefix for Shared CGN Space' > > as a BCP > > > >On its December 15, 2011 telechat, the IESG reviewed version 10 of > this > >document and requested various changes. These changes are reflected in > >the draft version 14 and the IESG now solicits community input on the > >changed text only. Please send substantive comments to the > ietf@ietf.org > >mailing lists by 2012-02-16. Exceptionally, comments may be sent to > > Is that a two-weeks Last Call? > > Will the determination of consensus be made only on the basis of this > Last Call? > > In Section 3: > >"A Service Provider can number the interfaces in question from > legitimately assigned globally unique address space. While this > solution poses the fewest problems, it is impractical because > globally unique IPv4 address space is in short supply." > > Unique IPv4 address space is not in short supply in some regions. If > it is globally in short supply, I gather that several regions have > already reached their IPv4 Exhaustion phase. I haven't seen any > announcements about that. > >"While the Regional Internet Registries (RIR) have enough address > space to allocate a single /10 to be shared by all Service > Providers, > they do not have enough address space to make a unique assignment > to > each Service Provider." > > The above is incorrect as RIRs are still providing unique IPv4 > assignments to service providers that request IPv4 addresses. On > reading this draft, I conclude that as IPv4 addresses are nearly > exhausted, the only option left is to deploy Carrier Grade NAT > instead of requesting IPv4 addresses from a RIR. > > For the determination of consensus, I do not support this proposal. > > Regards, > -sm > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Thu, Feb 9, 2012 at 10:59, SM wrote: > Hi Chris, > At 08:57 AM 2/9/2012, Chris Grundemann wrote: >> >> http://www.apnic.net/publications/news/2011/final-8 > > I am aware of the APNIC announcement. That's one out of five regions. My apologies, when you stated "I haven't seen any announcements about that." I thought you were not. Hopefully others found the link useful. >> Are you proposing that every ISP on the planet be given a /10 for >> inside CGN use, rather than one single /10 being reserved for this >> purpose? > > > No. > > If I am not mistaken, IPv4 assignments are on a needs basis. In my previous > comment, I mentioned that RIRs are still providing unique IPv4 assignments > to service providers that request IPv4 addresses. Even if the IANA pool was > not exhausted, it is unlikely that an ISP would get a /20 due to the > slow-start mechanism. In the ARIN region, slow-start only applies to new-to-ARIN organizations. Most (if not all) of the ISPs we're discussing here are established entities and are not subject to slow start. More to the point: I do not see giving everyone a unique bit of space for inside CGN use as an efficient solution to the problem. Likewise, waiting until we are completely out of IPv4 space before reacting to the problems that IPv4 free pool exhaustion WILL cause seems _very_ unlikely to produce positive results. Cheers, ~Chris > Regards, > -sm -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Hi Chris, At 08:57 AM 2/9/2012, Chris Grundemann wrote: http://www.apnic.net/publications/news/2011/final-8 I am aware of the APNIC announcement. That's one out of five regions. Are you proposing that every ISP on the planet be given a /10 for inside CGN use, rather than one single /10 being reserved for this purpose? No. If I am not mistaken, IPv4 assignments are on a needs basis. In my previous comment, I mentioned that RIRs are still providing unique IPv4 assignments to service providers that request IPv4 addresses. Even if the IANA pool was not exhausted, it is unlikely that an ISP would get a /20 due to the slow-start mechanism. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC
On Thu, Feb 9, 2012 at 10:25 AM, Lorenzo Colitti wrote:
> It seems to me that approximately 30% of the non-biolerplate text in this
> draft discusses DNS whitelisting. (And in fact, in its original form the
> draft entirely on DNS whitelisting - hence the filename. The rest was added
> later.)
>
> Whitelisting is a practice relevant to a few large websites (since nobody
> else is using it). It so happens that the websites that employ this practice
> are going to stop using it, all together. Given the cost and implications,
> I'd say practice is unlikely to be resurrected.
>
> So, you decide to tell the whole story, and talk about whitelisting *and*
> World IPv6 Launch. Or you can decide that whitelisting will soon be
> irrelevant, and not talk about either whitelisting or World IPv6 Launch. But
> you can't talk about whitelisting without talking about World IPv6 Launch,
> because if you do, your document is missing the key piece "how do you remove
> the whitelist", and that's a disservice to its readers.
>
> To be more specific, at least section 5.5 ("it is unclear how implementers
> will judge when the network conditions will have changed sufficiently to
> justify turning off DNS Resolver Whitelisting and/or what the process and
> timing will be for discontinuing this practice") is now incorrect. It *is*
> clear, and it's what those implementers are doing as part of World IPv6
> Launch.
>
> Does that make more sense?
Or, the way I read you, you tell us that this entire document isn't
relevant anymore.
It cover something called whitelisting that were in use for a short
periode of time for reason no one in a few year can understand as
relevant?
--
Roger Jorgensen |
rog...@gmail.com | - IPv6 is The Key!
http://www.jorgensen.no | ro...@jorgensen.no
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Thu, Feb 9, 2012 at 08:44, SM wrote: > In Section 3: > > "A Service Provider can number the interfaces in question from > legitimately assigned globally unique address space. While this > solution poses the fewest problems, it is impractical because > globally unique IPv4 address space is in short supply." > > Unique IPv4 address space is not in short supply in some regions. If it is > globally in short supply, I gather that several regions have already reached > their IPv4 Exhaustion phase. I haven't seen any announcements about that. http://www.apnic.net/publications/news/2011/final-8 http://www.coisoc.org/index.php/2011/internet-society-statement-on-apnic-ipv4-depletion/ http://www.apnic.net/community/ipv4-exhaustion/ipv4-exhaustion-details http://isoc.org/wp/newsletter/?p=3592 > "While the Regional Internet Registries (RIR) have enough address > space to allocate a single /10 to be shared by all Service Providers, > they do not have enough address space to make a unique assignment to > each Service Provider." > > The above is incorrect as RIRs are still providing unique IPv4 assignments > to service providers that request IPv4 addresses. On reading this draft, I > conclude that as IPv4 addresses are nearly exhausted, the only option left > is to deploy Carrier Grade NAT instead of requesting IPv4 addresses from a > RIR. Are you proposing that every ISP on the planet be given a /10 for inside CGN use, rather than one single /10 being reserved for this purpose? Cheers, ~Chris > For the determination of consensus, I do not support this proposal. > > Regards, > -sm > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
At 03:03 PM 1/30/2012, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'IANA Reserved IPv4 Prefix for Shared CGN Space' as a BCP On its December 15, 2011 telechat, the IESG reviewed version 10 of this document and requested various changes. These changes are reflected in the draft version 14 and the IESG now solicits community input on the changed text only. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-16. Exceptionally, comments may be sent to Is that a two-weeks Last Call? Will the determination of consensus be made only on the basis of this Last Call? In Section 3: "A Service Provider can number the interfaces in question from legitimately assigned globally unique address space. While this solution poses the fewest problems, it is impractical because globally unique IPv4 address space is in short supply." Unique IPv4 address space is not in short supply in some regions. If it is globally in short supply, I gather that several regions have already reached their IPv4 Exhaustion phase. I haven't seen any announcements about that. "While the Regional Internet Registries (RIR) have enough address space to allocate a single /10 to be shared by all Service Providers, they do not have enough address space to make a unique assignment to each Service Provider." The above is incorrect as RIRs are still providing unique IPv4 assignments to service providers that request IPv4 addresses. On reading this draft, I conclude that as IPv4 addresses are nearly exhausted, the only option left is to deploy Carrier Grade NAT instead of requesting IPv4 addresses from a RIR. For the determination of consensus, I do not support this proposal. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC
On Thu, Feb 9, 2012 at 00:36, Joel jaeggli wrote:
> Ops is not marketing.
>
And if I were looking for a marketing venue, a standards body that produces
ASCII text documents read by a handful of engineers would not be high on my
list. This is not about marketing.
> If you're saying some flag day makes the contents of the document no
> longer operationally relevant after a given date, I'll take the point
> but disagree.
>
I think you're missing my point.
It seems to me that approximately 30% of the non-biolerplate text in this
draft discusses DNS whitelisting. (And in fact, in its original form the
draft entirely on DNS whitelisting - hence the filename. The rest was added
later.)
Whitelisting is a practice relevant to a few large websites (since nobody
else is using it). It so happens that the websites that employ this
practice are going to stop using it, all together. Given the cost and
implications, I'd say practice is unlikely to be resurrected.
So, you decide to tell the whole story, and talk about whitelisting *and*
World IPv6 Launch. Or you can decide that whitelisting will soon be
irrelevant, and not talk about either whitelisting or World IPv6
Launch. But you can't talk about whitelisting without talking about World
IPv6 Launch, because if you do, your document is missing the key piece "how
do you remove the whitelist", and that's a disservice to its readers.
To be more specific, at least section 5.5 ("it is unclear how implementers
will judge when the network conditions will have changed sufficiently to
justify turning off DNS Resolver Whitelisting and/or what the process and
timing will be for discontinuing this practice") is now incorrect. It *is*
clear, and it's what those implementers are doing as part of World IPv6
Launch.
Does that make more sense?
Cheers,
Lorenzo
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: (IETF meeting attendees Frequently Asked (travel) Questions) to Informational RFC
I think that this sort of guidance to IETF local hosts may be helpful, and the current document is fine for publication. If the author has time to work on it, I would recommending severe pruning of the preamble text. On the whole it gets in the way of the list of questions. As has been pointed out, the list of things to consider can become endless. Up for consideration are... IMHO the question of visas is buried and not given enough detail. Of particular importance to IETF travellers is the amount of time that they will require to apply for a visa. Of course, this makes an n-squared information grid, and there can be no substitute for pointers to embassy web pages. But we have examples of there not being enough time between the announcement of the meeting location and the meeting itself (viz. three months!) National holidays have been known to impact IETF meetings and travel. Add to 3.3.1 availability of social health services and air quality info. Thanks, Adrian > -Original Message- > From: ietf-announce-boun...@ietf.org [mailto:ietf-announce- > boun...@ietf.org] On Behalf Of The IESG > Sent: 07 February 2012 22:59 > To: IETF-Announce > Subject: Last Call: (IETF meeting attendees' > Frequently Asked (travel) Questions) to Informational RFC > > > The IESG has received a request from an individual submitter to consider > the following document: > - 'IETF meeting attendees' Frequently Asked (travel) Questions' >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 > ietf@ietf.org mailing lists by 2012-03-06. 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 attempts to provide a list of the common Frequently >Asked Questions (FAQs) that IETF meeting attendees often ask >regarding travel logistics and local information. It is intended to >assist those who are willing to provide local information, so that if >they wish to pre-populate answers to some or all of these questions >either in the IETF Wiki or a meeting-specific site, they have a >reasonably complete list of ideas to draw from. It is not meant as a >list of required information that the host or secretariat needs to >provide, merely as a guideline. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-george-travel-faq/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-george-travel-faq/ > > > 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
Re: IAB statement: "The interpretation of rules in the ICANN gTLD Applicant Guidebook"
On Wed, Feb 08, 2012 at 02:03:31PM -0800, IAB Chair wrote a message of 116 lines which said: > The IAB has issued a statement entitled "The interpretation of rules > in the ICANN gTLD Applicant Guidebook". This is a very bad statement. When work started on document draft-liman-tld-names, there were no IDN TLD in the root and some expressed concern that the digits (in their Punycode encoding) could create a problem. Also, draft-liman-tld-names was disputed because it created new rules (explicitely forbidding all-digits TLDs) without a good reason. The document has fallen in disinterest and I'm quite surprised to see it resurfacing now: we have IDN TLDs in the root for a long time and the sky has not fallen. I hope that ICANN will ignore this statement. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
