Re: Consensus Call: draft-weil-shared-transition-space-request

> Given that this is not a last call but folks are weighing in anyhow, i > will say i oppose this allocations. +1 as has been discussed endlessly, it is technically broken, will not achieve squat, and is a waste of time. randy ___ Ietf mailing list Iet

Re: An Antitrust Policy for the IETF

imiho, the issue is a balance between participants who are educated on dangerous behavior and a bunch of rules with which the well-known and new amateur nit pickers drive us crazy. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/li

Re: Plagued by PPTX again

>>> so where is the web page that tells me for platform x how to convert >>> my generated pdf, which i have been using as the pub format for >>> years, into pdf/a? the link under "Guidelines for Creating Archival >>> Quality PDF Files" is a broken link. >> The Florida Center for Library Automation

Re: Plagued by PPTX again

> PDF/a is something browsers and natively by different OSs that can > directly display. When submitting formats that are not PDF/a, convert > and automatically link to the converted output with a prompt requesting > approval. > > http://www.digitalpreservation.gov/formats/fdd/fdd000125.shtml

Re: Adequate time to review all WG documents

which particular wg's do you plan to attend for which you are having problems understanding what you need to read? most of us have been here before randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf

Re: LISP is not a Loc-ID Separation protocol

15 30 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf

Re: IETF 82 Audio Streaming

i run a mac with firefox and the usual. when i went to access a stream, i was asked to allow an applet to own my machine. i.e. a default/simple user path led the user to very unsafe behavior. i do not give a damn what all the options might be. normal use paths should not encourage insecure beha

Re: IETF 82 Audio Streaming

> If instead you're talking about the applet, as I've explained in the > previous mail, it is not started by default and so you don't even need > to know it exists if you have your own SIP or RTSP client to access > the audio stream. my question is whether it can be disabled for the ietf streaming

Re: Fwd: Re: IETF 82 Audio Streaming

> you can skip such a fat frelling chance, if you want; just choose to > either attach to the RTSP stream, or to the landline phone bridge. >> meetecho seems to require me to let a java applet have its way with >> my machine. fat frelling chance. does the ietf really want to >> recommend such a pra

Re: IETF 82 Audio Streaming

> For general remote participation including meetecho support see: meetecho seems to require me to let a java applet have its way with my machine. fat frelling chance. does the ietf really want to recommend such a practice? randy ___ Ietf mailing list

Re: The death John McCarthy

>> First, as someone who chartered the working group, who has >> implemented Lisp (the programming language) at least four times, and >> who views Dr. McCarthy as a hero I disagree that name is problematic >> or disrespectful. And I almost take offense in the claim that this is >> a generational th

Re: Last Calls: [SOME RFCs] to HISTORIC RFCs

>> we don't have enough real work to do? > > Clean up is necessary work. Some hours ago > I tried to understand a discussion about the > "ISE" (independent stream), and gave up on > it when the maze of updates obsoleting RFCs > which updated other RFCs turned out to be > as complex as the colossa

Re: Last Calls: [SOME RFCs] to HISTORIC RFCs

we don't have enough real work to do? randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf

Re: What? This thread is talking about *voting* now?

> It's really annoying when a thread drifts to a wildly different topic > without somebody thinking to change the Subject header. > > My comments on nominees would be much less frank if I knew they > would be published. In fact, I doubt if I would make any at all. > > Here's a comment I sent in a

Re: Requirement to go to meetings

i live in tokyo and participate in three or more continent (NA, Euro, Asia) calls a number of times a week. i am currently one quarter of the way through an eight week four continent rtw (with south africa after taipei). and it ain't my first this year. boo hoo. get real here. we want global p

Re: Requirement to go to meetings

> perhaps we could model using the assumption that, a decade or so > hence, there will be no physical meetings, [almost] all will be > net-based. to make my troll more explicit (under an nsfw bridge?) o how does a 'town hall' of O(10^3) participants work socially? o how will/should incremental

Re: Requirement to go to meetings

perhaps we could model using the assumption that, a decade or so hence, there will be no physical meetings, [almost] all will be net-based. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf

