One other item:
Neither this, nor many NAT I-D's, address the particular
issue of sourcing IP addresses not assigned or owned by
the host/gateway, e.g., as they affect the standards
of RFCs 1122, 1123, and 1812.
If a device creates (rewrites) IP source
Peter Deutsch wrote:
g'day,
"Michael B. Bellopede" wrote:
...
Regardless of what occurs at higher layers, there is still the problem of
changing the source address in an IP packet which occurs at the network(IP)
layer.
The Content Services Business Unit of Cisco (Fair Disclosure
"BookIII, Robert" wrote:
Joe,
Am I to presume by your statement that you are of the mind that the
time for considering whether vs. which has already come and gone? Is there
anyone on this list who thinks that?
With respect to 'inside the WG', yes, the assumption has been (to me)
...
Joining that mailing list would not be useful, prudent, or honest for
people with sentiments like mine. Moving the question of the wisdom of
such proxies to WREC would be equivalent to moving the question of the
wisdom of wiretapping to the wiretapping working group. At best the
FWIW, there _was_ discussion in WREC of the hazards of transparent web
caching. I dug up an old e-mail, describing the hazards of transparent
web caching which I summarized at the time, when WREC was forming.
A copy of the note, admittedly very rough (just an outline, and a very
rough one at
At 12:02 PM 4/18/00 -0400, Michael B. Bellopede wrote:
Virtual Private Network (VPN) and a Virtual LAN (VLAN) are two unrelated
terms.
VPN deals with security and connecting nodes in a private network across a
public IP internetwork. Read RFC 1853 - IP Tunneling.
1853 is informational.
Daniel Senie wrote:
Ian King wrote:
From the reports I read, this was implemented by mapping phone numbers
to some other tag (which the user doesn't see) which is used to get the
calls to the proper carrier and ultimately to the proper user.
Sounds a whole lot like using DNS to map
Anthony Atkielski wrote:
Exactly ... but that's the magic of the variable address scheme. You only
have to allocate disparate chunks in a fixed address scheme because the size
of each chunk is limited by the length of an address field. But if the
address field is variable, you can make
Anthony Atkielski wrote:
I agree! Why create a finite anything when an infinite
possibility exists?
Exactly. If you designed an open-ended protocol, you're far less likely to
ever have to rewrite it.
PS - that's what we have version numbers for.
Open-ended can sometimes mean "you
[EMAIL PROTECTED] wrote:
On Tue, 30 May 2000 23:33:13 EDT, Garreth Jeremiah said:
Excuse me if this is answering the wron question here, but.
This is just cycling through the clients "DNS Suffix search order", which is
clearly set to: dept.other.edu
Not necessarily. Resolvers also
Harald Tveit Alvestrand wrote:
At 09:22 31.05.2000 -0700, Joe Touch wrote:
It may be useful to distinguish resolver behavior from browser behavior.
If the host has no more specific (explicit) resolver information,
the current fully-qualified hostname, minus the first component
John C Klensin wrote:
--On Friday, June 02, 2000 10:56 AM -0700 Joe Touch
[EMAIL PROTECTED] wrote:
The use of the trailing dot (www.netscape.com.) remains
a useful way to force the resolver to avoid suffix extensions.
And a useful way to induce massive confusion, since many
Brian E Carpenter wrote:
Lloyd,
Just to review the actual facts one more time:
The IAB is responsible for the RFC-Editor function under its charter, RFC 2850.
At the IAB's request, the ISOC sub-contracted the RFC-Editor function to ISI.
At the IETF's request (RFC 2026), the ISOC
"Theodore Y. Ts'o" wrote:
Date: Thu, 29 Jun 2000 13:22:32 -0400
From: RJ Atkinson [EMAIL PROTECTED]
Actually, IETF has made IEEE 802.11-DSSS the convention for wireless
LANs at all IETF meetings for some time now. This has been supported
at least at Oslo, DC, Adelaide,
RJ Atkinson wrote:
At 16:15 29/06/00 , Joe Touch wrote:
DS appears to be better for large, flat spaces (largely 2-dimensional,
under 3 stories tall, since transcievers on the middle floor largely
cover the upper and lower).
FH is better for more spherical spaces (largely 3
Vernon Schryver wrote:
think we mean having unincumbered availability of the common application
protocols, email, http, ftp, ssh, ...
that's not quite enough; in the UK we're seeing cable-modem ISPs
attempt to restrict services to those applications, or to a subset of
Vernon Schryver wrote:
From: Joe Touch [EMAIL PROTECTED]
...
would pacbell filtering all multicast at all CPE equipemt fall into your
bucket, where do you draw the line?
At IP, as Bob Braden said.
SMTP is _over_ IP.
Multicast _redefines_ IP (or portions
TSIGARIDAS PANAGIOTIS wrote:
I found this definition in the INTEROP Book of Carl Malamud.
The Internet (note the uppercase "I') is a network infrastructure that
supports reasearch, engineering, education, and commercial services.
The word internet (with a lowercase "i") refers to any
Pete Loshin wrote:
The last RFC I looked at, RFC 2917, has two (of four) references to
"work in progress". No, they don't reference specific I-Ds, but we all
know that "work in progress" is a code word for "some Internet-Draft"
and we all probably have no serious problem tracking down
Tim Salo wrote:
Date: Tue, 26 Sep 2000 00:02:00 -0700
From: Joe Touch [EMAIL PROTECTED]
Subject: Re: An Internet Draft as reference material
[...]
From RFC 2026, Section 10.3.1. All Contributions:
Reading along further in the same document:
... Internet Drafts
RJ Atkinson wrote:
At 19:07 03/01/01, Lloyd Wood wrote:
I'd just bounce all emails with non-text attachments with a message
requesting that attachments not be sent to the list, and that the
message be resent as text. Simple. sufficient.
Fully agree. There is no need to use any
Ed Gerck wrote:
Keith Moore wrote:
I expressed an opinion that this group should confine itself to addressing
short-term goals rather than trying to make NATs a part of the Internet
architecture.
NATs are already part of the Internet, and gaining share.
An alternate perspective
Brian E Carpenter wrote:
Joe Touch wrote:
...
Speaking of keeping standards, I am wondering why STD-2
is still RFC-1700, although the current version is kept by
IANA at http://www.iana.org/numbers.htm .
Very good question. I'll be glad to raise the issue with IANA;
at least
"Rahmat M. Samik-Ibrahim" wrote:
Joe Touch wrote:
I was not aware that there was ever a proposed STD-1 I-D and/
or last call.
STDs are labels of existing standard RFCs which go through
the usual procedure.
But, neither I was aware that there was ever an I-D and/or a
Harald Alvestrand wrote:
At 09:17 08/02/2001 +0100, [EMAIL PROTECTED] wrote:
Anyway, I agree with Mr Gao that it will be usefull to have a distinguishing
name for the last network element, something like ONE "outest network element"
or END "edge netework device" or any other that may be
Dan Cassiday - High End Server Systems wrote:
This note is to announce a new IETF email reflector to discuss methods for
running IP traffic over an InfiniBand fabric. A BOF on this subject
has been proposed for the March IETF meeting.
To join the reflector, send email to [EMAIL
Harald Alvestrand wrote:
At 09:03 15/03/2001 +0800, huangjianbo wrote:
I am working on a paper on router, but one problem blocked my process. That
is what's the differents between a switch and a router for the view of
theoritical.
As to the 3 Layer switch and router, both of them work
to the Internet. :-)
Joe Touch
Director, PCEN
Kastenholz, Frank wrote:
At 09:49 AM 10/23/01 -0400, RJ Atkinson wrote:
The challenge is that some folks clearly do use the wireless
LAN to download I-Ds to review precise text during the meeting
discussing that particular I-D (in lieu of carrying paper around,
I suppose), or for
[EMAIL PROTECTED] wrote:
Hi,
I have a question on how to print Internet Draft with the right
pagination on Windows machine.
Take the document below as an example,
http://search.ietf.org/internet-drafts/draft-hain-msword-template-06.txt
If I print this document from Internet
stanislav shalunov wrote:
NAT is an ugly hack that's impairing people's connectivity, right?
For some, it might be. Others find different faults with NAT.
A highly unusual for an IETFer (and very disturbing) perspective of
cable companies is provided in an article in CED magazine The CAT
Aaron Falk wrote:
On Wed, Nov 28, 2001 at 07:44:49PM -0500, Michael H. Warfield wrote:
On Wed, Nov 28, 2001 at 03:05:24PM -0500, Gene Hastings wrote:
Using NAT to connect several of your own computers is one thing.
Using it to connect your neighbors and buddies is quite another. Many
ISP
Bob Braden wrote:
* I don't believe the intent of 2119 was to change the meanings of
* should, must, etc., in RFCs, but rather to define new terms
* SHOULD, MUST, etc., with specific new meanings.
*
* Keith
*
Keith's statement was certainly correct when we first
Vernon Schryver wrote:
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Proprietary IP Protocol Type
From: Kuniaki Kondo [EMAIL PROTECTED]
I am working on a distributed router and i want to run my own proprietary protocol
inside over
the IP layer. ...
I also
Andrew G. Malis wrote:
Melinda,
I sent an email to the anonymous yahoo ID identified as the mplsissues
list owner to please identify him or herself, and to cease spamming IETF
and other lists.
I also completely agree with Randy's point. Posting to IETF lists
should be restricted to
Andrew G. Malis wrote:
Joe,
I also completely agree with Randy's point. Posting to IETF lists
should be restricted to list participants.
That's often harder to do than it appears, esp. for those who have
multiple mail addresses from which they might reply, or for those on
local
Keith Moore wrote:
Will not the spammers soon learn to send their spams with
one of these addresses as bogus sender?
You overestimate the spammers :-). Most probably have no idea what IETF
is or that they're spamming an IETF list.
I dunno. I've received several complaints from people
James M Galvin wrote:
On Fri, 15 Mar 2002, Joe Touch wrote:
A nontrivial number of users utilize employer-independent email
destinations, such as *@ieee.org, *acm.org, etc.
I'm not willing to write-off that as ignorance of how email works.
Sorry, you lost me here. I
Patrick R. McManus wrote:
[James M Galvin: Fri, Mar 15, 2002 at 08:40:44PM -0500]
On Fri, 15 Mar 2002, Joe Touch wrote:
These are destination-only addresses, used for forwarding. I tried this
with Mailman (presumably a modern application?), to which I had
subscribed [EMAIL
Patrick R. McManus wrote:
[Joe Touch: Sat, Mar 16, 2002 at 11:21:28AM -0800]
Lists for open discussion should require such hoops for participation,
esp. when there are plenty of reasonable, sufficiently correlated
identifiers than not a list member to identify spam.
...
I think you're
Keith Moore wrote:
Lists for open discussion should require such hoops for participation,
esp. when there are plenty of reasonable, sufficiently correlated
identifiers than not a list member to identify spam.
assuming you meant should not require I'm very much in agreement.
Oops - typed too
Patrick R. McManus wrote:
[Joe Touch: Sat, Mar 16, 2002 at 02:03:22PM -0800]
Patrick R. McManus wrote:
...
The e2e-interest blacklist is new. It appears to be a reaction to the
embarrassing amount of spam that that list has redistributed over the
last couple of years
It's a little over a year
Marshall Rose wrote:
This is something I have discussed with several people
and every one seems to agree.
The current registration fee of $575 is outrageously
high. Even though IETF claims to be an open forum with
no membership fee - you need $575*3=$1725 per year for
registration fee alone for
Marshall Rose wrote:
Joe - since you replied to my note rather than bonney's, i am obliged
to reply.
Unlike both of you, i am not expressing an opinion on the fees. What i
am saying is that neither of you have any data.
I had data - from other conferences. Granted, I'm asserting there
Rob Austein wrote:
The last time this came up for a TCP implementation I used to
maintain, our interpretation of Robustness Principle applied to this
problem dictated that we shouldn't send segments with checksum fields
set to all ones (that is, we shouldn't send ~(+0)), but that we had to
Bob Hinden wrote:
Ran,
Proprietary is a commonly used term to describe something that
does
not have a full, complete, and open specification -- which is the
current state of IS-IS. Now folks (including me) are trying to fix
that issue by publishing sundry non-standard RFCs on
John C Klensin wrote:
Hi.
I've recently had another close encounter with the patent system
and notions of prior art. It occurs to me that we could make a
slight modification to the Internet Draft structure and encourage
including an additional bit of information that would be quite
Lloyd Wood wrote:
Given that a large number of drafts, including even
draft-bradner-submission-rights-00.txt
currently end in a boilerplate saying copyright (year)
or an out-of-date year because the boilerplate has been cut and pasted
from a previous draft, it would be impossible to rely
Peter Deutsch wrote:
g'day,
John C Klensin wrote:
. . .
Please, folks, I am _not_ trying to restart the discussion of
archival I-Ds. Personally, I remain opposed to the idea, and
I believe that they should be treated as drafts and discarded.
If they result in an RFC, then the RFC
Keith Moore wrote:
if respecting the author's wishes isn't reasonable or practical,
it might be that you live in a pretty warped world.
Or a courtroom (or will).
These aren't just wishes; there are valid copyright issues.
Joe
Randy Bush wrote:
joe touch and crew, please turn it off
Jul 15 13:01:45 roam /kernel: arp: unknown hardware address format (0x0800)
As I said at 10:30, and will repeat, this is the result of an arp cache
that hasn't been flushed. An arp cache that we don't control, most
likely
Randy Bush wrote:
joe touch and crew, please turn it off
Jul 15 13:01:45 roam /kernel: arp: unknown hardware address format (0x0800)
As I said at 10:30, and will repeat, this is the result of an arp cache
that hasn't been flushed. An arp cache that we don't control, most
likely on a router
Randy Bush wrote:
We did (at 9:30am, minutes after the problem was detected). It didn't go
away. Now be an engineer and show us a trace.
a bit hard when it is broken arp packets
Jul 15 11:47:27 roam /kernel: arp: unknown hardware address format (0x0800)
Jul 15 11:47:27 roam /kernel:
Kevin C. Almeroth wrote:
It only requires being on a non-IGMP'd switch or a hub; at that point,
you can snoop the traffic and see any packet going to any multicast group.
It's much harder to snoop UDP; for non-broadcast, you'd have to be
in-line (on the wire, effectively) or on a hub. While
Kevin C. Almeroth wrote:
Multicast is necessarily a LOT weaker:
1) I can get a copy of packets by normal operation
(join a group). there is no equivalent for UDP,
notably for paths that aren't shared.
Again, not in all cases. You over-simplify the effectiveness of scoping.
Gary E. Miller wrote:
Yo Joe!
On Fri, 13 Sep 2002, Joe Touch wrote:
Without a dobut you are right, though I think the degree of difference is
awful small. Through hosts with root on switches or through wireless into
the mix and you are back to being roughly equivalent.
Hosts with root
Gary E. Miller wrote:
Yo Joe!
On Mon, 23 Sep 2002, Joe Touch wrote:
root has no problem seeing adjacent UDP even on a switch. Just
overflow the arp cache or poison it.
That all presumes the switch doesn't detect this as an attack and
shutdown that link, which is an entirely reasonable
Kevin C. Almeroth wrote:
Multicast is necessarily a LOT weaker:
1) I can get a copy of packets by normal operation
(join a group). there is no equivalent for UDP,
notably for paths that aren't shared.
Again, not in all cases. You over-simplify the effectiveness of scoping.
Joe Touch wrote:
Gary E. Miller wrote:
...
Barring that, please name ONE switch, or cite ONE credible reference
source, where arpspoofing is prevented at the switch by any means short
of harcoding the MACs.
Practical != economical. Further, there are MACs which are hardcoded
(i.e
Matt Crawford wrote:
Barring that, please name ONE switch, or cite ONE credible reference
source, where arpspoofing is prevented at the switch by any means short
of harcoding the MACs.
Never mind, even hard-coding the MACs to the right ports doesn't
solve the problem. Eve on port X can keep
Bill Cunningham wrote:
- Original Message -
From: Michel Py [EMAIL PROTECTED]
To: Bill Cunningham [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Monday, September 30, 2002 1:28 PM
Subject: RE: TCP/IP Terms
Bill,
Bill Cunningham wrote:
I think the main goal is to compete with
OSI's
[EMAIL PROTECTED] would be a fine place to discuss this
further, as it is (by definition) about (albeit recent) Internet history ;-)
Joe
Craig Simon wrote:
I've got a lot of information on this which I'd be happy to share and
exchange, but I still need and want more details. I'm not sure the
.
or give me proof of your claims?
How about proof of the hi-jacking? (sauce for the gander)
Until then, please keep your attacks those who are still able to defend
themselves.
Joe Touch
Director, Postel Center for Experimental Networking
USC/ISI
Harald Tveit Alvestrand wrote:
...
IETF SUB-IP area
...
Although the SUB-IP working groups have made considerable progress
(with 7 RFCs published, another 12 IDs approved for publication, 9 IDs
under IESG consideration and an additional 11 IDs having been passed to
the ADs for their
Danny McPherson wrote:
3. The I in IETF means that the IETF shouldn't be working
sub-IP anyway. Many of these discussions (layer 2 VPNs, in
particular) would be better served by occuring within the context
of their original host organization (i.e., IEEE for ethernet over
Eric Rosen wrote:
Joe Many of these discussions (layer 2 VPNs, in particular) would be better
Joe served by occuring within the context of their original host
Joe organization (i.e., IEEE for ethernet over IP), since it was those
Joe organizations that defined those LANs, and
Scott W Brim wrote:
On Fri, Dec 06, 2002 08:15:16AM -0800, Joe Touch allegedly wrote:
Eric Rosen wrote:
IEEE is certainly not the right place to determine how to carry
ethernet data and control frames over IP networks.
They defined ethernet. It is they who would best determine how
Danny McPherson wrote:
They defined ethernet. It is they who would best determine how to carry
ethernet over another protocol and keep current ethernet correctness.
Sure, but what about IP network correctness (e.g., security or congestion
control)?
Security isn't an IP issue; it's an IPsec
Scott Bradner wrote:
for what it's worth here is my personal opionion on what we should
do in the question of the sub-ip area
I think we should go with the status quo (with the IESG selecting two
volunteers to manage the area next March)
I do not think that we can make a reasoned decision to do
Vach Kompella wrote:
Let's also let the VRRP WG decide on the fate of SIP WG documents, the CALSCH WG
decide on the fate of OSPF WG docs... Let's particularly ignore the fact that
the folks closest to the issues have the most interest in getting the best
possible outcome.
We don't let WGs
I'm in favor of 1/
3/, again, seems contradictory. The status quo is that it disappears.
Continuing it without a fixed end date is to subversively result in 2/
without a clear charter definition and Nomcom participation.
To be specific, I don't think 3/ should be on the table, at least not
Eric Rosen wrote:
Keith In my experience, IESG has tremendous breadth - considerably
Keith exceeding that of any single WG.
You must be joking. Or perhaps you just mean that you tend to agree with
the IESG's program of trying to preserve the academic, ivory tower vision of
the
Yakov Rekhter wrote:
Paul,
Er, toning down the rhetoric a bit, it is worthwhile to ask two questions:
- Does keeping the WGs in one area help significantly?
- Does keeping the WGs in the IETF help significantly?
I think it would be worthwhile to ask the following three questions:
I do too.
[EMAIL PROTECTED] wrote:
It sort of had to start happening. Marriott apparently aims to provide
wireless access at 400 hotels in Germany, the U.K. and the U.S.
FWIW, wireless access != being on the Internet
Many places use NATs and/or firewalls, or require registered MAC
addresses (some
John Stracke wrote:
Pekka Savola wrote:
I would imagine that the IETF as _customers of the hotel_ can do
pretty much what it wants.
Depends on Marriott's contract with Wayport--it probably specifies some
degree of exclusivity. But Wayport might be happy to grant an exception
when they
Dave Crocker wrote:
Folks,
For some reason, we continue to make followup discussion a matter of
accident, rather than facilitation.
In line with Don's suggesttion:
We ought to make sure that all I-Ds and RFCs contain contact
information, not just for the authors, but also for the group
Vach Kompella wrote:
Melinda,
As a process kind of thing, I'm also concerned about the
growth of the temporary sub-IP area, so I think there are
issues here with both the work itself and in how the IETF
goes about taking on and structuring its work.
And proposals have been made to dismantle
Bob Hinden wrote:
Randy,
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.
... and email messages, to wit:
I think the expression that applies to
Zefram,
Our take on why NATs are bad is at:
http://dsonline.computer.org/0207/departments/wp4icon.htm
And our method for undoing what a NAT does, called TetherNet is at:
http://www.isi.edu/tethernet and paper about it is at:
http://www.isi.edu/touch/pubs/discex03-tethernet/
(Contact me if you
Doug Royer wrote:
Anthony G. Atkielski wrote:
NAT has obvious disadvantages. ...
... Chat and instant messaging services will fail, and there is no
way to get them to work with NAT.
So far I have not been able to get chat or instant messages services to
fail because
of NAT. (Not that I
Melinda Shore wrote:
...
I'm not sure if you're arguing that there should be a comprehensive
document presenting the technical problems introduced by NATs. I
suspect there should be, although frankly this is one particular
area where there's a clear and growing divide between this community
and
Michel Py wrote:
Joe Touch wrote:
Since we've been lacking a similar non-NAT solution,
we (ISI) built one called TetherNet, as posted earlier:
http://www.isi.edu/tethernet
What is this beside a box that setups a tunnel? What's the difference
with:
http://www.cisco.com/en/US/tech/tk583/tk372
Eric A. Hall wrote:
On 1/12/2004 9:03 PM, Noel Chiappa wrote:
IPv6's only hope of some modest level of deployment is, as the latter
part of your message points out, as the substrate for some hot
application(s). Somehow I doubt anything the IETF does or does not do
is going to have any affect
John C Klensin wrote:
Noel, I'm slightly more optimistic along at least two other dimensions...
...
(2) The no servers unless you pay business rates, and its close
relative, you don't get to run VPNs, or use your own email address
rather than ours nonsense you and many others are experiencing
Matt Holdrege wrote:
I am shocked that the IETF didn't rewire downtown Seoul to accommodate
our conference! The next thing we'll hear is that our TDMA phones won't
work. Or that they don't have TGI Friday's within easy walking distance.
:-)
About phones:
You can use a tri-mode CDMA USA phone
Keith Moore wrote:
Okay, I read draft-iesg-rfced-documents-00.txt regarding a proposed
change in IESG policy regarding RFC-Ed documents.
I'm opposed to the change, because I believe it would make it too easy
for harmful documents to be published as RFCs.
As someone who has been waiting over
Michael Richardson wrote:
One thing to consider, is having a web server which, when asked for:
http://www.ietf.org/ref/rfc0791.txt
redirects to:
http://www.ietf.org/std/std005.txt
STD-5 is a nice choice - it actually refers to 6 different RFCs.
So which one redirects to
Bob Braden wrote:
*
* And what happens when a STD is updated/revised?
*
* Joe
Joe,
Unnnh, let me guess. Update the web pointer to the new RFC(s)?
Bob Braden
I was thinking of the case where
791 - STD3
In which case when STD3 points to a new RFC, papers citing STD3 would be
Bob Braden wrote:
*
*
* Bob Braden wrote:
*
**
** And what happens when a STD is updated/revised?
**
** Joe
*
* Joe,
*
* Unnnh, let me guess. Update the web pointer to the new RFC(s)?
*
* Bob Braden
*
* I was thinking of the case
Michael Richardson wrote:
Valdis == Valdis Kletnieks [EMAIL PROTECTED] writes:
Valdis But anyhow, if we ever update STD005, we'll just do the
Valdis obvious - create STD079 or whatever we're up to, stick an
Valdis Obsoletes: STD005 on it, and stick an Obsoleted By:
Valdis STD079
Michael Richardson wrote:
Joe == Joe Touch [EMAIL PROTECTED] writes:
One thing to consider, is having a web server which, when asked
for: http://www.ietf.org/ref/rfc0791.txt redirects to:
http://www.ietf.org/std/std005.txt
Joe STD-5 is a nice choice - it actually refers to 6
Mike S wrote:
At 12:34 AM 6/16/2004, Sally Floyd wrote...
Alberto Medina, Mark Allman, and I have a draft paper on
Measuring the Evolution of Transport Protocols in the Internet
that has a section (Section V.B.) on Path MTU Discovery.
From the paper:
Table X shows that PMTUD is used and succeeded
Iljitsch van Beijnum wrote:
Why is the list of internet standards so hard to find?
It seems to me this list deserves top ranking on the first page at
www.ietf.org, but that's certainly not the case. (Try to find it and see
what I mean.)
It deserves top ranking on search engines; knowing that
Carl Malamud wrote:
You could do an opt-out period, say 6 months, before publishing
the database. With sufficient publicity, say periodic reposting
of the opt-out announcement on the ietf list, this seems to
strike a balance between the unspecified policy of the past
and a new policy for the
Spencer Dawkins wrote:
Dear Harald-the-General-AD,
Can we PLEASE do as Melinda says - change the policy now for new drafts?
That may have a chilling effect on new drafts. I.e., this isn't as
simple as let's just change it now for future stuff.
IMO, changing the policy would indeed be making
Carl Malamud wrote:
Hi Scott -
Thanks for pointing out the proceedings. Having the i-d's published
there certainly demonstrates how futile it is to pretend that we
can erase history. The position that Bill Manning and Joe Touch are
taking reminds of when I was ordered by the Secretary-General
Kai Henningsen wrote:
[EMAIL PROTECTED] (Joe Touch) wrote on 11.09.04 in [EMAIL PROTECTED]:
Spencer Dawkins wrote:
Dear Harald-the-General-AD,
Can we PLEASE do as Melinda says - change the policy now for new drafts?
That may have a chilling effect on new drafts. I.e., this isn't as
simple
Christian Huitema wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of
Joe Touch
Sent: Sunday, September 12, 2004 10:42 AM
To: Kai Henningsen
Cc: [EMAIL PROTECTED]
Subject: Re: archives (was The other parts of the report
Kai Henningsen wrote:
Joe
Melinda Shore wrote:
On Sunday, September 12, 2004, at 04:02 PM, Joe Touch wrote:
It's still unclear - the document contains required wording about its
expiration, under the same document. The two statements are in
conflict in that regard.
I have some problems with retroactively changing
Melinda Shore wrote:
On Sunday, September 12, 2004, at 06:03 PM, Joe Touch wrote:
Even the IETF distinguishes between normative refs and non-normative
(though it has a penchant for wanting to redefine those words too).
Private correspondence is not citable as a normative ref, nor
1 - 100 of 482 matches
Mail list logo
