[EMAIL PROTECTED] has already been denied posting rights on at least
one IETF WG mailing list because of this behaviour.
Is it time to dig out RFC 3683/BCP 83?
BTW - has anyone, anywhere ever seen a response from him/them when they
have been asked to stop spamming the IETF lists?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
All,
please find below the draft call for applications for the IAD position.
The current timeline for moving forward is as follows
DEC 18 Send out call for applications to
o IETF-Announce list
o ISOC announcement
On Thu, Dec 16, 2004 at 08:45:51AM +0100, Harald Tveit Alvestrand wrote:
[EMAIL PROTECTED] has already been denied posting rights on at least
one IETF WG mailing list because of this behaviour.
Is it time to dig out RFC 3683/BCP 83?
BTW - has anyone, anywhere ever seen a response from
Hello,
This is an update from the Old Standards experiment. Below are a list
of proposed standards that are candidates to be obsoleted. The old
standards mailing list has vetted out a good number, but still a good
number remains. We are looking for experts who can say affirmatively
whether
Typos etc. are easily fixed (in-line).
Isn't it normal to give a closing date for applications rather than to
say when evaluation of applications will start? It might also be usual
to indicate from when we are hoping to fill the post.
Is Salary levels commensurate with experience and
On Dec 16 2004, at 12:46 Uhr, Eliot Lear wrote:
RFC1618 PPP over ISDN
We had a short discussion about this in pppext.
The gist was: The document is pretty bad (partly because things were
murky in 1994, but also because it was written by Martians that had no
space ship to take them to the
Is Salary levels commensurate with experience and qualifications a
cop-out? You might say expected to be in the range...
Adrian
Agree with Adrian here - commensurate makes sense when you hire
several people with a range of experience, or when you are waiting to
see who actually applies before
Scott Bradner wrote:
I actually wonder if this is an issue for the IASA BCP document,
because it is about the Transition Team Transparency.
I do not think it is
So I propose to remobve it from the iasa-bcp queue or declare it
as No change needed.
makes sense to me
Agreed
Brian
I'm initially really surprised 1518/1519 is on this list. Wasn't there
recent talk (like last week) of extending CIDR? And if this is true,
shouldn't that work be completed before the existing docs are moved out to
the pasture?
At 12:46 PM 12/16/2004 +0100, Eliot Lear wrote:
Hello,
This is an
The current timeline for moving forward is as follows
DEC 18 Send out call for applications to
o IETF-Announce list
o ISOC announcement lists
o NANOG, SANOG, NORDNOG, AFNOG, etc
o Ask RIRs to forward to their respective announcement lists
That's pretty tight... 24
James M. Polk wrote:
I'm initially really surprised 1518/1519 is on this list.
Obviously, it's a bug. Of the Proposed Standards that the Internet
runs on, those are among the most important. I believe this was
pointed out on the old-standards list already, but it must have
got lost.
Brian
On Dec 16 2004, at 14:02 Uhr, Margaret Wasserman wrote:
RFC0885 Telnet end of record option
This option was, at least at one time, used for telnet clients that
connected to IBM mainframes... It was used to indicate the end of a
3270 datastream.
... and 5250 (RFC2877).
Note that there was
On 16-dec-04, at 14:55, Carsten Bormann wrote:
It's probably necessary to do a full dependency analysis to do this
right.
OMG, what a visit to the technology attic.
Why do we care if there are still implementations that are based on
these documents in use?
The important question is whether
Why do we care if there are still implementations that are based on
these documents in use?
The important question is whether there are going to be new or revised
implementations based on these documents.
A new implementation for tn5250 is about as likely as a new
implementation for NTP.
Margaret,
Thanks for your note. Please see below for responses:
Margaret Wasserman wrote:
RFC0885 Telnet end of record option
This option was, at least at one time, used for telnet clients that
connected to IBM mainframes... It was used to indicate the end of a
3270 datastream. I
Maybe we need a new category STABLE?
I don't think that would be a good name since it might imply that others
are INSTABLE ;-). Perhaps FROZEN, STATIC, MATURE?
...George
George Swallow Cisco Systems
Could this not be used for an enhancement? The IETF needs to globalize, to
motivate and reward its members (see current analysis), to motivate (cf.
RFC 3869) local Govs (meeting, debates, PR announces) and industries (PR on
products) and to get independent and stable money for its budget.
Why
Bert,
I'll remove it from the list with the expectation that the new MIB will
obsolete the old one. However, I note that is currently not stated in
the header of the draft.
Eliot
Wijnen, Bert (Bert) wrote:
W.r.t.
RFC1269 Definitions of Managed Objects for the Border Gateway
The way we've been running the experiment, if there is a portion of the
doc that is still useful then we leave it alone but recommend an update.
In other words no status change until someone takes further action.
Having said that, I will remove RFC 1618 from the list, but it would be
great if
*
* 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]
*
Based on the comments over the last several days and my
interpretation of RFC 3683/BCP 83, I ask the firm of
Upper Side, Paris France, to STOP POSTING COMMERCIAL NOTICES
to the IETF general list [EMAIL PROTECTED]
I quote from RFC 3683/BCP 83:
Guidelines have been developed for dealing with
I see this exercise has already reached the point of absurdity.
How can it possibly be worth anyone's time to look at each telnet option and
determine whether it is deployed? What possible purpose could be achieved
by changing the standards status of some telnet option? Is there some
Harald Tveit Alvestrand wrote:
[EMAIL PROTECTED] has already been denied posting rights on at
least one IETF WG mailing list because of this behaviour.
Is it time to dig out RFC 3683/BCP 83?
BTW - has anyone, anywhere ever seen a response from him/them when
they have been asked to stop
Eliot Lear wrote:
This is an update from the Old Standards experiment. Below are a list
of proposed standards that are candidates to be obsoleted.
RFC1793 Extending OSPF to Support Demand Circuits
the NEMO Basic Support protocol
From: [EMAIL PROTECTED] [mailto:ietf-languages-
[EMAIL PROTECTED] On Behalf Of Bruce Lilly
The point is that under RFC 3066,
the bilingual ISO language and country code lists are
considered definitive.
That is nowhere stated or even suggested in RFC 3066.
RFC 3066 section 2.2
Eric Rosen wrote:
Let me echo Bob Braden's if it's not broken, why break it? query.
Because maybe it is broke. Even if someone *has* implemented the telnet
TACACS user option, would a user really want to use it? The process is
broke. We say in 2026 that proposed standards should hang around
On Thu, 16 Dec 2004, Brian E Carpenter wrote:
James M. Polk wrote:
I'm initially really surprised 1518/1519 is on this list.
Obviously, it's a bug. Of the Proposed Standards that the Internet
runs on, those are among the most important. I believe this was
pointed out on the old-standards list
Carsten Bormann wrote:
RFC1618 PPP over ISDN
We had a short discussion about this in pppext.
The gist was: The document is pretty bad (partly because things were
murky in 1994, but also because it was written by Martians that had no
space ship to take them to the ISDN planet),
(sorry,
This is a simple way to simply do what we said we were going to do.
The worries about this whole anti-cruft business have always been (a) the
likelihood that it would do more harm than good, and (b) the likelihood that
it would waste enormous amounts of time on issues of no importance.
Let me try a slightly different cut on the discussion.
1/ I believe the IETF is trying to address the fact we would like
to be able to accept support in chunks that are greater than
individual meeting fees, and less than $100kUS. IMHO,
it's not that the IETF needs to be able to accept
Bob Braden wrote:
If it's not broken, why break it?
* Standards have been invented for creating markets.
That's strange, all these years I thought standards were for
interoperability.
Hear, Hear!
Folks, I took a look at the first posting, and was surprised at those
where I'm personally
Hi Leslie -
There's something I'm not quite understanding, and I was wondering if others
might share my confusion.
I can think of two reasons why taking small targeted donations is bad:
1. It's a pain to administer and account for.
2. It screws up the overall marketing plan in some way (e.g.,
At 05:53 PM 12/16/2004, William Allen Simpson wrote:
RFC1828 IP Authentication using Keyed MD5
RFC1829 The ESP DES-CBC Transform
Now *THESE* were historic when written! Due to US government pressure,
it took years (and big plenary protests) for them to be published!
Especially
Hi,
On Thu, 16 Dec 2004, John C Klensin wrote:
[...]
I suggest that the RFC Editor's traditional rule about normative
references from standards track documents to things of a lower
maturity level should apply here as well, even going backwards.
If you think there is value in RFC 1517, and it makes
Eric Rosen wrote:
Even if someone *has* implemented the telnet TACACS user option, would a
user really want to use it?
I don't know. Do you?
Yes, I do. Many of us do. And that's the point.
How do we go about answering a question like that?
We will spend less time discussing that
Carsten,
please read draft-ietf-newtrk-cruft-00.txt, in particular section 3.2, and
see if it answers your question this has been a major discussion
source
Harald
--On 16. desember 2004 15:40 +0100 Carsten Bormann [EMAIL PROTECTED]
wrote:
So what does HISTORIC
RFC0885 Telnet end of record option
This option was, at least at one time, used for telnet clients that
connected to IBM mainframes... It was used to indicate the end of a
3270 datastream. I don't know if it is still used in that fashion,
but Bob Moskowitz might know.
RFC1041
Eliot Lear wrote:
RFC1277 Encoding Network Addresses to Support Operation over
Non-OSI Lower Layers
This is still in use.
draft-melnikov-nsap-ipv6-00.txt references it and in theory it can be
updated to include bits of RFC 1277 which are still relevant.
On 16 dec 2004, at 04.18, Kurt Erik Lindqvist wrote:
-BEGIN PGP SIGNED MESSAGE-
The IETF Administrative Entity
Isn't it the transition team that is seeking the IAD at this point?
is seeking a highly capable individual
to serve as Administrative Director. You will report to the
W.r.t.
RFC1269 Definitions of Managed Objects for the Border Gateway
Protocol: Version 3
Why would this be cruft? The BGP4 MIB was just recently approved...
Good thing too. Take a good look at 1269. I don't think it would pass
a MIB compiler test today.
* From [EMAIL PROTECTED] Thu Dec 16 05:23:25 2004
* Mime-Version: 1.0
* Date: Thu, 16 Dec 2004 08:02:44 -0500
* To: Eliot Lear [EMAIL PROTECTED], IETF Discussion [EMAIL PROTECTED]
* From: Margaret Wasserman [EMAIL PROTECTED]
* X-Spam-Score: 0.1 (/)
* X-Scan-Signature:
From: Eric Rosen [EMAIL PROTECTED]
I see this exercise has already reached the point of absurdity.
How can it possibly be worth anyone's time to look at each telnet option and
determine whether it is deployed? What possible purpose could be achieved
by changing the standards status
Eliot Lear writes:
I'll remove it from the list with the expectation that the new MIB
will obsolete the old one. However, I note that is currently not
stated in the header of the draft.
I think RFC1269 (BGP-3 MIB) can safely be dropped even today, because
nobody is using BGP-3 anymore, and as
William Allen Simpson [EMAIL PROTECTED] writes:
RFC1598 PPP in X.25
RFC1618 PPP over ISDN
At one time, these were incredibly important in the 3rd world, and
some parts of Europe and Japan. Is X.25 completely non-existant
today? Heck, folks were running X.25 over ISDN
--On Thursday, 16 December, 2004 22:07 +0200 Pekka Savola
[EMAIL PROTECTED] wrote:
On Thu, 16 Dec 2004, Brian E Carpenter wrote:
James M. Polk wrote:
I'm initially really surprised 1518/1519 is on this list.
Obviously, it's a bug. Of the Proposed Standards that the
Internet runs on,
The IESG has received a request from the IP Version 6 Working Group WG to
consider the following document:
- 'Internet Control Message Protocol (ICMPv6)for the Internet Protocol Version
6 (IPv6) Specification '
draft-ietf-ipngwg-icmp-v3-06.txt as a Draft Standard
The IESG plans to make a
47 matches
Mail list logo