Re: Anotherj RFP without IETF community input (was: Re: RFP for Remote Participation Services Specifications Development)

> One thing to consider is charging for this service i strongly agree. whoever is drafting the rfp should charge heavily for putting up with massive micromanagement. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf

Re: [IAOC] Anotherj RFP without IETF community input (was: Re: RFP for Remote Participation Services Specifications Development)

> I don't see any significant value in asking the community for input on > an RFP that is for hiring someone to write a specification to generate > community input. the problem may be that you may lack a sense of humor, an appreciation of recursion, and a vision for just how twisted ietf process c

Re: Anotherj RFP without IETF community input (was: Re: RFP for Remote Participation Services Specifications Development)

i read the message from ray as an rfp for someone to write the rfp for remote services. aside from being a very amusing bureaucratic layer cake, this would not seem to need a lot of experience with remote access, but rather good ears and a taste for the bureaucracy and discord the ietf has become.

Re: Mipshop WG draft

>>> There is a WG draft in Mipshop WG which is no longer active. >>> The draft is about to expire and we can not submit a revision because the >>> datatracker submission tool gives Meta-data error. >> if you actually want help, you may want to copy and paste the error >> report > or just email ie

Re: Mipshop WG draft

> There is a WG draft in Mipshop WG which is no longer active. > The draft is about to expire and we can not submit a revision because the > datatracker submission tool gives Meta-data error. if you actually want help, you may want to copy and paste the error report > Hi Jari, gone skiing :)

Re: Last Call (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

> This is not actually correct. The IETF has a very long history of > pushing back on multiple redundant solutions to the same problem. > There are a great many cases of ADs, working group chairs, and others > pushing quite hard to prevent multiple solutions when one would work > fine. > > In the

Re: [mpls] R: FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

> IMO it is a statement of principle going forward. As such it does not > "fix" or "make go away" the current situation, but it would be an IETF > consensus position on a way forward. And I agree with that position. > > Lots of folks do proprietary deployments, squat on code points > etc. That can

Re: [mpls] FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

the ietf, and i hope all sdos, are supposed to provide users with interoperable multi-vendor choice, not non-interoperable multi-standard incompatibility. from a sic year old broadside The IETF’s vendor/market approach has engendered a ‘let the ma

Re: [sidr] Last Call: (The RPKI Ghostbusters Record) to Proposed Standard

> The IESG has received a request from the Secure Inter-Domain Routing WG > (sidr) to consider the following document: > - 'The RPKI Ghostbusters Record' >as a Proposed Standard note that some apps-area fixes have caused me to revise to -13 randy __

Re: [Idr] Last Call: (Deprecation of the use of BGP AS_SET, AS_CONFED_SET.) to Informational RFC

> The IESG has received a request from the Inter-Domain Routing WG (idr) to > consider the following document: > - 'Deprecation of the use of BGP AS_SET, AS_CONFED_SET.' >as an Informational RFC i have read and support this document. AS-Sets are essentially unused, the deprecation is needed f

Re: [xml2rfc] Multiple authors in reference

>> above five, the rfced's deal with the iesg is that the masthead lists >> an editor and all the rest are in a Contributors or Authors section > I see. So the author limit isn't really a "guideline" (as advertised) > or even a rule, just a backroom "deal". have you taken your meds today? ___

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

i do not care what the draft is called. i do not care whether it is info, experimental, or an IEN i do care that is says 6to4 MUST be off by default randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf

Re: [v6ops] draft-ietf-v6ops-6to4-to-historic

> The pain point is really the unnecessarily aggressive "kill what we > don't like" move-to-historic action. if we killed everything i do not like, there would be lot fewer rfcs. :) what people are saying is kill it because it is broken, bad, and does a dis-service to ipv6. randy ___

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 h

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 call

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 colorfu

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. th

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 expl

Re: Review of draft-ymbk-aplusp-08

> I'm a member and also the secretary of Operations directorate. the ops dir is a joke. does reviews for an area director who does not do his/her own? there is an ops cabal that meets at ietf and has ML etc. all actual ops except for one guest, the actual ops director, ron. > http://trac.tools

Re: Review of draft-ymbk-aplusp-08

