service
implementations to the world, e.g. risking buffer overflow attacks, etc.
This has nothing to do with NATs, however, as others have already
pointed out.
Lars
--
Lars Eggert [EMAIL PROTECTED] Information Sciences Institute
http://www.isi.edu/larse/ University
, why measure?
Lars
--
Lars Eggert [EMAIL PROTECTED] Information Sciences Institute
http://www.isi.edu/larse/ University of Southern California
smime.p7s
Description: S/MIME Cryptographic Signature
) may make sense. Also, under
this particular misconfiguration, there'll very likely be two ARP
responses for a lookup of the IP address in question, so maybe could be
used as an indicator that there's a problem.
Lars
--
Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute
track, whereas requirements documents would more
naturally fall under Informational or maybe BCP.
So PPVPN at least seems quite happy to go out-of-scope, and is thus
unlikely to stick to their given timeframe.
Lars
PS: I support 1/ - close SUB-IP and migrate the WGs.
--
Lars Eggert [EMAIL PROTECTED
me some light...
How about asking Microsoft?
Lars
--
Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute
smime.p7s
Description: S/MIME Cryptographic Signature
to have been flaky), but the RFC editor IPv6 server has been
up since last week.
You should see you are using IPv6 from
2001:490:f002:128:240:96ff:fe40:5bc9 on the bottom of the front page if
all went well.
Browser issue?
Lars
--
Lars Eggert [EMAIL PROTECTED] USC Information Sciences
script periodically updates the ical version based on the ASCII
agenda at http://ietf.org/meetings/agenda_59.txt. No guarantees for
accuracy!)
Lars
(PS: Re-sent, first message didn't make it to the list apparently.)
--
Lars Eggert NEC Network Laboratories
with that.
(A perl script periodically updates the ical version based on the ASCII
agenda at http://ietf.org/meetings/agenda_59.txt. No guarantees for
accuracy!)
Lars
--
Lars Eggert NEC Network Laboratories
smime.p7s
Description: S/MIME Cryptographic Signature
/meetings/[EMAIL PROTECTED] No
guarantees for accuracy!
--
Lars Eggert NEC Network Laboratories
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman
of the rising complexities of entering
the US - IETF in Cancun sounds good to me...
Lars
--
Lars Eggert NEC Network Laboratories
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf mailing list
[EMAIL PROTECTED
post it.
Lars
--
Lars Eggert NEC Network Laboratories
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
fligths.
But I agree, it's a tradeoff.
Lars
--
Lars Eggert NEC Network Laboratories
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
1 avaya
1 OpenLDAP
--
Lars Eggert NEC Network Laboratories
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
!
--
Lars Eggert NEC Network Laboratories
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
Jason Gao wrote:
Here ATP stands for Asymmetric Transport Protocol (somewhat for historical
reason), not Appletalk Transaction Protocol.
Welcome to http://atp.ebloggy.com/ to add comment.
Is there a paper on it? The web page and your email don't have details.
--
Lars Eggert
to have!
Lars
--
Lars Eggert NEC Network Laboratories
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
and RFC editor office hours to be very useful in
the past and am happy to see them partly offered again. I'd be even
happier if the RFC editor was also present and hope this will happen
again in Vancouver.
Lars
--
Lars Eggert NEC Network Laboratories
On Aug 3, 2005, at 14:40, Andrew G. Malis wrote:
I'm with the folks that like this schedule.
Since we're counting, me too.
Lars
--
Lars Eggert NEC Network Laboratories
smime.p7s
Description: S/MIME cryptographic signature
for the first
beer?
Lars
--
Lars Eggert NEC Network Laboratories
smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
meetings in the past
with no hosts - do we really depend on hosts still? How much would
the registration increase if there were no hosts? The additional cost
might easily be offset by lower airfare and cheaper hotel rates.
Lars
--
Lars Eggert NEC Network
when it comes to these
contractual things, but I'm sure the IAD is talking to people with
this expertise.
Lars
--
Lars Eggert NEC Network Laboratories
smime.p7s
Description: S/MIME cryptographic signature
___
Ietf
half joking.)
Lars
--
Lars Eggert NEC Network Laboratories
smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
a problem with WOT).
I won't be at the keysigning, but I can give 35 Thawte points as
well. Interested people, send email off-list.
Lars
--
Lars Eggert NEC Network Laboratories
smime.p7s
Description: S/MIME cryptographic signature
next time.
Lars
--
Lars Eggert NEC Network Laboratories
smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Hi,
so I'm happy to see that we now have IETF dates blocked until 2010 on
http://ietf.org/meetings/events.cal.html, but hotel information for
Dallas would be more useful to me personally. ETA on that?
Thanks,
Lars
--
Lars Eggert NEC Network Laboratories
these days.)
Lars
--
Lars Eggert NEC Network Laboratories
smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
be available until
the 25th.)
Lars
--
Lars Eggert NEC Network Laboratories
smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
of
the problem, which IMO is one of its purposes, no?
Lars
--
Lars Eggert NEC Network Laboratories
smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org
--
Lars Eggert NEC Network Laboratories
smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
19) also works, I'm
using one sometimes.
The OrangeWare driver also does not support WPA with any card AFAIK
(not an issue at IETF though.)
Lars
--
Lars Eggert NEC Network Laboratories
smime.p7s
Description: S/MIME cryptographic signature
.
And this in independent of which country you are based in - adjacent
meetings in, say, Europe, reduce travel for North Americans, too.
(I do realize that this complicates the scheduling algorithm though.)
Lars
--
Lars Eggert NEC Network Laboratories
smime.p7s
the meetings as close together
as possible.
Few of us have the luxury of going to meetings just to sit there.
Lars
--
Lars Eggert NEC Network Laboratories
smime.p7s
Description: S/MIME cryptographic signature
--
Transport-Enhancing Refinements to the Network Layer Interface (TERNLI)
(pronounce: turn-ly)
BOF Chairs:
tbd
Sponsoring Area Directors:
Lars Eggert [EMAIL PROTECTED]
Magnus Westerlund [EMAIL PROTECTED]
Jari Arkko [EMAIL PROTECTED]
Mailing List:
General
to:
[EMAIL PROTECTED]
General information about the mailing list is at:
https://www1.ietf.org/mailman/listinfo/tsv-area
Lars (for Magnus Lars)
--
Lars Eggert NEC Network Laboratories
smime.p7s
Description: S/MIME cryptographic signature
. 17, No. 5, October 1987.
[2] Heffner, J., M. Mathis and B. Chandler. Fragmentation Considered
Very Harmful. Internet Draft draft-heffner-frag-harmful-02,
Work in Progress, June 2006.
--
Lars Eggert NEC Network Laboratories
smime.p7s
public in this way, and the NomCom can decide whether they get higher-
quality feedback on the candidates for these positions. If yes,
that'd argue for making all candidate lists public in the future.
Lars
--
Lars Eggert NEC Network Laboratories
may motivate people to spend
more effort on writing NomCom inputs, because all input would
contribute to the final decision.
Lars
--
Lars Eggert NEC Network Laboratories
smime.p7s
Description: S/MIME cryptographic signature
a tangible token of participation.
Remove that, and the question might be asked? What do we get for
our money? more often.
the T-shirt, of course :-)
Lars
--
Lars Eggert NEC Network Laboratories
smime.p7s
Description: S/MIME cryptographic
for IPv6-related protocols:
http://www.tahi.org/
Lars
--
Lars Eggert NEC Network Laboratories
smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman
a small number of extensions to RSVP or
advisory documents to address specific application
scenarios. In order to maintain stable specifications,
additional work on RSVP in TSVWG requires Area Director
approval.
Lars
--
Lars Eggert NEC Network
--
Lars Eggert NEC Network Laboratories
smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
On 2007-2-20, at 11:51, ext Pekka Savola wrote:
It seems that are assuming the transport needs to happen in the
packet itself. While this is a possible approach, I don't see that
it needs to be the only one. For example, a mechanism where the
mutually trusting network components would
Ray,
On 2007-3-6, at 0:44, ext Ray Pelletier wrote:
IETF 70 will be held in Vancouver
IETF 73 will be held in Minneapolis
while it's absolutely fantastic to see announcements of specific
locations and dates this far ahead, we seem to have been moving to a
cycle of 3 meetings in North
On 2007-3-7, at 12:34, ext Brian E Carpenter wrote:
North America changes to Daylight Savings Time this weekend 10/11
March.
Europe changes two weeks later, 24/25 March, immediately after the
IETF.
This has consequences.
This may be useful to folks:
From: Jeff Williams [EMAIL PROTECTED]
Hi,
we've put together a search engine for IETF and IRTF mailing list
archives using the Google co-op tool. At this time, it indexes all
currently-active WG and RG mailing list archives(*) as well as
selected related and historic lists. You can access the search engine
at:
On 2007-4-24, at 17:43, ext Frank Ellermann wrote:
Lars Eggert wrote:
it indexes all currently-active WG and RG mailing list archives
I think it's a proper or favoured subset (selected by you) of what's
anyway in Google's index, specified in the form of URL patterns for
inclusion or exclusion
On 2007-5-26, at 14:24, ext Pekka Savola wrote:
(Note: this is still a draft version if you're referring to
http://www.ietf.org/IESG/content/ions/drafts/ion-tsv-alt-cc.txt)
This model raises one fundamental question issue of the scope of
this document.
Who should be evaluating section 3 and
On 2007-7-5, at 19:07, ext Tom.Petch wrote:
If we had a range of transports (perhaps like OSI offered), we
could choose the
one most suited. We don't, we only have two, so it may become a
choice of one
with a hack. But then that limited choice may be the reason why
the Internet
Protocol
On 2007-9-6, at 12:01, ext Elisa Boschi wrote:
To be specific, how would an application using
IPFIX over UDP obtain the packet loss information needed to implement
TFRC as recommended in Section 3.1.1 of the UDP guidelines draft?
The IPFIX implementation guidelines draft says:
The Collecting
Paul,
On 2007-9-6, at 14:51, ext Paul Aitken wrote:
As far as I can see, draft-ietf-tsvwg-udp-guidelines-02 contains
no guidance other than:
Applications that perform bulk transmission of data (3.1.1)
and
When applications that exchange only a small number of messages
with
a
See the recent email on ietf-announce:
Begin forwarded message:
From: ext Kurt Erik Lindqvist [EMAIL PROTECTED]
Date: September 4, 2007 17:13:49 GMT+03:00
To: [EMAIL PROTECTED]
Cc: IAOC Jabberr [EMAIL PROTECTED], ietf@ietf.org, IESG \(\(E-mail\)
\) [EMAIL PROTECTED]
Subject: Vancouver meeting
On 2007-9-14, at 21:54, ext Tony Finch wrote:
On Fri, 14 Sep 2007, Keith Moore wrote:
I actually don't think that having multiple concurrent TCP
connections
between two peers is a bad thing. sure we could have a transport
protocol that provided multiple streams, but why bother when
priorities such that objects that were being rendered on the screen
were transmitted at a higher priority, even while scrolling around a
large page.
On Sep 17, 2007, at 2:02 AM, Lars Eggert wrote:
You might be interested in Bryan Ford's SST paper from this year's
SIGCOMM:
Structured
On 2007-9-17, at 17:40, ext John Day wrote:
Fast Select was a single packet that opened, transfered data, and
closed a connection. The same as what Mr. Ford's description.
What you outline above is very different from SST. I'm surprised that
after reading the paper you'd think that there
Authors,
if you want to change the draft based on the sec-dir or gen-art
reviews, please let me know and either send me a corresponding RFC
Editor Note or tell me that you're submitting a new draft.
Lars
On 2007-10-23, at 9:06, ext Tom Yu wrote:
Bob == Bob Briscoe [EMAIL PROTECTED]
On 2007-11-6, at 2:08, ext Brian E Carpenter wrote:
Red herring as far as this draft is concerned: I'd be interested
to know why we are still willing to allow non-disclosure for
port numbers (see RFC 2780 sections 8 and 9.1). Port numbers
are going fast.
We've recently been discussing port
Hi,
I'm hoping that everyone who's criticizing the volunteers that create
and maintain our tools is considering to offer their obviously vast
expertise in Vancouver: http://www3.tools.ietf.org/tools/ietfdb/wiki/
VancouverSprint
Lars
smime.p7s
Description: S/MIME cryptographic signature
On 2007-11-25, at 23:51, ext Paul Hoffman wrote:
They still should (strongly) consider checking the validity of the
XML by comparing it to what the IESG approved.
I agree with Paul. The IESG approves the text version of a draft, so
the text version is definitive.
Making the XML available
On 2007-11-26, at 22:11, ext Henrik Levkowetz wrote:
I agree on the general sentiment of *one* deadline time.
I'd prefer it expressed in a TZ which iCalendar files and most
calendar
applications understand right off, though. UTC sounds good to me.
Let me put in a plug for
On 2007-11-28, at 19:00, ext Ole Jacobsen wrote:
Keep in mind that the locations are subject to change until a host has
been identified and the hotel contract signed. This means that you
could well see one of the OTHER meetings in 2009 take place in Europe.
TBD and Provisional really does mean
On 2007-11-28, at 20:08, ext Russ Housley wrote:
The IAOC plan for 2008 and 2009 is to have three meetings in North
America, two meetings in Europe, and one meeting in Asia. This
3:2:1 ration will be repeated for 2010 and 2011. So far, we are on
track to make this happen.
I appreciate
On 2007-11-29, at 6:28, ext [EMAIL PROTECTED] wrote:
I agree with your reasoning. I should have asked,
why do *ALL* IETF meetings have to be monolithic and all-inclusive?
They don't. Several WGs are holding interim meetings between the IETF
meetings. I'm not sure if there have been joint
On 2008-2-11, at 18:55, ext Dan York wrote:
Can we move some of this conversation in the bill below onto the
Internet using systems where our costs essentially go to $0?
(Obviously we still need to communicate to non-wired folks across
the PSTN, such as event location facilities, etc.)
Hi,
I enjoyed reading your draft, and I'm looking forward to discussing it
in Philly. (We've asked Jonathan if he'd present at TSVAREA or INTAREA.)
On 2008-2-13, at 15:44, ext Jonathan Rosenberg wrote:
I wrote this because of a discussion that happened during behave at
the
last IETF
On 2008-2-15, at 16:21, ext Bernard Aboba wrote:
However, I would suspect that clearly specifying how SCTP and DCCP
work with NAT would eventually make it possible to obtain a home NAT
supporting those protocols, particularly if implementations were made
available within the popular
Hi,
On 2008-2-14, at 18:38, ext Hallam-Baker, Phillip wrote:
In particular there are many cases where you would like to establish a
'lossy TCP connection'. That is you want the flow ct. advantages that
you get from establishing a control channel session while accepting
the
fact that in a
Hi,
On 2008-2-16, at 0:58, ext Jonathan Rosenberg wrote:
So lets say I am building an application and I want to extend that
application to users that may be NATted. Now, I have a choice. I can
build that application to run on SCTP, which may be advtantageous.
In that case, I'll be able
Hi,
IETF-75 takes place in Stockholm, Sweden, from July 26-31, 2009. A
bunch of us are planning to sail from Finnland to Stockholm during the
week before the IETF, and to sail back from Stockholm to Finnland in
the week afterwards. Coordinating this with several boats and a bunch
of
On 2008-7-28, at 13:55, ext Marc Manthey wrote:
NATs necessary for IPv6, says IETF chair
http://www.networkworld.com/news/2008/072109-nat-housley-qna.html
The quote form the article is: They are necessary for a smooth
transition from IPv4 to IPv6 so that the important properties of the
Hi,
On 2008-8-11, at 2:32, ext John C Klensin wrote:
--On Sunday, August 10, 2008 6:03 PM +0200 Julian Reschke [EMAIL PROTECTED]
wrote:
- check that if the document obsoletes or updates another
document, that one appear in the references section, and make
sure that the document actually says
Looks good. My only comment is about where the justification is to be
provided - the PROTO writeup is at least an alternative to putting
this into the document itself, and IMO it's a better alternative.
Lars
On 2008-8-13, at 12:21, ext Bert Wijnen (IETF) wrote:
The revision 1.8 of the
Hi,
I believe the gen-art comments need to be discussed before this
document can move before the IESG.
Lars
On 2008-8-21, at 23:30, ext [EMAIL PROTECTED] wrote:
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
On 2008-10-3, at 4:11, ext Joe Touch wrote:
Agreed; I propose to take this over to TSVWG. It's more general than
just TCP...
I agree that the intersection of TSVWG and SAAG will probably more or
less capture the correct set of folks, let's move the discussion there.
I'll send another
Hi,
On 2008-10-10, at 15:00, ext Marshall Eubanks wrote:
considered for prioritizing standardization work, for example the
number of operators and clients that are likely to be able to provide
or use that particular data. In any case, this WG will not propose
standards on how congestion is
On 2008-10-11, at 4:27, ext Enrico Marocco wrote:
Lakshminath Dondeti wrote:
It's difficult to write a charter without actually designing the
solution.
This is an interesting opinion. May I translate that to mean that
there
is already a solution in the minds of the people who wrote the
Hi,
On 2008-10-31, at 10:45, ext Robert Elz wrote:
This looks like useful work to do, and to me, the charter mostly
looks fine, just one point.
The (proposed) charter says ...
| * operate well in networks with FIFO queueing with drop-tail
| discipline
which in itself is OK, but doesn't say
On 2008-11-28, at 12:49, Stewart Bryant wrote:
We could maybe start earlier on Friday as well - say 8am - i.e. run
0800
till 1300 with only only a 10 min
coffee break. That would put nearly 5 hours into the schedule.
That overlaps with the IESG/IAB what happened this week breakfast.
(But
On 2008-12-3, at 10:47, Fernando Gont wrote:
(FYI, the draft originally aimed at Std. Track, and discussed other
alternative approaches for dealing with the problem of long delays
between connection establishment attempts. Then we changed the draft
category to Informational, to simply document
Hi,
On 2009-2-14, at 0:25, Marshall Eubanks wrote:
If I am reading this correctly the UK Centre for the Protection of
National Infrastructure
wants the IETF (or some other body) to produce a companion document
to the IETF specifications that discusses the security aspects and
implications of
Hi,
On 2009-3-3, at 22:54, Brian E Carpenter wrote:
I think adding any new mandatory section to all I-Ds is a bad idea.
It will quickly become bureaucratic. We've had proposals for mandatory
Management Considerations, IPv6 Considerations, and no doubt others
that I've forgotten, and they all
Hi,
On 2009-3-4, at 15:39, a...@tr-sys.de wrote:
I do not want to blame anybody, but in the TSV area I am aware
of documents in at least two different WGs that describe common
(and recommended) _existing_ implementation practice and have
not even been submitted to the IESG after more than 4
ftp.ietf.org, in the ietf-mail-archive directory
On 2009-3-31, at 5:41, Robert Moskowitz wrote:
I want to download the whole lisp maillist archive and import it into
Thunderbird.
I have a plugin for Thunderbird that will take mbox format, and I have
pulled in maillist archives from other
Hi,
all hats off
On 2009-4-14, at 1:38, Joe Touch wrote:
Advice in making a hardened version of TCP would be useful to the
implementation community.
To a large extent this is what draft-gont-tcp-security is about.
Implementation advice is outside the scope of the IETF. It's not even
Hi, Todd,
On 2009-4-14, at 22:21, Todd Glassey wrote:
Fernando Gont wrote:
Lars Eggert wrote:
I agree with Joe that some of the hardening techniques that
vendors are
implementing come with consequences (make TCP more brittle). To
me, this
is a *reason* this document should be published
Hi,
On 2009-4-14, at 20:51, Fernando Gont wrote:
Lars Eggert wrote:
My personal take is that the IETF is responsible for the
maintenance of
its protocols, and this effort carried ut by the UK CPNI should be
welcome, and the IETF should take the chance and benefit from this
work
to publish
On 2009-4-21, at 9:00, Sam Hartman wrote:
Keith, I've considered your points and continue to disagree. I'm
mostly replying in the interest of judging consensus.
I believe that the primary use cases identified in the MIF BOF are use
cases that are not going to go away. I think that saying
I agree with Sam and Jari. This is a good and overdue change.
Lars
On 2009-6-10, at 17:21, Jari Arkko wrote:
I also support the publication of this document (modulo some nits that
were discussed earlier). Yes, there are trade-offs. But having
observed
the process from various sides over
On 2009-7-5, at 16:20, Carsten Bormann wrote:
Would it help to simply call it 1.34 now?
(Then it would be picked up by distributions and packaging services
such as macports, and people could stop installing by hand.)
+1
I maintain the fink package for xml2rfc, and the committers asked me
Hi,
On 2009-7-5, at 16:24, Iljitsch van Beijnum wrote:
My apologies for the subject line. I'm very disappointed that the
silent majority of draft authors isn't speaking up. I can't imagine
that the vast majority of draft authors has absolutely no problems
with XML2RFC. So I'm assuming they've
Release early, release often.
Can't we simply do a 1.35 whenever the upcoming changes have been
finalized?
Lars
On 2009-7-7, at 0:30, Julian Reschke wrote:
Marshall Rose wrote:
julian, bill - i thought we were waiting on another revision for
boilerplate changes? is that imminent?
Some
On 2009-8-10, at 23:24, Joel M. Halpern wrote:
Please, approve this document for publication as an BCP.
Agreed.
Lars
smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
Hi,
On 2009-8-21, at 16:01, David Harrington wrote:
Maybe we should have an RFID reader/recorder at the door to each
session, and to send bills to people based on what they actually
attend (plus a base fee).
...
This approach might also cut down on people using sessions
to just read email and
Hi,
looks good.
I have one (probably stupid) question: who checks this and how? Will
we use different colored paper for the name tags for different days?
Will the secretariat patrol the hallways? Or is the abuse angle
something that we don't think is a realistic issue?
Lars
On
Hi,
On 2009-8-31, at 18:34, Adam Roach wrote:
In particular, when a user accesses a document at a url of the form
http://www.ietf.org/rfc/rfc.txt, there is going to be a strong
presumption on their part that the document was produced by the
IETF. In
the cases that this presumption is
On 2009-8-31, at 19:24, Joel M. Halpern wrote:
But the same could be said all our experimental and informational RFCs.
Should we insist that all experimental and informational RFC, even
from IETF WGs, carry big warnings THIS IS NOT AN IETF STANDARD.
FWIW, this was exactly what I proposed a
On 2009-10-16, at 15:54, John Leslie wrote:
There have been a number of voices favoring what Jari tried to call
as consensus, and I'd like to add mine.
+1
Lars (assuming my voice counts)
smime.p7s
Description: S/MIME cryptographic signature
___
Hi,
I'm proposing a change to the ID boilerplate in order to save some
lines on the first page. The current text says:
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute
On 2009-10-27, at 14:09, Scott Lawrence wrote:
On Tue, 2009-10-27 at 11:28 +0200, Lars Eggert wrote:
The list of current Internet-Drafts is at
http://datatracker.ietf.org/drafts/.
Is a nice space-saving measure, but isn't true. That URL leads to a
query page, not a list of current drafts
Hi,
On 2009-10-27, at 14:39, Lars Eggert wrote:
On 2009-10-27, at 14:09, Scott Lawrence wrote:
On Tue, 2009-10-27 at 11:28 +0200, Lars Eggert wrote:
The list of current Internet-Drafts is at
http://datatracker.ietf.org/drafts/.
Is a nice space-saving measure, but isn't true. That URL
Hi,
On 2009-10-28, at 11:53, SM wrote:
At 02:28 27-10-2009, Lars Eggert wrote:
The second URL points to a list of FTP mirrors, fully half of which
are defunct in some way (don't respond, DNS name doesn't resolve,
contains stale content, etc.) Again, nobody has been noticing this.
The second
1 - 100 of 151 matches
Mail list logo
