On 2/1/2011 9:19 AM, Cullen Jennings wrote:
So to summarize what you are saying, ports are allocated based on an
arbitrary view of the expert review. When this person will say yes or no
too can't be described and will change over time.
See my other post. Section 8.1.1 already states that
On 2/1/2011 10:00 AM, Eric Rescorla wrote:
On Tue, Feb 1, 2011 at 9:39 AM, Joe Touchto...@isi.edu wrote:
To clarify some of this discussion, providing some context that might be
useful:
1) the current doc already explicitly states the procedures for assignment
in each range of ports (see
On 2/1/2011 10:29 AM, Eric Rescorla wrote:
...
I'm sorry, but I'm still not clear.
This document has an affirmative statement against the use of multiple
ports for TLS.
I'm sorry, but it does not.
I states a goal, and a preference, and has plenty of wiggle room as I've
repeatedly quoted,
On 2/1/2011 11:14 AM, Sam Hartman wrote:
...
Joe, the IESG had a fair amount of negative experience with this style
of review just before I joined; this type of review was just about out
of the process leading to blocking objections when I joined as an AD.
I think that being able to discuss
On 2/1/2011 12:12 PM, Sam Hartman wrote:
Joe == Joe Touchto...@isi.edu writes:
Joe On 2/1/2011 11:14 AM, Sam Hartman wrote:
Joe ...
Joe, the IESG had a fair amount of negative experience with this
style of review just before I joined; this type of review was
Hi, all,
I've reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the
document's authors for their information and to allow them to address
any
Lars,
On 1/31/2011 7:06 AM, Lars Eggert wrote:
Hi,
On 2011-1-31, at 16:51, Paul Hoffman wrote:
On 1/31/11 12:23 AM, Lars Eggert wrote:
On 2011-1-30, at 17:12, Paul Hoffman wrote:
The above emphatic statements means that IANA can reject a request for an
IETF-approved protocol that needs two
The procedures that are specified - for ALL assignments - are the
PROCEDURES - the word itself is used specifically in the heading of
section 8.
That does not refer to the principles - again for which there are more
than sufficient wiggle words, and which already cite existing RFCs that
On 1/31/2011 9:16 AM, Joe Touch wrote:
Lars,
On 1/31/2011 7:06 AM, Lars Eggert wrote:
Hi,
On 2011-1-31, at 16:51, Paul Hoffman wrote:
On 1/31/11 12:23 AM, Lars Eggert wrote:
On 2011-1-30, at 17:12, Paul Hoffman wrote:
The above emphatic statements means that IANA can reject a request
Fwiw please see sec 8.1 of our doc which states which procedures of RFC 5226
are specified for each range, and already allows IESG approval as a path for
user ports.
Joe
On Jan 31, 2011, at 9:25 AM, Joe Touch to...@isi.edu wrote:
On 1/31/2011 9:16 AM, Joe Touch wrote:
Lars,
On 1/31
Hoffman wrote:
On 1/29/11 9:34 PM, Joe Touch wrote:
...
As per my other note:
RFC2780 specifies Expert Review as *one* of the viable means by which
IANA can decide on transport protocol port assignments. The term Expert
Review is defined in RFC 2434.
Neither document binds IANA to use the advice
On 1/29/2011 8:53 PM, Cullen Jennings wrote:
On Jan 27, 2011, at 17:29 , Michelle Cotton wrote:
We are changing that process right now. We have begun to report the
reviewer (with the review) in the email to the requester.
We just need to make sure this small change is communicated to
On 1/29/2011 8:54 PM, Cullen Jennings wrote:
On Jan 27, 2011, at 17:10 , Joe Touch wrote:
...
AFAICT, the experts team reports to IANA. We make recommendations to
them. They are the ones who have the conversation with the applicant.
They can take our advice or not - that's their decision
Hi, Tom,
On 1/28/2011 7:02 AM, t.petch wrote:
Is there any text about this, old protocol, situation, for I cannot see any? Or
are we at the mercy
of the expert reviewer?
Tom Petch
See Sec 7.2:
...IANA has flexibility beyond these principles when handling
assignment requests; other
On 1/27/2011 12:52 AM, Lars Eggert wrote:
...
Small Issue #3: I object to anonymous review
The current review is anonymous and this draft does not seem to change that. I
don't like anonymous review - it's not how we do things at IETF and it
encourages really bad behavior. I have several
Although this is a fairly old thread, I didn't see mention of the IPv4
ID draft we've been working on in INTAREA that addresses this:
https://datatracker.ietf.org/doc/draft-ietf-intarea-ipv4-id-update/
It was updated last Oct.
See esp. Sec 9.
Joe
On 8/31/2010 1:04 PM, John Kristoff wrote:
, david.bl...@emc.com wrote:
Joe,
Many thanks for reviewing the draft.
The requested changes look reasonable, with one clarification - protocol number
133 was used for a pre-standard version of FCIP, not iFCP .
Thanks,
--David
-Original Message-
From: Joe Touch [mailto:to...@isi.edu
Hi, all,
I've reviewed this document as part of the transport area
directorate's ongoing effort to review key IETF documents. These
comments were written primarily for the transport area directors, but
are copied to the document's authors for their information and to
allow them to address any
On 7/18/2010 11:05 AM, Patrik Faltstrom (pfaltstr) wrote:
On 18 jul 2010, at 19:18, Joe Touchto...@isi.edu wrote:
That seems to means you use one of two different RRs, depending on the response.
I don't see that as a step forward.
No, the other way around. You, in a protocol, use either
On 7/18/2010 12:14 AM, Patrik Fältström wrote:
On 17 jul 2010, at 21.39, Joe Touch wrote:
Are you suggesting a new RR instead of the SRV or in addition to the SRV?
The latter seems useful; the former begs the question of how many SRV variants
we would want.
A new RR that is a replacement
Hi, Cyrus,
On 7/16/2010 6:11 PM, Cyrus Daboo wrote:
Hi Joe,
--On July 16, 2010 2:55:42 PM -0700 Joe Touch to...@isi.edu wrote:
1) the document contains a section discussing the registration of caldev
and caldevs (Sec 3); a corresponding section for carddev and carddevs
should be added
Hi, Cyrus,
On 7/17/2010 12:00 PM, Cyrus Daboo wrote:
...
The SRV registry exists even in advance of IANA's management thereof.
Further, aliases have no meaning in the SRV registry - they are
meaningful only in the IANA ports registry, and only insofar as multiple
strings are assigned the same
Patrick,
Are you suggesting a new RR instead of the SRV or in addition to the SRV?
The latter seems useful; the former begs the question of how many SRV
variants we would want.
Joe
On 7/17/2010 12:33 PM, Patrik Fältström wrote:
On 17 jul 2010, at 21.27, Joe Touch wrote:
The appropriate
Hi, all,
I've reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the
document's authors for their information and to allow them to address
any
Hi, Jari,
Individual shop owners (and cab drivers) can always do what they want
(anywhere), even when the company they work for accepts cards.
As I noted, you can ask before you get into the cab.
Though I agree with your recommendation that backup cash is always
useful -- in any city.
Joe
Hi, all,
I've reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the
document's authors for their information and to allow them to address
any
Theodore Tso wrote:
...
This was my experience as well (I travel a lot, to many countries in
Europe and Asia, and have never had a problem until I travelled to the
Netherlands last year) --- except my ATM card didn't work, either. When
I talked to my bank, they told me it was because of
Jari Arkko wrote:
Phillip,
This is the main change from the US. In the US it is entirely
practical to carry only plastic and no cash at all.
This is mostly right, but maybe not universally true. Imagine my
surprise when I walked to a cab at LAX and asked to be taken to the
Anaheim
Dave CROCKER wrote:
On 4/1/2010 11:05 AM, Fred Baker wrote:
So - does RFC 5841 update RFC 3514, or obsolete it?
Probably not. RFC 3514 is actually a protocol. RFC 5841 is not.
A protocol needs to specify deterministic behavior by participants at
both ends of the exchange.
Phillip Hallam-Baker wrote:
...
Before you answer that, here is a list of consensus requirements on
the document format:
1) Easy to generate
2) Readily supported by a wide range of authoring tools
WYSIWYG authoring, IMO, ought to be required if we're claiming to climb
out of the stone age
Hi, all,
I've reviewed this document as part of the transport area
directorate's ongoing effort to review key IETF documents. These
comments were written primarily for the transport area directors, but
are copied to the document's authors for their information and to
allow them to address any
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi, all,
I've reviewed this document as part of the transport area
directorate's ongoing effort to review key IETF documents. These
comments were written primarily for the transport area directors, but
are copied to the document's authors for their
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
RJ Atkinson wrote:
...
BOTTOM LINE:
There seems to be clear consensus amongst folks outside
the IESG that (1) there is no current problem and (2)
no process change is warranted to make IESG notes mandatory
on non-IETF-track documents.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Noel Chiappa wrote:
From: Stephan Wenger st...@stewe.org
For the IETF as an organization, I see no value beyond traditions in
staying with the RFC publication model. (The marketing value of using
the RFC series is IMHO
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Sullivan wrote:
On Wed, Sep 09, 2009 at 09:19:05AM -0700, Dave CROCKER wrote:
First, you lack empirical data to substantiate your assessment of the
perception.
Well, Wikipedia (which IMO is primarily useful as a repository for
finding
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Russ White wrote:
If everyone knew, there would be more lobbying since there would be more
people participating. I doubt the direct or secret-list lobbying would
wane much as a result.
I don't think you'll get any more lobbying than you get
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Melinda Shore wrote:
SM wrote:
Hi Phillip,
At 08:32 10-06-2009, Phillip Hallam-Baker wrote:
A more useful change would be to abolish NOMCON and for those
currently qualified to sit on NOMCON to elect the IAB and ADs
directly.
The implications
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I am concerned about this development for several reasons:
1) exposing the full list to the entire community invites lobbying the
nomcom
This probably already happens to some extent, but do
we really want to encourage this?
2)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Phillip Hallam-Baker wrote:
The deliberative process of NOMCON means that it is more likely that
consensus will be reached on the candidates that fewest people object
to rather than those that have the strongest support.
Deliberation means that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I do not debate the utility to the Nomcom of this change.
I believe it comes with a cost, and I do not agree that it is a simple
decision. I do not agree that the Nomcom is the only party here worth
consideration.
Joe
Stephen Kent wrote:
Joe,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom.Petch wrote:
...
If you're here for a rubber stamp, you came to the wrong WG ;-)
Rubber-stamp? No, Joe. The UK CPNI rubberstamp is more than enough, and
when it comes to advice on this issues, I believe it's even more
credible. Ask the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fernando Gont wrote:
Joe Touch wrote:
I'm not at all clear that the WG needs this document.
Yes, we still have the option to ignore that vendors have had to figure
out by themselves how to produce a resilient implementation of TCP,
because
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fernando Gont wrote:
Joe Touch wrote:
So we had tcp-secure in 2004, icmp-attacks in 2005, a claim for a
trivial attack in 2008 (Outpost24/CERT-FI), and we'll probably continue
in this line, because we do nothing about it.
Whether we have
-Original Message-
From: opsec-boun...@ietf.org [mailto:opsec-boun...@ietf.org]
On Behalf Of Fernando Gont
Sent: Monday, April 13, 2009 1:23 PM
To: Joe Touch
Cc: t...@ietf.org; ietf@ietf.org; Joe Abley; op...@ietf.org;
Lars Eggert; Eddy,Wesley M. (GRC-RCN0)[Verizon]
Subject: Re
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fernando Gont wrote:
Smith, Donald wrote:
Please talk to vendors. I don't want to reproduce here
what seems to
be the consensus among vendors with respect to the current
state of affairs in terms of how up-to-date our specs are.
I talk to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Smith, Donald wrote:
...
The classic tenets for computer security is:
CIA - Confidentiality, Integrity and Availability.
TCP doesn't attempt to address Confidentiality.
However it was designed to address integrity and availability so
failures
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fernando Gont wrote:
Joe Touch wrote:
The consensus seems to be that the current state of affairs is something
like: a mess. Even if you do care to produce a resilient
implementation, that task is going to be much harder than necessary. You
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi, all,
I've reviewed this document as part of the transport area
directorate's ongoing effort to review key IETF documents. These
comments were written primarily for the transport area directors, but
are copied to the document's authors for their
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi, Sam,
Sam Hartman wrote:
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Steven M. Bellovin wrote:
On Wed, 1 Oct 2008 22:12:17 -0400
Steven M. Bellovin [EMAIL PROTECTED] wrote:
Steven Note 7.3.1 on
Steven TCP considerations. (Also note that 7.3.1 disagrees
Steven with 793 on the treatment of security
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sam Hartman wrote:
Joe == Joe Touch [EMAIL PROTECTED] writes:
Joe I was wondering about that; it seems inconsistent to have
Joe this document require something that is optional in RFC 4301.
I suspect you realize this, but some
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi, Mike (et al.),
Michael StJohns wrote:
Hi Joe -
...
At 02:18 PM 10/2/2008, Joe Touch wrote:
First, I don't agree with this document's recommendation in section 7.3.1.
TCP's current definition of a connection is:
local IP address
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michael StJohns wrote:
At 07:01 PM 10/2/2008, Joe Touch wrote:
...
The fix was to virtualize TCP so that there was a complete set of TCP
ports per distinct security domain.
I agree that this fixes your problem, but what it does is create a new
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Steven M. Bellovin wrote:
On Thu, 02 Oct 2008 17:48:07 -0700
Joe Touch [EMAIL PROTECTED] wrote:
The point I'm making is that there seems like there should be a way to
prevent the covert channel without mucking up TCP's definition of what
Mark Andrews wrote:
...
hk is not a legal fully qualified host name.
Agreed. hk., however, is.
No, it is not a legal hostname.
RFC 952 explicitly excludes trailing periods.
RFC 952 is not a standard.
Joe
signature.asc
Description: OpenPGP digital signature
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Moore wrote:
|
|
| Ted Faber wrote:
| On Tue, Jul 08, 2008 at 12:54:16PM +1000, Mark Andrews wrote:
| hk. is not a syntactically valid hostname (RFC 952).
| hk. is not a syntactically valid mail domain.
| Periods at the end are
Keith Moore wrote:
Joe Touch wrote:
Keith Moore wrote:
| RFC1043 defines the dot. The fact that some apps don't recognize it
is a
| bug.
|
| not when the application explicitly specifies that FQDNs are to be
used.
| in such cases the dot is superfluous.
Superfluous is fine. Prohibited
Keith Moore wrote:
Many, many working groups have looked at the problems associated with
relative names and determined that they're not acceptable. It's a
bug that relative names are forbidden in these apps, nor that the
final . is implicit and in many cases disallowed. These are
Keith Moore wrote:
It's nonsensical for an application to decide that relative names
are unacceptable, but to require users to input names as relative.
it's nonsensical for you to unilaterally declare that such names are
relative, when well over two decades of practice indicates otherwise.
Ray,
On Nov 28, 2007, at 11:03 AM, Ray Pelletier wrote:
All;
Some background as regards the Westin moving people to other hotels as
a result of renovations. We executed a contract with the Westin in
February 2007 when an Asian initiative fell through. In the contract
we were provided a
Steven M. Bellovin wrote:
On Wed, 14 Nov 2007 22:43:01 -0800
Joe Touch [EMAIL PROTECTED] wrote:
Sam Hartman wrote:
...
Yes, Steve almost certanily did slow down any heavy CPU use during
the time when he was doing the backup.
Our point--Steve, Steve and I--is that for a lot of uses
Stephen Kent wrote:
Joe,
This discussion seems to have moved from a discussion of crypto use on
home/office computers, to use in routers. There is no good motivation
for other than edge (CPE?) routers to make use of IPsec for subscriber
traffic.
BGP...
use of IPsec to
protect BGP is
Sam Hartman wrote:
Romascanu, == Romascanu, Dan (Dan) [EMAIL PROTECTED] writes:
-Original Message- From: Sam Hartman
[mailto:[EMAIL PROTECTED] Sent: Monday, October 29, 2007 10:24
PM To: Leslie Daigle Cc: IESG; ietf@ietf.org; [EMAIL PROTECTED]
Subject: [PMOL]
Hi, Steve,
Stephen Kent wrote:
Joe,
I disagree with your suggestion The software performance of security
protocols has been the more substantial issue, and is likely to continue
to be for the forseeable future.
I suspect that most desktop users do not need hardware crypto for
Hi, Steve,
Steven M. Bellovin wrote:
On Wed, 14 Nov 2007 15:39:50 -0500
Stephen Kent [EMAIL PROTECTED] wrote:
Joe,
I disagree with your suggestion The software performance of security
protocols has been the more substantial issue, and is likely to
continue to be for the forseeable
Sam Hartman wrote:
...
Yes, Steve almost certanily did slow down any heavy CPU use during the time
when he was doing the backup.
Our point--Steve, Steve and I--is that for a lot of uses and a lot of
users, no one cares.
Perhaps that's why everyone is using security. We don't have a problem
Harald Alvestrand wrote:
Joe Touch wrote:
Brian E Carpenter wrote:
...
I don't see increasing the areas; I see splitting them down as a
possible way. Leaving an AD at the top level with less work, and having
sub-ADs report to them.
draft-iesg-alvestrand-twolevel, published October 2003
Brian E Carpenter wrote:
On 2007-06-27 15:52, Joe Touch wrote:
Keith Moore wrote:
We could have more ADs and split and/or layer the work to reduce the
per-person load. That may not be the only - or even best - way forward,
It's not clearly even a way forward. the more ADs
Ted Hardie wrote:
...
That does not mean the IETF leadership is itself a meritocracy; it's not.
I believe there remains a disconnect between what people think the I*
roles are (primarily service, e.g., IMO), and what those in those roles
have sometimes interpreted it as (oversight based on
AFAICT, they're just visible indicators of who flies a lot, which means
they also tell people which bags might be more valuable to steal. I ask
them not to put the tags on.
Joe
signature.asc
Description: OpenPGP digital signature
___
Ietf mailing
Keith Moore wrote:
Joe,
What you say might have been true up until say the mid 1980s, but
today, it's hard to defend that statement. For many years the vast
majority of RFCs have been produced by IETF either from working groups
or individual submissions.
That vast number does not
Leslie Daigle wrote:
...
[*] This is perhaps a reasonable time to reiterate that
the IAB is, in fact, a separate entity from the IETF organization.
There are many who believe that all RFCs are Internet standards
documents, thus the current concern with adding IESG non-review
statements to
Jeffrey Hutzelman wrote:
...
I agree that things would be simpler if we could come up with a way to
do things that didn't require figuring out the answer. Unfortunately,
I'm not convinced we can. Before I go any further, let me point out
that I have no reason to believe that ISI will act
Leslie Daigle wrote:
Note that I never said that the IAB was not part of the
IETF family/universe/collection.
The important thing is that the IAB is independent in
its decision making, and not subject to the IESG's
whims or strictly bound by the IETF's input, which appeared to
be the
todd glassey wrote:
So someone submits something to the IETF for standardization that is
patented or that they intend to patent. But in the process of submitting the
work-product to the IETF for publication it is altered by the editor's both
in form and in functionality.
Another variant
Eliot Lear wrote:
Joe,
[...]
*independent* means that. It does NOT mean IETF-family controlled.
I would first see independent submissions abolished altogether. There
are many publishing outlets. This is not the 1970s. The term RFC has
been appropriated by the IETF community.
Marcus Leech wrote:
Todd Glassey wrote:
H... The SOW MUST define all the elements of the Editor's
responsibility and all the specific tasks they perform as well as the
SLA's for those Tasks. It also MUST address the SOD (Separation of
Duties) within the Editor's work since they are
Dave Crocker wrote:
...
And that leads to the basic question of professional editing. As I've noted
before, my recent experience with the RFC Editor's editors was quite good.
They
definitely improved the writing in the document.
However, such an editorial effort it expensive and I do
to standards-track; there
are other docs (Informational, BCP, Experimental) that are handled as well.
Joe
-Original Message-
From: Joe Touch [EMAIL PROTECTED]
Sent: Jul 21, 2006 9:03 AM
To: Marcus Leech [EMAIL PROTECTED]
Cc: Todd Glassey [EMAIL PROTECTED], Pete Resnick [EMAIL PROTECTED], IETF
Julian Reschke wrote:
Joe Touch schrieb:
...
And I'm worried about changes to XML that render the result
uncompilable, not minor text formatting changes. See the changes to 2629
(sometimes referred to as 2629bis, although no I-D has been issued - and
we're currently using this 'bis' version
Stephane Bortzmeyer wrote:
On Fri, Jun 16, 2006 at 03:46:16PM -0700,
Joe Touch [EMAIL PROTECTED] wrote
a message of 85 lines which said:
- edit source code (argh - back to the stone age)
I always assumed that most people involved in IETF edit source code
daily (I did not say
Julian Reschke wrote:
Joe Touch schrieb:
Julian Reschke wrote:
Joe Touch schrieb:
Stephane Bortzmeyer wrote:
On Thu, Jun 15, 2006 at 09:01:22AM -0700,
Joe Touch [EMAIL PROTECTED] wrote a message of 34 lines which said:
IMHO, IETF should always publish the source of its documents
Julian Reschke wrote:
Joe Touch schrieb:
...
As long as future versions are backward compatible with all past
versions, that's fine. That has not been my impression of xml2rfc over
the small window I tried to use it.
...
I guess that depends on the expectation. RFC2629 defines
Julian Reschke wrote:
Joe Touch schrieb:
Stephane Bortzmeyer wrote:
On Thu, Jun 15, 2006 at 09:01:22AM -0700,
Joe Touch [EMAIL PROTECTED] wrote a message of 34 lines which said:
IMHO, IETF should always publish the source of its documents
(the current RFC process is far from perfect
It's worth distinguishing the search for alternate normative output
formats from the search for a standard input format.
Or are you proposing 2629bis as a standard intermediate format, which
makes both camps (input and output) unhappy?
Joe
Carl Malamud wrote:
Hi -
There's been an awful lot
Carl Malamud wrote:
It's worth distinguishing the search for alternate normative output
formats from the search for a standard input format.
Or are you proposing 2629bis as a standard intermediate format, which
makes both camps (input and output) unhappy?
I think we should pick one
Iljitsch van Beijnum wrote:
On 17-jun-2006, at 0:18, Joe Touch wrote:
It's worth distinguishing the search for alternate normative output
formats from the search for a standard input format.
I think the mistake is to make the output format normative. If we make
the input format
Iljitsch van Beijnum wrote:
On 15-jun-2006, at 1:51, Mark Andrews wrote:
*Only HTTP, SMTP, FTP, and DNS traffic are permitted through an IPv6
Native firewall (pings, traceroutes etc. are dropped)
Why? Shouldn't we be prompting good firewall practices?
Droping
Stephane Bortzmeyer wrote:
...
IMHO, IETF should always publish the source of its documents (the
current RFC process is far from perfect in that respect).
Which source (XML2RFC is only one; some use troff, and others use Word,
among others)? Why would inter-source conversion be more useful
Harald Alvestrand wrote:
Ted Faber wrote:
On Mon, Jun 12, 2006 at 02:11:19PM +0200, Iljitsch van Beijnum wrote:
The problem with text is that you have to walk through memory and
compare characters. A LOT.
That's not where your code spends its time.
Run gprof(1). The majority
John Levine wrote:
This draft addresses none of the problems identified the last time it
came around, and I strongly encourage the IESG to say no.
Although I sympathize with the concern that some RFCs would work
better with fancier graphics, PDF isn't a solution to any problem I
Spencer Dawkins wrote:
The key question is whether there exists a format which is likely to be
sufficiently stable that we won't have to revisit this decision in
another 35 years. All the proposed formats - including PDF, XML, etc. -
are moving targets at this time.
That's why I suggested
Michael StJohns wrote:
Brian -
In absolute seriousness, I could publish an ID/RFC or other document
that says that I'm the king of the Internet - doesn't make it so.
These are the facts as I understand them.
1) The RFC Series has always been at ISI, originally under Jon Postel
the
Eliot Lear wrote:
Joe,
SRV records are not equivalent to either assigned or mutually-negotiated
ports; they would require extra messages, extra round-trip times, and/or
extra services (DNS) beyond what is currently required.
Just to be clear, I am not suggesting that no assignments be
Hallam-Baker, Phillip wrote:
From: Joe Touch [mailto:[EMAIL PROTECTED]
The second is a problem, for reasons
explained in my I-D, because it puts control over host
service offerings in the hands of whomever controls its DNS
(e.g., another thing for ISPs to claim makes you a commercial
Hallam-Baker, Phillip wrote:
...
You are confusing politics with technology and making a hash of both.
I would encourage you to review the doc; it discusses the details of the
differences in technical terms. I'll refrain from repeating them here.
Joe
signature.asc
Description: OpenPGP
Eliot Lear wrote:
Jeff,
Disclaimer - I wasn't even aware of this document before reading this
thread. However, I have now read it, so feel prepared to comment.
As it only just came out, you haven't missed much of a debate.
(1) The IANA is a group of adults, but it is no longer a group of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi, all,
In response to some discussion on this mailing list, the following ID
has been submitted. It's intended to become a TCPM work item (thus the
header) if there's sufficient interest.
PLEASE TAKE FURTHER DISCUSSION TO THAT LIST ([EMAIL
Hi, Noel (et al.),
Noel Chiappa wrote:
From: Joe Touch [EMAIL PROTECTED]
TCPMUX doesn't 'handoff'. It expects that .. the service desired is
served off of its port once opened after the initial exchange
(in-band).
.. The downside is that it then forces a two-step
Eliot Lear wrote:
In thinking about this some more if we end up with a TCPMUX like
approach for TCP, how shall UDP, SCTP, et al be handled? Is it okay to
handle them differently?
I'm addressing this in the draft (in progress).
UDP can't support the idea; there's no option space.The
201 - 300 of 482 matches
Mail list logo
