Could someone point me in the direction of any standards being developed
by the ietf regarding the interaction of the telecom SS7 network and
RSVP or diffServ?
Thanks for any help.
Jane
Hi
Very appropriate for XKCD to post this just a few days before an IETF
meeting.
http://www.xkcd.com/927/
(For those who are not familiar with XKCD, don't miss the alt-text on the
picture)
Yoav
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.or
e made for
breathing room for the implementer to be able to build a market (or
market share), but assessing a toll at the end of the standard
development process is parasitic. In the end, crippled standards like
this will lead to the fragmentation of the Internet.
Of course, this whole issue can b
Hi All,
I am working on a telecom project and am totally
new to CDR file formats. CDR files are files where call detail records are kept.
I want to know more about the following formats.
Variable lengthASN.1/TLVGPRS CDR
Can anybody help ? Please also let me know the
sources from which I
I LOVE this one.
Bert
On 7/20/11 8:23 AM, Yoav Nir wrote:
Hi
Very appropriate for XKCD to post this just a few days before an IETF
meeting.
http://www.xkcd.com/927/
(For those who are not familiar with XKCD, don't miss the alt-text on the
picture)
Yoav
___
[Helmet on]
Maybe they should first move the 14 competing standards to Historic.
On 7/20/11 10:17 AM, "Bert (IETF) Wijnen" wrote:
>I LOVE this one.
>
>Bert
>
>On 7/20/11 8:23 AM, Yoav Nir wrote:
>> Hi
>>
>> Very appropriate for XKCD to post thi
> From: Yoav Nir [y...@checkpoint.com]
>
> Very appropriate for XKCD to post this just a few days before an IETF
> meeting.
>
> http://www.xkcd.com/927/
And yet sometimes a standard will sweep away everything that was
before it.
One remarkably successful case is "ASCII" (containing the 26 lette
yet sometimes a standard will sweep away everything that
> was before it.
If "sweep away" is something that occurs after many years of
competing standards and a long period of time in which the
outcome was not clear, then sure. If you believe that either
ASCII or TCP/IP quickly &qu
> From: John C Klensin [john-i...@jck.com]
>
> If "sweep away" is something that occurs after many years of
> competing standards and a long period of time in which the
> outcome was not clear, then sure.
Yes. In the sense that over the long run, the number of &quo
Dear IETF,
I'd like to express opposition to approval of the RedPhone patented "TLS
authorization" standard application before you. Although the internet is
obviously a tool for the creation of great wealth, it seems to me the 'net's
regulatory bodies shouldn't allow themselves to be used to en
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.)
___
Ietf mailing list
[EMAIL PROT
You indicated that my criticism was incorrect regarding Mr. Klensin's
understanding of the standards process in regards to the description of
the current SMTP Standard. So, now I am confused, and would like to learn
how to correctly evalute the status of IETF Standards.
The following que
All,
Knowing my interest in this subject, Randy Bloomfield of the International
Center for Standards Research (university of Colorado, Boulder
International Telecommunications Program) has been kind enough to forward a
number of e-mails on this issue. Enough, so that I thought I might try to
At 18:02 2000-05-04 Lillian Komlossy wrote:
>The whole world will not switch over to Unix
>- the average user will always be more confortable with Windows
The whole world might not be comfortable with Windows but many,
many of my collegues around the world work at companies where
they have abso
Hi friends,
We are working on enabling SNMP provisioning of SONET features of a
transport Node.
We are currently referring to RFC 2558 . But, this is not able to
serve our purpose.
Please suggest us any other RFCs which may be relevant( We are
paticularly not
able to find the alarm(Tra
>
> > if AOL subscribers cared about standards
> > compliance they would have left AOL long ago.
>
> You're wrong about that. Remember when AOL didn't have anything to do
> with the Internet? That the standards for some of the ser
Dear all
Can anyone point me to a right site where consist of articles on RF
modulation standards?
Thanks
mano
Thanks and Best Regards
Have a Good Day
Manohar Menon
Fixed Network Planning Products
Plot 12155 ( Lot 13),
Jalan Delima 1/1,
Subang Hi-Tech Ind. Est Park
4 Shah
Hello all,
There are a number of Full Standards (STD20-24), that, IMO, need
revsising. Firstly, all of these documents define the protocols only
for TCP and UDP, and that might be useful to define them for such
protocols, as DCCP or SCTP. Moreover, in spite of being the Full
Standards, it
Hi, Refer http://samirsrivastava.typepad.com for posting on Standards
And Patents. Copyright of posting on Standards And Patents is free for
personal usage. Arguments were presented in favour of that standards
and their usage should be free from patents. If standards are
patentable then
n there is increasing awareness of the importance of
supporting truly open standards that can be implemented by anybody
without recourse to licensing, it would be a truly retrograde step to
allow this patent-encumbered standard to be approved.
I urge the IETF to send a strong signal in suppo
Hi. I had intended to bring this up at the plenary last night
but, since I had not raised it on the list and was tired,
decided not to.
Our standards process (RFC2026 and updates) more or less assumes
that documents progress from idea -> I-D -> Proposed -> Draft ->
Full. Ignore,
Since the IETF list is obviously in rehash-of-WG-discussion mode today, I
thought I'd contribute to the flamage, and rehash the logic behind the list
of old standards that arrived in your inboxes a few days ago.
Let's look back on what the IETF has decided previously.
In 1994
0
*> X-Spam-Score: 0.0 (/)
*> X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea
*> Content-Transfer-Encoding: 7bit
*> Subject: List of standards
*> List-Id: IETF-Discussion
*> X-ISI-4-32-5-MailScanner: Found to be clean
*> X-ISI-4-30-3-MailScanner: Found to be clean
--On 17 August 2004 09:20 -0700 Bob Braden <[EMAIL PROTECTED]> wrote:
*> From: Iljitsch van Beijnum <[EMAIL PROTECTED]>
*>
*> 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
Bob,
I think the intent of Iljitsch's note was that the "list of IETF
Standards" should appear in an obvious place (labeled "IETF
Standards") on http://www.ietf.org/ - if the label points to
http://www.rfc-editor.org/rfc.html, that's fine.
... leaving the qu
On 18-aug-04, at 13:15, Spencer Dawkins wrote:
I think the intent of Iljitsch's note was that the "list of IETF
Standards" should appear in an obvious place (labeled "IETF
Standards") on http://www.ietf.org/ - if the label points to
http://www.rfc-editor.org/rfc.html,
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> writes:
> --On 17 August 2004 09:20 -0700 Bob Braden <[EMAIL PROTECTED]> wrote:
>
>> *> From: Iljitsch van Beijnum <[EMAIL PROTECTED]> *>
>> *> Why is the list of internet standards so hard to find?
to:[EMAIL PROTECTED] On Behalf Of Glen
Zorn
Sent: Wednesday, August 18, 2004 9:31 AM
To: 'Ian Cooper'; 'Bob Braden'
Cc: [EMAIL PROTECTED]
Subject: RE: List of standards
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> writes:
> --On 17 August 2004 09:20 -0700 Bob Brad
ndard"
> is NOT a "request for comments".
Sigh. If this is the issue, could someone please initiate a
request to the IESG or Secretariat to change that link to read
"Internet Standards Index and RFC Materials" or something to
that effect (please take the wordsmithing offl
At 16:29 17/08/04 +0200, 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.)
See: http://www.rfc-edito
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
On 19 aug 2004, at 23:23, Joe Touch 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
It deserves top ranking on search engines;
So are you saying that we should put our trust into the undisclosed
> >> 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
>
> > It deserves top ranking on search engines;
>
> So are you saying that we should put our trust int
At 04:29 PM 08/17/04 +0200, Iljitsch van Beijnum wrote:
Why is the list of internet standards so hard to find?
I dunno. I tend to look for the most recent one in
http://www.ietf.org/rfc/rfc-index.txt. The most recent one I find is
http://www.ietf.org/rfc/rfc3700.txt.
Or, alternatively, I have a
provides more information than
http://www.ietf.org/rfc.html
I would actually like to point to the IETF site for Internet Standards.
The IETF RFC page would be my first choice if it included a bit more
text to explain what an RFC is, and a pointer to the list of standards
maintains by the R
It appears that IEEE 802 is now making many of their
standards available online at no cost in PDF format. Details
and limitations of this are available online at:
http://standards.ieee.org/getieee802/
Please don't ask me any further questions, because
the above i
ed "no", I don't see the
point of going into details.
The "Obsoletes:" header is a protocol that is too weak to carry the full
semantics of the relationship between documents.
Proposed Standards are being used in the real world, for reasons that the
users of those stand
--On tirsdag, juni 03, 2003 17:28:55 -0400 Dean Anderson <[EMAIL PROTECTED]>
wrote:
You indicated that my criticism was incorrect regarding Mr. Klensin's
understanding of the standards process in regards to the description of
the current SMTP Standard. So, now I am confused, and wo
IL PROTECTED]>
> wrote:
>
> >
> > You indicated that my criticism was incorrect regarding Mr. Klensin's
> > understanding of the standards process in regards to the description of
> > the current SMTP Standard. So, now I am confused, and would like to learn
> &g
On Wed, 04 Jun 2003 11:54:03 EDT, Dean Anderson said:
> Implementors are not the only users of standards. Businsess seek to
> purchase and sell "Standard" Services, and may receive just and public
> criticism for not providing the services they claim to provide. In some
&g
ED] wrote:
> On Wed, 04 Jun 2003 11:54:03 EDT, Dean Anderson said:
>
> > Implementors are not the only users of standards. Businsess seek to
> > purchase and sell "Standard" Services, and may receive just and public
> > criticism for not providing the services
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
> IPR is taken into account
> when it is time to advance a standard on the standards track
and in practice, IPR is also taken into account by individual
participants (if they know about it) when they decide whether
to contribute to a consensus for Proposed Standard.
Keith
> Rather than making fun of or scream "stupid", why don't we keep
> developing and arguing for standard based 'solutions':
You mean like RFC 2046?
The recommended action for an implementation that receives an
"application/octet-stream" entity is to simply offer to put the data
in a fil
Keith Moore wrote:
> Perhaps unfortunately, RFC 2046 doesn't come right out and say
> "DON'T EXECUTE CONTENT IN EMAIL MESSAGES".
>
> Then again, it doesn't say DON'T CUT YOUR CUSTOMER'S ARM OFF either.
Don't be silly; a vendor would never cut a customer's arm off. How would
they pull out their
] From: Keith Moore <[EMAIL PROTECTED]>
] ...
]You could have senders sign any executables. That might help a little,
] > as long as the sender's machine hasn't been compromised.
]
] this would also help, but we'd need a better way to verify the sender's
] signature than we have now.
On Thu, May 04, 2000 at 05:24:35PM -0600, Vernon Schryver wrote:
> ] From: Keith Moore <[EMAIL PROTECTED]>
>
> ] ...
> ]You could have senders sign any executables. That might help a little,
> ] > as long as the sender's machine hasn't been compromised.
> ]
> ] this would also help, but
> ] ...
> ]You could have senders sign any executables. That might help a
> ] little, as long as the sender's machine hasn't been compromised.
> ]
> ] this would also help, but we'd need a better way to verify the sender's
> ] signature than we have now.
>
> It wouldn't help much, un
In message <[EMAIL PROTECTED]>, Keith Moore writes:
>
>note that it takes a nontrivial user interface to communicate this to
>a recipient of email: e.g.
>
> NOTE: this message was signed by someone purporting to be
> Keith Moore <[EMAIL PROTECTED]>. The signature is validated
> by a certifi
On Thu, 04 May 2000 17:24:35 MDT, Vernon Schryver <[EMAIL PROTECTED]> said:
> It wouldn't help much, unless you are of the religion that believes
> authentication implies authorization. Or don't you think that
Unfortunately, some people are as neuron-paralized by this religion
as by many others
On Thu, 04 May 2000 15:25:37 EDT, Keith Moore said:
> Perhaps unfortunately, RFC 2046 doesn't come right out and say
> "DON'T EXECUTE CONTENT IN EMAIL MESSAGES".
>
> Then again, it doesn't say DON'T CUT YOUR CUSTOMER'S ARM OFF either.
>
> not that it would matter if it did...
There's simple ina
It may just be time for the IETF to develop a financial standards work group
seperate from the applications work group. I can even forsee a Simple Cash
Transfer Protocol? any objections?
Yours sincerely,
Nyagudi Musandu
On 27/Jul/11 08:07, Samir Srivastava wrote:
> Standards are developed by community & for community. There is no
> role of patent hunters in that.
I agree, with the exception of "defensive" patents, some of which are
announced with very elegant disclosures. Let's draw a v
ed by companies with
the help of international standards bodies - such as those Motorola Mobility
holds for Wi-Fi and online video - should be available for licensing on a fair
and nondiscriminatory basis.
...
'Actions aimed at preventing the sale of products that rely on industry
standards threaten to
For your information the IUSG (interested in the Intelligent Use of
the whole digital ecosystem) has just released the following statement
which reflect a friendly but non-IETF evaluation of the "Modern Global
Standards Paradigm" document proposed by the IETF and IAB Chairs to
the endo
s. IMHO we need to free human brain & cpu for
more important issues. It is not fair for people who work on
unpatented baselines specifications. What would have been situation if
IP header was patented? Thx Samir
On 7/27/11, Alessandro Vesely wrote:
> On 27/Jul/11 08:07, Samir Srivastava wrote:
tuation if
> IP header was patented? Thx Samir
>
>
> On 7/27/11, Alessandro Vesely wrote:
>> On 27/Jul/11 08:07, Samir Srivastava wrote:
>>> Standards are developed by community & for community. There is no
>>> role of patent hunters in that.
>>
>
Best IETF,
In response to the recent TLS submission, I would like to ask you sincerely to
reject at all levels any standard which relies on proprietary or otherwise
commercially-based technologies. Thank you very much for your consideration.
Best regards,
Ismael Fal
[EMAIL PROTECTED]
http://i
John,
On 2007-12-07 05:20, John C Klensin wrote:
Hi. I had intended to bring this up at the plenary last night
but, since I had not raised it on the list and was tired,
decided not to.
Our standards process (RFC2026 and updates) more or less assumes
that documents progress from idea ->
hture,
From: Brian E Carpenter [mailto:[EMAIL PROTECTED]
Sent: Thu 06/12/2007 3:18 PM
To: John C Klensin
Cc: ietf@ietf.org
Subject: Re: Revising full standards
John,
On 2007-12-07 05:20, John C Klensin wrote:
> Hi. I had intended to bring this up at the plenary la
Hardly seems worth the effort.
Of the 5092 RFCs published, just 67 are Full Standards.
Of those, how many realistically need updates?
Ad hoc may be a more efficient approach. Or, are you thinking about a
"lessons learned from RFC 2821-bis"?
On 12/6/07 8:20 AM, "John C K
--On Thursday, 06 December, 2007 16:55 -0800 Eric Burger
<[EMAIL PROTECTED]> wrote:
> Hardly seems worth the effort.
>
> Of the 5092 RFCs published, just 67 are Full Standards.
>
> Of those, how many realistically need updates?
>
> Ad hoc may be a more effic
etf/lemonade> for what lemonade is.
- Original Message -
From: John C Klensin <[EMAIL PROTECTED]>
To: Eric Burger; ietf@ietf.org
Sent: Thu Dec 06 18:25:39 2007
Subject: Re: Revising full standards
--On Thursday, 06 December, 2007 16:55 -0800 Eric Burger
<[EMAIL PROTECTED]>
ardstrack.com/ietf/lemonade> for what lemonade is.
- Original Message -
From: John C Klensin <[EMAIL PROTECTED]>
To: Eric Burger; ietf@ietf.org
Sent: Fri Dec 07 05:35:55 2007
Subject: Re: Revising full standards
--On Thursday, 06 December, 2007 19:33 -0800 Eric Burger
<[EMAIL
nowhere. Of course, as soon as
one attaches a date, one has solved a problem different from
"stable identifier for the current version of the standard".
And, of course, unless these can identify other than Full
Standards, they don't solve any of the STD problem that concerns
me.
An
t STD
is unacceptable and the fact that there are multiple competing standards bodies
out there and the IETF can benefit from the branding leverage.
One of the experimental results we might deduce from the relative success of
IETF application protocols over their OSI competitors is that text b
At 04:55 PM 12/6/2007, Eric Burger wrote:
Hardly seems worth the effort.
Of the 5092 RFCs published, just 67 are Full Standards.
The real issue is not "STANDARDs", but "standards". The great majority
of today's operational Internet protocol standards have status (ca
* The RFC Editor discovers that the community doesn't
quite know what to do with the STD number: It can't be
reassigned to the new document because it is at
Proposed. I shouldn't be left on the original document
because it really isn't our latest and bes
At 12:34 PM 12/6/2007, Hallam-Baker, Phillip wrote:
The numbering is problematic for many reasons, people have difficulty
keeping two sets of numeric identifiers straight. If you want me to refer
to something other than RFC-822 you have to give me something more
memorable to both myself and the
here to find the expected
replacement for RFC 821 and friends, ie 2821, in the standards
track.
Bob Braden
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
I'd second the motion to whack STD designation. Nobody wants STD's, anyway ;-)
I believe that many people want stable definitions of "well-known" Internet
standards.\,
like SMTP (or IP, for that matter). STDs were a relatively simple but
inadequate
solution for t
Bob Braden wrote:
I'd second the motion to whack STD designation. Nobody wants STD's,
anyway ;-)
I believe that many people want stable definitions of "well-known" Internet
standards. like SMTP (or IP, for that matter). STDs were a relatively
simple but inadequate solut
from others) to go to IETF-foo-2010 types of
names solves one problem, but does not solve the problem of
needing a _stable_ reference to the current state of a standard,
nor the problem of assignment of designators to Proposed and
Draft Standards. It, too, almost certainly requires an updat
number (still) accomplishes.
It's a new way into the maze and I think it's worth doing quickly, since
it doesn't misrepresent the formal standards process in any way. Ideally,
www.rfc-editor.org/smtp and www.rfc-editor.org/STD10 would also
take you straight there too. (Tools pro
standard).
On a lexical level I would suggest that the default mnemonic be
IETF-[-]- where the specifier is optional.
This allows for the various PKIX standards to be grouped together: IETF-PKIX,
IETF-PKIX-OCSP, IETF-PKIX-SCVP and so on.
In the case of a WG that is chartered to revise an
n't misrepresent the formal standards process in any
way. Ideally,
www.rfc-editor.org/smtp and www.rfc-editor.org/STD10 would also
take you straight there too. (Tools prototype?)
Of course, if "STD10" is a separate document, we are on the path
to ISDs. If it isn't, RFC 2026
STD series -- symbolic
names are *already* used by people who aren't immersed
in the standards process. Eg people refer to the email
transport protocol as SMTP, not STD-10.
I think that, for implementors and adopters alike, a
single, absolute definition is too simplistic a view to
be meaning
my final point. I am
*> fully in favour of a symbolic naming convention for STDs.
*> But that won't help rejuvenate the STD series -- symbolic
*> names are *already* used by people who aren't immersed
*> in the standards process. Eg people refer to the email
*>
--On 11. desember 2007 06:22 -0500 Iain Calder <[EMAIL PROTECTED]> wrote:
I think that, for implementors and adopters alike, a
single, absolute definition is too simplistic a view to
be meaningful in today's world. Merely renaming the STD
series won't solve the problem of deciding when/if the
Iain Calder wrote:
their descendants. For example, suppose a completely
different protocol called IEP (Internet Email Protocol)
arises in the future and, due to its vastly superior
characteristics, becomes the dominant mail transport
system. SMTP would then become historic and IEP would
need
On Tue, 11 Dec 2007, Iain Calder wrote:
>
> Protocols *can* get pushed aside by challengers that aren't their
> descendants. For example, suppose a completely different protocol
> called IEP (Internet Email Protocol) arises in the future and, due to
> its vastly superior characteristics, becomes t
I don't see the relevance of a service label such as 'email' in the context of
standards identifier either.
I do not think that there is any real likelihood that SMTP will be displaced by
another email protocol ever. When SMTP is displaced it is going to be displaced
by someth
7 10:43 AM
To: Iain Calder
Cc: ietf@ietf.org
Subject: Re: Revising full standards
On Tue, 11 Dec 2007, Iain Calder wrote:
>
> Protocols *can* get pushed aside by challengers that aren't their
> descendants. For example, suppose a completely different protocol
> called IEP (Interne
*> On a lexical level I would suggest that the default mnemonic be
IETF-[-]- where the specifier is optional.
*>
s are often chosen to be cute amd are rather obscure to all but
the most IETF-centric, so they are probably not a useful source for
short names of specific standards. N
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 mea
On Thu, 16 Dec 2004, William Allen Simpson wrote:
Folks, I took a look at the first posting, and was surprised at those
where I'm personally knowledgable.
RFC1378 The PPP AppleTalk Control Protocol (ATCP)
It was widely implemented. I still use this. My $1000 HP LaserJet 4ML
works fine, it
On Dec 16 2004, at 18:13 Uhr, Harald Tveit Alvestrand wrote:
please read draft-ietf-newtrk-cruft-00.txt, in particular section 3.2,
Ah good, I did.
o Usage. A standard that is widely used should probably be left
alone (better it should be advanced, but that is beyond the scope
o
en the time the obsoleting
document is approved and the publication of the RFC.
But I think the old-standards team can take RFC 1269 off the list with a
note saying "obsoleted by draft-ietf-idr-bgp4-mib, no action necessary".
Good!
Harald
_
Pekka Savola wrote:
There's certainly no illusion that these protocols are not being used
in some part(s) of the universe.
The question is really whether the IETF is interested in maintaining
them any longer, and whether we expect significant new deployments of
these protocols.
Marking the doc
Pv6 soon (for the past decade). So, the WG wasted its
time on IPv6
So, here's my promise to you. I'll track down McGregor, and we'll
write something up. I will work on moving my Proposed Standards,
assuming that the IESG is actually _interested_ in doing its job.
The proof will
thing else is not a good thing either for the
Internet (what ever the "Internet" may then mean since IETF says it is the
adherence to its Internet documents).
Then may be someone will consider publishing the "Internet Book" were the
consequences of the valid standards and R
needed
>
> which usually means that the shepherding AD needs to fiddle
> with the RFC Editor note in the announcement before sending it.
>
> It's one of the oddities of the way we process data that it's
> quite hard to know that something's already obsoleted bet
--On fredag, desember 17, 2004 11:56:43 -0500 John C Klensin
<[EMAIL PROTECTED]> wrote:
But I think the old-standards team can take RFC 1269 off the
list with a note saying "obsoleted by draft-ietf-idr-bgp4-mib,
no action necessary".
Harald,
Sorry, but I've got a procedu
--On Friday, 17 December, 2004 22:31 +0100 Harald Tveit
Alvestrand <[EMAIL PROTECTED]> wrote:
>
>
> --On fredag, desember 17, 2004 11:56:43 -0500 John C Klensin
> <[EMAIL PROTECTED]> wrote:
>
>>> But I think the old-standards team can take RFC 1269
--On fredag, desember 17, 2004 11:49:04 -0500 William Allen Simpson
<[EMAIL PROTECTED]> wrote:
So, here's my promise to you. I'll track down McGregor, and we'll
write something up. I will work on moving my Proposed Standards,
assuming that the IESG is actually _interes
Harald Tveit Alvestrand wrote:
--On fredag, desember 17, 2004 11:49:04 -0500 William Allen Simpson
<[EMAIL PROTECTED]> wrote:
So, here's my promise to you. I'll track down McGregor, and we'll
write something up. I will work on moving my Proposed Standards,
assuming that
--On lørdag, desember 18, 2004 13:04:52 -0500 William Allen Simpson
<[EMAIL PROTECTED]> wrote:
So, here's my promise to you. I'll track down McGregor, and we'll
write something up. I will work on moving my Proposed Standards,
assuming that the IESG is actually _interes
> "John" == John C Klensin <[EMAIL PROTECTED]> writes:
John> Harald,
John> Sorry, but I've got a procedural problem with this. I-Ds
John> can't obsolete anything, even I-Ds approved by the IESG.
John> While "fiddle with the RFC Editor note in the
John> announcement..." ma
> Date: Fri, 17 Dec 2004 13:16:25 +0100
> From: Harald Tveit Alvestrand <[EMAIL PROTECTED]>
> Subject: Why old-standards (Re: List of Old Standards to be retired)
> Message-ID: <[EMAIL PROTECTED]>
> In 1994, the IETF community resolved to make the following procedure
Hi -
> From: "Bruce Lilly" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, December 20, 2004 10:49 AM
> Subject: Re: Why old-standards (Re: List of Old Standards to be retired)
...
> 1. annual review of hundreds or thousands of standards in an
1 - 100 of 1048 matches
Mail list logo
