Fwd: WHEN are CERF & CROCKER going to be Accountable...?

[Techno CAT <[e-mail]>]

The first question....NOT answered...was....
...
WHEN are CERF & CROCKER going to be Accountable...?
...
with respect to "you are also free to build your own root"
...
Why would anyone "build a root" in this day and age. That is so 1980s DNS.
Peer-2-Peer DNS & Currency technology has clearly demonstrated the
superior architecture of NON Centralized IANA ICANN etc.
...
As for...."You will soon have many more choices of TLD."
...Jon Postel said that in 1998...



---------- Forwarded message ----------
From: Vint Cerf <[e-mail]>
Date: Sun, Apr 13, 2014 at 9:01 AM
Subject: Re: WHEN are CERF & CROCKER going to be Accountable...?
To: Techno CAT <[e-mail]>
Cc: Steve Crocker <[e-mail]>, Fadi Chehadé
<[e-mail]>, kathy brown <[e-mail]>, Brian E
Carpenter <[e-mail]>, Miles Fidelman
<[e-mail]>


nonsense.

it is easy and cheap to get a domain name at second level or below.
You will soon have many more choices of TLD.
The reason people use the large providers is convenience of not having
to run your own servers.

you are also free to build your own root if you want and try to get
people to use it.

vint



On Sun, Apr 13, 2014 at 9:55 AM, Techno CAT <[e-mail]> wrote:
>
> "all of this actually unrelated to DMARC"
>
> Really ? Artificial Scarcity IANA DNS policies and Toy Protocols have
> pushed people away from the simple models where people and
> domains were closer to 1 to 1. People were forced into mass
> service providers such as Yahoo. They then want to take their
> email "handles" and use them other places. They did that and now
> are not encouraged to do that.....this ALL can be traced to the
> STONEWALLING of DNS by POSTEL CERF and  CROCKER.....
>
> WHEN are CERF & CROCKER going to be Accountable for THEIR #ICANN #IANA
> #ARIN #ISOC #IETF Eco.System?
> http://mm.icann.org/pipermail/ianatransition/2014-April/000476.html …
> #NTIA #DOJ #FTC
>
> http://mm.icann.org/pipermail/ianatransition/2014-April/000476.html
>
> [IANAtransition] [IANAxfer] DMARC snafu as a wake-up call
>
> Vint Cerf vint at google.com
> Sun Apr 13 11:54:39 UTC 2014
>
> Previous message: [IANAtransition] [IANAxfer] DMARC snafu as a wake-up call
> Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>
> ________________________________
>
> Steve's analysis strikes me as the correct one.
>
> see www.dmarc.org
>
> v
>
>
>
> On Sat, Apr 12, 2014 at 9:58 PM, Steve Crocker <steve at shinkuro.com> wrote:
>
> > Apparently I can't post to this list from this email address.  I'm not
> > sure why, but the other readers of this list will have to depend on your
> > inclusion of my message in your reply.  This also means you'll have the
> > last word :)
> >
> > The liability argument you're suggesting is a very slippery slope.  The
> > IANA group does do some checking before changes are made to the entries in
> > the root zone for top level domains, but for general protocol parameter
> > entries I don't believe they do more than make sure entries are distinct.
> >  If expert judgment is needed for a particular protocol parameter registry,
> > that's arranged in advance when the registry is defined by the IETF.
> >
> > But all of this actually unrelated to DMARC.  Anyone can publish whatever
> > they want in his own portion of the DNS tree, and anyone is free to depend
> > upon or ignore what's published.  The DMARC conventions come out of the
> > email community.  There just isn't any direct connection to ICANN or IANA.
> >  Thus, even if the IANA team had wanted to intercede, they couldn't have.
> >  They simply aren't in that loop.
> >
> > Steve
> >
> > Sent from my iPhone
> >
> > > On Apr 12, 2014, at 9:20 PM, Miles Fidelman <mfidelman at meetinghouse.net>
> > wrote:
> > >
> > > Steve,
> > >
> > > Long time, no see.
> > >
> > > In theory, what you say is true.  But... I wouldn't be so cavalier as to
> > assume no liability.  "I was following orders" has never been valid
> > defense, for anything.  And standards bodies have been held liable for
> > failing to exercise a "duty of care."  Re. email, IANA, and by extension
> > ICANN, does handle various SMTP-extension related stuff.
> > >
> > > Still - a bit offtrack from the transition.
> > >
> > > Miles
> > >
> > > Steve Crocker wrote:
> > >> Miles,
> > >>
> > >> IANA publishes what it's told to publish.  Editorial control lies
> > elsewhere.  The definition of DNS and how it's to be used is done within
> > the IETF.  Allocation of top level domains is done within ICANN but IANA's
> > role is to execute the decisions that are made in the other parts of ICANN.
> > >>
> > >> The current DMARC problem isn't really even a DNS problem except that
> > DNS is used to publish DMARC information.  The current DMARC problem is,
> > well, a DMARC problem.  The community that defined, implemented and depend
> > upon DMARC are the ones who need to sort this out.  That's the email
> > community.  ICANN does not play a role here.
> > >>
> > >> Steve
> > >>
> > >> Sent from my iPhone
> > >>
> > >>> On Apr 12, 2014, at 7:47 PM, Miles Fidelman <
> > mfidelman at meetinghouse.net> wrote:
> > >>>
> > >>> Sorry - I mentioned it as a cautionary tale, and the thread seems to
> > have exploded.  But... in thinking about it, I will say it sure does seem
> > like an IANA/ICANN related issue - given that the DNS system is the vehicle
> > that propagates DMARCS policies.
> > >>>
> > >>> Miles
> > >>>
> > >>> Brian E Carpenter wrote:
> > >>>> Miles,
> > >>>>
> > >>>> I understand that you are very seriously inconvenienced by this.
> > >>>> I just think you're reading it wrong from the point of view
> > >>>> of "IANA transition".
> > >>>>
> > >>>>> On 13/04/2014 10:50, Miles Fidelman wrote:
> > >>>>> ...
> > >>>>> After all, what's really causing this DMARC
> > >>>>> debacle is precisely the publication of a DNS record containing
> > >>>>> "p=reject" by Yahoo, multiple large players honoring that record,
> > >>>> It's inside a TXT record as I understand it. ICANN has absolutely
> > >>>> nothing to do with TXT records. The DMARC draft actually says it
> > >>>> quite well:
> > >>>>
> > >>>>   "DMARC assumes that entities who send messages with their domains in
> > >>>>    the RFC5322.From field and wish to protect those messages with
> > DMARC
> > >>>>    can
> > >>>>
> > >>>>    1.  Control DNS entries for the domains to be protected, including
> > >>>>        adding arbitrary new subdomains with TXT records...."
> > >>>>
> > >>>> Therefore, control lies entirely with the domain's controller, Yahoo
> > >>>> in this case, according to the DMARC non-standard itself.
> > >>>>
> > >>>> Yahoo has chosen to use a TXT record that is described in an
> > unapproved
> > >>>> draft (that seems unlikely ever to be approved except as an
> > independent
> > >>>> publication) using a format not assigned by IANA (so far).
> > >>>>
> > >>>> That's an issue of Yahoo governance.
> > >>>>
> > >>>>> denying delivery to a huge number of legitimate emails - effectively
> > a
> > >>>>> DDoS attack, effected through the DNS system, with no recourse.  DNS
> > is
> > >>>>> under IANA and ICANN purvue.
> > >>>> The names in the root zone are under ICANN purvue and the contents
> > >>>> of the various registries are under IANA stewardship.  But there it
> > >>>> ends. Neither of them is responsible for network operations.
> > >>>>
> > >>>>    Brian
> > >>>>
> > >>>>> To me, that makes it a governance issue.
> > >>>>>
> > >>>>> Miles Fidelman
> > >>>
> > >>> --
> > >>> In theory, there is no difference between theory and practice.
> > >>> In practice, there is.   .... Yogi Berra
> > >>>
> > >>> _______________________________________________
> > >>> IANAxfer mailing list
> > >>> IANAxfer at elists.isoc.org
> > >>> https://elists.isoc.org/mailman/listinfo/ianaxfer
> > >
> > >
> > > --
> > > In theory, there is no difference between theory and practice.
> > > In practice, there is.   .... Yogi Berra
> > >
> > > _______________________________________________
> > > IANAxfer mailing list
> > > IANAxfer at elists.isoc.org
> > > https://elists.isoc.org/mailman/listinfo/ianaxfer
> > _______________________________________________
> > IANAxfer mailing list
> > IANAxfer at elists.isoc.org
> > https://elists.isoc.org/mailman/listinfo/ianaxfer
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mm.icann.org/pipermail/ianatransition/attachments/20140413/cb797e99/attachment-0001.html>




-- 
3DNB - Real Banking for Your VIRTUAL Worlds
http://3DNB.COM
Login: ZOOM
Password: BOX

@Techno_CAT_r
http://Twitter.com/Techno_CAT_r