> Operations directorate and Security directorate reviews are solicited > primarily to help the area directors improve their efficiency, particularly > when preparing for IESG telechats, and allowing them to focus on documents > requiring their attention and spend less time on the trouble-free ones

Re: Comments on

> Since your goal in an exchange like this is to keep things unproductive, to > distract from the original goal you have no concept of what my goal is and have no prerogative to say so. it is mostly to try and cut through the bs, hyperbole, innuendo about network experiments which have never hap

Re: Comments on

> The assumption that simply posting a notice constitutes sufficient > "permission" to disclose data is one more example of the challenges > we face in producing reasonable policies and following them. i think you had better have a cite for where a message was posted and ietf network data were dis

Re: Comments on

Has "the IETF" been authorizing people to conduct human subjects research without the informed consent of the subjects? >> yes, we drag them into black helicopter and mess with their genitals. >> you can be the first in maastricht. > Thanks for demonstrating the type of knowledge and prof

Re: Back to authentication on the IETF network (was: Re: IETF 78: getting to/from/around Maastricht)

> What does "physically authenticate people" mean here? Show that they > have a badge (common and meets the stated requirement of "keep the > IETF network for IETF attendees")? Or write down the name? Or write > down the name and the network port for the cable they pick up? we'll probably never

Re: IETF 78: getting to/from/around Maastricht

> I would even argue that restricting everything to WPA2 and 802.11g or > better would be entirely reasonable by now. i am sure you would. the meeting net ops are responsible for seeing that as many people can get on net as possible. the object is to deliver packets not religion. to that end, a

Re: Comments on

>> Has "the IETF" been authorizing people to conduct human subjects >> research without the informed consent of the subjects? yes, we drag them into black helicopter and mess with their genitals. you can be the first in maastricht. sheesh! ___ Ietf mail

Re: Comments on

> That started when Jeff Schiller was security AD. Though I can't > remember who actually did the code. > > Though at the time the issue was no so much the carelessness of the > users as the fact that the IETF password protocols were broken. i am not confident of either of those statements randy

Re: Comments on

> Randy, we have had at least one "researcher" sniffing passwords in > plenary WiFi traffic and posting them, to embarrass people into using > more secure technology. I believe he was an Ops AD at the time :-) >> o but i am sure there are wifi spies snooping and playing. and i >>suspect that

Re: Comments on

> this privacy policy effort is not a means to put someone in the > spotlight because a mistake has been made. what an amazing turn of argument. there are communists in the state department, i have their names on this sheet of paper which i will not reveal. -- joe mcarthy as a researcher, a net

Re: Comments on

>>> And "yes" we have researchers looking into the traffic, people storing >>> all sorts of data, etc. >> >> we do? about our traffic on the ietf meeting network? stuff other than >> the _ephemeral_ data the noc ops use to manage the network? > > Yes, the IETF meeting network. cites, please.

Re: Comments on

[ fwiw, i am not bothered if some folk well-versed in such things develop and put forth a policy about how the ietf treats data about members, attendees, network, ... ] > And "yes" we have researchers looking into the traffic, people storing > all sorts of data, etc. we do? about our traffic

Re: IETF privacy policy - update

> I would have to assume it is the only forum in the world in which they > expect that level of anonymity aside from payment possibly uncloaking you, i am not aware of an ops meeting that checks id or even considers the issue interesting. randy ___ Ietf

Re: IETF privacy policy - update

> Perhaps the better question is, do some people not sign the blue > sheets because of whatever they think the current privacy policy is? or use bogus sig on blue sheet. yes. the rfid discussion pushed me over the tolerance line on this class of issues in the ietf. randy _

Re: Admission Control to the IETF 78 and IETF 79 Networks

> The issue is not that the IETF and IETF attendees are required to obey > the laws of the venue, but rather whether or not the IETF chooses to > hold a meeting in a venue where the law is sufficiently ... > restrictive, draconian, capricious, ?? ... to require the IETF to > change its model of ope

Re: Admission Control to the IETF 78 and IETF 79 Networks

the only hard issue i have heard is log access and retention. it is clear radius logs, the only logs being used (aside from landings and take-offs of black helicopters), should be destroyed at the end of the meeting. but should they be wiped more frequently? their intended use is solely for de

