►
From YouTube: 2022-06-07 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
D
Okay,
let's
jump
into
the
phone
thanks
for
joining.
As
always,
please
add
your
names
to
the
agenda
to
attend
this
list.
The
first
item,
just
for
your
information,
we
will
be
doing
a
spec
release
this
week,
like
the
usual
monthly
release.
D
Just
for
your
information.
Next
one
anthony
otlp
1.0
when.
B
So
once
again,
carlos
there
is
the
scope
attributes
pr
that
I
think
is
ready
to
be
merged.
But
since
you
were
doing
the
release,
I
would
prefer
it
to
go
after
the
release
so
that.
E
B
D
D
Okay,
thanks,
perfect
okay.
Next
one
otp
1.0
anthony.
F
Yes,
I
think
this
is
a
question
of
raised
before
I'll,
raise
it
again,
because
there's
currently
a
pr
proposing
that
we
change
several
of
the
constant
identifiers
that
are
used
in
otlp
and
I
think
we're
at
the
point
where
we've
said
the
data
model.
Still
the
product
is
stable,
but
we
keep
changing
things
and
we've
changed
things
in
ways
that
have
broken
people
before
I'd
really
like
for
us
to
say
we're
done.
This
is
stable.
It's
1.0
what
yeah.
F
B
B
B
We
do
not
really
want
to
mark
the
protocol
1.0
that
that's
my
opinion
now
do
we
want
to
do
this
particular
change
or
no,
I
think
I
think
I
would
like
to
talk
about
that.
I
am.
I
don't
have
a
strong
opinion
that
we
should,
but
I
I
guess
I
would
prefer
to
if
there
is
a
way
to
do
that.
So
I
don't
know
what
people
think
about
1.0.
B
B
B
The
other
opposite
of
that
would
be.
Is
there
anything
more
to
be
included
in
1.0?
Do
we
miss
anything
more
work
to
be
done
before
we're
confident
that
we
wanted
to
to
be
1.0
release.
C
Is
it
possible
to
do
it
for
individual
signals,
because,
at
least
for
me,
it
feels
really
weird
that
we
have
had
1.0
for
tracing
for
quite
a
while
now
with
sdks
that
claim
to
be
stable
but
are
using
an
unstable
communication
protocol
soon
to
be
in
the
same
boat
for
metrics?
Why
why?
Why
is
it
unstable?
C
F
B
Okay,
so
I
guess,
let's,
let's
focus
on
what
we
want
to
do
right,
not
not
what
we
did
in
the
past.
I
guess
right,
if
possible,
what
what
do
we
think
is
missing
before
we
can
actually
declare
1.0
other
than
saying
that
json
is
also
part
of
our
stability
guarantees.
It
is
stable
and
that
generated
code
is
also
stable.
I
would.
A
F
F
Then
we
need
to
have
at
least
some
guarantee
that
we
will
not
change
our
own
identifiers
if
protobuf
wants
to
change
how
the
generated
code
works,
that's
fine,
but
we
can't
simply
be
randomly
changing
identifiers
that
people
expect
to
be
stable,
but
that's
that's
something
that
only
gohan
has
the
problem
because
you
expose
it
publicly.
I
I
don't
know
that
it's
only
go
that
has
that
problem.
Python.
E
F
A
D
H
Terms
yeah,
but
when
it
comes
to
user
experience,
it's
better
just
to
inform
the
user
that
there
was
a
change
that
could
be
breaking.
A
F
F
A
C
With
with
tigran
that
we
already
did
that
it's
too
late,
so
we
need
to
focus
on
what
is
the
the
concrete
ask
for
the
future?
I
would
say
stable
identifier,
names
and
stable
json,
and
then
we
can
go
to
1.0.
C
Generated
code
yeah,
I
think
that
depends
too
much
on
the
internal
working
of
a
code
generator.
I
don't
know
you
know,
maybe
maybe
someone
else
knows
better
than
I
do,
but
I
don't
know
how
we
can
claim
that
generated
code
is
perfectly
stable,
but
we
can
say
we
use
this
code
generator
and
we
make
these
stability
guarantees
like
we
won't
change
identifiers.
We
won't
change
whatever.
G
A
Depends
on
what
generator
used
to
for
the
json,
but
if
we,
if
we
comment
and
say
this
field,
has
to
be
mapped
to
this
json
field,
I'm
not
saying
that
we
should
do
that
in
proto.
But
what
I'm
trying
to
say
is:
I
think
it's
independent,
the
the
way
how
you
name
an
identifier
in
a
struct
versus
the
way,
how
you
encode
it
as
a
json.
C
C
A
I
I
keep
hearing
that
v2
and
I
I
will
not
go
and
ask
how
how
many
people
are
switched
to
ipv6
and
it's
for
20
years
v2.
So,
let's,
let's
let
me
let
me
have
my
doubts
about
v2
and
still
try
to
give
enough
guarantees
that
for
1
0,
but
not
everything.
That's
that's
right.
D
B
So
we
are
not
saying
that
the
generated
code
won't
change,
because
we
don't
really
control
that
that's
a
behavior
of
the
generator,
but
we
will
say
possibly
that
we're
not
going
to
change
the
identifiers,
the
names,
the
structure
of
the
messages
or
the
whether
the
enum
is
inside
the
message
or
outside
things
like
that
which
affect
the
generated
code.
Ourselves.
A
F
A
For
example,
for
the
for
the
embedded
struct
for
the
embedded
and
it's
perfectly
the
same.
A
Also
for
for
one
more
question
related
to
this
and
jason:
do
we
guarantee
the
string
names
for
enums,
or
do
we
guarantee
the
ids
for
a
nouns,
the
the
numbers
in
the
json?
A
Def,
you
can
definitely
use
both
yeah
in
the
json
protobuf
generated
code.
You
can
use
both
either
the
id
that
you
are
located
to
the
enum,
but
the
id
by
the
number
I
mean
or
the
stream.
A
A
So
so,
by
the
way,
if,
if
we
declare
only
the
string,
only
the
ids
for
a
gnomes
then
moving
enums
is
fine
if
with
full
name
for
qualify
name
that
you
are
allowed
to.
Also
that's,
probably
not
fine
in
json,
because
I
think
that
changes,
if
you
are
embedding
things,
but
I
would
like
to
to
start
with
definitely
we
have
to
include
json,
but
we
have
to
make
the
final
calls
on
on
these
unknowns
in
json.
A
I
think
and
and
yeah
it
will
include
if
we
say
that
we
use
the
same
code
for
for
json
as
well,
then
the
same
protocol
for
json
or
or
or
we
use
a
different
definition
of
the
json.
That's
that's
another
thing
that
I
want
to
to
make
sure.
C
To
me,
the
reason
to
have
identifier
names
stable,
is
probably
going
towards
the
same
reason
that
anthony
wanted
the
client
library
generated
code
to
be
stable.
You
know
I,
I
don't
think
we
want
to
depend
too
much
on
the
internal
workings
of
a
code
generator,
but
we
can
make
it
as
likely
as
possible
that
it
won't
break
right.
If
we
say
we
won't
change
the
identifiers,
then
you
have
a
much
higher
likelihood
of
compatibility
between
versions
with
generated.
G
B
B
Field
names,
they
are
part
of
the
json.
Unless
we
are
going
with
a
custom
code
generator,
then
we
have
to
guarantee
the
stability
of
that
part.
The
message
names
and
field
names.
I
don't
think
we
want
a
custom
generator,
it's
a
possibility,
it's
an
option.
I
don't
see
the
reason
why
we
want
to
complicate
our
lives
and
do
that.
Actually,
if
we
are
doing
that,
if
we're
saying
that
message,
names
and
field
names
cannot
be
changed,
they
are
part
of
the
guarantees.
B
B
A
B
A
C
A
Deviating
from
that
by
deviating
that,
if
you
are
writing
manual,
for
example,
manual
json
or
you
are
using
a
different
library
for
json
decoding,
you
may
have
to
implement
extra
things
for,
for
this
again,.
A
Not
proto
has
a
capability
on
the
json,
pb
or
whatever
library,
to
say
encode
this
as
numbers
or
encode
these
as
strings.
A
D
B
Yeah,
we
can
maybe
continue
the
discussion
offline.
There
is
an
issue
opening
the
spec
repo
about
the
json,
but
there
is
an
issue
about
1.0.
I
will
open
one.
I
will
capture
what
we
discussed
here.
My
position
is
that,
if
we're
doing
the
message
name
and
field
stability,
we
just
should
go
all
in
and
declare
all
the
symbolic
names
stable,
but
maybe
there's
other
thoughts
so
I'll
open
an
issue
and
we'll
mention
you
guys
there
and
let's
continue
the
discussion
there.
A
B
B
Yeah,
that's
that
I
don't
know
by
the
way.
I
guess
it
depends.
I
I
wanted
to
understand
anthony
how
much
of
pain
that
is
like
is
it.
F
B
A
Okay:
okay,
let's,
let's
let
me
let
me
have
one
more
comment
here:
tigran,
should
we
remove
the
helpers
because
one
of
the
things
that
I
figure
out,
we
have
two
enums,
as
helpers
for
the
flag,
masks
and
stuff
like
that,
which
I
don't
think
they
are
never
on
the
wire.
They
are
just
helpers
for
people
to
work
with
the
flags
that
is
on
the
wire,
which
is
a
union
eight
or
something
I
think
we
should
remove
those
initially,
and
why
do
we
want
to
what's?
What's
the
problem
with
keeping.
A
My
point
is
not
is
not
is
not
consistent
across
them.
It's
an
easy
way,
it's
an
easy
fix,
because
I
don't
think
we
should
have
them
yet
until
we
decide
exactly
and
be
consistent
across
all
the
flags,
we
have
trace
flags
in
logs.
We
have
data
point
flags
in
things,
and
things
are
meaning
different
things.
If
you
are
looking
that
the
data
point
flags,
it
means
the
final
value,
not
the
mask
value
in
the
log
records.
A
A
B
D
J
Yeah
I
haven't
been
in
hawaii
a
while,
so
I
have
a
number
of
things,
hopefully
they're
kind
of
quick.
I
noticed
I
have
a
user
who's
asked.
I
was
hoping
someone
data
doug
might
be
here
that
in
a
database
client,
that's
instrumented.
J
He
doesn't
see
the
error
in
datadog
trace
ui
for
a
query
like
that
breaks
a
constraint
in
postgres,
and
he
does
if
it's
added
as
an
exception,
I
noticed
in
the
database
client
semantic
conventions.
There's
no
mention
of
what
to
do.
It's
a
set
like
status
as
an
error.
J
If
the
query
fails,
which
I
think
which
we
do
and
kind
of
took
as
assumed,
but
I
wasn't
sure
I
mean
there's
not
that
much
guideline
on
what
status,
how
status
should
be
used,
so
I
think
bring
up
whether
or
not
that
should
be
added
to
the
semantic
conventions
for
database
clients
and
curious.
J
F
J
Okay,
I
was
looking.
I
was
trying
to
understand
the
datadog
collector
code
because
it
has
code
specific
to
looking
at
status
and
the
error
message
and
converting
it
to
something
and
tag
I
mean
it
has
tags
as
well.
As
for
exceptions,
I
mean
it
wasn't
clear.
It
seemed
like
it
might
be
doing
something
that
would
convert
it
to
what
it
expects,
but
apparently
it
doesn't
work
in
the
end.
J
J
A
K
D
J
J
It
would
be
nice
if
different
tracers,
especially
now
that
we
have
instrumentation
scope
so
that
things
can
be
scoped
much
more
finely
than
a
library
that
you'd
be
able
to
set
a
sampler
that
would
be
used
by
a
specific
tracer
by
using
a
sampler
provider,
so
basically
an
object
or
function
that
returns
a
sampler
based
on
some
information.
That's
given
to
it.
J
But
now
there's
an
issue
that
this
might
actually
be
not
backwards,
compatible
and
like
go
and
some
others.
So
there
might
be
some
issues
there,
but
I
think
the
idea
at
least
is
useful.
A
What
informations
can
we
provide
at
the
tracer
level
at
the
tracer
level,
we
have
the
instrumentation
name,
instrumentation
library,
version
stuff
and
now
we'll
have
attributes.
So
these
are
the
extra
information.
So
I
think
what
we
can
do
to
make
it
smart.
A
She's,
probably
unmuted
for
by
mistake.
So
let
me
these
are
the
only
informations
what
I
would
do
tristan
the
tristan.
I
would
provide
the
two
ways
of
achieving
this.
You
either
provide
these
informations
with
every
call
or
you
build
this
provider
pattern
where
you
provide
it
once
and
then
you
don't
provide
for
the
subsequence
code,
because
you
provide
it
first
time
you
get
a
new
object,
and
now
you
know
you
recall.
A
J
Make
sense
yeah.
I
can
see
that
being
a
good
compromise.
I
can
add
that
to
the
spec
and
do
others
agree
there.
I
need
composition.
J
Then
we
can,
I
can
go
to
my
next
one,
really
quick,
the
before
end.
I
don't
think
there's
as
much
to
discuss
here
now,
because
I
talked
with
tyler
about
it,
and
I
put
a
proposal
at
the
end
of
this
that,
because
I
would
prefer
we
don't
need
before
n,
but
it
keeps
coming
up
so
before
end
would
be
a
processor.
That's
able
to
modify
the
span.
J
J
A
You
want
to
add,
you
want
to
add
the
baggages
to
the
span
at
the
end
event
or
before
end
or
whatever.
Okay.
Now
now,
to
be
honest,
I
who,
who,
how
is
the
next
consumer
of
these
things,
because
in
my
mind,
I
think
I
was
thinking
that
the
next
consumer
will
be
a
span
data
which
you
can
modify.
A
Next
consumer,
what
after
so
so
so
you
have
you
have
a
processor
okay.
So
so
what
I'm
trying
to
say
is
the
spam
processor?
Has
these
two
hooks,
okay,
that
and
works
on
the
span
on
the
span?
Object
that
is
read
on
right,
only
correct,
except
the
span
context,
but
it's
right
only
most.
A
A
And
the
reason,
the
reason
why
I
want
this
approach
versus
allowing
people
to
write
is
because,
if
you
allow
people
to
write,
you
have
to
protect
against
multiple
threads
and
concurrency
synchronization
and
all
the
other
problems
versus.
If
it's
immutable,
you
don't
have
all
these
problems.
J
Yep
I
mean
I
I
didn't
want
before
end,
because
I
think
it
starts
asking
what
about
after
start,
what
about
after
end
before
start
so
preferring
not
to
have
a
before
end
and
yeah.
So
the
wrapper
idea,
I
think,
is
the
way
forward.
Just
needs
to
be
written
up
perfect
all
right.
If
there's
nothing
else
on
that
one.
My
last
one
is
really
quick.
J
I
brought
this
up
with
the
some
other
people
discussing
it
that
when
I
noticed
that
instrumentation
scope
isn't
a
a
super
set
of
instrumentation
library,
basically
the
instrument,
the
library
information
is
lost.
In
a
sense,
it
can
still
be
added
somewhere
to
your
your
spans
or
your
yeah,
your
spans
as
attributes,
but
the
the
library
that
it's
coming
from
and
the
version
of
that
library
is
no
longer
part
of
the
actual
spec
saying
that
you
need
to
have
these
on
there
or
you
should
have
these
on
there.
J
B
J
Well,
I
mean
the
instrumentation
library
has
been
removed
from
like
the
the
protos
and
everything
so
there's.
No,
I
mean
it's
a
super
set
in
the
sense
that
it
would
enter
it
encompasses
all
of
these,
in
the
sense
that
people
are
probably
still
going
to
be
using
instrumentation
libraries,
those
names
and
versions
the
same
ones
when
they
create
a
scope.
J
B
B
J
J
I
mean
if
you
wanted,
to
search
for
all
the
spans
being
generated
by
a
specific
instrumentation
library
version.
That,
maybe
was
you
thought
was
having
problems
or
I
could
see.
E
J
A
A
But
what
I'm
trying
to
say
is
people
and
people
were
assuming
that,
for
example,
a
fully
qualified
class
name
is
fine
for
that,
because
we
asked
we,
we
made
that
that
discussion
so
so,
for
example,
to
answer
your
question:
if
they
respect
our
suggestion
that
the
name
should
be
unique
and
they
should
use
fully
qualified
names
there,
even
if
they
create
scopes
smaller
than
the
library,
for
example,
they
probably
most
likely
will
have
the
same
prefix
as
the
library
dots.
Some
I
mean.
I
A
Correct
I
get,
but
that
was
a
bit
of
a
heck
if
you
really
need
to
see
the
spans
from
that,
and
you
know
that
this
is
the
pattern
that
they
are
using,
because
in
the
end,
what
I'm
trying
to
say
is
say
this
is
a
free-form
stream,
no
matter
how
we
name
it
or
how
we
put
it.
People
will
use
whatever
they
want.
J
Oh
yeah,
I
agree,
that's
why
I'm
saying
maybe
we
should
have
a
part
of
the
semantic
inventions
to
have
like
now
that
scope
might
have
or
is
probably
going
to
have
attributes
soon.
They
could
be
library,
name
and
library
version
within
that.
That
is
the
name
and
version
of
the
library,
that's
instrumented,
so
I
was
bringing
it
up,
as
would
do
people
think
that
could
be
useful
and
that
this
was
useful
before
when
it
was
instrumentation
library,
and
should
it
be,
you
know,
proposed
or
does
it
seem
like
just
extra
information?
That's
not.
I
I
I
Okay,
but
then
we
could
say
you
know,
define
a
semantic
convention
hotel.library.name,
which
is
exactly
the
don't
name
and
and
use
that.
B
B
I
Yeah
but
but
what
was
said
now
is
that
the
scope
name
might
be
anything
and
not
necessarily
the
library
name
true.
So
if
we
want.
E
E
A
B
Yeah
we
have
that
we
say
that
the
most
common
approach
is
to
use
the
library
name.
We
also
tell
that
we
recommend
using
fully
qualified
name
the
combination
of
these
two
things
essentially
in
in
most.
I
guess
cases
should
result
in
something
that
is
properly
identifiable
right
when
you
receive
this
data
for
the
cases
when
people
ignore
this
recommendation-
and
it
includes
some
chunk
data
there
I
mean
for
for
those
cases,
are
you
going
to
rely
on
the
fact
that
they
are
diligent
enough
to
include
the
semantic
convention
properly
and
with
the
library
name?
B
B
B
J
There's
probably
like,
if
there's
cases
where,
like
an
http
server,
where
you
might
want
to
scope
for
each
endpoint,
that's
going
to
be
user
defined,
but
the
library
name
that
would
be
on
the
the
tracer
would
attributes
would
be
or
that
on
the
scope.
Attributes
could
be
added
by
the
library
itself,
not.
A
By
the
user,
but
but
yeah,
but
that
means
the
scope
is
owned
by
the
user.
If
the
users
scope
it
their
own
code,
it's
their
own
library
there,
so
they
they
do
the
right
thing
this.
They
name
it
that
part
of
the
code.
Even
though
it's
a
library,
it's
a
http
plugin,
but
it's
their
library
there,
like.
I,
don't
see
a
problem
with
that.
A
J
That's
the
when
I
get
what
you're
saying
that
the
user
might
not
be
handling
what
setting
it
right
and
that
now
it's
the
instrumentation
library
is
their
own
if
they're
adding
the
scopes
creation
themselves
but
yeah.
I
still
so.
I.
B
It
could
be
misleading.
That's
the
that's
a
problem.
You
can't
expect
that
that
the
library
name
there
is
going
to
be
what
you
think
is
going
to
be.
That's
the
thing.
If
who
owns
the
scope
of
the
person
who
created
this
code,
is
it
in
the
user
defined
code?
In
that
case,
you
should
not
expect
that
there
is
a
library
name
there,
even
though
that
code
is
probably
called
by
the
library
right,
it's
it's
http
handler.
B
That
is
not
the
expectation.
It's
a
user's
user
scope,
user
defined
scope,
the
name
there
is
going
to
be
probably
the
application
name,
the
class
name
of
the
handler,
something
like
that.
There's
no
expectation
of
a
library
name
there
matching
whatever
the
http
library
they
are
using.
That's
not
the
case,
yeah!
That's
a
good
point!
There.
A
So
I
think,
I
think,
the
ones
that
we
write
the
libraries
that
we
write.
We
should
follow
the
same
rules
that
were
before
yeah
and
now
and
now,
if
user
has
this
code
like
plugins
for
a
library
like
handler,
they
may
create
their
own
scope
or
they
may
use
the
same
scope.
Personally,
I
would
recommend
them
to
create
their
own
scope
if
they
create
spans
there
and
stuff,
because
it's
actually
their
scope
there.
A
B
Yeah
and
the
users,
if
the
user's
code
happens
to
be
a
formal
plugin
for
a
library,
then
that
formal
plugin
can
have
its
own
formal
library
name
right.
If
not
it's
a
completely
custom
code
in
the
application,
there's,
probably
no
library
to
speak
of
right.
It's
an
application.
You
give
it
a
name
application,
name,
class
name,
something.
B
J
D
D
Perfect,
are
you
round
yeah.
M
Hi,
thank
you
cool,
so
I
have
two
topics.
The
first
one
is
super
short.
I
adopted
the
requirement
levels
and
existing
specs
and
I
have
two
questions:
the
first
one
from
metric,
maintainers,
jack
or
tyler,
or
somebody
else
can
you
folks.
Please
take
a
look
and
the
other
one
to
bug
them.
M
A
It's
fine.
My
suggestion
was
like
when
I
looked
at
the
numbers
I
mean
I
didn't
count
per
se,
but
when
I
looked
at
the
changes
I
saw
lots
of
required
and
I'm
like.
Oh,
are
we
making
the
mistake
right
now
by
declaring
almost
everything
required?
That
was
my
feeling
from
reading
the
pr,
maybe
I'm
off,
but
I
I
want
to
put
it
in
your
mind
that
it's
a
good
time
to
double
check
if
we
have
not
been
too
greedy
and
declare
everything
required
before.
A
M
I
appreciate
it,
thank
you
and
it's
a
great
concern
and
yeah.
We
should
reduce
it.
It's
just
there.
We
have
a
lot
of
requirement
level
not
set
which
means
recommended,
and
it's
like
way
higher
number
than
we
have
there,
but
yeah.
There
are
some
things
we
can
improve
and
I
will
follow
up
on
this.
M
Thank
you,
okay.
The
other
one
is
I'm
great
that
christian
is
here,
so
we
can
discuss
it
properly.
M
So
I
have
to
change
for
http
attribute
attributes
to
reduce
the
number
of
supported
required
attribute
sets
to
one,
and
we
have
a
we
start
discussing
what
net
peer
name
means
and
christian
created
the
issue
that
they
have
an
agenda
to
co,
to
discuss
whether
it's
a
low
level
socket
attribute
or
it's
the
logical,
remote
endpoint,
and
I
believe,
however,
we
use
it
now.
It's
logical,
remote,
endpoint
across
all
the
semantic
conventions
we
have
general
convention
is
very
vague
about
it.
M
It
doesn't
say
what
it
means
exactly:
it's
a
remote
host,
name
or
similar.
This
is
a
quote
so
going
forward.
The
question
is,
how
do
we
see
it
and
if
we
can
focus
for
a
moment
on
the,
should
we
keep
the
current
status
quo
on
this
http
for
request
and
then
address
this
change
later
in
all
specifications
or
do
we
feel
blocked
and
we
need
to
resolve
socket
yes,
logical
thing
before
this
one
gets
merged
christian?
Did
they
capture
it
right.
I
Yeah,
I
think
so
on
yeah
it's
it's
currently
the
conventions
for
these
net
attributes.
They
are
right,
a
bit
convoluted.
So
if
you
read
further
down,
there
is
and
section
net
dot,
starter
name
attributes
and
it
says
yeah
for
a
net
peer
name.
It
should
be
the
name
that
was
used
to
look
up
the
ap
address
that
was
connected
to
if
you
use
a
b
based
communication.
So
it
kind
of
says
it
should
be
the
lower
level
name.
I
But
I
agree
that
currently
we
have
it
as
required
for
a
pc
and
database
either
that
ip,
which
maybe
should
be
completely
removed,
I'm
not
sure
if
it's
useful
for
especially
for
a
database
to
know
to
notice-
or
it's
certainly
useful
but
not
required-
maybe
because
we
all
special
database
name
and
so
on.
I
I
M
I
I
I
M
I
Yeah,
but
the
question
is
in
the
instrumentation:
do
you
need
to
special
k
special
case
something
to
capture
the
name
of
the
proxy,
or
do
you
need
to
special
case
something
to
capture
the
name
from
the
url?
It
probably
depends
on
how
you
concretely
implemented
this.
If
you
didn't
think
of
the
scenario,
then
you
might
get
one
or
the
other.
M
M
So,
let's
maybe
create
an
issue,
have
a
separate
discussion,
but
it
may
be
not
http
specific
question.
I
think
it's.
M
D
Sorry
for
interrupting,
we
only
have
to
mean.
Can
we
continue
discussing
sorry
for
the
lack
of
time.
M
Yeah,
I
think
we're
stuck
in
this
discussion
and
we
need
somebody's
help
to
resolve
it.
That's
my
impression.
I
Okay,
although
I
think
we
are
close
to
an
agreement,
even
though
we
may
might
disagree
on
the
reasons
but
yeah,
basically,
I
would
be
fine
with
declaring
that
net
peer
name
is
the
logical
name
and
then
for
http.
We
need
to
define
what
is
logical
yeah.
Then.
I
think
we
can
go
forward
with
that
and
find
out
later
on
or
attribute
for
a
low
level
name,
because
I
think
that's
still
useful.
M
Okay,
thank
you
appreciate
it
so
I'll
try
to
summarize
it
and
some
proposal
and
we'll
talk
it
we'll
take
it
offline.
Thank
you.
D
Perfect,
thank
you
so
much
for
that
and
there
sorry
we
don't
have
time
to
talk
about
attribute
spec
issue,
but
these
people
can
take
a
look
at
that
after
the
call
it's
about
this
specul
inconsistency
with
proto-definition
of
attributes.
L
Yeah,
I
think
I
put
a
nice
little
summary.
I
think
it's
just
a
clarification,
but
I've
heard
inconsistent
things
across
the
board,
so
I
just
want
to
have
it
all
clarified
and
get
it
fixed.