►
From YouTube: IETF114 DMARC 20220728 2000
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
The
big
hand
and
the
little
hand
are
on
their
respective
good
places
to
tell
us
that
it
is
now
20
hundred
utc,
which
is
eight
o'clock
somewhere
about
four
o'clock
in
philadelphia.
It's
time
to
start
ietf,
114
dmarc
working
group
session,
I'm
barry
lieber,
you
see
on
the
screen.
Seth
says,
excuse
me
seth
blank
and
we
are
the
co-chairs.
A
Here
we
go
our
agenda
for
the
day,
some
intro
and
admin
stuff,
and
then
we
we
go
look
at
the
issues
closure
on
the
tree,
walk
issue
which
I
hope
we
can
get
in
a
reasonable
reasonably
short
time.
Here.
We've
been
batting
that
around
a
lot
on
the
mailing
list,
an
issue
that
I'm
raising
on
how
to
talk
about
mailing
list
interoperability
in
in
the
best
spec
and
then
whatever
other
issues
we
have
todd
has
one
or
two.
A
Maybe
I
think
whatever
it
is,
will
be
quick
and
then
discussion
on
the
the
two
reporting
docs
for
whatever
time
we
have
left
and
whether
there's
anything
to
talk
about
on
them.
We
have
a
one-hour
session
here.
A
So
we'll
start
with
the
administration
stuff,
with
the
slide,
with
the
very
small
writing
note
the
note
well
well,
it
is
telling
you
what
your
responsibilities
are
with
respect
to
intellectual
property
rights,
declarations
and
that
sort
of
thing,
if
you
are
unfamiliar
with
any
of
it,
please
read
up
on
it.
You
should
be
well
familiar
with
it
by
now.
I
think.
A
Meeting
tips
for
this
meeting
and
we
will
enforce
this-
make
sure
you
sign
on
to
the
session
using
the
meet
echo
light
client,
if
you're
in
the
room
and
put
yourself
in
the
microphone
queue
by
raising
your
hand
in
that
tool.
Otherwise
we
will
not
recognize
you,
even
if
you
are
recognizable.
A
You
can
get
there
by
oh
well,
yes,
we
don't
have
somewhere
in
the
room,
there's
probably
something
to
scan
that
has
a
qr
code
yeah
on
the
backs
of
some
of
the
chairs,
or
you
can
do
it
from
the
from
the
meeting
agenda.
A
Let's
see,
oh
yes
and
wearing
masks,
please
do
wear
your
masks
even
when
you're
at
the
microphone,
the
microphones
have
been
picking
people
up
very
well
unless
you
are
standing
up
here
at
this
mic
or
this
one,
in
which
case
we
presume
you
are
socially
distanced
and
you're
just
spewing
your
germs
on
the
microphone
for
the
next
person
to
eat
remote
participants.
Please
make
sure
your
audio
and
video
are
off,
except
for
seth
when
you
are
not
speaking,
and
please
turn
your
video
on.
A
Okay,
so
the
purpose
of
this
meeting
is
to
resolve
whatever
remaining
issues
we
have
on
the
dmarc
bisdraft.
We
hope
that
we
can
get
this
finished
sometime
very
soon,
and
so
is
the
agenda
that
I
showed
you
before,
which
we
see
again
here.
Okay,
does
anyone
have
any
bashes
for
the
agenda?
Anything
you
want
to
add
anything.
You
want
to
change,
seeing
nothing,
let's
get
started
tree
walk
is
the
text
in
version
14,
which
you've
obviously
read
through
entirely
because
todd
posted
it
as
long
ago
as
last
night
is
the
text
there.
A
B
Tim
tim
wisinski,
we're
up
to
15
and
I
posted
the
diff
in
the
hedge
dock,
so
folks
can
compare
13
to
15
to
look
at
the
tree,
walk
examples.
A
C
The
the
only
thing
I
changed
was
the
there
were
there
were
a
bunch
of
tree
walk
examples.
The
one
for
the
one
that
used
the
psd
was
was
extremely
simple,
so
I
made
it
slightly
more
complicated,
so
you
now
have
mega
dot
bank
dot
example
and
giant
dot.
Bank
dot
example,
where
bank
dot
example
is
a
ph.
C
It's
a
psd
and
mega
bank
has
a
dmarc
record
and
giant
bank
doesn't
and
it
so
so
one
does
a
tree
walk
yeah,
sorry,
so
it
does
a
tree
walk
up
from
mail.mega
and
finds
it
it's
aligned,
and
then
it
does
free,
walk
up
from
mail.giant
and
finds
it
is
not
aligned
because
they're
they're
parallel
under
the
psd.
So
I
think
that
is.
C
I
believe
that
is
about
as
complicated
a
psd
example
as
as
anywhere
close
to
reality,
and
I
think
it
and
it
points
out
what
it
do,
what
what
what
the
psd
flag
does.
It
makes
the
pre-walk
different.
So
I
I
think
I
think,
as
far
and
other
than
that
we've
had
endless
discussions
and
nothing
else.
I
haven't
seen
anything
else
that
needs
to
change.
I
hope
we're
done.
A
Okay,
thanks
john
for
the
summary
I
I
agree
from
your
description,
not
having
read
it
myself,
but
from
your
description.
I
agree.
That's
the
kind
of
example
I
was
looking
for.
So
thank
you.
B
Tim
tim
wilsinski,
I
agree
with
john
I'd
love
that
example
of
his
that
complicated
one.
My
only
comment
would
be
do
we
need
like
a
bad
example
like
so
in
a
lot
of
our
dna
stocks
we
always
have
like
this
is
like
not
the
thing
to
do
right
and
we
show
people
like
you
know
so,
and
I'm
wondering
if
or
if
that's
just
going
to
give
people
like
bad
ideas.
C
Having
gone
through
the
psl
to
see
what
examples
are
plausible,
I
don't.
I
think
it's
very
unlikely
that
anybody
would
do
a
more
complicated
example
other
than
to
make
other
than
other
than
to
make
some
sort
of
point.
So
I,
in
this
particular
case
I
yeah-
I
I
I'm
falling
out
on
the
side
of
don't
don't,
show
the
more
complicated
stuff
because
they're
unlikely
to
think
of
it
think
about
it,
otherwise,
and
it's
and
it
would
be
a
bad
idea.
A
D
Just
re-reading
everything
in
fine
detail
this
morning
and
I
went
back
to
the
original
use
cases
we
talked
about
when
we
talked
about
the
tree
walk,
and
I
think
we
may
have
something
to
discuss
that
is
potentially
a
wrench,
but
I
think
there's
it
has
to
do
with
the
the
max
depth
of
n
and
the
way
it's
currently
written.
Is
you
jump
if
the
the
number
of
labels
is
greater
than
five?
You
blop
off
a
bunch
and
move
to
the
widest
labels
and
the?
D
I
think
that's
the
cleanest
way
to
do
it,
because
you
have
a
very
explicit
determination
at
the
end
of
that
you've
you've
reached
a
tld
if
you've
walked
the
whole
way.
You
know,
there's
no
policy,
you
know
you
do
not
have
to
apply
dmarc
to
the
message
flow.
I
think
the
problem
with
that
is
the
the
complex
organization
use
case.
That
was
one
of
the
explicit
reasons
for
the
tree:
walk,
which
is
the
you
know.
D
The
federal
government
use
case
than
the
university
use
case,
which
is,
I
have
sub-organizations
within
sub-organizations
with
complex
sending
environments
and
the
dmarc
reports
jump
the
person
who
can
actually
do
something
about
that.
So
just
to
use
a
real
example
right.
It's
a
right.
The
u.s
secret
service
right
uss.dhs.gov,.
D
We
actually
miss
the
use
case
of
that
walking
up
to
the
appropriate
department,
same
thing
in
a
university
with
a
math
department
and
some
departments
under
it,
and
if
we
just
walk
for
five
and
then
stop,
I
think
that
actually
solves
the
problem.
But
then
it
creates
a
a
separate
issue
which
is
right.
D
If
you
have
the
abuse
use
case
of
a
dot
b,
dot
c
dot
d,
dot,
e
dot,
f,
dot,
dot
domain,
you
could
walk
through
five
say
I'm
done,
but
there
could
still
be
a
dmark
policy,
then
that
you
never
get
to
that
says,
reject
the
message,
and
so
it's
a
lot
less
clean
and
there's
a
there's
a
trade-off
there.
But
I
am
concerned
about
that.
D
A
C
D
C
C
More
than
five
still
seems
awfully
hypothetical
and-
and
the
thing
is
like-
I
know
that
I
know
these
deep
they're,
these
deep
names
inside
organizations,
but
they
tend
not
to,
but
those
deep
names
tend
not
to
be
different
organizations.
They
just
tend
to
be
a
lot
of
names
within
the
same
organization,
in
which
case
the
jump
doesn't
hurt.
D
E
A
E
Okay,
I
came
up
here
with
another
question:
oh
yeah,
so
and
I'm
glad
tim's
here
because
he
might
be
able
to
let's
simmer
lane
when
we
we
get
it.
And
someone
says:
oh,
a
tree,
walk!
That's
pretty
weird.
Did
anybody
talk
to
the
dns
people
about
this?
Should
should
dns
deer
look
at
this?
Should
we.
A
Was
there
are
several
people
in
the
room
who
are
dns
folks
and,
and
he
said,
sketchy
ones,
but
I
I
don't
think
you're
that
sketchy,
so
it
is
being
watched
by
the
dns
crowd.
We.
E
Count
on
you
being
sketchy
so
I'll,
just
plan
to
send
it
to
them.
Thanks
todd.
F
A
F
But
I
I
just
want
clarity
on
what
seth
was
proposing,
because
I
don't
I
didn't
hear
at
least
an
early
con
earlier
conversation.
Can
I
speak?
Yes,
sorry.
Thank
you.
I
didn't
hear
that
he
was
asking
to
change
from
five
to
six
to
seven.
I
heard
that
he
was
asking
to
not
do
a
jump.
Just
do
five
lookups
starting
with
the
leftmost
label,
and
you
know.
A
A
Okay,
I
I
think
at
this
point,
if
you
think
the
that
other
changes
are
needed,
that
you,
the
the
right
answer,
is
to
post
specific
text
that
you
want
to
see
changed
and
then
the
the
editors
will
consider
that
tim.
B
D
No,
I
wanted
to
just
thank
the
editors
for
the
added
example.
It
made
it
very
clear,
and
so
so
thank
you.
Yes,.
A
Okay.
Well
seeing
no
further
discussion
on
the
tree
walk.
I
think,
just
pending
the
resolving
whether
we
need
to
say
something
more
about
seth
the
issue
seth
raised,
we're
done
so
john.
Why
don't
you
and
seth
sort
out
offline,
seth's
question
and
then
we'll
go
from
there.
A
Or
next
week
would
be
fine
also,
but
you
know
whatever
john
will
be
home
tomorrow.
He
can
do
it
so,
whatever
it
is,
you
guys
will
sort
it
out
report
back
to
the
mailing
list
when
it's
done
and
now
the
issue
I
wanted
to
raise.
A
We
have
a
little
bit
in
section
8.5
that
mentions
the
the
breakage
we
get
in
mailing
lists
from
dmarc
p,
equals
reject
policies
and
the
reference
to
rfc
6377,
which
we
published
a
while
ago.
A
A
My
view
is
that
I
don't
feel
right
putting
this
out
as
proposed
standard
with
something
that
blatantly
breaks
long,
a
long
time
protocol
that
we've
used
on
the
internet
for
dealing
with
mailing
lists.
So
I
think
that
we
need
to
make
some
normative
statement
that
dmarc
p
equals
reject.
Policies
are
not
intended
to
be
used
on
domains
that
that
may
post
to
mailing
lists
and
stuff,
like
that,
the
intent
of
p
equals
reject
was
for
transactional
mail
sorts
of
things
not
for
arbitrary
people
sending
arbitrary
email
to
to
places
on
the
internet.
A
I
think
we
need
to
make
such
a
statement.
I
prefer
at
a
bcp,
14
keyword
level
using
a
should
not
so.
My
proposal
is
to
have
something
in
there
saying
that
you
should
not
use
p
equals
reject
under
these
kinds
of
circumstances
and
that
it's
intended
for
this
sort
of
use
and
we'd
have
to
sort
out
what
the
text
is
and
I'd
like
to
start.
A
discussion
on
that
murray
is
the
first
in
the
queue.
E
So
we
talked
about
this
a
little
bit
last
night
and
I'm
generally
supportive
of
using
bcb14
to
say
this
in
the
sense
that
I
would
also
be
willing
to
defend
it
to
the
isg
if
they
say
well,
this
is
you
know
if
they
resist
its
use,
so
I'm
supportive
of
that
since
we're
talking
about
6377
and
since
that
came
out
some
number
of
years
ago,
is
there
anything
in
it?
E
That
is
stale
that
we
should
consider
commenting
on
like
is:
is
that
still
enough
or
do
we
need
to
say
more
than
than
that
has
the
has
the
advice
of
6377
evolved
at
all?
I
just
wonder
if
it's
an
old
reference
that
we
should
update.
A
A
H
Pete
resnick,
I
guess
one
question
I
would
have
is
given
your
framing
that
this
particular
behavior
of
p
equals
reject
with
email,
with
the
caveat
that
the
email
is
not
transactional
will
cause
problems.
Why
is
it
not
just
a
must-not.
H
H
A
Well,
just
I
I
have
sympathy
for
that,
and
what
we
often
do
in
the
ietf
is
use
should
not
when
we
know
that
must
not
will
be
ignored
or
when
we
think
that
it
will
be
an
it
will
be
difficult
to
get
consensus
with
it
and
I've
always
sort
of
bristled
at
that
approach.
So
I
have
some
sympathy
for
what
pete
just
said.
Something
else
for
us
to
discuss.
Seth.
I
I
C
C
A
Okay,
seth,
you
are
going
to
jump
in
first.
H
So
this
pete
resnick,
first
of
all,
I
think
john
overstates,
the
case.
It
is
not
that
all
mailing
lists
solve
this
problem.
Most
now
have
hacked
around
it,
but
there
are
still
some.
I
still
get
bounces
and
I
think
it
is
fair
for
the
document
to
say
there
are
mailing
lists.
Many
mailing
lists
most
mailing
us.
I
don't
care
which
we
say
do
work
around
this
by
changing
the
from
field
in
ways
that
remove
the
original
information,
but
be
absolutely
clear
that
you're
removing
the
original
information.
It
is
a
hack.
H
It
is
unnecessary
if
people
implemented
it
correctly.
You
know
I
I
don't
object
to
more
explanation
as
to
why
it
says
must
or
should
not-
and
I
agree
with
you-
barry
should
not
when
there
is
absolutely
no
explanation
for
why
you
might
do
it.
The
other
way
reasonably
is
kind
of
just
you
know,
yeah,
but
put
in
as
much
explanation
of
the
state
of
affairs
as
you
like,
but
the
instruction
should
be.
Don't
do
that.
D
So
I
strongly
disagree
on
the
tell
people
not
to,
but
I
do
agree,
there's
a
very
real
problem
like
I
think
we
must
address
the
breakage
and
I
think
in
the
charter.
We
must
address
the
breakage
for
this
document
to
move,
and
so,
as
chair
there
there's
a
there
is
something
material
that
we
must
have
in
the
document
about
the
impact
of
dmarc
on
forward
and
mail
streams
with
good
guidance.
D
So
I'm
strongly
in
agreement
there
as
chair
as
an
individual,
I
think
what
we've
seen
as
an
ecosystem
mailing
lists
aside
for
a
second,
is
that
dmarc
is
valuable
in
an
enormous
number
of
players
and
the
mailboxes
all
say
we.
We
desperately
want
all
mail
to
come
with
a
dmarc
policy,
specifically
one
that
tells
us
how
to
handle
unauthenticated
mail,
and
so
I
think,
we're
doing
a
disservice
that
to
the
the
power
and
efficacy
of
the
standard
by
telling
people
not
to
use
it.
D
I
do
think
if
we
can
separate
like
if
we
could,
if
we
could
wave
a
magic
wand,
say
arc
is
well
deployed
and
the
the
forward
and
mail
case
is
used,
we
wouldn't
be,
is
managed.
We
wouldn't
be
having
this
conversation
and
my
question
is:
do
we
need
to
dig
into
that
with
ark
and
what's
needed
there,
two
materially
complete
this,
or
do
we
need
to
say,
hey
here's,
what
we've
done
it's
not
yet
ready
mailing
lists
could
rewrite
the
from.
D
D
It's
understand
what
you're
doing
and
both
the
benefit
of
having
dmarc
and
the
impact
on
forwarded
mail
streams,
but
I
I'm
very
against
as
an
individual
must
not-
or
I
should
not
here,
because
I
think
the
value
and
the
whole
point
of
the
protocol
is
to
protect
your
domain
from
spoofing.
K
Hi,
jim
benton,
I
strongly
agree
with
pete's
comment
to
I
forget
who
made
it
somebody's
earlier
comment
that
ietf
will
look
stupid,
telling
people
not
to
use
something
that
we
published
before.
I
think
much
the
opposite.
K
K
I
mean,
maybe
maybe
we
need
to
make
it
clearer
to
people
which,
which
rfcs
are
informational
and
which
ones
are
standard
track,
but
that
got
really
far
along
became
a
federal
government
mandate
to
publish
p
equals
reject
and
it
shouldn't
have
happened
so
ietf
coming
back
and
saying
what
you
did
before
was
not
the
right
thing
to
do.
I
think,
is
the
right
statement
to
make
so
just.
A
Before
you
sit
down,
I
I
believe
that
john's
statement
wasn't
along
the
line
of
you.
Shouldn't
have
implemented
the
early
version.
It's
more
that
he's
basically
saying
we
know
that
people
are
finding
value
in
demark
the
way
they're
implement
the
way
they've
deployed
it
and
they're
not
going
to
change.
So
we
would
look
stupid
telling
them
they
must
john.
Is
that
a
pretty
accurate?
So
it's
it's
more
that
that
we
we
would
be
saying
something
that
we
know
they're
not
going
to
pay
attention
to
and
that's
what
would
make
us
look
silly.
K
A
You
so
I'm
I'm
in
the
queue
next
and
perfect,
because
I
can
respond
to
seth
again
as
a
participant.
A
B
G
G
A
J
Brown
gondwana
here
definitely,
I
think
we
need
to
find
a
pathway
for
arc.
There's
at
the
moment,
there's
no
way
as
an
intermediate
to
know
whether
the
receiver
accepts
arc.
I
haven't
been
trying
to
bring
that
work
here
just
yet
or
find
someone
who
wants
to
do
that
work
because
we're
trying
to
get
this
stuff
done,
but
I
think
that
is
probably
the
next
thing
this
working
group
will
need
to
look
at.
J
D
C
C
I
mean
the
example
I'm
thinking
of
is
I
host
the
mail
from
my
town
government
and
I
have
a
small
enough
mail
server
that
I
actually
look
at
the
bounces
from
time
to
time-
and
I
saw
like
you
know
they
were:
they
were
getting
mail
from
the
u.s
census
in
2020,
which
was
really
important
for
them.
It
was,
it
was
p,
equals
reject
it.
It
only
used
spf,
it
did
not
have
dkim
signatures
and
I
forward
their
mail
to
gmail,
which
was
of
course
rejecting
it
all.
C
You
know,
so
I
I
think
rather
than
saying
don't
use
like,
rather
than
saying
basically,
rather
than
insulting
people,
rather
than
rather
than
implicitly
insulting
people
who
you
work
arounds
on
mailing
lists.
I
would
phrase
this
to
say
that
the
cost
of
using
dmarc
is
that
some
of
you,
some
of
your
legitimate
mail,
will
get
lost
and
perhaps
slightly
anonymize
the
mailing
list
example
in
the
example
I
just
gave.
You
know
and
say
so
be
aware.
You
know
be
be
aware
of
that.
C
If
you
decide,
if
you
decide
to
to
enforce
a
policy
and
in
some
cases
such
as
mailing
lists,
there
may
be
there,
there
may
be.
There
may
be
back
end
workarounds,
which
are
beyond
the
scope
of
our
discussion
yeah.
I
think
I
think
we
can
say
that
sound,
reasonable
and
you'd
be
basically
we.
We
can
say
that
without
denying
what
people
do,
while
still
making
it
clear
that
we
that
there
is
a
problem-
and
if
you
just
do
this
naively,
you
may
be
sorry.
A
C
H
Pete
bresnik
people
always
misunderstand
what
2119
words
mean.
We
have
voluntary
standards
in
this
organization
by
saying
must
not
again,
there
are
no
protocol
police,
no
one's
going
to
stop
anybody
from
doing
this,
much
less,
stop
them
from
dorking,
with
their
re-transmission
timers
in
tcp,
which
they
continue
to
do.
H
The
reason
you
say
must
not
is
because
you're
saying
this
will
cause
damage
if
some
people
interpret
that
as
a
conformance
requirement,
not
our
problem
and-
and
god
bless
them
if
it
does
right
if
they
interpret
it
as
oh,
the
ietf
said.
I
can't
do
that.
Therefore,
I
must
stop
well
they're
silly,
but
good.
Let
them
feel
that
way.
H
The
reason
we
say
these
things
and
standards
is
to
explain
when
you
should
can
may
must
do
certain
things
to
protect
the
network,
and
what
our
must
means
in
this
organization
is,
if
you
don't
do,
this
damage
will
occur,
must
not
means.
If
you
do,
this
damage
will
occur.
Let's
be
clear
about
that.
I
mean
even
what
seth
pointed
out,
which
is.
We
should
say
that
you
know
there
are
reasons
you
might
choose
to
do.
H
Otherwise,
that
is
by
definition
what
2119
says
is
should
not
so
if,
if
we
agree
with
what
seth
said,
then
we
should
use
should
not
in
the
document
I
happen
to
think
we
can
be
stronger,
but
let's
not
try
and
not
use
the
tools
that
we
have
in
this
organization,
because
some
people
might
misunderstand
them
and
then
therefore
think
we're
silly.
I
think
that's
not
a
good
reason
to
do
that.
J
B
L
In
the
room
to
make,
because
every
one
of
the
speakers
had
something
amazing
to
say
speaking
just
to
pete-
I
I
you
know-
I
agree
with
that.
I
I
think
that
setting
the
context
at
the
top
of
the
document
and
saying
look,
this
is
the
context.
L
Then
the
shoulds,
the
musts
and
maze
all
fall
into
place
right,
which
means
that
if
you
want
to
employ
this-
and
you
want
to
use
the
protections
it
provides
saying
saying,
must
is
within
that
context
right.
So
that's
my
number
two
is.
I
really
do
think
that
it's
important
that
you
know
in
you
know
encounter
to
say
the
dhs
case.
I
think
it's
important
that
we
do
say
you
know
you
should
do
this.
You
must
do
this
in
order
to
take
advantage
of
the
protections
that
this
specification
provides.
L
If
you
don't
want
the
full
protections
again
back
to
what
pe
was
saying
right,
you
can,
you
can
make
a
local
policy
that
lessens
that
more
power
to
you,
but
at
the
end
of
the
day,
if
you
want
the
protections
that
this
provides,
you
say
that
and
then
something
else
someone
brought
up
earlier
about
arc.
Yeah,
we
have
a
lot
of
arc
data
that
basically
points
out
that
there
are
some
use
cases
where
it's
incredibly
useful.
There's
other
use
cases
where
it's
less
useful.
L
We've
seen
no
use
cases
where
it's
harmful,
so
you
know-
and
I
often
decide
we
have
these
conversations
about
how
to
employ
arc
as
an
identifier
in
order
to
hang
these
things
off
of.
I
don't
think
it
belongs
in
this
document,
but
I'm
happy
to
have
folks
ping
me
and
we
can.
We
can
work
on
that.
So
my
time
at
the
mic.
A
Thanks
trent,
and
I
will
say
that
you
I
feel
like
you
are
in
the
room
with
us.
So
all
working
victor.
I
Victory
a
disclaimer
I
neither
publish
nor
consume
dmarc,
so
you
can
discount
whatever
I
say
based
on
that,
I
do
support
the
the
must.
Not.
I
think
it's
a
good
idea.
I
also
hope
the
document
contains
somewhere
a
text
that
makes
makes
it
clear
to
people
that
just
publishing
p
equals
reject,
isn't
a
silver
bullet
to
protect
them
from
all
impersonation
attacks.
I
You
know
just
the
other
day.
You
know
my
mother-in-law
was
reading
an
email
and
the
display
name
said
something
about
apple.
You
know,
that's
an
email
from
apple,
so
you
know
the
the
protection
you
get
from
p
equals
reject,
is
rather
limited
in
scope,
and
so
because
of
that,
if
one
has
low
value
from
it
and
expects
too
much
from
it
when
it's
mostly
doing
a
disservice
doing
so,.
A
Nevertheless,
what
elizabeth
told
me
one
time
was
that
it
wasn't
her
decision
and
she
wasn't
happy
with
it,
but
in
looking
at
the
results
she
would
make
the
same
decision
if
she
had
to
make
it
because
it's
just
been
wonderful
for
them
and
they're
all
aware
that
that
people
are
still
getting
fooled
by
look-alike
domains
and
and
and
pretty
names
and
whatever
else
they're
aware
of
it.
But
I
mean
I
guess
you.
One
of
your
points
is
write
that
in
the
document,
so
it's.
K
Jim
fenton
again
so
some
of
you
that
are
more
operationally
tied
in
than
my
tiny
domain,
probably
have
more
know
more
about
this,
but
I
mean
we've
been
talking
as
though
the
breakage
problem
is
limited
to
mailing
lists.
K
That's
my
point:
is
it
isn't
entirely?
There
are
other
situations.
I
think
there
are
instances
of
recipient
side
forwarding
alumni
domains,
things
of
that
sort
where
you
run
into
a
problem
as
well.
Those
are
not
something
that
the
originating
domain
is
necessarily
even
aware
of,
and
so
we
need
to
consider
that
you
know
telling
telling
the
originating
domain
don't
publish
p
equals
reject
if
you're
sending
the
mailing
lists.
Well,
that
isn't
enough.
A
Yeah
I'll
get
an
anecdote.
The
university
of
florida
shut
down
their
alumni
domain
because
they
were
having
too
much
trouble
with
dmarc,
but
that's
not
something
anyone
any
sender
can
control
they.
You,
you
give
them
an
alumni
address
to
use,
they
use
it
and
it
doesn't
get
to
you
because
of
dmarc.
They
have
no
control
over
that
the
one
where
they
are
using
it
on
a
domain
where
their
users
are
regularly
posting
to
email
lists
that
they
have
control
of,
and
so
that
that
was
my
angle
on
it
anyway.
A
D
Not
to
touch
on
the
the
other
points
and
like
the
back
and
forth
in
the
chat,
but
I
I
think
what
I'm
hearing
is
for
mailing
list
interoperability.
What
we
have
in
the
document
is
not
enough
and
we
do
have
to
work
out
something
in
the
list
and
the
form
it
takes
is
up
for
discussion,
but
that
we
must
address
this
in.
The
document
is
not
for
discussion
we
have
to,
and
it's
not
sufficient
in
its
current
state.
A
Yes,
that's
what
I
get
also
I'm
seeing
a
lot
of
support
for
should
not
or
must
not,
but
we
haven't
completely
addressed
your
concern
about
that.
Yet
so
so
yes,
there's
plenty
of
discussion
to
be
had
anything
else.
A
All
right
next
topic,
todd
I'll
I'll
leave
it
to
you
here.
Are
there
other
issues
you
would
like
to
discuss
and
I'll
just
while
he's
getting
up
say
that
todd
just
moved
over
some
issues
that
we
we
just
shifted
from
the
older
data
tracker
tracking
to
get
github
tracking,
so
todd
got
to
move
a
few
issues
over
from
the
old
system
and
go
ahead.
F
F
I
believe
scott
answered
my
question
about
how
the
text
should
be
rearranged,
so
we'll
have
to
do
you
know
the
next.
The
next
raffle
deal
with
that
it
sounds
like
we
still
have
some
tweaks
to
make
to
the
tree.
Walk!
Yes,
john!
Is
that
what
we
came
out
of
the
other
discussion
or
no?
Were
we
done
with
the
tree
walks.
J
A
I
Since
tree
yuak
was
mentioned,
and
I
just
read
it-
I
have
a
question
more
and
more.
It
seems
that
it
goes
all
the
way
up
to
you
know,
dot
com,
which
seems
rather
silly
in
some
ways.
I
imagine
that's
being
discussed
at
length.
I'm
curious.
A
A
B
Tim
was
timothy
talking
about
being
complete.
What
I
wanted
to
point
out
was
there's
two
parts
in
the
security
considerations.
Section
10.3
and
10.4
10.3
is
on
dns
security
that
I
hope
the
dns
people,
like
victor
and
wes
and
folks
here
we'll
take
a
look
at
and
what
john
wrote
looked.
Good
and
10.4
is
display,
name
attacks,
victor,
so
10.4
10.4
actually
talks
about
display,
name
attacks,
which
is
something
you
had
just
mentioned.
So
you
may
want
to
look
at
that
text
and
see
if
you
can
actually
add
some
suggestions
to
that.
A
A
D
A
Okay,
al
alex
will
take
his
issue
to
the
mailing
list.
A
M
Alex
brockman
comcast
editor
for
the
aggregate
document,
so
I've
been
kind
of
holding
off
waiting
to
see
some
of
the
changes
through
tree
walk
and
some
of
that
to
see
how
that
might
impact
the
aggregate
document.
That's
what
I
expected.
A
M
And
so
I
I
was
talking
with
todd
a
little
bit.
I
don't
think
there's
anything
that
is
truly
monumental.
That
needs
to
be
changed,
but
I'm
certainly
there
are
still
some
open
tickets
that
need
to
be
gone
through
that
so
it
needs
to
be.
I
probably
discussed
a
little
bit,
but
I
don't
know
that
any
of
them
are
extremely
critical
either.
M
So
if
anybody
has
anything
else
that
there
that
they
disagree
with
I'm
happy
to
I'm
here,
you
can
smack
me
around
the
side
of
the
head
and
that's
fine,
but
that's
the
only
one
that
I
really
know
about
so.
A
G
M
Okay,
alex,
I
know
what
he's
talking
about.
I
haven't
gone
back
and
done
that
I
don't
know
how
much
interest
there
is
in
having
that
done.
He
there's
the
request
is
to
have
it
so
that
it
is.
I
think
that
the
document
basically
auto
verifies
itself
is
that
correct.
M
H
M
John
was
asking
about
an
rnc
rng.
I
think
the
one's
compact
one's
not
so
those
I,
but
I
don't
think
that's
what
ale
is
asking
about.
I
think
he's
there
was
something
else
and
there
was
a
there
was
a
google
document
out
there
somewhere
that
was
created
by
I
think
matt,
and
I
don't
matthias
and
I
don't.
I
have
to
go,
find
it
again
if
you
or
if
you
want
to
send
to
me,
I
will
take
another
look
at
it.
It
might
be
even
being
a
ticket.
J
G
Perhaps
I
would
propose
to
to
only
put
the
headers
of
of
the
original
message
in
the
mail,
because
currently
you
can
do
both
and
actually
nobody
does
it.
As
far
as
I
saw,
but
there
are
privacy
issues,
and
so
it
is
seldom
used
is
not.
G
M
Todd-
and
I
were
talking
earlier
this
week
about
maybe
like
a
header,
header-only
version
of
reports
or
so
that
you
don't
include
the
content
even
more
so
you
could
potentially
just
include
perhaps
the
message
id
so
that
they're,
you
know
because
there's
still
pii
inside
of
the
message,
headers
there's
still
the
email
address
or
there
could
be
something
in
the
subject,
those
sorts
of
things.
M
So,
if
you
were
to
include
just
the
message
d,
which
I
realized
could
be
duplicated,
that
there's
no
requirement
that
it'd
be
unique,
but
at
least
it
would
give
you
something
to
potentially
go
on
to
go
back
to
the
source,
ip
and
say:
hey.
Do
you
know
what
these
were?
A
It's
up
pete.
Do
you
remember
offhand
what
message
id?
What
guarantees
there
are
on
message,
id
being
unique,
pete,
chuckles
and
while
he's
coming
up
to
the
mic
seth,
what
do
you
have
to
say.
D
Two
things:
one:
there
was
an
original
ticket
for
stripped
down
failure,
reports
which
is
basically
limiting
it
to
header
information,
and
it
might
be
worthwhile
to
dust
that
off,
but
two,
I
think,
there's
an
rfc
6973
impact
due
to
privacy
on
failure,
reports
that
we
need
to
discuss,
and
so
I
will
that's
clearly
we're
not
going
to
have
that
discussion
in
10
minutes.
It's
probably
a
list
discussion,
but
I
feel
like
we.
D
I
feel
like
that's
a
critical
one
and
frankly,
the
operational
impact
of
almost
no
one
or
no
no
major
mailbox
sends
failure.
Reports,
some
open
source
software
does-
and
I
believe,
10
cent
out
of
china
sends
them,
but
but
no
other,
there's
no
other
source
of
them
in
the
wild
and
so
from
an
operational
perspective
and
a
6973
perspective.
I
think
there's
a
a
real
conversation
to
be
had.
H
So
this
is
pete
resnick.
The
short
answer
is
53
22
says,
must
be
globally
unique
and
and
here's
something
that's
what
I
thought:
here's
some
ways
you
might
try
and
make
that
happen,
but
guarantee
it
does
not.
Nothing
is
guaranteed
right
because
it
says
you
might
want
to
use.
You
know,
append
a
dome.
You
know,
use
a
domain
name
on
the
right
hand,
side
that
you
have
control
over,
so
you
can
make
sure.
What's
on
the
left-hand
side,
is
globally
unique.
J
L
A
Intended
it
is
intended
to
be
best
effort,
unique
yeah,
so
I
I
think
we
can
generally
rely
on
them
being
unique
for
the
purposes
oh
yeah
yeah
alex
says
his
point.
Is
the
spammers
don't
care
they'll,
reuse,
whatever
they
feel
like
and
absolutely
of
course,
so
all
right.
Anyone
else
is
there
anything
else.
We
need
to
talk
about
related
to
dmarc.
Victor,
don't
bother
putting
yourself
in
the
queue.
I
Thanks
just
one
quick
note
about
tree
walking-
and
I
dna,
if
I
remember
correctly-
idna
introduces
at
least
two
maybe
three
additional
label
separating
period
characters
so
that
when
you're
parsing
a
domain
name,
they
can
be
separated
by
period
or
idiographic,
full
stops
or
a
couple
of
other
weird.
A
A
Let
me
just
no,
you
can
stay
up
at
the
mic.
I'm
just
repeating
john's
answer
is
that
he
thinks
that
what
victor
was
just
talking
about
is
in
2003.
I
dna
not
2008.
C
This
is
a
hopeless
pit.
This,
the
idn
punctuation,
is
a
pit
of
hopeless
despair
that
I
don't
think
we
should.
I
don't.
I
don't
think
we
should
get
into.
I
think
anybody
who
anybody
who
knows
how
to
turn
you
labels
into
a
labels
will
have
will
have
their
own
opinions
about
what
dots
to
look
for,
and
I
don't
think
we
need
to
talk
about
it.
A
A
A
Okay,
any
anything
further
will
be
taken
to
the
list
on
that
point,
so
seeing
nothing
else,
I
think
we
have
now
five
minutes
back
to
our
afternoon.
A
Thank
you,
everybody
for
coming,
and
especially
thanks
to
the
people
who
came
remotely
and
if
you're
in
europe,
thanks
for
coming
late
in
the
evening.
D
Thank
you.
Everyone.
Thank
you
again
for
the
to
the
editors
for
pulling
everything
together
and
making
such
rapid
changes.