On 21/08/13 19:00, Joe Touch wrote:
So what would you use for muxing, if TCPMUX is not a good idea?
You need to roll your own. The requirements of systems vary widely, as
do the costs/benefits of different approaches.
I listed a few before, but here's a more comprehensive list:
-
On 21/08/13 20:03, Bob Braden wrote:
Indeed, TCPMUX is quite historic... it represents a Road Not Taken. My
memory is a bit hazy after 30+ years,
but I think there was a serious discussion around 1979 of using strings
instead of contact port numbers
for opening TCP connections. Here is the hazy
Subject: Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender
Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to
Proposed Standard Date: Thu, Aug 22, 2013 at 12:23:56AM -0400 Quoting Scott
Kitterman (scott@kitterma
On Thursday, August 22, 2013 00:26:35
On 08/21/2013 08:44 PM, Olafur Gudmundsson wrote:
Most of the recent arguments against SPF type have come down to the following
(as far as I can tell):
a) I can not add SPF RRtype via my provisioning system into my DNS
servers
b) My firewall doesl not let SPF Records through
On 8/21/13 4:40 PM, Dave Crocker wrote:
On 8/21/2013 12:46 PM, Pete Resnick wrote:
It is not your complaint about the imposition of new requirements that
is problematic, or your point that it is not useful to continue that
line of discussion. Talk about the utility of a comment all that you
On Aug 22, 2013, at 4:36 AM, Jelte Jansen jelte.jan...@sidn.nl wrote:
On 08/21/2013 08:44 PM, Olafur Gudmundsson wrote:
Most of the recent arguments against SPF type have come down to the
following (as far as I can tell):
a) I can not add SPF RRtype via my provisioning system into
This looks reasonable to me and given how much effort it has taken to get
agreement on theses words, I am not keen on any of the material changes I have
seen proposed.
On Aug 21, 2013, at 11:52 AM, The IESG iesg-secret...@ietf.org wrote:
A new IETF working group has been proposed in the
On Thu, Aug 22, 2013 at 10:22 AM, Pete Resnick presn...@qti.qualcomm.comwrote:
Some folks have simply dismissively said, Go read the archive, without
pointers.
Pete, I like your position, but I believe go read the archive or the
equivalent will continue to be a standard response unless
Barry Leiba barryle...@computer.org writes:
The general point is that the new people whom we want
to draw in as productive participants will be watching how we treat
each other and deciding whether they want to wade into that pool.
It's not just new people watching and being turned off.
OK, direct question; I'll take the (short) time to give a direct answer.
On 8/22/13 9:53 AM, Scott Brim wrote:
Pete, I like your position, but I believe go read the archive or the
equivalent will continue to be a standard response unless someone is
responsible for giving a more thorough
On 8/22/2013 12:44 AM, Martin Sustrik wrote:
On 21/08/13 19:00, Joe Touch wrote:
So what would you use for muxing, if TCPMUX is not a good idea?
You need to roll your own. The requirements of systems vary widely, as
do the costs/benefits of different approaches.
I listed a few before, but
Hi Erik,
Thank you for the review.
Please see inline.
Cheers,
Med
-Message d'origine-
De : v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] De la part de
Erik Kline
Envoyé : jeudi 22 août 2013 13:22
À : Owen DeLong
Cc : v6...@ietf.org; IETF Discussion
Objet : Re: [v6ops] Last
REQ 1:
6434 5.9.1 is already a MUST. This does not need to be repeated.
6434 5.8 is already a MUST. Unless you want to make multipart
ICMP a MUST (why?) as well, this too can be removed.
REQ 6:
re 6434 12.2, this MUST does not appear to be stronger than 12.2's MUST
frankly even
Hi Hector,
At 07:29 22-08-2013, Hector Santos wrote:
Besides the SPF type issue, I believe there are still a number of
integrated protocol issues to address. How does the following RFCs
play into SPFBIS output, the SPF type and the overall BIS document?
Should RFC4408BIS update any of these
On 22/08/13 16:01, Thomas Narten wrote:
Barry Leiba barryle...@computer.org writes:
The general point is that the new people whom we want
to draw in as productive participants will be watching how we treat
each other and deciding whether they want to wade into that pool.
It's not just new
On Thu, Aug 22, 2013 at 1:36 AM, Jelte Jansen jelte.jan...@sidn.nl wrote:
While I appreciate the argument 'this works now, and it is used'
(running code, and all that), I am very worried that we'll end up with
what is essentially a free-form blob containing data for several
protocols at the
In article 5215cd8d.3080...@sidn.nl you write:
So what makes you think the above 4 points will not be a problem for the
next protocol that comes along and needs (apex) RR data? And the one
after that?
SPF is ten years old now. It would be helpful if you could give us a
list of other protocols
The IETF Trust Trustees are pleased to announce that Ole Jacobsen has been
selected as the IETF Trust
Chair. Ole was selected following the resignation of Chris Griffiths as Chair,
who assumed the
chairmanship of the IAOC. This will be Ole's second stint as Chair as he
succeeded Marshall
Pete, I like your position, but I believe go read the archive or the
equivalent will continue to be a standard response unless someone is
responsible for giving a more thorough response. Who do you think that
should be?
If you've had the most fleeting look at this:
Hi Eric,
This looks good - comments follow ...
a) I assume that overload control development work will derive more specific
security requirements - e.g., as REQ 27 is stated at a rather high level.
The discussion in security considerations section seems reasonable.
We agree with this.
Hi David,
We agree on all your points, and will make the updates in the next version,
pending shepherd instructions.
Thanks!
Ben.
On Aug 22, 2013, at 2:50 PM, Black, David david.bl...@emc.com wrote:
Hi Eric,
This looks good - comments follow ...
a) I assume that overload control
Part of the question is whether the IETF is going to work with ICANN, IANA
and the ccTLD to audit delegations for servers that are not RFC 103[45]
compliant and suspend delegations where the servers are not compliant.
* no responding to queries based on query type
* not having a
I can't myself think of a good justification for sarcasm, (well, maybe [1]:-)
good sarcasm is like good protocol design - many can recognise it, some can
appreciate it, few can truly understand its nuances, and even fewer can create
it.
You're just not one of them.
Lloyd Wood
Pete, et al,
On 8/22/2013 7:22 AM, Pete Resnick wrote:
So, now at the point of IETF LC, the correct thing to happen is to
let folks make their objections, point them to places in the prior
conversation where the WG, the chairs, the ADs, and assorted other
folks became convinced, and see if
LC should not be treated as a right of passage, to test the patience of
folks who have developed a document.
rite?
Lloyd Wood
http://sat-net.com/L.Wood/
Total of 272 messages in the last 7 days.
script run at: Fri Aug 23 00:53:02 EDT 2013
Messages | Bytes| Who
+--++--+
5.88% | 16 | 5.06% | 118905 | d...@dcrocker.net
5.51% | 15 | 5.10% | 119919 |
The IESG has approved the following document:
- 'LDP Downstream-on-Demand in Seamless MPLS'
(draft-ietf-mpls-ldp-dod-09.txt) as Proposed Standard
This document is the product of the Multiprotocol Label Switching Working
Group.
The IESG contact persons are Adrian Farrel and Stewart Bryant.
A
27 matches
Mail list logo
