It is *astonishingly* expensive. It only seems cheap until you have to
maintain it. And yes, I'm going by Actual Live Customer Experience In
Actual Live Large Companies.
if it were easy to show this we would not be discussing the topic
I don't know many companies who decide to do
Could any body tell me where i can find a tutorial/specification for NHRP
that is RFC 2332 - you can get the RFC through the IETF web page at
www.ietf.org
Scott
WAP is not an IETF activity - it is from the WAP Forum
http://www.wapforum.org/
Dave is an old friend of the IETF - he has now undertaken an assignment
at the US Federal Communications Commission and asked me to forward
his invitation to contact him in his new role.
Scott
Date: Wed, 23 Feb 2000 16:00:29 -0500
From: "David Farber" [EMAIL PROTECTED]
Subject:
you might study history - our process used to be that way we changed it
to avoid problems that we found
1/ refusal to negotiate
2/ false patent claims to delay the process
3/ patent claims from people who have nothing to do with the standards process
and the claim could be years after the
Scott Bradner gave a presentation at the G8 hi-tech crime event in Paris last
week
the presentation is at:
http://golem.sobco.com/presentations/2000.05.17-g8/index.htm
since the real work of the confreence was done in private it was hard
to tell what was actually going
Peter - for the last few years the IESG has required IETF working groups
to have meaningful Security Considerations sections in standards
track RFCs - these must include a threat and security analysis
Scott
the IETF's RFC/BCP's etc etc are the property of ISOC.
this is more than a bit simplistic
the ISOC holds a copyright license on RFCs that permit them to be
published and freely copied and, in most cases, the right for derivative
works within the IETF standards process - the authoirs retain
as long as we do not care about fragmentation of the routing space this
idea is neat
Scott
---
Vinton's idea has much merit. A scheme to allocate blocks of addresses to
manufacturers would be much easier to support than an organization
attempting to process individual email requests, or CGI
An informational RFC certainly meets these requirements.
I don't think we want to say that any info RFC qualifies
so how do we say just what we want to say and no more?
Scott
We have enough real technical issues to deal with in
the IETF. It isn't constructive to create new non-technical
issues that we don't need to have, IMHO.
I do not much like the idea of establishing precedents that can come back to
hurt us - saying (as some have in this discussion)
Is the reason for creating this archive driven in part by the
desire to document IP (intellectual property) claims that may
arrise?
yup - that is a major reason
Scott
Perhaps the IETF should consider adding an explicit warning
to each I-D when it enters the archive:
STATUS OF THIS MEMO:
THIS DOCUMENT IS AN EXPIRED INTERNET-DRAFT. USE OF
THIS MEMO FOR ANY PURPOSE EXCEPT AS A HISTORICAL
DOCUMENT IS STUPID, WRONG, AND
I will admit to some level of confusion
the subject line of this thread is "NATs *ARE* evil!" yet most of the
discussion is about the use of private addresses - something that
a whole lot of firewalls also do - howcum the subject line is
not "NATs Firewalls are evil!" or "use of private
Nothing personal Frank, but in a general sense I'd say you weren't doing
your job well enough.
easy to say if you have not been and AD
Frank was a good AD and managed WGs as well as any of us (and better than many)
yet getting people out of presentation mode is hard and takes previewing
the
No I-D editor should ever have the need to
make up a PowerPoint slide show.
I strongly disagree
one of the most successful methods I've seen is to have a series of
slides (powerpoint or not) each with one issue tersley described
and a few options listed - this is used to focus the discussion
note that it is hard for the rfc edior to accept nroff
too often people use their own macro packages which are incompatable
also too often people change the text between the time that the iesg
approves of a doc and when then send it to the rfc editor - so the
rfc editor has to check for that
None of the Mac folks I've talked to have had any success with the
wireless DHCP. We have to hand configure.
I had no problems with the DHCP on my Mac - often getting an address
long before many of the non-macs around me got addresses
Scott
I think we need to have a clear discussion
about which kinds of NDAs are compatible with IESG duty.
see RCC 2026 section 10.2 -
the simple answer is "none"
Scott
The alternative, IMO, is to have IETF participants who are employed by
industry companies such as Cisco and Microsoft viewed as official
representatives of their companies rather than as individual (and independent)
participants.
would the Cisco rep's opinion count the same as the rep for
HT Kung I have been working on some IDs dealing with anonymous forwarders
for signaling applications - we have established a mailing list to
talk about the IDs
to subscribe - send mail to [EMAIL PROTECTED] with
the word subscribe (no quotes) as the subject
the IDs are
total BS (as to be expected)
---
From [EMAIL PROTECTED] Tue Oct 16 12:17:44 2001
From: Jim Fleming [EMAIL PROTECTED]
To: James M Galvin [EMAIL PROTECTED], Robert Elz [EMAIL PROTECTED]
Cc: vint cerf [EMAIL PROTECTED], pindar@HK. Super. NET [EMAIL PROTECTED],
linda@icann. org [EMAIL
Pete sez:
I agree. The purpose of the liaison should be to keep the IETF
informed about the goings-on of the ITU. Insofar as the actions of
any other standards or commercial organization might have a
significant impact on the decisions of the working group (e.g.,
knowledge that a
IMHO, it's long past the time that the IETF should have a centralized
mail management system where lists can be (not forced to be, of
course) centrally created and yet still managed by individual list
authors.
yup - and its been the case for quite a while
Scott
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
suck^H^H^H^Hvolunteers to manage the area next March)
I do not think that we can make a reasoned decision to do
However, unless
I'm severely confused (which is always possible), the prohibition against
derivative works came from the ITU side of the fence,
the prohibition is more not used all that often - two main cases where
is is
1/ vendor work publish for the information of the community
and they meant the current 2434 definition
or they misread 2434 (or did not read 2434) and thought they knew
what IETF consensus means
Scott
RFC 2026, section 10.4 (A) says Standards track documents shall include
the following notice; (B) says ... each standards document shall
include the following invitation. This should be mentioned in 2223bis
in section 4 and in Appendix C (btw, the fourth subsection of App C is
labelled B
Iljitsch wrote:
The confusion that the ARPAnet supposedly had a military function stems
from the research done by Paul Baran at the RAND Corporation in the
early to mid 1960s. He proposed high-availability packet switched
network for military command and control.
in case anyone is
Perhaps, perhaps not. I live in Ontario Canada and in the recent
blackout, my phone kept working.
i.e., you did not have a ISDN or wireless phone
Scott
It is my impression that wireless local loop systems (WLL) for
telephony include backup batteries in subscriber units as well. That
I was referring to cordless phones - not cel phones
they also die when the power goes out, for some reason some people
do not expect that to be the case
Scott
note that this survey was done *after* the decision was announced
as a done deal - I, for one, took that into account when I responded
From: Bob Hinden Brian Haberman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], Brian Haberman [EMAIL PROTECTED]
Date: Tue, 16 Sep 2003
IAB,
Please consider this input for the IAB discussion on Tony's appeal of the
site local decision. This should not be considered a separate appeal.
(Which I would think would have to start at the beginning with the working
group chairs.)
I do not have an opinion on the particulars of Tony's
the reason I don't try to repudiate BCP 5 is that it's clear that for IPv4
we're out of addresses,
total BS
http://www.iana.org/assignments/ipv4-address-space
If you can convince the RIRs that it's feasible to relax the
allocation criteria for IPv4 blocks,
Keith
Just what would you suggest in the way of relaxing?
The basic rule is now - if you (the requester) can show you are going to
use the space you can get it.
Relaxing from that would seem
If you have $2500 to ante up for the allocation.
you might take a look at the RIR web pages - it does not cost
an ISP $2500 to get additional address space allocated - the
additional fee for additional space for large ISPs is generally zero.
end site allocations are a different story but
In private email I was asked to review the tape of the IPv6 discussion in
San Francisco.
ftp://limestone.uoregon.edu/pub/videolab/video/ietf56/ietf56%20-%2003202003%20-%20INT%20ipv6.rm
The SL discussion starts at 1:02 into the session.
The chairs first presented a set of slides talking about
Yesterday I posted a message that said that I agreed with the IPv6 working
group chairs that rough consensus was reached to deprecate IPv6 site local
addresses. That said, I do have an issue on the discussion that led up to
that consensus decision. I do not think there was much of an actual
I'm resending this since it looks like it did not get posted the last time
a mailing list to followup on teh newtrk BOF has been created
[EMAIL PROTECTED]
subscribe
mail [EMAIL PROTECTED]
subscribe newtrk in body
web user interface
I just reposted the draft minutes for the newtrk BOF to the newtrk list
if you were at the BOF and spoke (or if you just sat there) please
review the minutes and send any suggestions for clarifications to me
asap (also please fix the spelling of your name if it is wrong)
instrustions to
The real issue is whether an ECN bit is reserved, or not reserved.
it's not reserved -- the ECN bits are assigned by RFC 3168
i.e. ECN is a proposed standard and the bits that it uses in the IP header
are fully assigned
Scott
Yes, but if you're a firewall that stepped into a temporal stasis box
before 3168 was published, you're still thinking that the bits are
reserved,
woe be to new applications through such a firewall
Scott
I have not heard
From [EMAIL PROTECTED] Mon Jan 5 15:14:02 2004
X-Original-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Date: Mon, 05 Jan 2004 14:52:34 -0500
From: David R. Oran [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Has anybody heard back from the Hotel in Seoul?
my request was a faxed on and I have not heard back
---
From [EMAIL PROTECTED] Mon Jan 5 16:08:50 2004
X-Original-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Date: Mon, 5 Jan 2004 15:56:03 -0500
Subject: Re: Has anybody heard back from the Hotel in Seoul?
Content-Type: text/plain;
fyi - I've posted a draft charter for a newtrk WG to the newtrk list
archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html
subscribe to list: mail to [EMAIL PROTECTED]
subscribe newtrk in body
list address: [EMAIL PROTECTED]
Scott
a few comments on the IESG proposal:
from draft-iesg-rfced-documents-00.txt
2. Background material
The review of independent submissions by the IESG was prescribed by
RFC 2026 [1] section 4.2.3 and RFC 2418 [2] section 8. RFC 3710 [3]
section 5.2.2 describes the spring 2003 review
I think we might want to begin thinking of these two functions (technical
review and copy-editing) as two different functions, which are joined at
the hip currently, but aren't necessarily so joined forever.
agreed, but if they become disarticulated there will need to be
a solid way for
I get really
worried about text -- especially new text-- in these procedural
documents that enables or encourages potential protocol
lawyers... whether they are inside the IESG or outside the core
IETF community.
a reasonable worry (sorry to say) - note though that the text I'm
--On 10. mai 2004 09:33 -0400 Scott Bradner [EMAIL PROTECTED] wrote:
this misses one of the outcomes listed in RFC 2026 - specifically (quoting
from 2026):
the IESG recommends that the document be brought within the
IETF and progressed within the IETF context
this path has
Anything else should (IMHO) be advice to the RFC Editor and the author, and
not be part of the formal position-taking the IESG makes.
we may be debating termonology
your ID says The IESG may return five different responses
that seems to eliminate the possibility of communicating any
such
C Klensin [EMAIL PROTECTED]
To: Scott Bradner [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Last Call: 'The IESG and RFC Editor documents:
Procedures' to BCP
In-Reply-To: [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
X-Mailer: Mulberry/3.1.3
looks good to me - one suggestion of clearer language and a potential
addition
o Documents for which special rules exist, including IAB documents
and April 1st RFCs, and republication of documents from other SDOs
- the IESG and the RFC Editor keep a running dialogue on which
fwiw - this works for me
---
From: John C Klensin [EMAIL PROTECTED]
To: Scott Bradner [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Last Call: 'The IESG and RFC Editor documents:
Procedures' to BCP
--On Monday, May 10, 2004 10:57 AM -0400 Scott Bradner
[EMAIL
So what is the rationale for organizing ourselves based on our
respective countries?
to match legal jurisdictions
Scott
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
I think this is still not clear enough that it describes optional processes
that can be used *if desired* by a working group
e.g. the first sentence of abstract would be better if it said
something like:
This document proposes an optional experimental set of alternative
decision-making
might be better as:
In no way should this experiment or any future BCP for this small
number of cases take precendence over the IETF's normal mode of
operation. Specifically, these procedures are only to be
used when a working group agrees to use them.
Define agrees. When
this refers to copyrights from somewhere other than the ISOC
(the W3C or an individual person for example)
multiple copyright notices, if all from teh ISOC, is just fine
Scott
___
Ietf mailing list
[EMAIL PROTECTED]
see RFC 2860
Scott
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
Harald sed:
scenarios C and D envision incorporating the *support function* for the
IETF. The IETF would remain an undefined entity under these scenarios.
I've had another suggestion that the IETF (the real technical process
entity) should become a formally recognizable entity of
I think the IETF also has paid employees
the IETF currently has no employees (paid or otherwise)
Scott
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
For what it's worth I feel about the same way that Brian does about the
restructuring options.
I think that both options A B make sense, could be done quickly and
would be a positive step in regularizing the relationship of the IETF
to its admin functions. Both options provide a way for the
In his scenario, not only the Administrative Czar would need explosive
bolts, but also the RFC Editor and Secretariat, etc.
that depends on the contracts with those suppliers - if the contract
is signed by the IETF chair or the admin czar for the IETF (rather than
for the ISOC) I would not
leslie sez:
In my reading of Scenarios A B, the suggestion
is that ISOC takes on the administrative work more-or-less
directly.
takes on the admin work or contracts vendors to do the admin work
i.e., the difference between hiring people and paying vendors
it might make a difference if bolt
John sez:
But, as far as I can tell, the separate organization model
bets the entire survival of the IETF against a nothing will go
wrong assumption.
so far the people who are pushing for the separate organization model
have not come up with anything other than 'it would feel better' or
'the
1. As far as I can tell, there is no scenario in which the IETF chair
is signing anything.
the IETF chair currently does that sort of thing (see for example the
ICANN PSO MoU)
also see Brian's note
Scott
___
Ietf mailing list
[EMAIL PROTECTED]
As it stands now, ISOC's
role in the RFC Editor contract is balanced by its need to understand the
standards process; it should and does understand what the
RFC Editor does for the IETF.
as well as the ISOC's ability to understand what the IAB (which manages
the RFC Editor) wants the RFC
fwiw - I would like to see a public archive of old IDs
something like
http://www.potaroo.net/ietf/html/xids-curr.html
would be ideal (imo)
I also think that there needs to be a concentrated effort to bring the
mailing list archives up to date on the IETF web site (part of that is
to retrieve
imo we should start a search for a Administrative Director now
Scott
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
the last time we talked about this Jorge said that he saw no problem
(legally) to just offer a takedown process to anyone who felt that
they did not want their ID to last longer than N days
but, to me, its quite silly to pretend that IDs actually disapear
from the net just because teh IETF takes
imo we should start a search for a Administrative Director now
Does it have to be a hire, or can it be contracted, like anything else?
not sure, my guess is that we want an individual to do this but
the problem with that is dealing with truck fade on the individual
Scott
Following on from that does the expiry indicate that the copyright reverts
back from ISOC to the authors? I hadn't expected that to be the case.
note that the only rights that the ISOC has for IDs is to publish
them and to make derivative works (unless they are marked so as to
not allow
PROTECTED]
X-BrightmailFiltered: true
Date: Fri, 10 Sep 2004 15:24:46 +0100
From: Stewart Bryant [EMAIL PROTECTED]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: scott bradner [EMAIL PROTECTED]
Cc
Bill - as I said in a previous posting - it would be quite fine
for you to say 'IETF- you do not have permission to post my expired ID'
and the IETF should then remove your ID from the IETF's public archive
but just because you might want to do that shoudl not (imo) keep the
IETF from posting the
One of those terms/conditions was a limited period
of publication, after which, the rights revert back
to the author(s).
ps - look at RFC 3667 section 1 (g)
Scott
___
Ietf mailing list
[EMAIL PROTECTED]
not saying it could not happen, just that not all that
sure of the value proposition of this particular line
item makes it worthwhile going after the collective
at this time.
yup - no value here - its just the intellectual history of the IETF :-)
Scott
bil sez:
ah... but said RFC did not exist at the time my IDs
went out. and my cursory perusal of said RFC seems
to indicate that it is mute on materials submitted
into the IETF process in times that pre-date said
RFC existance.
fully agree - that was not
Something was pointed out to me in private mail that I should have
remembered but did not.
Since Aug 1998 the IETF proceedings have included the then-current
Internet drafts (except for one meeting which seems to be missing).
As I recall, this was started when the secretariat started offering
Ole sed:
I believe there are better mechanisms we could use
fwiw - the proposal from a few years ago was
1/ have a directory called expired_IDs
2/ move IDs from the normal ID directory to this
new one when they expire, are replaced with an
updated version,
Christian asks:
What about successive versions of the same draft?
yes, successive versions would be retained - that is what I refered to
in bullet 2
2/ move IDs from the normal ID directory to this
new one when they expire, are replaced with an
Harald asks
I feel some urgency to make sure that we have meeting arrangements in place
for 2005 - without imperiling our ability to make the best long-term
choices for the IETF.
the logical path seems to be to ask Foretec to start making arrangements
for next year's meetings - doing so in a
not to prolong this not-related-to-the-reorg-topic too much longer
but fwiw - I think that the IETF is well within its rights when it
publishes the proceedings that include now-expired IDs and would be
well within its rights to publish expired IDs in a public archive
from RFC 2026 (October
If we follow the combo path, we also commit ourselves to breaking the
function into multiple pieces - which may discriminate against a solution
where other suppliers of services may be able to do the whole thing more
effectively than they can do parts of it.
that may be the case but (imo)
this looks pretty good but a few comments
this seems to have taken the approach of taking a fully formed ID text
and trying to parse and check it, not an unreasonable approach but was
the alternative of having the submitter fill in some or all of the meta
data on a submission form (authors names
Bill says:
actually, i think that the WG chairs are the -wrong- people
to ensure that the right text is part of each -00 IDs. you
really want proper legal review of each -00 id to ensure that
the copyright text is correct/intact.
I do not recall saying anything
bill continues to insist:
Hum this follows from the last para of your email, excerpted
below, where you intimate that an idea for making this work is
to require WG chairs to pre-approve the submission of -00 WG IDs.
nope - the WG chairs decide if the ID is one the WG
High order bit: To me Scenario C contains significant complexity and
risk when compared to Scenario O while providing, in my opinion, no
useful advantages.
some observations:
Both Scenarios depend on the development of a job description for an
admin director of some kind - as has been mentioned
Karl Auerbach reminded me in private mail (forwarded with permission)
On Tue, 21 Sep 2004, scott bradner wrote:
The Scenario C document says that there are 3 prerequisites required
before the option of a corporation can be considered viable at all
...
3/ assurance that a corporation
Harald opines:
re: 1/ Considering the level of participation in this discussion on the
IETF list I do not see how one could assert that there was IETF
consensus without an explicit discussion at an IETF plenary - I do not
think that just issuing a last call (as envisioned by the Scenario
But I bet not for tragic events like terrorist strikes/threats or war related
issues. So setting up some reserves of our own seems better to me.
those options are not exclusive
it's a very good idea to have reserves, its also a good idea to
explore event cancellation insurance
Scott
Bert justifies by:
Besides my (wordy) response to you back on Sept 4th (or 3rd in US)
as availabe at:
http://www1.ietf.org/mail-archive/web/ietf/current/msg31057.html
which I read as saying
I distrust the IETF's ability to react if things get bad
with the ISOC
I do not
Bert,
well, I think we will just have to agree to disagree
people have heard both of our opinions and should express their own
on the list /or in Harald's survey tool
Scott
___
Ietf mailing list
[EMAIL PROTECTED]
]
To: [EMAIL PROTECTED] (scott bradner)
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: Re: Copying conditions
References: [EMAIL PROTECTED]
From: Sam Hartman [EMAIL PROTECTED]
Date: Sun, 10 Oct 2004 16:02:02 -0400
In-Reply-To: [EMAIL PROTECTED] (scott
small quotes are fine (under fair use) but significant excerpts are not
(under normal copyright law and under the copyright notices on IETF RFCs)
Scott
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
Simon sez:
For IDN, I want to be able to extract the tables from RFC 3454 and use
them in my implementation.
For Kerberos, I want to be able to use the ASN.1 schema in my
implementation, and copy the terminology section into my manual.
For SASL, I want to incorporate portions of the
Does this qualify as a small quote?
sigh
reprinting full RFCs has been permitted encouraged ever since RFCs
were first published - the copyright on the RFCs makes that clear
Scott
___
Ietf mailing list
[EMAIL PROTECTED]
I do think that some patent holders want to make their technology
available to the free software community. I believe that if the free
software community agreed on what it wanted, it would be reasonable
for the IETF to pass that along to IPR holders as information to
consider when drafting
eric is saying that the previous situation
whereby a draft author surrendered the IPR before RFC publication was better.
that has never been a requirement
Scott
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
Jeff Schiller was the second Security AD, who started around 1994 or so.
I forget exactly when.
see http://www.ietf.org/iesg_mem.html
Scott
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
but according to RFC 3667, the only
organization permitted to produce such derivative works would be
ISOC/IETF.
this is the way that its been since rfc 2026
note that an rfc can be copied in full with no problems
and that an author can give permission to produce derivative works
its just
If you extract, say, a C header file, or an ASN.1 schema, from an RFC
into an application, I believe that may be regard as a derivative
work.
see RFC 3667 Section 3.3 (a) (E)
(E) to extract, copy, publish, display, distribute, modify and
incorporate into other works, for any
1 - 100 of 299 matches
Mail list logo
