Total of 202 messages in the last 7 days.
script run at: Fri Mar 6 00:53:02 EST 2009
Messages | Bytes| Who
+--++--+
4.95% | 10 | 4.29% |53786 | petit...@acm.org
4.95% | 10 | 3.76% |47110 | d...@dotat.at
--On Thursday, March 05, 2009 10:37 -0800 Paul Hoffman
wrote:
> At 1:14 PM -0500 3/5/09, John C Klensin wrote:
>> I'd like to be sure that the people proposing this are all
>> actually proposing the same thing... versus the possibility
>> that they have different things in mind.
>
> Fully agre
Andrew Sullivan wrote:
> On Thu, Mar 05, 2009 at 10:32:28AM -0800, Doug Otis wrote:
>>> Note that there has been work in DNSOP suggesting that rejecting on
>>> the failure of reverse DNS lookup is not always a good idea.
>> Agreed.
>
> Just to be clear: I am not sure I agree with those who t
On Thu, Mar 05, 2009 at 10:32:28AM -0800, Doug Otis wrote:
>> Note that there has been work in DNSOP suggesting that rejecting on
>> the failure of reverse DNS lookup is not always a good idea.
>
> Agreed.
Just to be clear: I am not sure I agree with those who think reverse
DNS should not be
Paul Hoffman wrote:
+1, after San Francisco. Let's give the volunteer tool authors some breathing
space.
+1
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/i
At 1:14 PM -0500 3/5/09, John C Klensin wrote:
>I'd like to be sure that the people proposing this are all
>actually proposing the same thing... versus the possibility that
>they have different things in mind.
Fully agree.
>The proposed IAB document,
>draft-iab-streams-headers-boilerplates,
This
On Mar 5, 2009, at 6:30 AM, Andrew Sullivan wrote:
On Thu, Mar 05, 2009 at 01:00:55PM +, Tim Chown wrote:
Hi,
Just an observation, I don't know whether its been changed or
applied recently, but we had some mails to various IETF lists soft
rejected overnight due to failure of the recei
--On Thursday, March 05, 2009 05:44 -0800 "Hallam-Baker,
Phillip" wrote:
> I doubt that this is a huge tool-builder issue. Lets not go
> looking for problems.
>
> I think moving the boilerplate is a good idea, particularly
> for people who are still reading the TXT versions of the docs.
>
> T
On Thu, 5 Mar 2009, Paul Vixie wrote:
>
> so the policy you're arguing for is that clients should always randomize?
When the client has topology information it should follow that (i.e. rules
1 - 8). When it doesn't have topology information it should use the order
it gets from the DNS (i.e. rule 1
>/24 - could be, but is it worth?
>/16 - not a chance; there are a lot of LIRs with /20 in RIPE region, so
>/16 is way too
>much (and you can have quicker connection to U.S. than to some parts of
>Europe).
there are three modes here.
first, you can do some good.
second, you ca
> > you'll see roundrobin and lifo, among others, in many caches including
> > stub caches.
>
> Large numbers of sites have been depending on this behaviour for over 15
> years, so it was wrong of RFC 3484 to break it.
some number of vendors have depended on revenue from selling this feature
but
> RFC 3484 is correct as it is.
>
>Here I don't. The idea behind is good, the implementation is not.
>Client would have to know BGP path to DA + DB and decide on basis of
>routing protocol. Selection based on longest matching prefix will work
>in only very small percent of cas
On Wed, Mar 4, 2009 at 9:04 PM, wrote:
> we now return you to your rant.
Sorry, if I sounded too harsh.
my error here - Paul said DNS does no ordering... he did not specify
> ordering of what.
Order of RRs in zone file is not relevant for the order "on the wire".
DNS (as in DNS protocol) do
On Wed, Mar 4, 2009 at 6:57 PM, wrote:
> On Wed, Mar 04, 2009 at 05:11:47PM +, Paul Vixie wrote:
> > > > i disagree. dns-based load balancing is an unfortunate overloading
> and
> > > > should never be done. RFC 3484 is correct as it is.
> > >
> > > Why is it right for topology-ignorant cli
* Paul Vixie:
>> Large numbers of sites have been depending on this behaviour for over 15
>> years, so it was wrong of RFC 3484 to break it.
>
> some number of vendors have depended on revenue from selling this feature
> but i'd say that only a small number of sites ever saw any benefit from it.
* Christian Huitema:
> The order of5C records in a DNS response is, at best, a
> hint. Relying on it as if it were a mandate to clients is a gamble.
When you run RRset-based load balancing, you don't rely on servers
preserving order, or reordering responses. It is completely
sufficient that ther
* Paul Vixie:
> neither a client or a server can be guaranteed topology-aware. dns leaves
> ordering deliberately undefined and encourages applications to use their
> own best judgement.
The "leaves undefined" part is at odds with your previous statement
that RFC 3484 is correct. It is complian
On Mar 4 2009, Ondřej Surý wrote:
On Wed, Mar 4, 2009 at 6:57 PM, wrote:
[...]
DNSSEC does reorder RRSets within a zone. Which is a new feature.
When we started talking about order of RRSets? This is purely discussion
about order of RRs in RRSet. Order of RRSets in zone is irrelev
my error here - Paul said DNS does no ordering... he did not specify
ordering of what. we now return you to your rant.
--bill
On Wed, Mar 04, 2009 at 07:54:37PM +, Chris Thompson wrote:
> On Mar 4 2009, OndEej SurC= wrote:
>
> >On Wed, Mar 4, 2009 at 6:57 PM, wrote:
> [...]
> >>
On Thu, Mar 05, 2009 at 01:00:55PM +, Tim Chown wrote:
> Hi,
>
> Just an observation, I don't know whether its been changed or applied
> recently, but we had some mails to various IETF lists soft rejected
> overnight due to failure of the receiving MX to perform a successful
> reverse DNS loo
On Thu Mar 5 13:00:55 2009, Tim Chown wrote:
Just an observation, I don't know whether its been changed or
applied
recently, but we had some mails to various IETF lists soft rejected
overnight due to failure of the receiving MX to perform a successful
reverse DNS lookup on the IPv6 sender addr
I doubt that this is a huge tool-builder issue. Lets not go looking for
problems.
I think moving the boilerplate is a good idea, particularly for people who are
still reading the TXT versions of the docs.
The only piece I would keep on the front page is the bit that says where
comments should
Marc Petit-Huguenin wrote:
If you did contribute an early implementation or did think of
contributing but finally didn't, please respond to this email with
your story. Interesting points are why you did (or not) the early
implementation, will you do more, what would motivate you to do more
On Wed, 4 Mar 2009, Paul Vixie wrote:
> only in the case where the server is depending on rr ordering within
> rrsets, which dns has never guaranteed and which many caches (both rdns
> and stubs) randomize or reorder anyway, and where the server's
> imputation of topology knows about every private
"TSG" wrote:
Then the template has to be changed. Will the IETF still continue to
accept documents formatted the old way or will it mandate this change
everywhere - and gee - that could be our own little stimulus package -
we may have to hire someone to move the (c) in all of the existing
do
Tim Chown wrote:
[...]
> It's not uncommon for IPv6 servers to be multiaddressed, so mail admins
> will probably just need to be a wee bit more careful, and certainly try
> to avoid using autoconf globals on servers.
Nothing wrong with EUI-64 or autoconf, as long as you actually want them
there ;)
Hi,
Just an observation, I don't know whether its been changed or applied
recently, but we had some mails to various IETF lists soft rejected
overnight due to failure of the receiving MX to perform a successful
reverse DNS lookup on the IPv6 sender address.
- Transcript of session follows
On Wed, Mar 04, 2009 at 02:09:22PM +, Tony Finch wrote:
> It seems that Vista implements RFC 3484 address selection, including the
> requirement to sort IP addresses. This breaks a great deal of operational
> dependence on DNS-based load balancing, as well as being based on an
> incorrect under
6MAN WG is working on this.
Jari
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
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 year
30 matches
Mail list logo
