Re: Bake-off as trademark
Date: Mon, 06 Nov 2000 15:14:45 -0500 From: "Henning G. Schulzrinne" [EMAIL PROTECTED] Subject: Bake-off as trademark I've been approached regarding the use of the (claimed-to-be) trademarked term bake-off. It would be helpful if somebody can provide credible evidence that this term has been used within the technical community for many years. (In case you didn't know, http://www.bakeoff.com/ shows the non-technical use) RFC 1025, "TCP and IP Bake Off", J. Postel, September 1987. -tjs
Re: Suggestion
Keith Moore wrote: Why cannot IETF arrange Netmeeting sessions. the last thing we need is more pro-Microsoft bias in this community. I hope that this sentiment won't distract us from what I hope are more important objectives, one of which presumably is to effectively communicate with our audience. I don't know whether NetMeeting is the right answer. But, I am pretty sure the question ought to be "How can we more effectively communicate our message?", not "How can we avoid using Microsoft products?" (Awaiting a modest proposal to outlaw PowerPoint at IETF meetings...) -tjs
Re: An Internet Draft as reference material
From: Keith Moore [EMAIL PROTECTED] Subject: Re: An Internet Draft as reference material Date: Mon, 25 Sep 2000 18:34:54 -0400 To the contrary, I believe that you granted broad permissions when you submitted a document as an Internet Draft. a. not everybody uses the "anything goes" form of the boilerplate, nor are they required to do so. b. some internet drafts predate that boilerplate From RFC 2026: 10.3.1. All Contributions By submission of a contribution, each person actually submitting the contribution is deemed to agree to the following terms and conditions... From RFC 1602: 5.4.1. All Contributions By submission of a contribution to ISOC, and in consideration of possible dissemination of the contribution to the Internet community, a contributor is deemed to agree to the following terms and conditions: ... I believe that the requirement that authors include the boilerplate was added fairly recently in response to some authors submitting documents that explicitly stated that the author was not granting the rights specified in RFC 1602 and RFC 2026. I understand that only specific exceptions to this grant of rights are currently permitted, to avoid each author creating their own exceptions (e.g., "My document can't be distributed on Tuesdays"). (The current discussion _may_ raise the issue of whether any exceptions to these grants of rights should be permitted.) This grant of rights has been in effect since April 1, 1994. I understand that the function of the boilerplate is to reduce quibbling by requiring the author to make this grant of rights explicit. Yes, some Internet Drafts pre-date April 1, 1994, and I assume their status is less clear. -tjs
Re: An Internet Draft as reference material
Date: Mon, 25 Sep 2000 09:56:02 -0700 From: Joe Touch [EMAIL PROTECTED] Subject: Re: An Internet Draft as reference material [...] PS - is no one else alarmed by the re-publishing of material submitted under an explicit agreement for 'removal after 6 mos'? I know _I_ have not been asked for such permission. To the contrary, I believe that you granted broad permissions when you submitted a document as an Internet Draft. For example, in draft-touch-ipsec-vpn-00.txt you write: [...] This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except for the right to produce derivative works. [...] From RFC 2026, Section 10.3.1. All Contributions: l. ... However, to the extent that the submission is or may be subject to copyright, the contributor, the organization he represents (if any) and the owners of any proprietary rights in the contribution, grant an unlimited perpetual, non-exclusive, royalty-free, world-wide right and license to the ISOC and the IETF under any copyrights in the contribution. This license includes the right to copy, publish and distribute the contribution in any way, and to prepare derivative works that are based on or incorporate all or part of the contribution, the license to such derivative works to be of the same scope as the license of the original contribution. On a bad day, I might be inclined to ask: Am I the only one concerned about authors "forgetting" that they have granted broad rights to the ISOC and IETF? -tjs
Re: An Internet Draft as reference material
Date: Fri, 22 Sep 2000 14:22:33 -0400
From: Stephen Kent [EMAIL PROTECTED]
Subject: Re: An Internet Draft as reference material
I want to second Bob Braden's pithy observation re I-Ds. If they
make it through the process and become RFCs (including informational
RFCs) then they clearly merit retention and they achieve it, since
RFcs are archival.
See for example RFC 2549, "IP over Avian Carriers with Quality of Service".
I don't know if this was ever an Internet Draft, but it did make it
through the process.
However, many I-Ds do not make it through the
process and to archive them may seem to elevate them to a status that
they have not merited. ...
I don't think that quality (whatever that is in this context) is necessarily
a monotonically increasing function within the working group and Internet
Draft process. A number of good ideas (documented in Internet Drafts) have
been dropped because of programmer whine ("That's not what I implemented",
"It's too hard", "It will take too long", ...), rather than lack of
obvious "quality". Not all Internet Drafts that never became RFCs were
bad ideas -- some of them are good ideas that, for any number of reasons,
never made it through the process.
I think the cure (destroying old documents) is probably worse than the
problem (people referencing obviously draft or unofficial documents).
-tjs
Re: getting IPv6 space without ARIN (Re: PAT )
To: [EMAIL PROTECTED] (Sean Doran) Subject: Re: getting IPv6 space without ARIN (Re: PAT ) Date: Thu, 17 Aug 2000 15:09:48 -0400 From: Thomas Narten [EMAIL PROTECTED] Sean, Spamming the ietf list is bad form. Trolling is no more appropriate. Please take this elsewhere. [...] Sean does have a habit of asking questions that highlight the fact that IPv6 isn't ready for wide-spread production deployment. I understand that you might you might not want to be reminded of this situation, but I believe that your response (particularly as an IETF area director) is inappropriate. A more appropriate response might be to aggressively promote IPv4/IPv6 migration at IETF meetings. You might: o Coordinate an IPv6 migration help desk at the IETF that will help attendees upgrade their laptops to run IPv6, o Run IPv6 (only) on the desktop machines at the IETF, o Publish traffic statistics that compare the volume of IPv4 versus IPv6 usage at the IETF meetings, o Set an objective for when the IPv6 traffic is at least as great as IPv4 traffic at IETF meetings, and o Set an objective for when IETF meetings will support only IPv6. If you can point me to a production-quality Windows 98 IPv6 stack, I would be happy to try to install it on my laptop, and maybe even run it at the next IETF meeting and help you with your migration project. (Oh, and make sure wireless works.) Of course, I have been accused of being a counter-revolutionary for making these sorts of suggestions... -tjs
Re: more on IPv6 address space exhaustion
Subject: Re: more on IPv6 address space exhaustion Date: Mon, 14 Aug 2000 22:41:40 +0200 (CEST) From: [EMAIL PROTECTED] (Sean Doran) [...] Incidentally, this sort of thing reveals to me the stark horror of NAT in an IPv6 Internet -- a misfiring rewrite rule could expose innocent children to shocking content their parents may not be equipped to explain. I assume this scenario will be dutifully added to all of the "Why NATs are Evil" documents. -tjs
RE: Complaint to Dept of Commerce on abuse of users by ICANN
From: "Steve Doty" [EMAIL PROTECTED] Subject: RE: Complaint to Dept of Commerce on abuse of users by ICANN Date: Thu, 3 Aug 2000 08:48:55 -0700 Well the real question her his do any of us that are complaining have corp. sponsors? If we do not have that Million dollar sponsorship then We can not do nothing. We are just specks on the icanns ass. An alternative explanation is that the "complainers" don't have sponsors because their ideas (complaints) haven't been interesting for anyone to fund them. -tjs
Re: Email Privacy eating software
Date: Fri, 14 Jul 2000 16:13:35 +0200 (CEST) From: Steven Cotton [EMAIL PROTECTED] Subject: Re: Email Privacy eating software On Fri, 14 Jul 2000, Steven M. Bellovin wrote: That, in turn, would likely require monitoring of the RADIUS traffic, which (if it were different from release to release) might have forced the downgrade. RADIUS logfiles provide lots of interesting information. They'll know your dial-up habits, phone number, length of time connected etc. The FBI should just start their own ISP. How do you know "they" (whoever "they" might be) haven't? -tjs
Re: The Non-IETF Informational RFC Publication Fiction
Date: 27 Jun 2000 16:38:48 - From: Mohsen BANAN-Public [EMAIL PROTECTED] Subject: Re: The Non-IETF Informational RFC Publication Fiction [...] I believe I also played a significant role in establishing the RFC Editor's independence based on my insistence on doing it by the book. [...] And, Al Gore is the father of the Internet... -tjs
Re: HTML email
Date: Fri, 19 May 2000 13:51:35 +1000 (EST) From: Bruce Campbell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: HTML email [...] tytso I wonder how many people are still using plain-text, tytso non-HTML enabled mail readers? ... Just a quick survey on the last 513 messages seen in the IETF list, based on X-Mailer header: [...] Most of these do natively understand HTML email to a certain extent, or can be configured to pass HTML email to an outside viewer, and a small number send HTML email by default (based on personal experience). I don't If I count correctly, your list contains 284 samples. I suspect that a good number of the remaining 229 mail messages were created by older mailers that don't generate an X-Mailer header. I assume this message doesn't contain an "X-Mailer: Berkeley Mail forever" header. (Ok, ok. I have been known to use vi as my HTML editor, too...) -tjs And, from NANOG (I deleted most of the headers, but I didn't see an X-Mailer:): From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please Format Your Posts Date: Sat, 13 May 2000 22:13:09 -0700 I know that I am old curmudgeonly now, but surely I cannot be the only NANOG person who uses UCB Mail on occasion? Or is it a lost cause to expect people to be concerned about the number of characters on a line, when they are arguing that we shouldn't worry about the number of globally-known routing prefixes? Sean. (who could buy a fancy email system, but doesn't want one at home and who could buy a big-iron router, but doesn't want one at home)
RE: VIRUS WARNING
From: "Michael B. Bellopede" [EMAIL PROTECTED] Subject: RE: VIRUS WARNING Date: Mon, 8 May 2000 09:27:14 -0400 It should be pretty obvious that the only reason that viruses are so prolific on MS platforms, is that so many people are using them Hardly. Compare the apparent security considerations in the design of Microsoft Outlook and Word (execute pretty much anything with few limitations on the effects the executing code can have on the hosting system) with those of Java and the Java virtual machine (provide a sandbox in which the code executes and provide mechanisms (e.g., the SecurityManager) that control the effects of the code executing in the sandbox can have on the broader environment). It should be pretty obvious that security is a greater design consideration for some systems than for others. -tjs
Re: VIRUS WARNING
Date: Sun, 7 May 2000 17:55:19 +0200 To: IETF general mailing list [EMAIL PROTECTED] From: Jacob Palme [EMAIL PROTECTED] Subject: Re: VIRUS WARNING [...] I have set my MS Office programs to always ask me before running a macro in an unkown file in it. The advantage is less risk for viruses, but the disadvantage is that I have to OK those questions from MS Office of whether to accept macros. And if they occur too open, there is a risk that I click "yes" before thinking through the risk of doing this. [...] Other disadvantages include: o You have very little basis upon which to make a decision. You can decide based upon whether you trust the sender (which isn't much to go on, as shown by the recent batch of Outlook viruses), but you can't decide based on whether the macro might damage your system. o Once you click "yes", there is apparently little limit to the damage that the macro can do, (if it isn't executing in a well- constructed sandbox). -tjs
Privacy and IETF Document Access
I recently noticed that ftp.ietf.org requires the use of an e-mail address (well, ok, something that looks like an e-mail address) as a password for anonymous login. (see sample below) I suggest that: o The IETF, consistent with its traditional concern about network privacy, disable this feature and allow anonymous access to documents without requiring an e-mail-like password, o Explain why e-mail addresses are being collected from anonymous ftp users, and o Explain who has had access to the list of e-mail addresses. -tjs [Geez. This is the organization that (appropriately) declined to standardize wiretapping solutions, but collects information about everyone who accesses its documents???] % ftp ftp.ietf.org Connected to www2.ietf.org. 220 www2 NcFTPd Server (licensed copy) ready. Name (ftp.ietf.org:salo): anonymous 331 Guest login ok, send your complete e-mail address as password. Password: 530-You must supply a valid email address as your password. 530-For example, "[EMAIL PROTECTED]" is okay. 530 Login failed. ftp: Login failed. Remote system type is UNIX. Using binary mode to transfer files. ftp ls 550 Login first, then I might let you do that. 421 Disconnecting you since you didn't login successfully within 15 seconds. ftp
Telemetry Protocols?
Has the IETF ever undertaken any work related to telemetry or wireless telemetry protocols? (Or, is some even underway that I don't know about?) Is this an activity better suited for some other organization, (even if these sorts of things use IP)? I suppose Automatic Vehicle Location (AVL) protocols could fall in this category, as well, (something that looks like it will become Internet- related pretty quickly). -tjs
