RE: Last Call: draft-klensin-rfc2821bis

> >> OTOH, I think standardizing this convention makes all > sorts of sense, > >> but not, of course, in 2821bis. > > > > Why not in 2821bis? Is 2821bis really that time critical? > > It is on its way to Draft Standard. This would be a > sufficiently new feature to force recycle at Propo

RE: IETF Last Call for two IPR WG Dcouments

> c) to distribute or communicate copies of the Original Work > and Derivative Works to the public, with the proviso that > copies of Original Work or Derivative Works that You > distribute or communicate shall be licensed under this > Non-Profit Open Software License or as provided in section

RE: problem dealing w/ ietf.org mail servers

> > Which (autoconfig) you should either not be using on > servers, or you > > should be configuring your software properly to select the correct > > outbound address. > that's a bizarre statement. the distinction between a client > and a server is an artificial one. either autoconfig is >

RE: Single-letter names (was: Re: Update of RFC 2606 based on therecent ICANN changes?)

> Alphabetic scripts such as Latin mostly represent sounds used > to make up words. While one can certainly find some > legitimate single-character words (such as the article "a" or > the personal pronoun "i") And lest someone might think that this curiosity of single character words only app

RE: Proposed Experiment: More Meeting Time on Friday for IETF 73

> I oppose this experiment. I already donate to my employer a > significant amount of travel time on weekends without wanting > to add to it. Flight schedules are tightening, thanks to the > cost of fuel, which means that having sessions on Friday at > all poses a problem now, if I want to ge

RE: Proposed Experiment: More Meeting Time on Friday for IETF 73

> > To elaborate, my understanding is that the rules for > teleconferencing > > are governed by the rules for interim meetings, which require > > something like one month's advance notice plus attendance > requirements > > at the previous IETF, and a minimum period of time between > meetings

RE: Proposed Experiment: More Meeting Time on Friday for IETF 73

> "Teleconferencing", in this context, includes any > communications vehicle that enables participants to meet > without having to travel, and which they all agree to. Could > be telephone, skype with or without video, Marratech, Webex, > Citrix, or anything else as long as they all agree. So

RE: request for comments -- how to?

> I have an idea for a new anonymous routing protocall -- and I > was wondering what I should do to get input. I was told by > some people to post here. First Steps --- Write a document that describes the protocol. If you can implement it as well, great, but to start you need to have a d

RE: About IETF communication skills

> Maybe IETF should be thinking about what actions and > policies, uniformly applied, will result in the most accurate > representation of its work to the community. In my experience, the best action to take would be to advise, or teach, people how to handle media interviews. Back when I used t

RE: About IETF communication skills

> I don't know what "accredited" means anymore. IMHO it should mean "real journalists" in this context. That excludes technical experts who play at journalism on their blog. Since the intent of the press conference is to help non-technical writers understand both the IETF technology and the IETF

RE: About IETF communication skills

> >> I don't know what "accredited" means anymore. > > > IMHO it should mean "real journalists" in this context. > > That excludes technical experts who play at journalism on > their blog. > > Right, we wouldn't want to encourage reporting by people who > actually know what they're talking abou

RE: Proposals to improve the scribe situation

> > Many people do not have the liberty of upgrading machines or OSs at > > ease. > > But is that a problem for you or for the network team ? > > There is a point where certain legacy hardware is just not > going to cut it anymore and I don't believe that that is the > fault of the network tea

RE: draft-rfc-image-files-00.txt

> On first reading this seems to be an interesting way to go. It seems to be heading in the right general direction, but I wonder why it does not concentrate on specifying inputs rather than outputs. Given that XML is now widely used as the input format for RFCs, it seems worthwhile to review the

RE: IETF copying conditions

> > I think the *whole point* of a standard is to restrict how > things are > > done, in order to promote interoperability. > > Standards are recommendations not restrictions. Let's say that the restrictions viewpoint wins out in the IETF and all RFCs are copyrighted in such a way that I am not

RE: draft-hoffman-utf8-rfcs-03.txt

