►
From YouTube: IETF99-DMARC-20170720-0930
Description
DMARC meeting session at IETF99
2017/07/20 0930
https://datatracker.ietf.org/meeting/99/proceedings/
C
B
B
We're
in
Prague
but
we're
in
Brussels.
Yes,
so
yes,
I
encourage
those
of
you
who
are
sitting
in
Berlin
to
come
to
Brussels
and
let's
get
started
with
Demark.
We
have
an
hour
I
believe
and
then
D
Krupp
comes
in
ten
minutes
later
and
you're
all
encouraged
to
stay.
For
that
we
have
a
new
note
well,
and
this
is
actually
it
referring
to
the
new
RFC
81-79,
which
has
some
changes
over
the
old
ones.
B
B
If
you
are
posting
from
an
address
that
has
a
reject
policy
and
your
posts
cause
unsubscribes
for
other
people
on
the
mailing
list,
I
am
going
to
ask
you
to
post
from
a
different
address
and
if
you
don't
I,
am
going
to
block
your
address
from
posting.
I
will
repeat
that
on
the
mailing
list,
but
that
is
the
policy
for
now.
You
are
disrupting
the
mailing
lists
operation
and
that
will
no
longer
be
tolerated.
B
Maybe
there's
nothing
to
say
about
this,
but
I
would
like
to
kick
off
a
little
discussion
about
that,
and
then
we
talk
about
what
we
do
next
after
the
arc
document,
which
is
the
Demark
usage
document
and
Tim
I
believe,
is
on
remotely
and
and
he
will
lead
that
and
then
I
imagine
we're
going
to
be
out
of
time.
But
if
not
we'll
see,
if
there's
anything
else
to
talk
about,
does
anyone
have
anything
they
want
to
add
to
strike
from
or
change
on
the
agenda?
B
A
A
We
got
a
new
forwarder
thanks
to
Andreas
in
place
and
the
fast
mail
guys
made
some
good
progress
on
their
mail
authentication,
Milt
er
in
Pearl,
and
we
look
forward
to
having
that
committed
soon,
so
that
people
can
download
the
latest
and
greatest
on
that
and
make
use
of
it.
I
also
had
a
conversation
with
John
Levine,
which
I
do
I,
don't
see.
Oh
there,
you
are
that
I
think
you're
working
on
some
sort
of
an
implementation
as
well
right
in
Perot,
so
we're
gonna
have
a
couple.
A
B
B
Don't
all
need
to
be
there
for
it.
We
can
do
hackathon
participation
remotely
sure.
So,
for
those
of
you
who
are
not
aware,
the
IETF
hackathon
is
held
the
Saturday
and
Sunday
before
the
IETF
meeting
and
is
a
way
to
get
some
coding
done
related
to
IETF
projects,
IETF
working
group
projects-
and
this
was
the
first
time
that
the
d
mark
people
participated
in
yeah.
We
can
certainly
sign.
A
B
A
A
So
Steve
and
Seth
and
I
met
with
henrik
and
robert
on
tuesday.
They
were
very
happy
to
hear
about
the
progress
with
ARC
and
the
fact
that
we
had
some
implementations
that
would
actually
work
for
mailman
too,
which
is
what
is
currently
being
run
for
the
lists
and
they
were
looking
for
two
specific
things.
A
But
possibly
sometime
in
September,
we
might
get
that
turned
on
for
the
IETF
lists,
and
then
we've
also
been
working
with
the
Magh
Mela
mailman
administrator
to
get
the
MA
glass,
which
also
run
on
mailman
to
ark,
enabled
and
I.
Think
that
will
probably
be
a
little
bit
sooner.
For
that
is
that
yeah,
okay
in
sometime
in
the
next
couple
of
weeks,
we'll
get
the
MOG
lists.
So
there'll
be
a
first
pass
production
run
and
then
we'll
follow
up
with
openSUSE
package
and
get
it
on
the
IETF
lists.
But.
B
D
D
A
B
E
C
B
A
First
off
I'll
run
through
a
couple
of
settled
issues
that
we've
sorted
through
in
list
discussion
this
week
and
will
be
reflected
in
the
next
release
of
the
spec
first,
one
is
whether
or
not
it's
mandatory
to
sign
the
archive
in
occation
results
within
the
ark
message
signature,
and
we
have
decided
no
and
I've
not
seen
any
objections
to
that
on
the
list.
So
I'll
consider
that
settled.
The
second
one
is
collapsing
CV
invalid
into
CV
fail
that
was
done
a
little
while
ago,
so
that
we
will
only
have
fun.
Oh.
F
F
A
Me
do
the
for
settled
issues
first
and
then
we'll
take
comments
on.
Oh,
please,
so
the
collapsing
CV
invalid
into
fail,
so
that
we
only
have
a
nun
fail
and
past
was
done
a
couple
of
weeks
ago
before
the
deadline
on
submitting
changes.
The
last
two
are
the
arc
or
the
authorization
results.
Authentication
results
are
equals
policy
being
added
to
the
pass/fail
methods
and
then
the
question
of
how
to
deal
with
multiple.
A
Our
author
authentication
results
headers
when
you're
doing
an
arc
sealing
I
think
that
we've
talked
it
through
and
everybody
agrees
how
to
do
it,
and
it
was
just
a
matter
of
getting
wording
put
in
to
consolidate
them
all
into
one
and
and
stick
them
into
the
arc.
Authentication
results
header.
So
questions
and
feedback.
F
Although
I'm
sitting
up
front
pretending,
this
is
the
morph
working
group,
we
I'm
just
a
participant
here
so
about
the
not
signing
of
aar
which
I
support,
but
it
just
occurs
to
me
that
we're
going
to
have
an
installed
base,
some
of
which
does
sign
and
expect
that
to
be
there
and
some
that
does
not
are
we
concerned
about
a
period
of
interoperability?
Is
you
know,
because
it's
optional
so.
A
F
A
C
F
A
A
A
Ultimately,
if
the
temporary
failure
is
of
long
enough
duration,
that
the
message
is
undeliverable
because
you'll
never
accept
it,
then
it'll
go
back
to
the
sender
and
they'll
know
that
their
DNS
is
broken
and
that's
I.
Don't
think
that
there's
a
value
in
putting
a
an
arc
result
in
that
says:
hey
I
couldn't
figure
this
out,
because
the
DNS
wasn't
cooperating
because,
frankly,
if
you're
passing
a
message
through,
let's
take
a
mailman
scenario,
it
will
within
milliseconds,
if
not
seconds,
pass
through
your
entire
infrastructure
and
be
out
the
back
door.
A
B
A
Another
area
in
open
area
in
the
spec
is
cleaning
up.
Some
of
the
language
I
am
currently
working
on
melding.
The
working
draft
with
Murray's
proffered
rephrasing
of
significant
sections
of
it,
and
so
after
the
meeting
I
will
be
submitting
that
as
the
next
version
of
the
draft,
because
Murray's
version
was
quite
a
bit
more
succinct
and
many
areas
and
I
hope
that
it
will
be
meaningful
to
people
if
people
really
hate
it
and
prefer
mine,
then
we'll
roll
it
back.
A
It's
the
lovely
thing
of
get,
and
there
are
some
challenges
as
I've
been
trying
to
come
up
with
the
wording
on
how
we
deal
with
algorithm
evolution
so
dealing
with
the
concept
of
a
chain
that
spans
multiple
mediators
and
some
of
them
want
to
sign
with
RSA
sha-256
of
whatever
key
length,
and
some
of
them
want
to
sign
with
an
elliptic
curve
which
isn't
approved
yet.
But
we're
going
to
talk
about
that
in
the
next
hour
ish.
A
F
C
F
A
A
The
initial
language
in
the
spec
wasn't
clear
on
the
fact
that
you
have
to
evaluate
chained
validity
status
when
it
comes
in,
would
then
put
that
on
the
result
when
it
goes
out.
Many
initial
implementations
we're
putting
a
change
status
when
it
was
received
and
separately
computing,
a
change
status
when
it
went
out
and
they're
basically
saying.
Oh,
it
was
good
when
I
came
in
and
now
it's
busted
you
deal
with
it
and
that's
not
the
right
model.
So.
A
A
A
Think
the
hallway
discussions
kind
of
converged
on
that's,
not
a
spec
issue,
and
so
we're
gonna
have
to
help
people
bootstrap
outside
of
the
spec,
which
is
good,
and
then
we've
got
an
open
question
around
the
AAR
content
and
format
which
we'll
cover
kind
of
on
my
next
set
of
areas
with
the
enhanced
reporting
and
then
the
last
one.
Is
the
standards
track
versus
experimental
question
which
I
left
for
the
end?
Any
questions
before
we
get
into
the
standards
versus
experimental.
B
A
A
B
A
B
Last
issues
resolved
modulo
the
discussion
we're
about
to
have
yes,
okay,
good.
Let's
ask
everybody
to
be
aggressive
about
responding
and
getting
this
sorted
out,
so
we
can
make
that
schedule
Dave.
Would
you
like
to
state
your
argument
for
using
for
making
this
experimental,
where
we've
got
the
red
button
waiting
for
you
there?
He
is
here's
Dave
go
ahead
and
mash
the
button.
He
is
a
blue
ghost
Dave
you're
on.
G
This
is
a
feeling
that
the
role
of
Ark
involves
dynamics
and
practices
that
need
some
experience,
and
since
this
involves
infrastructure
service
on
the
average,
when
one
isn't
completely
clear
what
the
dynamics
will
be
with
an
infrastructure
change,
one
wants
to
proceed
cautiously,
and
so
my
suggestion
for
how
to
proceed
cautiously
is
to
initially
issue
this
as
experimental,
and
when
the
industry
feels
that
there
is
enough
experience
to
write
a
substantive
BCP
on
how
arc
should
be
used
not
based
on
theory
but
based
on
practice.
Then
the
spec
would
be
ready
for
four
standards
track.
A
And
my
concern
in
response
to
that
is
looking
at
the
official
idea
of
descriptions
of
what
it
means
to
be
experimental
is
that
I'm
concerned
them
I
scare
people
off
from
well,
it's
not
worth
us
implementing,
because
after
all,
it's
just
an
experiment
and
I
think
that
we've
put
enough
work
into
it
and
we
do
have
enough
implementations
already
in
practice
at
Google
and
AOL
as
the
primary
largest
ones
right
now
that
it's
worth
moving
on
the
standards
track
with
it.
So.
B
And
as
as
chair,
I'll,
throw
in
some
process
things
that,
first
of
all
we're
afraid,
people
won't
implement
it
if
it's
experimental
is
not
a
reason
not
to
make
it
experimental
if
experimental
is
the
right
status,
but
the
other
side
of
it
is
that
it's
not
black
and
white
that
it
is
a
judgment
issue.
If
we
think
that
this
is
ready
for
us
to
propose
a
standard
realizing
that
it
may
be
changed
later,
then,
standards
track
may
be
the
right
thing,
but
Dave's
point
about
experience.
A
B
C
B
The
the
issue
is,
one
thing
we
could
consider
is
whether
putting
out
the
RFC
as
soon
as
possible
and
making
it
experimental
and
then
revising
it
in
six
or
eight
months
to
be
standards
track
is
appropriate
or
whether
saying
we're
gonna
make
it
a
stable
draft
and
leave
it
in
draft
state
for
a
while
to
get
that
feedback
and
then
go
to
publication
requested
a
standards
track.
That's
another
possibility.
C
B
H
I
A
We
do
we
have
some
initial
reports
that
there
are
some
smaller
operators
that
have
implemented
arc.
I,
don't
know
how
many
and
we
did
have
a
training
session
that
was
done
in
Lisbon
last
month.
It's
a
mall,
meeting
and
I
think
the
gentleman
behind
you
in
line
may
be
able
to
comment
further.
So
if
you
guys
want
to
do
a
trade
thing
and
then
I'm
sorry
catch
your
name,
can
you
please
really
arts.
J
Seth
blank
from
Velma,
so
we
did
an
arc
training
at
MOG
and
basically
to
bootstrap
the
issue,
there's
basically
a
list
that
a
bunch
of
the
major
receivers
and
some
other
report.
Processors
put
together
of
the
intermediaries
that
break
mailing
lists
and
it's
a
pretty
well-known
group
of
about
2,000
intermediaries
and
that
this
basically
never
changes,
and
so
we're
really
comfortable
publishing
that
list
publicly
making
it
available
for
use.
It's
a
short-term
fix
to
bootstrap
the
specific
problem.
J
There
needs
to
be
a
better
solution,
long
term,
but
because
of
that,
I
actually
think
that
Dave
has
convinced
me
that
experimental
makes
sense,
because
this
is
where
we're
gonna
have
problems.
I
think
we'll
know
pretty
quickly
and
pretty
quickly
within
your
three
to
six
months,
where
the
issues
come
from.
If
this
works,
if
we're
having
reputation,
it's
used
with
small
receivers
and
I
think
this
is
an
experiment
that
we
need
to
define,
but
we
can
move
to
standards
track
within
a
few
ifs.
If
we.
A
A
B
The
the
decision
point
there
is
what
we
think
will
be
best
for
implementations.
Will
they
get
the
implementations
we
need
if
we
leave
it
as
a
draft
and
announced
to
the
world
that
it's
a
stable
draft
that
isn't
going
to
change,
but
we're
just
waiting
for
feedback?
If
we
think
that
will
get
us
enough
implementations
to
do
the
experiment,
then
we're
fine
if
we
think
it
needs
to
be
an
RFC,
even
if
that's
experimental
in
order
to
get
the
implementations,
then
we
should
go
the
other
way.
Yeah.
A
B
J
B
As
an
example,
the
HTTP
to
development
was
done,
the
other
way
where
they
had
cuts
where
they
said.
This
is
an
implementation
draft
and
everybody
implemented
it,
but
the
difference
is
that
all
the
major
players
were
in
the
room
there
and
we're
all
implementing
it
at
that
time.
We
don't
have
that
situation
here.
J
A
K
Chris
Newman
I
reviewed,
you
know
so
I've
read
the
draft
and
started
work
on
implementing
it,
and
you
know
the
art
protocol
draft.
You
know,
I,
don't
see
anything
that
I
suspect
is
wrong
with
the
technical
part
of
the
art
protocol
draft.
Now
you
know
the
reputation
model,
that's
where
we
have
uncertainty,
but
that's
not
gonna
be
standard
track
anyway,
in
the
first
round
of
publication.
So
let's
just
publish
it
standards
track
because
you
know
at
this
point
we
you
know
generally
I,
think
it's
experimental.
B
B
F
This
is
Marie
and
repeating
something
Jim
said
in
driver.
We
both
are
agreeing.
On
the
other
hand,
in
contrast
to
what
Honduras
said,
there
are
a
lot
of
people
who
think
that
any
RFC
with
any
status
is
basically
a
standard.
There
was
a
story,
posted
set,
posted
it
and
then
a
Facebook
page
this
morning
that
someone
referred
to
Demark
as
a
standard,
even
though
it
is
purely
informational
and
in
fact
has
no
IETF
consensus
right.
So
that's
right,
yeah
and
then
well.
A
F
G
Add
to
that
then
the
the
fact
that
the
role
of
this
mechanism
in
the
trust
for
handling
email
is
unique.
We
we
do
not
have
any
operational
experience
with
this,
and,
as
we
get
that
experience
we
it's
possible,
we
will
find
that
the
spec
needs
changing.
The
signatures
might
be
more
fragile
than
we
want
in
deployed
networks.
G
There
may
be
some
other
problems
that
make
this
work
less
well
than
we'd
like,
and
the
fact
of
history
with
transitive
trusts
is
not
promising,
doesn't
mean
it
won't
work
now,
but
it
means
that
we
ought
to
be
cautious
about
it.
The
fact
that
there
are
people
out
there
who
don't
understand
what
a
standard
an
IETF
standard
is
or
the
difference
between
standard
and
RFC
has
been
touted
as
a
problem
for
the
entire
history
of
the
ITF.
The
reality
is,
the
ITF
has
some
rules
for
how
it
does
labels.
G
G
F
J
J
J
Hi
Dave
we
get
on
there
finish.
Thank
you.
So
as
I
was
saying
this,
we
have
lots
of
little
shiny
that
in
real
time,
I'm
not
quite
sure,
I
sequential
signing
it's
different,
I
started
Peterson
hearing.
Why
so
I
mean
like
you
know?
You
could
certainly
say,
for
instance,
that
we
don't
know
that
when
we're
rolling
on
up
we're
rolling
on
a
protocol,
you
know
we
don't
have
protocol
with
this
exact
sequence
of
bits
before,
and
so
we
have
no
experience
with
that.
J
G
E
J
G
It
wasn't
much
of
a
question
adjust,
so
the
view
that
networking
dynamics
is
trivial
because
we've
done
one
kind
of
thing
and
we're
now
doing
something
that
is
a
different
dynamic
and-
and
forgive
me
if
I
think
that
signing
something
doing
a
series
of
signatures
that
depend
on
each
other
is
a
fundamentally
different
dynamic
than
doing
a
single
signature.
I
can't
comprehend
seeing
that
as
anything
other
than
different
and
so
I,
don't
know
how
to
explain
to
you.
I
mean
my
in
point
of
fact.
This
is
like
trying
to
prove
a
negative
I.
G
L
A
B
C
From
gondwana
fast
now
so,
I
actually
asked
a
question
earlier,
which
goes
directly
to
this
point.
What
happens
if
you
can't
do
a
DNS
lookup
halfway
along
the
chain,
if
you're
rejecting
it
from
the
first
sender,
find
you
400
it
until
it
fails
if
you're
rejecting
a
halfway
down
the
chain
who's
it
bouncing
back
to
that.
That
is
a
question
that
we
do
have
to
think
about.
Well,.
A
If,
if
we're
looking
at
a
mediator
being
a
mailing
list,
then
presumably
it
would
be
sitting
in
the
outbound
queue
of
the
mailing
list.
Processor.
If
you're
looking
at
somebody
doing
a
more
of
a
dot
forward
type
forwarding
again,
it
would
be
sitting
in
their
queue.
Where
does
it
bounce
back
to
well
probably
postmaster,
frankly,
in
most
implementations
to.
C
Come
out
from
the
mailing
lists,
then
it's
going
to
cause
a
bounce
failure
and
going
to
cause
that
person
the
receiver
to
be
removed
from
the
mailing
list,
when
the
actual
faults
is
the
DNS
records
of
the
sender,
which
brings
us
right
back
to
the
issue
that
we
currently
have
with
the
Demark
list.
That
people
who
are
sending
from
incorrectly
or
strictly
configured
domains
are
causing
other
people
to
be
removed
from
the
list,
and
that
would
actually
be
the
same.
Failure
mode.
Interesting.
G
Sort
of
curse
to
me,
we
do
curse
to
me.
We
have
one
operational
example
of
problems
with
signing,
and
that
is
that
dkm
is
designed
in
a
way
which
should
work
just
fine
from
client
to
client
from
the
author
to
the
recipient,
but
operationally
the
experience
is
it:
doesn't
it
works
from
the
originator
to
the
receiver
and
generally
doesn't
survive
within
the
enterprise?
A
A
B
K
B
B
D
D
B
F
A
B
G
I
just
wanted
to
add
in
response
to
the
the
criteria
for
going
the
standards
track.
What
what
I
proposed
and
I'm
continuing
to
think
makes
sense
is,
when
there's
comfort,
to
write
a
usage
document
that
says
this
is
how
you
use
arc
in
operational
service,
and
it
describes
not
just
the
implementation
of
the
the
mechanism,
but
the
integration
of
the
mechanism
into
email
operations.
When
there's
comfort
with
writing
a
version
of
that
that
has
substance,
then
the
spec
will
be
stable.
B
A
A
Essentially,
ultimately,
it
goes
back
to
the
operator,
but
it
is,
it
is
mechanically
mediated,
and
so,
as
such,
there
are
a
couple
of
data
points
that
are
desired
for
the
initial
sender
in
order
to
be
able
to
troubleshoot
problems
in
they're
sending
infrastructure.
Those
are
specifically
the
IP
that
it
came
out
of,
and
the
selector
that
was
employed
in
initiating
the
chain
and
I
think
that
actually
carries
through
the
entire
arc
sequence.
So
every
mediator
can
have
the
same
sort
of
a
problem
that
occurs
and
therefore
adding
those
two
pieces
of
information.
A
We
would
propose
to
add
that
in
there
is
an
open
question
about
how
that
gets
formatted
into
we
don't
necessarily
want
to
put
it
into
the
70601
authentication
results.
Header,
because
again,
that's
designed
for
an
individual
person
to
consume
as
a
client
receiver
of
the
message,
but
how
we
carry
it
through
and
get
it
into
the
AAR
and
how
that's
formatted
is
open
to
question
Marie.
We're
not
quite
sure
if
you
were
joking
when
you
suggested
putting
it
in
inline
JSON,
but
a
few
people
have
said:
hey,
that's
a
really
good
idea.
A
It
because
the
comment
could
be
formatted
as
inline
JSON.
Why
not,
anyway?
Okay,
so
we're
gonna
have
to
have
some
honest,
we'll
take
it
to
the
list
as
far
as
how
we
get
these
things
incorporated
into
the
AAR.
The
other
questions
are
when
and
where
to
report
with
ARC.
Every
step
ought
to
be
reporting
back
to
the
sender.
That's
going
to
result
in
multiple
reports
for
a
single
message,
but
that's
up
to
the
report,
consumer
systems
to
consume
and
consolidate,
and
that
probably
isn't
going
to
be
a
problem.
A
Although
we're
having
some
some
people
having
whiplash
here
at
the
front
desk
and
I,
think
that
was
the
the
crux
of
the
question
around
enhanced
reporting.
So
format
is
really
the
open
question
and
then
how?
If
at
all,
do
we
change
the
format
and
structure
of
the
Demark
report
in
order
to
accommodate
arc
and
and
potentially
other
extensions
right?
A
F
J
Chef
Blanc,
Bella,
Mel
I
think
it's
important
in
the
current
spec
before
it
goes
to
final
call
to
get
in
what's
transmitted
and
how
but
I
think
we
can
actually
do
the
reporting
methods
before
the
update
to
Demark
in
a
later
spec
I.
Don't
think
we
need
to
necessarily
that
into
this,
because
that
feels
complicated
and
potentially
that
just
will
take
some
extra
time
may
need
some
additional
work.
A
B
D
So
in
comments
about
previous
discussion
about
experimental
standards
track
and
how
it
affects
our
plan,
the
bran
is
still,
you
know,
you
publish
a
new
document
within
a
week.
We
still
go
to
working
Plus
:.
Well,
assuming
it's
close
enough
and
them
as
in
did.
This
doesn't
affect
the
short-term
timeline
anyway,
if.
A
B
B
M
Great
hey
just
about
the
arc
work
and
how
it
affects
D
mark
reporting.
There
was
some
lists.
Traffic
that
was
was
was
making
arguments
about
what
the
contents
of
arc
should
be
to
enable
certain
kinds
of
D
mark
reporting.
It's
really
hard
to
follow
the
argument,
though,
if
we
don't
really
know
what
the
desired
e
mark
reporting
looks
like
so
it's
kind
of
hard
to
flip
it
around
and
say
hey.
We
need
this
without
actually
talking
about
what
needs
to
be
a
Demark
report,
so
yeah
I
family
really
need
to.
B
M
All
right,
I
just
wanted
to
say
that
it's
hard
to
put
one
thing
before
the
other
and
follow
the
arguments.
If
we
don't
really
know
that
the
end
goal
is
all
right.
Okay,
so
the
d
mark
usage
document
a
couple
days
ago,
I
posted
a
summary
to
the
list.
This
all
began
with
hey,
let's
not
make
usage
guide
unless
sweet,
unless
we
really
need
it.
M
M
Our
protocols
pushed
out,
experience
is
gathered,
and
then
you
push
for
a
standards
track
document.
So
the
way
I
see
it
is
a
usage
guide
would
be
important,
so
we
could
go
through
collect
operational
experience,
codify
it
in
some
way
in
the
form
of
a
document
and
then
push
it
out,
and
so
this
argument
was
pushed
to
the
list
and
said
and
and
the
the
pushback
was
well.
If
there's
something,
if
there's
something
new
that
needs
to
be
shared,
then
then
maybe
we
should
to
look
look
at
making
a
usage
guide.
M
So
I've
gone
through
and
collected
a
few
questions
in
the
summary
email
and
that's
where
it
is
right
now,
there's
a
small
collection
of
people
that
want
to
contribute
to
the
usage
guide,
but
it's
still
essentially
being
bootstrapped
I've
tried
to
facilitate
the
process
by
identifying
people
from
different
parts
of
the
email
ecosystem
and
getting
them
to
share
their
experience.
There's
only
been
two,
these
kind
of
interviews
so
far
pushed
to
the
list.
M
I
personally
find
them
valuable,
but
if
the
rest
of
the
working
group
does
not
and
the
feeling
is
that
hey
if,
after
the
ark
work
is
far
enough
along
to
move
to
the
next
stage
of
the
Demark
working
groups
charter
that
is
working
on
Demark,
the
technical
spec
is
a
standards
track
document.
Then
it
doesn't
make
sense
to
tie
up
the
working
group
with
this
work.
So
I'll
put
it
out
to
the
to
the
group.
M
Now
if
a
usage
guide
is
worth
working
on,
it
makes
sense
to
do
it
now
with
sort
of
a
focused
effort.
Otherwise,
if
there's
no
real
traction
within
the
working
group
itself,
this
work
could
go
on
somewhere
else.
A
different
context.
I
I
personally
feel
that
the
IETF
is
set
up
to
do
exactly
this
kind
of
work.
So
why
not
dude
in
this
context,
so.
B
Let
me
start
the
objection
that
was
raised
was
that
there's
there
are
already
a
lot
of
places
to
look
for
guidance
on
using
Demark.
Why
should
we
do
another?
One?
Is
there?
Is
there
anybody
who
wants
to
stand
up
and
support
that
argument
and
say
no
there's
enough
of
this
stuff
out
there
already?
We
don't
need
to
spend
our
time.
A
B
A
B
M
The
interviews
that
I've
been
doing
and
publishing
to
list-
that's,
that's
not
the
the
final
form.
I
was
just
trying
to
get
people
to
start
sharing
their
operational
experience,
but
in
response
a
response
in
two
parts,
one
I
think
that
there
are
certain
parts
of
the
email
stream
that
are
underrepresented
in
terms
of
documentation
and
how
to
interoperate
with
Demark,
basically
email
receivers.
M
I,
don't
think,
there's
a
lot
of
support
for
them
personally,
if
you're
a
domain
owner,
there's
lots
of
help
commercially,
free
and
otherwise
to
get
Demark
implemented,
but
email
receivers
have
very
little
in
the
form
of
resources.
The
second
part
would
be
email
service
providers
that
are
sending
email
on
behalf
of
others.
The
advice
and
guidance
is
pretty
spread
out
so
that
that's
there's
an
underserved
and
basically
underrepresented
parts
of
the
ecosystem
that
don't
have
this
kind
of
documentation.
D
E
D
D
B
B
What
do
you
think
about
continuing
work
on
this
for
now
and
not
making
the
decision
and
deferring
the
decision
about
whether
publish
it
too
later
after
the
working
group
gets
a
chance
to
see
how
it
develops
and
what
is
in
it
are
you
willing
to
work
on
it
with
the
idea
that
it
might
not
be
published?
If
the
working
group
decides
the
content,
isn't
sufficient?
B
M
B
Then
my
proposal
is
that
we
continue
working
on
it
with
the
idea
that
it
might
not
wind
up
as
an
RFC
that
the
working
group
publishes
depending
on
what
the
content
winds
up
being
okay
and
there
are
a
lot
of
nods
from
the
room.
So
that
seems
good,
and
that
is
the
end
of
our
time.
I'll
just
ask
if
anyone
in
the
room
or
on
Medeco
has
any
final
comments
and
Marie.
Would
you
read
button
Tim.
B
B
Set
did
you
have
a
comment
or
researching
will
take,
has
come
in
to
the
list.
I'll
say
as
in
as
the
chair
managing
this
stuff,
and
you
know
not
having
any
more
say
than
that.
My
view
is
that
we
should
not
be
making
Demark
a
standards
track
document
until
we
have
something
we
can
do
in
Denmark
to
actually
address
the
mailing
list.
B
Problem
I
think
we
really
need
to
spend
our
I'm
thinking
about
what
we
can
do
to
do
more
than
just
patch
it
up
with
something
like
Ark,
but
actually
have
a
mitigation
in
in
the
Demark
spec.
Maybe
that's
not
realistic,
in
which
case
we
can
rethink
it.
But
let's
think
along
that
line.
Where
can
we
go
in
the
spec
that
will
make
the
spec
a
standards
track
thing
that
doesn't
damage
existing
long-term
usage
on
the
Internet?
F
B
We
certainly
before
we
actively
start
work
on
a
standards
track
version.
We
can
do
the
preparatory
stuff
and
we
do
have
what
okay
and
we
do
have
a
wiki
to
work
with
on
that
the
whole
dies
given
the
D
mark
has
significant.
This
is
Jim
Fenton,
given
the
D
mark
has
significant
operational
issues,
which
is
why
arc
exists
right,
Oh
wrong.
One
sorry,
Jim
I'd
be
interested
in
seeing
a
split
between
the
reporting
and
policy
aspects
of
D
mark
make
them
separate
documents,
okay,
and
we
are
out
of
time
plus
three
minutes.