*
* I'll grant FTP an exemption, it came well before NAT units became
* prevalent (Was there an FTP-over-NCP before The Great IP Deployment?).
There certainly was. FTP and Telnet were both ARPANET NCP protocols
in use since ~1972.
Bob Braden
* However, I do agree that anybody
trouble if I ever heard of one.
I don't believe this argument, John. The IP address is (part of) the
transport layer end point address, something that an application can
reasonably be expected to know about in the existing Internet
architecture.
Bob Braden
*
* I don't believe this argument, John. The IP address is (part of) the
* transport layer end point address, something that an application can
* reasonably be expected to know about in the existing Internet
* architecture.
*
* Unfortunately the existing Internet is no
ck,
Right idea, wrong link layer. The low-order 24 bits of an IP address
was originally a 24-bit ARPANET (/Milnet/DDN) host address.
Bob Braden
it was an architectured
solution to the problem. It is documented (at least) in section
6.1.4.3 of RFC 1123.
Bob Braden
you suggest has in fact been in progress for some time now. However,
the RFC Editor cannot soon remove the original names, because lots of
folks have them buried in scripts, and pragmatic continuity is more
valuable to the IETF membership than quibbling.
Bob Braden
your EMSD RFC 2524 would not have been
published at all.
Bob Braden
ried to float the concept of an
extended Internet defined by email connectivity.
Bob Braden
Elevators are fundamentally inimical to the IETF, because
elevators don't scale.
Bob Braden
en because the working group chairs were tired; however, it was
their failure in this case. I expect that similar cases exist in other
working groups.
Bob Braden
Valdis,
Please see RFC 1127.
Bob Braden
are for the most part contributions to the process of creating a
* standard. It would be inappropriate for most of them to be made even
* Informational RFCs. While it may be worthwhile to retire I-Ds as
If they are not worth keeping, they are not worth keeping.
Bob Braden
* active
It is indeed shameful. One wonders why it was not published at an
Informational RFC. (It's not too late...)
Bob Braden
*
* Eliot
*
*
*
ft.
*
*
Agreed.
Bob Braden
hnical use)
*
* Thank you.
* --
* Henning Schulzrinne http://www.cs.columbia.edu/~hgs
*
*
Henning,
Please see RFC 1025 from Sept 1987, or IEN 160 (online at
the RFC Editor web site) for a November 1980 bake off.
Is this 20 years ago early enough?
Bob Braden
to the reader, but here's a clue: it's
a different world out there!)
Given this context, it actually seems somewhat remarkable to me that
the IETF has so far been able to adapt to changing circumstances
(without becoming another ISO or ITU).
Bob Braden
but still
* could not find any information about it.
*
* Does anyone know where I can find such information ?
*
* Thanks for your help.
*
*
Please see RFC 1644.
Bob Braden
* From [EMAIL PROTECTED] Wed Jan 17 00:13:11 2001
* From: [EMAIL PROTECTED]
* To: [EMAIL PROTECTED]
* Subject: about RFC2178
* Date: Wed, 17 Jan 2001 16:49:54 +0900
* MIME-Version: 1.0
* Content-Type: multipart/alternative;
boundary="=_NextPart_000_0025_01C080A5.845ADB80"
*
*
* However, I have to observe that this strange thing called ARPANET
* appears to be using private addresses :-)
*
* And I assume there were ALGs to translate between NCP and TCP hosts...
*
*
Nope. Dual stacks.
Bob Braden
*--Steve Bellovin, http
consideration. This makes simplicity and uniformity
very precious indeed.
Bob Braden
istory of Internet development. Not that
the actual history is particularly relevant to today...
Bob Braden
advantage of it.
*
Keith,
As I am sure you recall, the IETF held a BOF on "TCPng" some years
ago. It went over exactly the same ground tilled Mr. Gao. The BOF's
conclusion was that any gains would be marginal and would not justify
the trauma of change.
Bob Braden
* well-known, but some RFCs such as those on OSPF may be much
* more vivid if written in XML. There have been quite a few
Vivid? We are talking about deeply complex technical documents
here, not MTV. What do you mean, "vivid"?
Bob Braden
aving your algebra dance on a screen? We can color the independent
variables red, the functions green, and ...
The serious protocol implementors I know construct their own private
"gif"s on whiteboards and in their heads, and they get by without
animation. Sheesh.
Bob Braden
*
* The other thing that would be nice is a way of getting all of the
* authors current contact info in one place and up to date.
*
* -MM
*
If you have a good idea on how to keep contact information
up to date, the RFC Editor would like to know.
Bob Braden
or
to the WG or to the author or to normative references. It is
NOT due to formatting, editing, or proof-reading.
Bob Braden
*
* --
* Dave Crocker mailto:[EMAIL PROTECTED]
* Brandenburg InternetWorking http://www.brandenburg.com
* tel: +1.408.246.8253; fax: +1.408.273.6464
*
Titto Patrignani wrote:
* Some RFCs contain plenty of tabs, both in the ascii figures and in the
* text itself. Text file tabs are assumed to jump to a column that is a
* multiple of 8 (that is 8,16,24,...). I don't know a way for specifying
* this in WORD.
* I defined a .dot
/history.html.
Bob Braden
* synchronous-only VOIP. ST must have stood for 'Stream Telephony'.
*
Actually, it stands for "STream", although it was indeed designed
for packet audio.
Bob Braden
*
* IANA: Unless you can find some evidence of implementation, please
* retire the IP protocol number 5 assignment as Historical.
*
Nonsense. See RFC1819.
Bob Braden
that are
deliberately sensationalistic (which they think sells mags) and short
on facts. I can understand using the company as a convenient way
to avoid this unpleasantness.
Bob Braden
thought
they owned it, since they paid for its development. But cooler heads
prevailed..
Bob Braden
*
* She thanked me for my suggestion, but seemed not to be interested in
* my offer to supply the format checking program.
*
* I have a couple of questions regarding format policy:
*
* - Are unpaginated drafts acceptable? I think they probably should
* be (and have
the approach of
maximum flexibility whenever feasible.
Bob Braden
*
* In the past, why did Ma Bell charge for telephone extensions on a per instrument
* basis?
Probably because Ma Bell was responsible for internal wiring, if
I recall correctly.
Bob Braden
and other historical documents,
see; www.rfc-editor.org/history.html
Bob Braden
garage... ;-)
Bob Braden
* --
* Chip Rosenthal * http://www.unicom.com/ * [EMAIL PROTECTED]
* They're after my domain! * http://save.unicom.com/
*
will begin to understand why the
IETF Way is interoperability testing, not conformance testing But you
are free to make your proposal at IAB plenary of the next IETF.
This discussion is in a loop.
Bob Braden
* 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 introduced the
capitalized words
layer. Layer 2 is the link layer.
Bob Braden
the number of prescriptions that
doctors have written.
Increasingly, the most important standards RFCs may be the
(ill-advised) ones we DON'T publish.
Bob Braden
count. Hey, I could have written the RSVP RFC as five documents;
would that be a win? I don't think so.
Bob Braden
. We got where we are today by taking a long
view... we need to push back against those who would let short-term
optimizations produce long-term ossification.
Bob Braden
these issues to rest in 1988, in RFC 1071.
Bob Braden
* From [EMAIL PROTECTED] Tue Jun 25 21:56:52 2002
* X-Authentication-Warning: ietf.org: majordom set sender to [EMAIL PROTECTED]
using -f
* Mime-Version: 1.0
* X-Sender: [EMAIL PROTECTED] (Unverified)
* Date: Tue, 25 Jun 2002 23:51:15 -0500
* To: Thomas J. Hruska [EMAIL PROTECTED]
* From [EMAIL PROTECTED] Wed Jun 26 12:55:35 2002
* X-Authentication-Warning: ietf.org: majordom set sender to [EMAIL PROTECTED]
using -f
* From: Bill Cunningham [EMAIL PROTECTED]
* To: [EMAIL PROTECTED]
* Subject: PPP RFCs
* Date: Wed, 26 Jun 2002 15:40:23 -0400
* MIME-Version:
*
* There is no strict, formal, official distinction between packet or
* datagram.
Dave,
Section 1.3.3 of RFC 1122 (to which you were a significant
contributor) tried hard to get the definitions precise.
Bob Braden
of the terminology.
[Why] do we have to do this all over again?
Bob Braden
.
But it is not particularly confusing.
Bob Braden
Folks,
I would like to suggest that it is (well past) time to stop
feeding the trolls on this topic.
Bob Braden
believe.)
So, on New Year's Eve, hoist one for the 20th anniversary of the
Internet.
Bob Braden
* Routers brought to you by Bob Hinden of BBN.
** Prominent survivors included Dan Lynch of Interop fame.
And of course Vint Cerf was working
. There are enough slightly-incorrect facts
about the early history of the Internet floating around, without my
inadvertantly creating a new non-fact!
Bob Braden
of the proposed method should be identified and
* justified.
Maybe it's time for someone to write an I-D entitled
Crankback Considered Harmful ?
Bob Braden
the long-term benefits
of publication, so we are pleased to get your input.
Bob Braden for the RFC Editor
. Was it published
in any archival form?
Bob Braden
, the suggested solutions, and their up/downsides. Such a
document would not have to be complete to be very useful; a snapshot at
a particular time would be a big step forward.
Bob Braden
, I strongly suggest that a *Standards Track* document be
* written, with more detail on the messages, especially their processing.
Indeed, that is what IETF consensus means, isn't it?
Bob Braden
* Also, more detail on what the goal is here, under what circumstances
* these messages need
don't grok why it is particularly desirable to make the documentation
standards track, since in either case formal IETF action is involved.
Bob Braden
* Is it? That's good. Currently, the document is Informational, and
* is being processed as such. Can this be changed?
*
* Kireeti.
*
is hard intellectual work,
harder than sitting in front of our terminals, reading our email,
(re-)inventing ... etc., but I believe it is the only real path
to progress.
In the Internet community, the RFC series of docuemnts has been
perpetuated as an archival document series for this purpose.
Bob
Not liking to create unnecessary noise on large public lists (really!),
I trimmed the IETF off the following message. Bert W. has suggested that
this was inappropriate, as the issue is a general IETF issue.
Bob Braden for the RFC Editor
- Begin Included Message -
From [EMAIL PROTECTED
for RSVP, I interpret IETF consensus as meaning that at least a Last
Call was conducted. To use any other interpretation seems to me to
be dishonest. I guess I am agreeing with Kireeti.
Bob Braden
in the IETF but is not the
* product of an IETF Working Group.
*
* The IESG contact person is Scott Bradner.
*
Should that title be: 'LDP and RSVP-TE Extensions for Optical UNI Signaling'?
RSVP-TE is not RSVP.
Bob Braden
SCSI over IP, etc.
Can't we please resist terminology pollution? In the IETF we call these
[data] link layers.
Bob Braden
* IPI, IEEE-1394 (firewire) and Fibre Channel. These transports are
* I/O specific and have limited distance capabilities. The iSCSI
* protocol defined in draft-ietf
and were therefore potential note takers.
Bob Braden
*
this explanation is helpful.
Bob Braden for the RFC Editor
* part of RFC2400 is as follows
*
* Internet Architecture Board Standards Track[Page 20]
*
* RFC 2400 Internet Standards
* From [EMAIL PROTECTED] Wed Mar 5 15:59:37 2003
* Date: Wed, 5 Mar 2003 18:41:15 -0500
* From: Keith Moore [EMAIL PROTECTED]
* To: Geoff Huston [EMAIL PROTECTED]
* Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
* Subject: Re: Last Call: Instructions
.
The other archives, which no doubt existed, were written on DEC
tapes, IBM 360 mainframe files, etc. Not too useful today.
Bob Braden
* From [EMAIL PROTECTED] Mon Mar 10 14:11:52 2003
* X-Sender: [EMAIL PROTECTED]
* Date: Mon, 10 Mar 2003 14:03:31 -0800
* To: Bob Braden [EMAIL PROTECTED]
* From: Fred Baker [EMAIL PROTECTED]
* Subject: RE: Network Working Group
* Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL
more of OUR lives to this issue!
Bob Braden
.
Bob Braden
or the technology
to develop them all. I believe that the IESG needs to say NO more
often. I know that's tough, but that's why we chose such excellent
members of the IESG.
Bob Braden
demonstrate that users don't want any of these blocked services,
because they aren't using them today.
Huh?
Repeating this argument endlessly and fervently does not make
it any less a contradiction. Can we move on to something more useful?
Bob Braden
* do it. In the meantime, I wear a hat.
*
* -Ekr
*
Perhaps that was Keith's point... a hat as a cure for baldness is
akin to a NAT box as a cure for end system insecurity.
Bob Braden
* From [EMAIL PROTECTED] Mon Jun 23 08:26:17 2003
* Date: Mon, 23 Jun 2003 06:26:03 -0400
* From: vinton g. cerf [EMAIL PROTECTED]
* Subject: Re: non-complain mail system at alcatel.com
* X-Sender: [EMAIL PROTECTED]
* To: Michael Richardson [EMAIL PROTECTED], [EMAIL PROTECTED],
*
.
Bob Braden
a generation of work,
is no longer available to tell us the origin of the saying. Perhaps it
was original; I certainly assumed so at the time.
FWIW
Bob Braden
.
Grenville,
Nicely said!! I would like to see your motto inscribed over the
IETF portals... We create with diligence and offer with humility.
Bob Braden
formal standards bodies do. The IETF, for good
reason, chooses instead to let documents develop in the most expedient
fashion, and then notate them with (approximate) notations like
Obsoletes and Updates.
Bob Braden
*
* Hi,
*
* I'd like to see the concept of an RFC updating another RFC
an incredible amount of work for many people,
It is true that writing quality documents, no matter what
you call them, is always an incredible amount of work. Work well
spent, I believe.
Bob Braden
in the importance of using Informational
to capture important documents and ideas as RFCs.
Bob Braden
that can refer to the STD series of documents?
Note that:
ftp://ftp.rfc-editor.org/in-notes/std/std51.txt
already works.
Bob Braden for the RFC Editor
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
specifications in the Proposed Standard or Draft Standard category.
Few specs make it to Standard, for a variety of real-world reasons.
Perhaps STD numbers should be applied all levels of the standards track
(but before we did that, we would need to think carefully about the
consequences).
Bob Braden
*
* 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
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
*
*
* 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
STDs which would point to mulitple RFCs.
*
* Joe
Truth.
Bob Braden
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
to configure it all correctly. Down that path lies disaster,
IMHO. Path-coupled signaling provides auto-configuration of path
information, and that seems like it's worth the cost in much of the
network.
Bob Braden
___
Ietf mailing list
[EMAIL PROTECTED
not hard to find, actually. Try: http://www.rfc-editor.org/rfc.html
Bob Braden for the RFC Editor
*
* ___
* Ietf mailing list
* [EMAIL PROTECTED]
* https://www1.ietf.org/mailman/listinfo/ietf
*
___
Ietf
, but they don't seem to
have anything to do with the topic you started on.
Bob Braden
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
from this OI.
But then, you knew all that.
Bob Braden
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
of Section 4.2a(C) of RFC 3667 (and RFC 3667bis).
Bob Braden
for the RFC Editor
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
run out of IPv4 addresses. Has anyone
looked to see how today's data extrapolates from the predictions then?
Was it as S curve, after all??
Just wondering...
Bob Braden
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo
/rfceditor/sow.shtml. A less detailed form is on
the RFC Editor web site, at www.rfc-editor.org/DOCUMENTS/purpose.html.
Bob Braden for the RFC Editor.
*
* Does that make sense?
*
* Margaret
*
*
*
*
* ___
* Ietf mailing list
* [EMAIL
*
* It's probably necessary to do a full dependency analysis to do this
* right.
*
If it's not broken, why break it?
Bob Braden
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
* Standards have been invented for creating markets.
That's strange, all these years I thought standards were for
interoperability.
Bob Braden
* Gruesse, Carsten
*
*
* ___
* Ietf mailing list
* [EMAIL PROTECTED]
* https://www1
excuse to change the category
of this document.
Bob Braden (speaking for himself)
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
*
*
* --On Wednesday, 02 February, 2005 14:19 -0500 Bruce Lilly
* [EMAIL PROTECTED] wrote:
*
* ...
* Q: Why is the reference to ASCII given as the 1968 version
* ratherthan ANSI INCITS 4-1986 (R2002)? [N.B. no typos,
* the dates reallyare 1968 and 1986]
* ...
that the correct
response is to argue in favor of his original position at high volume,
with 10 messages a day, and with ad hominem attacks on his detractors.
What a pleasant relief... Surely, this gentleman deserves a
commendation from the rest of us for understanding, honesty, and good
manners.
Bob Braden
*
* A very simple solution would be to write the documents in French :-)
*
*
* That would be illegal. ;)
*
* Carl
*
Ah, but here is the clever bit. We don't CALL it French, we call
it Freedom Language.
Bob Braden
___
Ietf
Re: formatting RFCs: Please see
http://www.rfc-editor.org/formatting.html
which is also hyper-linked under Publication at the RFC Editor web site.
A good place to start, if you are concerned with RFCs.
RFC Editor
___
Ietf mailing list
* INTERNET-DRAFT? There is a discussion about restrictions on
* content of the title -- RFC 2223 has text prohibiting a dot in
* the title (implying that some circumlocution would be required
* in a title addressing use of 802.11, etc.).
*
It is a minor point, but the restriction
1 - 100 of 269 matches
Mail list logo