> Perhaps a workable compromise is to specify > UTF-8 as the encoding for RFCs, but limited today to some > subset of the full Unicode character set. If UTF-8 is the *ARCHIVAL* encoding for RFCs, that does not prohibit a repository from converting this encoding to some set of formats that are mo

RE: placing a dollar value on IETF IP.

> It all goes back to the light bulb as a great example of > standards setting - back before there was a standard base for > bulbs, I'm sure every light bulb manufacturer had a vested > interest in their pre-standard bases and sockets - whether it > screwed left or right or used push-in pins, t

RE: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

> And what does this have to do with the technical details of > running and using one? We all know that spam stinks and > DNSBLs stink, too. > Unfortunately, the alternatives to DNSBLs are worse. That's a rather narrow view. Very large numbers of people think that Instant Messaging is a far sup

RE: IP-based reputation services vs. DNSBL (long)

> Would refusing to publish as a standard stop > implementations or merely create potential interoperability > issues that could lead to more legitimate messages being dropped? How would refusing to publish a document that is already public, CREATE potential interoperability issues? The questio

RE: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

> there's a lot of evil e-mail messages out there; the cost of > letting even one of those messages through is unacceptable, > so false positives are OK. This is precisely the sort of thing that should have been covered in much more detail in the Security Considerations section of the draft.

RE: several messages

> Huh? Concrete, real example: I send a message to an IETF > mailing list. > A list subscriber's ISP rejects the forwarded message. > IETF's mailman drops the subscriber, because this has been > happened multiple times. > I can't notify the subscriber, because their ISP also rejects > my ema

RE: uncooperative DNSBLs, IETF misinformation (was: several messages)

> - DNSBLs are temporary fad, they'll never last. >(we've been serving DNSBLs for 10 years) Longevity is no guarantee of future survival. > - DNSBLs are bad for email. >(we alone flag some 80 billion spam emails *per day*, spam which >would otherwise clog servers and render email comp

RE: uncooperative DNSBLs, IETF misinformation (was: several messages)

> >> - DNSBLs are a temporary fad, they'll never last. > >>(we've been serving DNSBLs for 10 years) > > > > Longevity is no guarantee of future survival. > > A good argument against publishing a standard for any > technology at all. Not at all. But it seems to me that the IETF does try to de

RE: [BEHAVE] Can we have on NAT66 discussion?

DL> Port/Overload NAT for IPv4 (NAT:P) has security benefits > in that it requires explicit configuration to allow for > inbound unsolicited transport connections (via port forwarding) > to 'inside' hosts. Perhaps you missed this statement from

RE: uncooperative DNSBLs, IETF misinformation (was: several messages)

> > This still breaks deliverability. > > How? A user writes an email and sends it to another user. The other user does not receive the email. This means that deliverability is broken. The DNSBL is an agent in preventing that delivery. To my mind, this deserves some explicit discussion in the Sec

RE: uncooperative DNSBLs, IETF misinformation (was: several messages)

> > A user writes an email and sends it to another user. The other user > > does not receive the email. This means that deliverability > is broken. > > The DNSBL is an agent in preventing that delivery. > > Is this unique to DNSBLs? If not, then why does it merit > deeper consideration in the

RE: several messages

> Although this one has been, IMO, a little more hostile than > necessary (on both sides), anyone who isn't interested in > that type of review should not be looking for IETF Standardization. And for those who have not read the Tao of IETF, the relevant section is 8.2. Letting Go Gracefully

RE: [BEHAVE] Lack of need for 66nat : Long term impact to applicationdevelopers

> Yeah, but we're trying to get rid of that stuff, or at least > considerably reduce the cost and complexity, because (among other > things) it presents a huge barrier to adoption of new multiparty apps. Promoters of NAT, particularly vendors, seem to have a two-valued view of the network in whic

RE: Advice on publishing open standards

> For the past 5 years, I've been processing written sign > language as data. > I've worked directly with the inventor of the script, which > is over 30 years old. > > We are ready to standardize. The latest symbol was finalized > last month after more than a year of improvements and refining

RE: The internet architecture