Re: Admission Control to the IETF 78 and IETF 79 Networks

> I do remember the guarded terminal rooms in 1995-1998. the terminals themselves were being guarded, not their use. they were expensive. now there are no terminals in the terninal room. so the name was apt. :) > The use of WLAN started out with a small group of early adopters > somewhere arou

Re: Admission Control to the IETF 78 and IETF 79 Networks

>> "It is clear to people unfamiliar with the IETF that IETF meeting >> participants means people who have registered for the IETF meeting." > ... and their accompanying persons (who can also get a slip). i see no reason to limit it to persons. what if an attendee has a dog with wifi, a wifi fifi

Re: Admission Control to the IETF 78 and IETF 79 Networks

> I'm concerned about the correlation between my MAC address and the > hosts I communicate with. and how and why would you suggest that be logged? i am not aware radius does that. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/l

Re: [75attendees] IETF74 T-Shirt Art Donated to IETF Trust

> Personally, I'd just put it up on CafePress, direct the revenue stream > back to the IETF, and see what happens. Anything cleverer than that > seems like a waste of effort to me. while i am extremely sympathetic to the economic and social aspects of this approach, a serious aspect of the qua

Re: [74attendees] [75attendees] IETF74 T-Shirt Art Donated to IETF Trust

>> now we know where the ipr is. and we have lengthy discussion of who, >> how, why, and black helicopters. > Can we GPL/CCL the artwork? Or would this mean that I have > to give a t-shirt to anyone who asks where I got mine? ;^) cc or bsd license can avoid that problem but, if i remember ari

Re: [75attendees] IETF74 T-Shirt Art Donated to IETF Trust

> Juniper has donated the art for the highly popular IETF74 San > Francisco T-shirt (brown, IPv6 World Tour, "concert" concept) to the > IETF Trust. cool. and thanks. now we know where the ipr is. and we have lengthy discussion of who, how, why, and black helicopters. but, months later, wh

Re: [73attendees] Is USA qualified for 2.3ofdraft-palet-ietf-meeting-venue-selection-criteria?

Melinda Shore wrote: > Is the issue the visa requirement itself or is it how visas are > processed? from my pov, the latter. is it easy for folk from all countries to get to the ietf meetings? for example, that chinese have problems getting to this meeting is a major and embarrassing disaster.

Re: [73attendees] Is USA qualified for 2.3ofdraft-palet-ietf-meeting-venue-selection-criteria?

> How would you solve the problem? hold the meetings in non-terrorist countries. i.e. not the united states. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf

Re: [73attendees] Is USA qualified for 2.3ofdraft-palet-ietf-meeting-venue-selection-criteria?

[EMAIL PROTECTED] wrote: > I believe our US government would like to grant visas to as many > people as they can. However, if anyone wants to attend a meeting in > the US is granted a visa to come here, then I can imagine there will > be 100 million visa applications for the IETF meeting in CA next

Re: [58crew] RE: IETF58 - Network Status

>> basic lessons previously learned were not put to use here, e.g., lowering >> the radios so wetware limits range and reduces xmtrs bandwidth fight. > Right. Like this really works. This just ensures that the folks in the > middle of the room will get really bad performance. Been there. the oppos

RE: IETF58 - Network Status

basic lessons previously learned were not put to use here, e.g., lowering the radios so wetware limits range and reduces xmtrs bandwidth fight. randy

Re: IETF58 - Network Status

> Note that getting 802.11a works even better. until everybody does, and 'everbody' is twice as many people as now

Re: fun with base stations...

> Right now, I'm hearing (from where I'm sitting) eight different 802.11b > base stations on channel 6. Is this the intended configuration? it is not an accident. it is not the production plan. but they are not charging extra for it at the moment. :-)

Re: Fw: Review of proposal: Education team

>> what is a "team?" how are they chartered, reviewed, ...? who can join? >> what are the rules for their process? > see also: "design team" and/or "directorate" there are written answers to those questions for your examples. there are not for this 'educational team.' randy

Re: Fw: Review of proposal: Education team

