Noel Chiappa
Monday, December
31, 2012 11:27 AM
...It's been quite a
ride.
born in 1963, i felt throughout the 70's and 80's that i had been born
too late, that all the fun stuff had been done already. now in the 10's i
feel like we're just getting going and that i
The IESG has received a request from an individual submitter to consider
the following document:
- 'Multicast DNS '
draft-cheshire-dnsext-multicastdns-08.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.
The NTP issue is rather specific and affected ntpd when you had
server pool.ntp.org
server pool.ntp.org
server pool.ntp.org
in your configuration.
And some those mirrors I mentioned are affected by *deterministic*
reordering. They don't care if traffic hits the closest instance,
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 interconnect that may
affect client
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 10, and historical practice). This
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 case,
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 i'd
i disagree. dns-based load balancing is an unfortunate overloading and
should never be done. RFC 3484 is correct as it is.
re:
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
in http://www.theregister.co.uk/2007/09/21/802_11n_patent_threat/, we see:
Letters of Assurance are requested from all parties
holding patents which may be applicable to any IEEE
standard. Basically they state that the patent owner
You mean like:
https://datatracker.ietf.org/ipr/about/
no, i was thinking of the promise not to sue, rather than the promise to
disclose the possibility of suing.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
no, i was thinking of the promise not to sue, rather than the promise to
disclose the possibility of suing.
You mean like:
...
If technology in this document is included in a standard adopted by IETF
and any claims of any Cisco patents are necessary for practicing the
standard, any
As mentioned above PI blocks can be used for this. As such organizations
who can convince all ISPs in the DFZ that they are important enough to have
their own routing slot can cough up the dough and be there, others will just
have to do with this mechanism to get around.
by what method do you
absent such a method, the network operators who dominate the bottom-up RIR
policy process are almost certainly going to make PI hard to qualify for.
In the ARIN region, one can qualify for PI today with as few as 256 hosts,
and there was a recent proposal that would have indirectly dropped
On the other hand, that gateway and that use of MX records helped to unify
addressing and message formats and provide a more uniform user experience
and eventually a cleaner transition to pure Internet based mail. And once
the gateway was in place and the hosts on our DECnet got better
it's not as if NAT got killed because people in IETF objected to it.
yes, but do you think that was because that ietf was powerless to stop it, or
because that ietf was willing to let consenting adults try out new ideas? i
was there, and from what i saw, it was the former.
it's more like
Without going into debate about consenting adults, and while I might
disagree with Paul in certain fine points, I'd suggest that we consider the
ULA-G proposal within the IETF and ask that Paul submit it as an I-D. ULA-G
could have broad application if in fact we solve the multihoming problem
if you really believe there is going to be a routing system problem, then
you absolutely have to support ULA-C because it is the only way to enforce
keeping private space private.
Also doesn't seem to me to make a lot of sense. There is a set prefix of
ULAs now. Filtering it on is already
Mumble. It's hard for me to buy the idea of there not being a core
portion of the Internet from which all public addresses are reachable.
i was going to say, but these addresses aren't public, but then i saw the
larger problem, which is that the internet's architecture has guardians who
are
it certainly is a problem. and yet failure to provide direction seems
to cause even more problems.
providing leadership is different from providing direction. it includes
things like unsolicited positive vision and innovation, and willingness toward
constructive criticism and guidance when
... If we fail to provide good ways, consenting adults might (and
usually do) come up with worse ways.
is that how you characterize NAT, firewalls, and application layer gateways?
utk-mail11 may have seemed to you like a way to extend the internet, but
to the greybeards of the time who had
And really, there's no way I'd trust DNS to do this. I've spent too
many years watching it break. --Keith
i suspect that you're measuring the wrong thing, or that you're not paying
attention to the what that you're measuring. in a every distributed system
of sufficient size, there is always
my persistent question to the enterprise operator is this: how
frequently do you plan to switch your isp, or how many times did you
do that in the past?
That's actually irrelevant. Regardless of the real answer, enterprises
are not willing to buy into vendor lock.
sorry to add more chaff, i know i'm over quota for the day, but...
In other words, IPv6 is already obsolete, before it's even deployed.
Noel
do you mean that IPv6 was too little, too soon ?
___
Ietf mailing list
Ietf@ietf.org
http://sa.vix.com/~vixie/ula-global.txt has my thoughts ...
are they still refusing to put it into the queue or do anything?
refuse is such a strong word.
Even after several month? Well let really hope that will change now when/if
IPv6-wg change the name to 6man and we can start working
In the enterprise world, where I live now, IPv6 is just flat out a
non-starter without PI space. Its just not even a discussion that's
even useful to have, because the answer to IPv6 without PI is just No.
some day when i'm ready to write my autobiography i shall search the archives
for all
# That said, if people want to limit the effect of these 'bogus' queries
# onto the root servers I suggest that ISP's join into the AS112 project.
# Also it would maybe be an idea for AS112 to add .local there?
yes, but only when some rfc reserves .local the way rfc1918 reserves the
# But what about the other direction? When IETF reserves a name, is it
# always null-routed to AS112? It does not seem so, .example (RFC
# 2606), for instance, is not delegated.
if as112 is asked, my bet is, as112 will cooperate.
for .example, as112 wasn't asked. (yet?)
be transparent;
but in my sunshine-law way of looking at things, everything that can
be opened, should be opened.
--
Paul Vixie
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
In section 3, the draft hijacks local.. Not _local. or
local.arpa., but local..
hijacks is the wrong word. stuart asked long and hard for a forward-name
that was nonuniversal in the way that rfc1918 addresses are, and finally he
did what a lot of people do when faced with entrenched ietf
in http://news.bbc.co.uk/2/hi/programmes/click_online/4317521.stm we see:
---
Early attention to security issues might have given us a better
internet today - or the project might never have taken off at all, says
Robert Kahn.
The net's co-inventor tells BBC Click Online how it all began,
The IAB is ready to ask the RFC-Editor to publish
What's in a Name: False Assumptions about DNS Names
draft-iab-dns-assumptions-02
as an Informational RFC. This document reviews the potential
assumptions that may be made based on domain names, as well as
.)
let's keep going to minneapolis for as long as they'll tolerate us, and
let's try to find summertime destinations that are equally appalling to
the MFLD community. paris, in that regard, should be OFF the table.
--
Paul Vixie
___
Ietf mailing list
this must be a long holiday weekend or something.
The hotel absolutely sucks, thanks, so much so that I, for one, have
sworn _never_ to stay there again.
and we will all, of course, miss you very much.
Your concern over the travel budgets of others is touching (if a
little creepy).
let 'em
vendors to do it.
--
Paul Vixie
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
An earlier comment from Brian Carpenter, to which several people agreed,
indicated that we should consider the need for an IETF sunshine law
separately from the IASA structure.
i didn't agree but i didn't want to use everybody's time arguing about it,
and i still don't. but it turns out that
know there's an RFC that describes this cooperation. in any case it's
in general use in enterprise networks, but less so in isp's and soho's.
--
Paul Vixie
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
where the executive
branch of the U.S. government is trusted beyond any possible reproach.
128 bits ought to be just about right. so, ipv6 may yet come into vogue.
--
Paul Vixie
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman
is chickenhearted.
--
Paul Vixie
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
given the relative ease of acquiring v6 address space and the
relative ease of deploying v4+v6 end hosts and either v4+v6 campuses
or v6 tunnels in v4 campuses, there is no incentive to do nat/v4 any
more, and precious little incentive to do nonat/v4.
*I* can get v6 connectivity easily
that.
--
Paul Vixie
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
that completely.
You're not raising trivial issues here, but they are separable from the
administrative stuff.
i could have sworn that this thread was about patents. when did we decide
that we were actually talking about Plan O from Outer Space?
--
Paul Vixie
somebody told me...
I agree with you 100% on ipr disclosure. I'd go even farther:
if you want it to be an ietf spec and you have relevant ipr,
you have to disclose *and* quit-claim. And, yes, it would make
sense for the admin. body to have somebody agressively doing
searches just in case.
[vixie]
... i do think the iesg/iab should think carefully about making
something a proposed standard or draft standard or full standard
without having first negotiated royalty-free use rights on behalf of
all future implementors, as scrocker did with jbezos for the RSADSI
IPR that went into
somebody asked me...
What is your position on these issues then?
i think that anyone who comments on the mailing list, or in WG meeting
minutes, or as a draft author, should have to disclose any relevant IPR
of which they are then aware or of which they become subsequently aware,
whether or not
.)
--
Paul Vixie
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
liability, not redistribution, and thus doesn't
care about details like commerce. This could be a lesson for IETF if we
really are going to address IPR issues in the boilerplate by adopting any
kind of open source attitude.
--
Paul Vixie
___
Ietf
redistribution. The older BSD
licenseware limits only liability, not redistribution, and thus doesn't
care about details like commerce. This could be a lesson for IETF if we
really are going to address IPR issues in the boilerplate by adopting any
kind of open source attitude.
--
Paul
... notwithstanding, how can a specification be considered a standard
if over half of the operators on the planet refuse to deploy it
because of patent/licence issues.
i can't understand why this matters. if ietf were to change its policies
so that only open technology was allowed in the
Is there situation that multiple root servers installed behine
multiple routers within one AS?
yes. that situation exists inside cogent, with c-root.
If router-P enables PPLB, would there be some problem with TCP based
DNS requests?
your diagram didn't make sense to me so i'll answer
know what the gtld servers are doing.
but f-root's configuration is outlined at http://www.isc.org/pubs/tn/,
read ISC-TN-2003-1 and ISC-TN-2004-1. also http://www.isc.org/ops/f-root/.
--
Paul Vixie
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1
association, i think you need
every new IESG and IAB member to add their signature to all current MoU's
and other agreements. but you should find a lawyer. a better lawyer than
the one who was standing by last time this stuff was discussed or signed.
--
Paul Vixie
.
...
and what is the relationship of an ietf participant to that entity? will
we be members of the ietf association? isoc has members. usenix has
members. ietf eschews not only voting, but membership and classification.
is that time over?
--
Paul Vixie
___
Ietf
from
rubber-stamping ~SPF and to try to stop MARID from using either TXT RRs or
a new RRtype. i've found that you just can't stop newbies from wanting to
make their own mistakes. (like teenagers in that way.)
--
Paul Vixie
___
Ietf mailing list
[EMAIL
/mailfrom.txt. thanks!
--
Paul Vixie
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
leslie,
you wrote, in response to john:
We are in agreement that key strategic decisions have to be made
with the informed consent of the community. Harald and I have
made the commitment to put as much on the table as is possible ...
let me quote from california's sunshine law:
The
was one critic's description. Speaking as an early adopter of Vint's and
Jon's philosophy of openness/inclusiveness/interoperability, it's really
painful to see balkanization and to consider it inevitable.
--
Paul Vixie
___
Ietf mailing list
[EMAIL
appears to not be an expert.
--
Paul Vixie
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
As the AD who sponsored this work, I have to disagree. ...
The recent interim meeting resulted in an agreement to work on
a converged spec taking ideas from SPF and Caller-ID.
Why? These are latecomers to the field. Or is it because of this:
their own 1U, but everybody can configure their
mail clients and web authoring tools to deal with more-distant providers.
--
Paul Vixie
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
mail ought to be done.
--
Paul Vixie
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
... HREF=http://sa.vix.com/~vixie/mailfrom.txt;MAIL-FROM/A.
I do not see a draft in the ietf process anyplace . Was this
ever submitted ? I do notice that several of the other
proposal's make mention of this work , But in none of them do
they mention it as a
/A.
--
Paul Vixie
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
these whackos and
loons, and the reason most often given to me by others why they don't answer,
is that you should never try to teach a pig to sing, because it wastes your
time and annoys the pig. (RAH, writing as LL)
and until next spring or early summer, i'll be content to leave it at that.
--
Paul
of your television set to the loons and trolls...
--
Paul Vixie
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
Paul, and other rootserveroperators (good scrabble word :), what would
your answer/problem/arguments/... be if an ISP would decide to inject
routes to the root-servers into their local network and point these
request to a local dns cache(s), which would have the correct routes to
the the
[EMAIL PROTECTED] (Dean Anderson) writes:
... For the less technical, an exchange point is ...
I don't think there's anyone on this list less technical than you, Dean.
--
Paul Vixie
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org
you're at
it, please outlaw those fiendish DNS-based load balancers. f-root should
still be a 486DX2-66 like it was in ~1995, rather than fifty 1GHz pentiums,
and the 500X load 10 years later is due to client stupidity, not population
growth or backbone speed increases.
--
Paul Vixie
us.
I don't think anonymous, class-based criticism will get us much
further. We need to be specific about what our problems are.
well, if highlighting a difference of opinion is the first step toward
resolving it, then we're on our way.
--
Paul Vixie
that i'd avoided having to look at directly.
please show some self-restraint.
--
Paul Vixie
I might be willing to take a first-first email from someone who has a
history of not-spamming, without requiring that they suffer a penalty
(other than my reporting them to the third-party trust agency) if they
violate that.
no, you would not.
dave, you're not thinking of this as information
of optimization or elegance.
so, it's possible that there is some overlap between my universal privacy
goals, and my support for the long-awaited dnssec extensions, and my support
for the procket/juniper/cisco/paix/nasa/verio/shepfarm/isc multicast
deployment effort.
--
Paul Vixie
.
Is that what you mean?
no. for one thing, this is not (at heart) an smtp problem. more later.
--
Paul Vixie
... you asked about trust query protocols, not about blackhole
lists. as the creator of the first blackhole list, let me just say,
they don't scale.
Are you saying that a new secure scalable trust query protocol be help?
more of a new trust system than what you said. one thing to chew
Now traditionally in IP networks we get away with lots of stuff, but
do you think that something like this would hold up in the voice
business?
voice is dominated by large players including some governments, and
international interconnection seems to be regulated by the itu. if
voice were
sending you e-mail you have no fonts for about
products you'd have no use for, that is.
--
Paul Vixie
there is, but vern says it won't work, so i won't go into it again, yet.
--
Paul Vixie
forever live in an e-world where only private actions matter.
--
Paul Vixie
symmetric closure of the relationship can be reached by an IP
packet from. --Seth Breidbart
--
Paul Vixie
, and if realnetworks is still doing absolutely no confirmation
on e-mail addresses they send bulk e-mail to, then i'll probably continue
to boycott that application suite, no matter how free the players are.
--
Paul Vixie
What you are saying is that for religious reasons you are unwilling to
use FREE and widely used tools in order to help us develop our own.
well, actually, that's not what i said at all.
Next thing you'll be telling me PDF is a bad thing.
and no, that won't be the next thing i'll tell you.
, multicast still isn't a realistic possibility.
--
Paul Vixie
the principle i've always followed is that
all communications must be by mutual consent
Excellent principle, Paul. I'd like to put it at the head of the list.
Ok, I'm dense. How do I meaningfully consent to
somebody for which I have no a priori information
about their
-mail.)
(and i don't think i want to have to pay an X.509 CA for that priviledge.)
--
Paul Vixie
[smtp] is what the world uses today and will continue to use for quite
some time. reports of its death are just a tad premature.
When folks agree on the new mail transfer services that we need and
when we try to add them to smtp and fail, THEN we can have productive
discussions about a
PV well, except that that's not how dns was created, or http, or html, or
PV nntp, or xml, or rpc/xdr/nfs, or sip, or pgp, or jabber.
_New_ services get created in all sorts of ways and for all sorts of reason.
if you believe that ssh was a new service (compared to telnet) then i agree
with
i'm pretty comfortable with www.dictionary.com's definition of consent.
Ah, are we about to develop psmtp (psychic simple mail transport protocol)?
no. but through a combination of open source and public benefit licensing,
we are eventually going to be able to tell whether a message was
between the transport and mailbox, and it *will* get
replaced with something that can carry trust indicators and deal with
multilevel agency. but the real and larger work is the meatspace-sized trust
web, without which smtp is probably as good as e-messaging can ever get.
--
Paul Vixie
at the
grownups table.)
--
Paul Vixie
, while
we deal with methods, like authentication.
--
Paul Vixie
@ to
generate interest.)
--
Paul Vixie
an existing refereed forum for non-standards work, or just self-publish it?
--
Paul Vixie
/35 routes are being discouraged in favor of /32 entries...
4,064,000,000 addresses to ensure that just one host -might-
have global reachability. IMHO, a /48 is even overkill... :)
i think the important points for ietf@ to know about are (a) that this
is an open issue, (b)
: there is no
officially supported way to do zone transfers for the root. This can stop
working at any time.
indeed, it's been downhill ever since 10.0.0.53 went away. now it's chaos.
--
Paul Vixie
things, but the
internet is definitionally and constitutionally uncontrollable. yay!
--
Paul Vixie
constraints, or adding new constraints that aren't
generally accepted (or even generally known) makes evolution just stop.
(this issue came up during the verisign sitefinder debates, and i'd like
to thank klensin and bellovin for clarifying my thoughts on this topic.)
--
Paul Vixie
[EMAIL PROTECTED] (J-F C. (Jefsey) Morfin) writes:
Most of all when the hacker seats in the Oval Office, what is the solution?
Kaspurcheff was not the only root hacker to be known. Jon Postel was too.
good bye, sir.
--
Paul Vixie
comments.
jfc
please learn the basics before you come in here and start making proposals.
--
Paul Vixie
and without protection.
i guess what karl has shown here is that on the internet there is no buck
or that it doesn't stop anywhere or some combination thereof.
--
Paul Vixie
We do, however, have trouble, even at our currently reduced size.
yes. and if we ever start to succeed again, the size will increase again.
By the way, what about .museum?
.museum does not delegate all of its subdomains.
not all tld's are delegation-only.
--
Paul Vixie
1 - 100 of 150 matches
Mail list logo