> I know IETF thinks IP is the center of the universe and the > one true religion. But not in process control it is not. A > PIC controller comes with 384 bytes (BYTES, not kilo) of RAM. This is wildly out of date. For at least the last 10 years cheap and common PICs have been made with more R

RE: The internet architecture

> IMO, one of the biggest challenges surrounding IPv6 > adoption/deployment is that all applications are potentially > impacted, and each and everyone one of them needs to be > explicitely enabled to work with IPv6. Or NAT-PT needs to improved so that middleboxes can be inserted into a network

RE: The internet architecture

> It may > well be that having applications be more brittle would be an > acceptable cost for getting a viable multihoming approach > that address the route scalability problem. (All depends on > what "more brittle" really means.) But the only way to answer > such questions in a productive man

RE: sockets vs. fds

> It's possible that this represents insight worth sharing > broadly, so I'm copying the list. > > It isn't immediately obvious to me why file descriptors would > have had a major impact, so can you elaborate? Down at the end of this page

RE: How I deal with (false positive) IP-address blacklists...

> Second, the fact that 10 years ago you set up sendmail for > the computer club at your college doesn't make you an expert > on modern large scale email systemms administration. The > operational concerns for large-scale email setups today are > very different from thost that would have applie

RE: How I deal with (false positive) IP-address blacklists...

> Maybe it's just me, but I'll take the evidence presented by > someone who has access to the operational statistics for a > mail system that services 10s of millions of end users and > handles thousands of outsourced email setups over someone > like myself who runs a tiny little setup any da

RE: How I deal with (false positive) IP-address blacklists...

> > Why should > > it not be as simple to set up an IETF standard email system for a > > small organization as it was 10 years ago? > > > If you go back far enough, New York City was small and > friendly. Not much required to build a satisfactory home there. > > Things have changed. No

RE: How I deal with (false positive) IP-address blacklists...

> Schemes that attempt to assess the desirability of the email > to the recipient have been tried - personal whitelists, > personal Bayesian filters, etc. etc. In practice they haven't > worked all that well, perhaps due to the average user's > inability to capably and consistently perform such

RE: The internet architecture

> Yes, of course. There are lots of ugly things that can > happen. You don't have to go very far to run into why. The > question is why have we insisted on not doing it right for so long? Perhaps because others were working on the problems of application communication without IP addresses. AM

RE: NATs as firewalls

> (2) NATs provide a huge advantage for customer support > organizations of ISPs supporting such lower-end (in terms of > financial returns, at least) connections. With a standardized > NAT setup, the setups of all of their customers are pretty much > the same, including the address ranges used by

RE: NATs as firewalls

> > No real disagreement here but I do see a way forward. > First, clarify the > > terminology. Second publish a pair of RFCs rather like 1009 entitled > > "Requirements for Consumer Internet Gateways" and "Requirements for > > Enterprise Internet Gateways". > > Are you aware of RFC 4084 "Termin

RE: NATs as firewalls

> How do we establish the political coalition necessary to act? 1. Form a political coalition. 2. Get an existing coalition such as MAAWG to take on the work. 3. Get the USISPA to take on the work http://www.usispa.org/ 4. Get the USIIA to take on the work http://www.usiia.org/ 5. Get the USISPA,

RE: References to prior work (was: Re: Last call comments aboutdraft-housley-tls-authz-extns-07)

> > Fully disagree. A reference to a dead document that the > > reader cannot find directly provides no histor nor context. > > Many of the most important events in history are only known > through second hand accounts. Some RFC authors provide an ACKNOWLEDGEMENTS section in which they acknowl

RE: NATs as firewalls