> The IESG is considering creation of a formalized "education team" to manage > the IETF education efforts, which have so far been managed informally. > This is a new type of entity in the IETF, and community feedback is > therefore sought both on the specific charter and on the concept of having >

Re: Multiple Address Service for Transport (MAST)

> From: Dave Crocker <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > The multi6 mailing list is probably the most appropriate venue for > discussing this proposal, so it is the only address showing in the TO > field. However, I have blind cc'd additional lists, for

literature review [ was: blah blah blah ]

> literature review (prior art?) research as bernard pointed out a while ago, the lack of a review of, and reference to, the [should be] known literature is notable in many classes of ietf work and an embarrassing number of internet drafts. randy

Re: You Might Be An Anti-Spam Kook If ...

> 7) Discover that wood makes OK bridges too, make lots of notes about > strength, insect prevention, and the like. Publish the Second Edition. > > 8) Discover metal. Make notes about fatigue and rust. Publish Third > Edition. many years ago, i saw, in the uk midlands, a (large outdoor) museum

Re: You Might Be An Anti-Spam Kook If ...

> Ok, I'll stop feeding the troll now. troll? what troll? procmail is your friend. randy

[no subject]

> have we completely deprecated 's for A6's or is still considered > bcp? we're keeping them both as we have moved ipv4 to experimental

RE: VoIP regulation... Japan versus USA approaches (RE: Masataka Ohta, Simon)

> No, on the contrary. For example, if it hadn't been for proactive > regulatory intervention in local loop unbundling in Korea and > Japan and many other regulatory measures, there wouldn't be such > a dynamic broadband market in those countries nor would one see > so much growth in VOIP services.

Re: Solving the right problems ...

> IETF picks some pretty nice places to meet. you betcha! this year you can come to minneapolis in november, a major change as we have been meeting there in march. the hamster tunnels are a scenic marvel to keep in one's scrap- book forever. and you can have walleye cooked many ways, as long as

RE: AW: www.ietf.org.

>> v6 has one salient feature, more address space. religious >> selling does not help the case for v6. > I don't think making a server accessable over IPv6 is religious selling. > Some might even consider it 'running code', ... or don't we believe in that > anymore? with the current size of th

Re: AW: www.ietf.org.

> unless there is a reason why that host should not be using v6 > services, hmm? because it works now? v6 has one salient feature, more address space. religious selling does not help the case for v6. make it work simply and directly, not through 42 hacks. get router, dsl, ... vendors to suppor

Re: AW: www.ietf.org.

> i get an unknown host with ping6 www.ietf.org try ping

Re: Korean cell phones

>> - GSM is very limited, if at all existent (I found one network listed >> as >> "planned for Sept 2003") > > I was in Seoul a few weeks ago and my tri-band GSM handset couldn't > find any network. There may be GSM coverage somewhere, but it certainly > doesn't make itself easy to find. >

help wanted

we need a few good wg chairs. expertise in one of v6, radius, or wireless necessary. experience with operations and ietf process are major plusses. ability to catch me in corridors is also a plus :-) randy

Re: in-addr.arpa missing

> If you think that is strange I got 81.160.251.0 just now given the netmask, that is a perfectly legitimate interface address randy

in-addr.arpa missing

i received 81.160.221.53 via dhcp. but Host 53.221.160.81.in-addr.arpa not found: 3(NXDOMAIN) randy

Re: re the plenary discussion on partial checksums

>> Why, oh WHY would I want to receive a known corrupted packet ? > why oh why would you ever want to talk with someone over a phone that > occasionally clicked or popped? and why would i mind cheese with holes in it? i don't care about cheese or voice phones. i care about internet data packets.

Re: Multicast Last Mile BOF report

let's get real here. though we have been pushing it since i was in nappies (and i have deployed it in isp(s), and i also donate to hopeless progressive causes), there is far more email traffic about multicast than there is actual multicast traffic on the WAN internet (yes, it is heavily used on a

Re: Multicast Last Mile BOF report

>> and 500 gadgets do not make a technology adopted when it has no >> business model folk can understand. > one business model that might be understandable is: you should support > multicast if/when it saves you enough bandwidth (over the same content > being sent over separate unicast streams) to

Re: Multicast Last Mile BOF report

>> there is a serious contest to see how many mechanisms multicast >> and v6 can develop to overcome why they are not being deployed. >> they should get a clue. > Look at how many mechanisms NAT required before it was deployable. there was demand for nat. > Ease of deployment != good and 500 gad

Re: Multicast Last Mile BOF report

> The problem being tackled isn't completely clearly defined, but the > general philopshy is that multicast is not being deployed because most > potential receivers are using ISPs that don't supply multicast > service. The proposal is that we need some form of auto-tunnelling > protocol which woul

Re: First Timers

> We will be attending the 57th IETF meeting to be held in Vienna and this > will be ours first IETF Meeting. Is there any dress code which is followed > out there? yes, clothes are pretty universally expected to be worn. randy

Re: The requirements cycle (Re: WG review: Layer 2 Virtual....)

> L2VPN is not progress. It's the opposite. users do want ways to bridge a layer two lan across the internet. and this seems a legitimate desire that should be doable without breaking anything. of course, this will drift into areas where we know large l2 networks have problems. but, if properly

RE: WG review: Layer 2 Virtual Private Networks (l2vpn)

> "We're doing it" is a statement of fact. However, we've been > doing it for over two years. Pseudo-wire work has been ongoing > for over 4 years. MPLS has been ongoing since 1996 or > thereabouts. no disagreement. the question i am hearing is not why is this being done, but rather why is the

Re: full list for moderated list (was: CLOSE ASRG NOW IT HAS FAILED)

a look at the paper post i receive every day would lead me to believe that an archive that includes unsolicited commercial post would be on the order of ten times as large as that for legitimate post. why will the internet email be any less polluted? and you want folk to archive the ? so the sea

Re: US Defense Department formally adopts IPv6

hyperbole alert! > Vendors must be compliant by Oct 1 > http://www.washingtonpost.com/wp-dyn/articles/A8-2003Jun13.html?nav=hptoc_tn that's not what is says at all. what is says is "The evolution toward the new standard must be taken into account for all purchases starting Oct. 1" which, i

Re: Answering questions and defamation (was: RE: Theutilitiy of IP is at stake here)

> From: John C Klensin <[EMAIL PROTECTED]> > To: Dean Anderson <[EMAIL PROTECTED]> john, don't you have a mail filter? randy

Re: Thinking differently about the site local problem (was: RE:site local addresses (was Re: Fw: Welcome to the InterNAT...))

> of course it is possible to write apps that do not use DNS, but this is > rarely done. why not just embed the ip addresses in the data payloads? death to nats! :-)

Re: Thinking differently

> During this discussion I've seen references to the "69/8 debacle". > Can anybody explain what the debacle is/was? Is this a magic phrase > for real insiders? Is is something that happened only on a local > net? If not, why don't you explain to the rest of the world? What > IS the argument hinted

Re: Tutorials

> Since they would be taught by IETF engineers, probably for > not all that much money, it seems a bit onerous to ask the > benefactors to do more travel so that they carry out a difficult > task mostly for the benefit of the IETF. > ... charlie, you're talking to someone who has spent a considera

Re: Barrel-bottom scraping

> I think that ISOC/IETF tutorials could be a very good idea. It would at > least give us the opportunity to brain-wash others for the things which > we believe. yup. but, as one would want them done by the well clued and best speakers, it would be nice if they were not too close to ietf meeting

Re: Fwd: Re: Financial state of the IETF - to be presented Wednesday

> I second Margaret Wasserman's suggestion that the 2003 budget information > should be made public. i doubt anyone disagrees. but i am not sure fortec has one. now that we actually have back numbers, forward management seems a good, though not novel, idea. randy

Re: Fwd: Re: Financial state of the IETF - to be presented Wednesday

> Everyone bring a baked good to Vienna... and send coals to newcastle

reverse

rip.psg.com:/usr/home/randy> host 130.129.132.249 Host 249.132.129.130.in-addr.arpa not found: 2(SERVFAIL)

Re: IETF: v6 works, v4 is broken

> (DHCP servers are probably dying quite frequently..) windoze?

<    1   2   3   4   5   >