> is a crisis to force action. That will occur sometime after > 2010 when they need more than they already have and find that > the lease price per IPv4 address per day has been moving up > from its current averages of $1/day or $5/day depending on > contract length (a price service providers s

RE: NATs as firewalls

> (i) there is every reason to expect a run on remaining > addresses at some point, whether induced by "public > coverage", "larcenous providers", ISP or RIR anxieties, > or something else. In other words HIGH PUBLIC PROFILE. Interestingly, this roughly coincides with incr

RE: NATs as firewalls

> IPv6 is not inevitable, the issue is how to make it so. Yes, and I believe that the way to make it so is to define the standard for connecting to the IPv6 Internet. That standard should NOT be to connect a computer via dialup modem or to connect a computer via its USB port. Instead, it should b

RE: Prague

> For those of you with experience in Prague/Czech Republic- > How practical is it to rent a car? > There are a couple of places outside Prague I would like to visit on the > weekend (in particular the JAWA Motorcycle Museum of Konopiště, about 20 > miles outside Prague), and I am consid

RE: NATs as firewalls

> > Can you show me real examples of an RIR repossessing > address space? If > > so, what is stopping them from reclaiming some of those /8s? > > The legal costs... While ARIN would have one hell of a court > battle trying > to reclaim 18/8, the MIT Office of the President would have no trouble

RE: NATs as firewalls

> Also this appears to be tied to the US business model where the ISP > supplies you with the box and you don't get to change it (or > even own it). > For example in the UK we are already down the path of selling > such a DSL > + NAT/fireewall + router box (I have one here) but the ISP > just

RE: DNS role (RE: NATs as firewalls, cryptography, and curbing DDoS threats.)

> One approach for "name" based authorization would place an encoded > hash label of the domain name being authorized within the > authorizing > domain. Client validation can be as simple as resolving the name of > the client, where this name can then be utilized in conjunction with > a

RE: NATs as firewalls

> Can you show me real examples of an RIR repossessing address > space? If > so, what is stopping them from reclaiming some of those /8s? ARIN regularly repossesses address space according to their treasurer. http://lists.arin.net/pipermail/ppml/2007-March/006129.html This fact is well known

RE: NATs as firewalls

> Recovering three-quarters of an /8 delays the moment of truth by less > than a month. Work hard and you might gain a year or even more, but > would that year really make a difference? And that is why there will never be a market for IPv4 addresses. Any trading activity can only ever buy a few

RE: Game theory and IPv4 to IPv6

> An actor can be in one of several states: You rigged the list of states. There is more than one possible state that include IPv6 connected as the baseline. For instance, IPv6 connected with access to 6/4 web proxy and 6/4 smtp forwarder. There are other possibilities. Consider a large communit

RE: Pingsta Invitation

> Hence, for myself, I think I see no reason for me to join, and no > reason for any of us to. If you read the terms there is a good reason why EVERYONE associated with the IETF should NOT join Pingsta. I quote: -- Proprietary Rights You agree that all content and materials delive

RE: Remote participation (re: identifying yourself at the mic)

> > Perhaps Sun would like to volunteer its system for an experiment? > > It isn't ours. As best I can tell we use some high-end conference > bridging + AT&T concall services along with traditional room > PA systems. Is there something wrong with implementing some IETF technology at an IETF mee

Can the RIRs bypass the IETF and do their own thing?

> If the draft RFC was resurrected > Would you still think this was an end-run on the RIR process? > > Would you be in support of the draft moving forward? Seems to me that if the draft is not resurrected, there are no ULA addresses for ARIN or RIPE to register, regardless of anything that ARIN

RE: [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing?

> > The US DoC has as much say for ARIN as it does for the RIPE NCC. > > The US DoC, through IANA functions, says, e.g., what IP Address blocks > each can allocate. That seems to qualify as 'much say' So it seems that you and Ray are in agreement. All the other details are not terribly relevant

RE: [ppml] [address-policy-wg] Those pesky ULAs again

> That's broken. As it has been stated in previous messages > some days ago, RIR communities can do whatever they want, > especially if IETF fails. That may be true but since the IETF is not failing, there is no reason for the RIRs to take over any IETF functions. > I'm doing IETF work, but i

RE: IANA registration constraints (was: Re: Withdrawingsponsorship...)

> We would at last have a mechanism to trump the usual claim > that an internet draft has been submitted so please consider > me as good as being a standard. ULA-C was in a draft that has expired and was in fact specifically dropped by the WG that produced the ULA RFC. Nevertheless, at least on

RE: Domain Centric Administration, RE: draft-ietf-v6ops-natpt-to-historic-00.txt

> > They are saying that NAT is not > > a appropriate for solution in a IPv6 world. It adds a lot > > more complexity than just a stateful firewall. > > A stateful firewall doesn't also provides provider > independence and an ability to have a form of multi-homing > without play

RE: Domain Centric Administration, RE: draft-ietf-v6ops-natpt-to-historic-00.txt

> > This is the time when everyone should be running dual stack. > > So, what lesson(s) ought the IETF to take away from the fact > that people aren't? That MPLS with 6PE is a superior migration scenario. Or perhaps, that defining migration scenarios without the full involvement of network

RE: Domain Centric Administration, RE: draft-ietf-v6ops-natpt-to-historic-00.txt

> > That MPLS with 6PE is a superior migration scenario. > > > Or perhaps, that defining migration scenarios without the full > >involvement of network operations people is an exercise in futility. > If the lesson we have learned is that the only practical way > to handle and route IP (whethe

RE: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition

> ...and the only problem I have with the above is that the > word MOST can be misleading. it's not as if most of the > problems with NATs would go away if only all NATs were to > suddenly support UPnP extensions to allow > NAT traversal. that would certainly help, but significant > brain-d

RE: chicago IETF IPv6 connectivity

> Your old one is 802.11B or G and you want G or N Your old one is IPv4 and you want IPv6. Does anybody believe that the transition to IPv6 at the edge is *NOT* going to require a complete replacement of gateway devices? Given that transitioning the Internet provider edge to IPv6 is going to res

RE: chicago IETF IPv6 connectivity

> DNS names are not a > good way to solve this problem for reasons of performance and > reliability and because a DNS name does not, in practice, > uniquely bind to a particular host. And DNS names are not in use on all Internet Protocol internetworks. This is because of the security issues of

RE: chicago IETF IPv6 connectivity

> But the entire existence of this problem stems from the > notion that the entire communication must flow over a single > path. MPLS ECMP? RFC 4928? --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf

RE: Charging I-Ds

> > IETF unique way could be to charge a fee for an address > allocation to > > RIRs. On their side RIRs would charge for assignments as > they do now > > and return a fair share back to IANA/IETF. > > A IP address use fee might help solve two problems. When based upon > relative scarcities

RE: IPv4

> If I was the isp in that situation hp has something I want and many others want. There is absolutely nothing to be achieved by threatening hp and much to be lost. Even if the threat worked the party that brought the case and paid for the costs would most likely not get the allocation anyway. Whe

RE: IPv4

> The only effect that threats from ARIN would have in this > situation is to make the situation worse. HP uses the address > space internally. Transition to a different address space > where they are behind a NAT has real costs for them. They are > only going to make the transition if they can

RE: IPv4

> As for your repeated appeals to senior management, who do you think is more likely to share our values, engineers or managers? To date, the debate has been dominated by engineering concerns. However I think the concerns of senior managers are more relevant and, in general, support the current

RE: I-D ACTION:draft-wilson-class-e-00.txt

> > >This document directs the IANA to designate the block of IPv4 > > >addresses from 240.0.0.0 to 255.255.255.255 > (240.0.0.0/4) as unicast > > >address space for limited use in large private Internets. > Some widespread IPv4 stacks refuse to handle these addresses, > so nobody wo

RE: I-D ACTION:draft-wilson-class-e-00.txt

> >> Some widespread IPv4 stacks refuse to handle these addresses, so > >> nobody would ever want to use them on the public IPv4 Internet. > >> > > > > And some widespread IPv4 stacks, refuse to handle IPv6 addresses. > > > it seems likely that more hosts currently support IPv6 than > su

RE: e2e

> Robust for what? Spammers? The simple fact of the matter is > that the alternative is to just shut down port 25 given the > growth in both volume and complexity to filter. Finally, a sensible solution! After all, why should any mail server operator accept incoming email from another server w

RE: e2e

> As both of you know and understand, the email system was > built to be an any-to-any mesh. That's not just a design > goal. Folks have operated a lot of gateways, written a lot > of 8-to-7 code, and jumped through a lot of hoops to make > sure that the network effect of email was a great as

RE: e2e

> >Is there an informational RFC that describes the overall email > >architecture that is provided by the various IETF protocols? Such a > > http://tools.ietf.org/html/draft-crocker-email-arch-09 This is nice but a draft is not an RFC. Hopefully it will progress and can then become a starting p

IPv6 addresses really are scarce after all

It seems that someone in ARIN land believes that IPv6 addresses are scarce resources that need to be carefully dribbled out to customers according to need. The following proposal has just been formally made to change ARIN's allocation policy. --start of copied text-- Replace the text in

RE: IPv6 addresses really are scarce after all

> this is silly. any site with even a single IPv4 address can > get a /48 through 6to4, and this was chosen to match the > architected minimum allocation for a native prefix. > > someone should tell ARIN that trying to mess with the address > architecture is out of their scope. And that someo

RE: IPv6 addresses really are scarce after all

> "ARIN ... belives IPv6 addresses are ... resources that need > to be [distributed] according to need." > > I guess I have to agree with this sentiment. If the ARIN > community decides there is a better way to distribute IP > addresses *OTHER THAN* need, I'd be really happy to hear what > th

RE: IPv6 addresses really are scarce after all

> In other words, a mesh of standard Ethernet bridges already > allows you to partition traffic between the segments, without > the need to do configuration of routers. (Yes, you do have to > arrange the connectivity so that voice traffic doesn't have > to go over the HD video network to get to

RE: IPv6 addresses really are scarce after all

> Could you please site chapter and verse? Here's what I can find: I quoted a formal proposal which has just been announced but which does not yet have an official proposal number in the ARIN Policy Proposal Archive. I believe this proposal met the deadline for discussion and voting at the ARIN m

RE: IPv6 addresses really are scarce after all

> I know the reasons behind the /48 etc but it just going to > cause us trouble to keep it like that, we should divide the > /48 cateogry of users into two: > - people that can get the current /48 as long as they have > more than ONE subnet > - people that only have ONE subnet, typical home-user

RE: New models for email (Re: e2e)

> My strong belief is that a proposal for a new protocol that > does the same thing as SMTP but slightly better is a total > non starter. No matter how much better the protocol is the > cost of transition will dominate. Right! It is not the protocol that is at fault, it is the architecture in

RE: e2e

> I.e., a new mail protocol will have to > address things like forwarding and mailinglists explicitly. Not protocol. A new email architecture will have to address all these things explicitly, but the protocols may indeed be usable as is, or with minor changes. The point is that we need to examin

RE: DNS as 1980s technology [was Re: The Internet 2.0 box Was: IPv6 addresses really are scarce after all]

> The IETF has a simple process for all of this: write a draft. Not true. The IETF also runs a large number of mailing lists for discussion of things both general and specific. It is not necessary to start work by writing a draft. One can also start work by discussing the problem area on one or

RE: IPv6 addresses really are scarce after all

> If I assign 4M /48's of IPv6 (one to each cable modem on my > network), according to the HD-ratio I am justified to obtain > something around a /20 of IPv6 addresses. In other words, I am > justified in getting 268M /48's even though I am only > using 4M of > them.

RE: IPv6 addresses really are scarce after all

> > I find the fact that RFC 3177 has not been revised to reflect the > > reality of today is a bit disapointing. > "reality of today" seems like an odd concept when trying to > make or revisit design decisions that will need to serve us > for decades. I keep seeing people making the same mist

RE: one example of an unintended consequence of changing the /48boundary

> 6to4 is a transition technique that I would argue is not > really appropriate for a large site (i.e, one with _many_ > subnets). I.e. one with a /48 allocation from an RIR. Therefore it would appear that 6to4 is targeted at small sites such as home users who will likely receive a /56 from the

RE: IPv6 addresses really are scarce after all

> The definition of a small network is pretty much "single > subnet". Yes, I understand very well that the average home of > the future will have a mixed wiring. Of course, my own home > does have Ethernet and Wi-Fi. In the not so distant future, > it will have several Wi-Fi networks operating

RE: IPv6 addresses really are scarce after all

> (2) The many examples you give seem to be to be associated > with different domains of authorization and privilege for > different groups of people and functions within the home. My > impression of the experience and literature in the field is > that almost every time someone tries to create

RE: one example of an unintended consequence of changing the /48boundary

> > Think back to the days when the OSI protocols were > expected to be the > > next big thing > > No doubt the savvier members of the investment community will > remember those days, and the predictions of how much money > would be made/lost by those who did/didn't invest in OSI, and

RE: IPv6 addresses really are scarce after all

> We shouldn't be surprised that a "one size fits all" approach > (where home users get the same amount of space by default as an IBM or > Microsoft) doesn't seem to make a lot of sense to some people. I think this is a wrong comparison. The intent is to give a /48 to a site where a site is eit

RE: IPv6 addresses really are scarce after all

> But the /48 boundary is not. We had a long discussion about > that in the IPv6 WG, and our specs were carefully cleansed to > make sure there were no real dependencies on such a boundary. > Think Randy Bush saying "your reinventing IPv4 classful > addressing" about a thousand times. :-) It

RE: IPv6 RIR policy [was Re: IPv6 addresses really are scarce after all]

> I'd encourage folk to read the entire IPv6 policy to get a > more complete picture. > And, for those of you worried about end users being given a > /64 (or worse), from a registry perspective, it is 100% > acceptable to give every end site a /56. That is what the > above wording means, and

RE: IPv6 RIR policy [was Re: IPv6 addresses really are scarce after all]

> 1. This is NOT ARIN's decision to make, nor that of any of > the other RIRs, because the /48 decision is not independent > of many other design decisions in IPv6. Show me the document where this is explained. I'm not disagreeing with you, I am just saying "Show me the document" because if you

RE: IPv6 RIR policy [was Re: IPv6 addresses really are scarce after all]

> A /48 per 'site' is good, especially in the case of > businesses, for home-usage though, most very likely a /56 > will be more than enough. As such IMHO having 2 sizes, one > business, one homeuser, would not be a bad compromise, > otherwise the really large ISP's, eg the ones having multiple

RE: [address-policy-wg] Re: IPv6 addresses really are scarce after all

> Will all due respect, even if you assume a "home" with ten > occupants, a few hundred subnets based on functions, and > enough sensor-type devices to estimate several thousand of > them per occupant and a few thousand more per room, 2**64 is still a > _lot_ of addresses. This is hyperbole.

RE: [Ietf-http-auth] Re: Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt)

> Hmm... I'm still not sure what you're trying to say. My point > is that there shouldn't be any consensus calls by anyone on > the ietf-http-auth mailing list. Why not? Does the IETF have a patent on IETF processes? > It's not a WG. Why not? Of course, you probably mean that any consensus c

RE: [Ietf-http-auth] Re: Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt)

> > So you also want a different word to "shepherding"? > > No. I want there not to be an implication that the > development of this document is a formal activity of the IETF. Let me give you a short lesson from IETF 101. If the name of a draft contains ietf as the second component, or the name

RE: Symptoms vs. Causes

> > and IMHO, any solution that doesn't let the user type his password > > into some Web form is a non-starter, both for reasons of backward > > compatibility and because sites (quite > > legitimately) want to provide a > > visually attractive interface to users which is consistent > across all

RE: IPv6 will never fly: ARIN continues to kill it

> > Oh man, that's rich. Do you actually believe that? > > If you design the network for IPv6 and not just copy the > IPv4 model. If you use the technology that has been developed > over the last 20 years, rather than disabling it, yes it is > possible. OK, how is it pos

RE: Symptoms vs. Causes

> > So much for typing. How about selecting password letters > from dropdown > > boxes, or from an image map with scrambled letters that was sent to > > the browser. > > Sorry, what about these? They have essentially the same > security properties as cleartext passwords. One would hope that

RE: IPv6 will never fly: ARIN continues to kill it

> > From: Tony Li <[EMAIL PROTECTED]> > > > As a practical matter, these things are quite doable. > > Tony, my sense is that the hard part is not places *within one's own > organization* where one's addresses are stored, but rather in > *other organizations*; e.g. entries in *their* fi

  1   2   >