►
From YouTube: IETF-DETNET-20230307-1300
Description
DETNET meeting session at IETF
2023/03/07 1300
https://datatracker.ietf.org/meeting//proceedings/
A
A
A
I'm
Lou
Berger
janosvarcos,
as
I
mentioned,
is
having
some
audio
issues
and
we'll
be
rejoining.
We
had
to
reboot
this
computer,
but
we're
going
to
get
started.
We
also
have
David
black
our
technical
advisor
and
we
might
end
up
with
our
secretary,
although
it
is
quite
early
on
the
west
coast
of
the
U.S.
A
A
Please
keep
your
audio
off.
Unless
you
are
asked
to
speak
or
you
are
the
one
Speaking
it
says,
headsets
recommended
recommended
I
think
today
it
works
pretty
well
without
it.
We're
using
meet
Echo,
obviously
you're
you're
here
with
us.
So
thank
you
for
joining
note,
taking
you
can
get
to
through
the
there's
a
button
in
the
upper
right
about
the
note
taking
if
you
can
join
the
Hedge
Doc
and
help
us
capture
the
discussion.
That
would
be
great.
The
recording
of
this
meeting
will
also
be
available
after
the
session.
A
You
joining
here
also
serves
as
a
virtual
blue
sheet,
so
no
action
is
required
there
today
we're
going
to
be
after
the
intro
we're
going
to
get
an
update
on
the
requirements
draft.
This
is
our
working
group
document
on
scaling
requirements
really
headed
towards
an
enhanced.net
data
plane
we
had
at.
We
had
talked
about
having
a
design
team
some
process.
Things
got
in
the
way
of
the
formal
design
team,
so
we've
decided
that
we
are
going
to
proceed
with
a
series
of
open
working
meetings.
A
Those
meetings
are
going
to
be
chaired
by
our
Tech
advisor
David,
black,
so
David.
Thank
you
so
much.
The
focus
of
this
meeting
is
on
the
process
related
to
how
we're
going
to
progressing
and
making
sure
that
everyone
has
an
opportunity
to
talk
and
to
hear
what
the
planned
process
is
we're
going
to
not
get
into
too
much
discussion
of
of
solutions.
Here.
A
So
that's
where
we're
going
to
spend
the
boat
bulk
of
the
time.
The
open
discussion
is
to
focus
on
this
process
and
making
sure
that
those
who
wish
to
contribute
to
the
data
plane
enhancements
have
an
opportunity
to
participate
in
the
proposed
working
meetings
and
with
that
I'm
going
to
hand
off
to
Pang
go
ahead.
Tourless.
C
Yeah
so
I
am
was
suggesting
an
additional
item
on
the
agenda
yesterday,
sorry
that
was
so
late
and
that
was
the
you
know,
discussed
and
promised
type
of
method
that
could
help
this
process
with
respect
to
criteria
assessment
for
for
the
different
mechanisms.
So
if,
if
we
have
time
for
that,
maybe
that
would
be
useful
to
get
started.
Having
participants
located
in
this
meeting.
A
Okay.
Well
thanks
for
that,
as
you
mentioned,
it
came
in
quite
late.
We
had
others
who
wished
to
speak
and
we
had
said
that
those
people
will
will
go
to
that
first
open
meeting
and
talk
about
it
there
as
well
as
talk
about
it
on
the
list
wouldn't
be
fair
to
you
know,
have
your
material
come
in
so
late
and
have
you
know,
have
those
others
not
be
able
to
speak
in
front
of
you?
A
C
By
the
way
I
haven't
seen,
actually
anybody
else
make
a
requests
on
the
mailing
list,
so
I
think
it
would
be
great
if,
if
those
other
requests
and
the
according
drafts
would
be,
you
know
communicated
openly
on
the
mailing
list,
as
opposed
to
just
requested
to
chairs,
because
then
it's
very
opaque
to
understand.
What's
going
on
with
other
people
in
the
working
group.
A
They're
welcome
to
contribute
in
the
way
they
see
fit.
You
know
the
usually.
We
ask
to
not
clutter
the
working
group
with
all
session
requests.
We
did
the
same
just
now
for
the
upcoming
ietf.
It's
pretty
typical
not
to
have
the
session
requests
come
on
on
the
whole
list
and-
and
you
know
at
clutter
there
I
certainly
agree
that
I
would
like
them
to
contribute
on
the
list
publicly
in
the
open
meetings
bring
documents
forward.
A
A
A
D
A
D
And
also
thanks
for
all
of
them,
so
first
as
the
name
was
changed
from
large
scale
to
scaling.
We
also,
we
also
changed
the
words
in
the
whole
document,
but
we
don't
give
a
definition
of
scaling
internet
different
from
the
previous
name
of
large
scale.
The
authors
don't
think
the
definition
of
it
is
needed
so
as
abstract.
Zero
words
that
changed
from
long
hops
per
hop
time
variation
and
to
light
version
in
latency
Mountain
hopes
as
David's
suggestion.
D
D
So
here's
the
summary
of
major
comments
and
changes.
Most
of
them
happened
in
Section
3
and
the
leads
to
some
restructuring.
We
added
the
explicit
requirements
regarding
flow
fluctuation,
caused
by
large
number
of
flows
corresponding
at
about
it.
Five
in
key
attributes
related
to
the
new
comment.
So,
to
make
the
relation
clear
for
each
K
attributes,
we
add
the
specific
section
reference
which
could
be
presented
later
and
for
section
3.1.4.
D
We
change
the
title
to
provide
mechanisms
not
requiring
synchronization
from
support
a
synchronizing
based
methods
so
that
it
it
looks
more
compatible
for
the
four
sub
sections.
On
the
fourth
section,
3.4
and
three
point:
seven
moves
a
different
level
of
than
that
service
demand
to
section
3.7
and
add
some
explanations
for
them
and
for
Section
3.4
is.
D
It
is
now
about
the
aggregation,
which
is
in
section
3.5
in
the
old
version
and
also
add
some
words
reference
to
the
existing,
obviously
and
the
last
for
the
section
4.3
and
4.4,
and
there
is
no
one
to
one
reference
between
the
bodies
into
in
introduction.
The
sub
sections
in
section
three
and
the
relationship
might
be
entered
here.
D
D
So
next
are
the
key
attributes
in
section
to
introduction
and
Technical
requirements
in
Section
3
and
the
data
plan,
enhancement
and
requirements
in
section
4..
So
first
are
the
key
attributes
in
introduction.
Some
of
them
are
changed
in
red,
including
spiriting
and
re-emerged,
but
not
so
much
change
about
interactions.
D
So
here
is
it
is
that
there's
relaxed,
claw
clock,
synchronization
or
no
clock
synchronization
in
different
domains
and
the
end-to-end
path
is
combination
of
low
and
high.
It
is
a
hops.
There
are
virus
transmission
rates
supported
at
different
ports
on
the
different
network
nodes,
and
there
are
large
number
of
flows
which
may
be
difficult
to
be
identified.
D
So
the
technical
requirements
is
closely
light
with
HK
attributes.
It
is
now
that
tolerate
time,
asynchronously
and
next
is
support,
large
single
hope,
propagation,
latency,
common
dates.
The
higher
link,
speed
and
B
is
scalable
to
massive
traffic
flows,
while
moving
the
different
level
of
standard
service.
You
want
to
requirement
seven
and
Local
5
is
prevent
flow
fluctuation
from
District
disturbing
service,
and
next
they
tolerates
the
failures
of
links
or
nodes
and
tablet.
Topology
changes
and
the
last
one
is
supports
enhancement
of
queuing
magnesiums.
D
So
this
is
a
whole
picture
and
for
this
slide
to
make
it
clear,
here's
a
one-to-one
mapping
of
Kit
attributes
and
the
technical
comments
and
again
I
want
to
introduce
them
again
and
hope
you
can
check
it
with
it
within
your
site.
If
this
will
be
the
discussion,
maybe
not
okay,
this
slide
could
be
a
good,
abstract
and
Foundation,
and
well
so.
E
D
Okay,
I
will
I
will
go
so
here's
the
section
for
it
has
four
requirements
of
data
plan
enhancements
which
are
not
closely
aligned
with
each
technical
bonds
and
for
common
one
is
support,
aggregated
flow
identification.
It
could
be
aligned
with
one
of
oh
sorry.
It
is
from
the
five
not
one
before
in
the
new
version.
Sorry-
and
the
second
one
supports
meta
information
used
by
functions,
ensuring
the
domestic
latency.
It
could
be
aligned
with
a
comment
7.
D
D
Guess
we
we
think
to
maybe
enhance
the
government
story.
Another
story
section
three
to
give
a
mapping,
but
we
don't
really
have
the
tact,
so
we
are
not
sure
if
we,
if
we
could,
if
we
can
and
finally
at
the
final,
we
can't
provide
useful
text.
Maybe
we
were
removed.
The
last
two
government
in
section
four.
A
A
A
B
B
Bottom,
you
should
show
along
the
bottom
somewhere
there.
It
is
carefully
hit
carefully
hidden
behind
the
note
that
says
it's,
your
slides,
okay
got
it.
It
works.
Thank
you.
So
all
of
this
is
proposed,
so
I'm
gonna,
I'm
gonna,
run
through
the
slides
and
then
it's
going
to
be
open.
Discussion
I
mean
I.
B
The
two
open
working
meeting
goals
that
were
announced
and
there's
been
some
question.
Other
topics
are
going
to
be
outside
the
scope
of
these
working
meetings.
They
may
still
be
within
the
scope
of
the
work
group
as
a
whole.
This
is
not.
This
is
an
a
focused
effort
to
go
deal
with
cueing.
It's
not
going
to
it's
not
intended
to
do
everything
that
that
could
be
done
or
should
be
done
to
to
enhanced
debt
net.
B
B
He
they,
the
authors,
have
have
very
helpfully
put
each
each
requirement
in
its
own
draft
section
and
I.
Think
as
we
go
along,
we
need
to
remove
requirements
that
aren't
for
scaling
that
affects
requirements.
4.3
and
4.4
I
think
the
working
group
sort
of
get
working
group
sort
of
gets
to
decide
whether
those
are
closely
related
to
scaling
or
ought
to
be
pursued
sued
independently.
B
So
with
the
refines
and
requirements,
the
next
step
is
to
determine
which
proposed
solution
is
satisfied
which
requirements.
This
is
something
like
a
two-dimensional
Matrix
of
solutions
on
one
axis
requirements
on
the
other
access,
and
here
the
section
numbers
help
a
lot
because
it
means
we
could
just
put
the
section
numbers
in
The
Matrix
as
labels
and
people
can
go.
Look
at
the
student
requirements.
Draft
explains
what
each
of
them
means
in
much
more
detail.
B
Then
the
fun
starts
need
to
do
a
priority,
triage
of
of
requirements
figuring
out
among
all
the
things
that
are
in
the
requirements
draft.
How
do
they
stack
up
against
the
importance
of
of
actually
satisfying
them
in
a
perfect
world
we'd?
Have
we
we'd
find
easy
to
satisfy
all
of
them?
The
world's
not
perfect
reality
has
a
habit
of
intruding
now.
B
A,
B
and
C
in
this
slide
is
shown
as
in
order,
but
in
practice
are
going
to
be
going
to
be
pursued
concurrently,
because
there
will
be
feedback,
there
will
be
feedback
among
them.
If
we
discover,
for
example,
that
there's
a
particular
requirement
that
this
all
the
solutions
are
having
difficulty
satisfying,
maybe
that
requirement's
not
not
been
stayed
well
and
it
needs
to
be
and
need
to
be
refined.
B
Somehow,
out
of
all
of
this,
we
we,
the
hope,
is
to
converge
on
a
set
of
solutions
to
progress
that
satisfy
at
least
the
most
important
requirements,
perhaps
not
all
of
them,
perhaps
not
comprehensively
and
somehow
obtained
working
group.
Rough
consensus
for
all
of
this
I
think
this
is
a
point
at
which
Group
shares
expect
that
I
have
a
black
hat,
a
magic
wand,
I'm
going
to
produce
a
rabbit,
we'll
see
how
we'll
we'll
see
how
well
that
works.
B
Okay,
a
little
bit
more
on
priority
triage
I
mentioned
this
in
the
previous
slide
that
the
purple
text
is
what's
on
the
previous
slide
in
essence,
I
want
to
sort
sort
of
sort.
The
requirements
into
sort
of
three
categories
must
requirements.
If
we
don't
satisfy
the
requirement
we're
wasting
our
time.
B
Should
requirements
really
does
mean
what
what
should
is
strong
strongly
recommend
that
we
forgot
how
to
satisfy
it,
as
there
would
be
significant
drawbacks
to
scale
of
debt
and,
if
not,
satisfied
and
may
requirements
it
says
in
quotes
nice
to
have
there
are
some
benefits.
Notion
can
drawbacks
if
requirement
is
moved
and
if
we
discover
requirements,
don't
even
make
it
to
nice
to
have
that's
a
strong
suggestion
that
perhaps
requirement
ought
to
be
removed
from
the
requirements.
Draft.
B
This
set
of
mustard
May
applies
to
the
entire
set
of
of
community
Solutions.
We
progressed
there.
May
there
may
well
be
more
than
one
if
there's
more
than
one
that's
selected
for
progression,
different
requirements
could
be
satisfied
by
different
solutions.
It's
not
necessary
that
a
single
solution
meet
meet
all
of
the
requirements,
although
that
would
be
that
would
be
nice
and
simple.
B
Okay,
two
more
slides
all
right.
The
dismantic
design
team
did
in
fact
get
something
useful
done.
We
figured
out
what
we're
up
against
in
scheduling
meeting
times,
and
it's
not
great.
So
there
are
five
important
time
zones
for
participants
are
listed
here
and
there
is
no
good
meeting
time
across
all
five
of
these
time
zones.
So
since
I'm,
in
the
eastern
time,
Eastern
Time
Zone
I
put
the
meeting
times
in
Eastern
time,
I'm
hoping
people
can
quickly
convert
their
own
time
zone.
B
The
Proposal
is
to
alternate
meetings
between
slots
that
are
12
hours
off.
Alternate
between
8
and
10
in
the
evening
eastern
time
and
8
and
10
in
the
morning
Eastern
time.
What
happens
here
is
that
the
8
to
10
in
the
evening
is
bad
for
Europe.
Eight
to
ten
in
the
morning
is
bad
for
the
Pacific
time
zone.
Us,
West,
Coast
part
of
this
is
that
the
some
of
these
some
of
the
time
slots
like
this
one
are
not
great
for
Asia
and
based
on
interest.
B
We
have
a
large
set
of
of
folks
from
Asia
who
want
to
participate.
I
don't
want
to
go.
It
somehow
doesn't
feel
right
to
hit
to
to
force
all
the
meetings
into
the
evening.
In
Asia,
all
working
group
open
meetings
will
be
recorded,
so
those
some
of
the
meeting
lands
in
a
bad
time
zone
you'll
be
able
to
to
review
the
recording
post.
B
Frequency
is
every
two
weeks
starting
at
the
Oklahoma
ietf
meetings,
and
there
are
the
time
slots
for
the
proposed
first
for
the
proposed
first,
two
meetings:
April
11th
the
evening
sought
eastern
time
and
April
26th
the
morning
slot
eastern
time.
What
will
happen
on
April
11th
is
for
a
lot
of
people.
That
will
be
that
will
be
sometime
on
April
12th,
so
these
meetings
are
in
fact
about
two
about
two
weeks.
B
Apart
last
slide,
we
would
invent
your
head
of
us
welcome
questions,
welcome
comments,
welcome
even
dead
cats
and
rotten
tomatoes
and
a
an
Asian
colleague,
a
friend
of
mine
reminds
me
that
I
need
to
explain
my
American
cultural
references.
This
is
a
reference
to
The
Adventures
of
Huckleberry
Finn,
a
well-known,
a
well-known
book,
oh
by
Sammy,
Clements
AKA,
Mark,
crane,
okay,
open
for
questions
and
comments.
A
Before
opening
the
queue,
did
you
go
back?
One
slide?
Yes,
so
I
put
in
the
chat
that
we
would
like
to
get
closure
on
timing.
Before
talking
about
any
other
topic,
we
think
it's
really
really
important
that
as
many
people
who
want
to
contribute
to
this
effort
are
able
and
that
the
meeting
times
can
work
for
the
collective
group.
So
I
would
like
to
get
feedback
on
this
proposal.
If
it's
good,
for
you
feel
free
to
say
in
chat,
it
works,
it
works
for
you.
A
C
Right
so
I
think
when
you
were
looking
for
time
slots,
you
were
asking
the
back
then
officially
suggested
members
of
the
design
team,
so
maybe
it
would
be
good
to
to
Simply
check
for
the
others
that
want
to
participate.
So
in
my
case,
I
certainly
want
to
want
to
put
my
tips
on
this
time.
Slot
right
five.
B
C
Actually,
the
one
thing
that
I
I'm
glad
you're
trying
to
do,
although
I'm
not
remember
that
we've
ever
successfully
managed
to
make
people
happy
with
the
altering
times.
If
there's
an
example,
that
would
be
good
to
know,
I
mean,
as
I
said,
right,
I'm
open
for
any
anything.
My
preference
is.
Is
this
time
started?
You
know.
F
Poster
proposed
a
meeting
time
but
I
do
have
a
small
concern
regarding
the
alternate
because
it
I
I
think
it's
not
so
common
that
we
alternate
every
two
weeks
and
given
that
the
time
looks
at
it,
it's
a
lot.
It's
just
8
to
10
pm
and
8
to
10
a.m.
The
the
the
the
change
is.
There
is
only
a
very
slight
change.
People
may
get
confused
if
they
check
their
website
and
another
thing
is
I.
I
I
haven't
checked,
but
if
there
is
a,
for
example,
a
holiday
happened
on
I
think
that's
Tuesday.
F
Then
we
still
need
to
make
some
notification
in
advance
to
say
whether
we
just
bypass
that,
for
example,
the
first
time
type
first
time
slots
or
we
just
postpone
it
by
still
using
the
the
first
time
slot.
Something
like
that.
So
my
my
comment
is:
it
looks
like
the
alternating
the
time
time
slot
is
a
little
is
a
little
bit
hard
for
executing,
but
I'm,
okay,
with
their
both
the
time
slots.
Actually
yeah.
G
A
C
A
A
C
B
C
B
That's
I
think
that
would
make
that
would
make
some
sense.
Let's,
let's
try
this
and
let's
try
this
and
see
and
see
how
see
how
see
how
well
it
works.
I
mean
intros.
It
turns
out
my
my
preference
is
actually
is
actually
for
the
8
pm
to
10
p.m.
Time,
slot
I'm,
no
good
at
8am
without
a
serious
dose
of
coffee.
H
Hi
I
am
just
the
wondering
I'm.
Okay,
with
that
on
the
time
proposal,
I
just
wondering
oh
well,
we
have
a
kind
of
side
meeting
in
in
Japan,
because
I
think
most
of
the
people
who
care
about
this
question
will
be
there
and
it
will
be
great
if
we
can
sit
together
face
to
face-
and
just
you
know,
maybe
just
one
hour
is
okay.
We
can
discuss
about
the
the
the
the
schedule
or
or
anything
else.
D
A
H
B
Thank
you,
sir,
and
I
want
to
reinforce
what
Lou
said
about
going
to
list.
One
of
the
reasons
that
I
propose
a
a
meeting
every
other
week
as
opposed
to
every
week,
is
to
encourage
work
to
be
done
between
the
meetings
and
encourage
work
to
be
visible,
visible
on
the
mailing
list
list.
That's,
ultimately
where
progress
is
progress
is
made
and
decisions
are
made.
C
That
was
when
we
take
it
to
the
list.
That's
particularly
ask
the
folks
for
feedback
from
folks
who
will
not
be
in
Yokohama
like
David,
also
at
which
points
in
time
they
would
be
able
to
join
remotely
to
that
site
discussion,
and
then
we
can
set
it
up
accordingly,
get
a
room
and
so
on.
So
thanks
she's
on
for
for
taking
the
lead
and
I'll
be
happy
to
chime
in
and
support
the
logistics.
A
B
C
You
know
monopolize
the
microphone,
so
please
everybody
stand
up
here,
so
I
think,
as
as
an
author
on
the
scaling
requirements,
draft
right
and
and
having
memorized
your
mass
shots
and
everything
I
guess
the
way
I
see
it
is
that
we
we
should
be
concerned
about
how
what
we
write
in
the
requirements
draft
as
a
working
group
would
be
mapped
to
the
design
team
right.
So
in
terms
of
what
is
out
of
scope,
what
is
in
scope
and
then
what
is
in
scope?
C
The
must
should
and
may
would
be
more
important
to
get
right.
Then
you
know
I
guess
for
the
ones
that
are
out
of
scope
where
we
wouldn't
address
them
immediately
through
this
effort,
but
through
other
TBD
efforts
in
in
the
working
group
and
I
guess
what
I'm
missing
for
that?
Mapping
is
a
little
bit,
I
think
the
type
of
goals
we
think
we
can
address
with
queuing
right.
C
So
in
terms
of,
if
I
look
at
the
requirements
draft,
it's
it's
talking
about
latency,
Jitter
and
a
bunch
of
other
things,
and
so
maybe
maybe
there
would
be
a
way
to
say.
Okay,
here
is
the
the
type
of
functionality
that
that
we,
you
know,
think
we
can
address
through
through
the
queuing,
and
that
is
Jitter.
That
is
a
latency
and
I.
Think
and
that's
where
I
think
also.
C
C
The
point
that
that
some
of
those
things
we
may
want
to
compare
things
on
are
related
to
Hardware
feasibility.
I
think
the
clocking
is
is
one
good
example
that
we
do
cover,
but
yeah.
If
you
have
any
especially
you
know,
as
the
tech
advisor
have
any
more
abilities
to
constraints
the
the
things
you
think
we
we
should
and
could
achieve
with
the
queuing
that
that
would
be
great
to
have
as
added
input
into
the
process.
Okay,.
B
B
G
G
H
But
the
you
know
from
the
perspective
of
the
communication
and
Inter
operation
between
different
devices
and
the
implementations,
the
the
in
encapsulation
may
be
another
very
important
topic
for
for
this
work.
So
I'm
I'm
I
just
want
to
ask.
Will
this
also
be
considered
during
our
discussion
or
it
will
be
left
after
the
queuing
discussion.
B
I'm
tempted
to
try
to
to
it
sounds
like
a
yes,
no
question
I'm
tempted
to
try
to
answer
it
with
a
little
bit
of
both
to
the
extent
that
the
queuing
mechanisms
require
additional
information
on
the
wire
I
would
think
that
they
would
influence
an
encapsulation
discussion,
but
job
one
is
to
figure
out
the
job.
One
is
figure
out
the
queuing
mechanisms
I'm
not.
H
Yeah,
it
sounds
reasonable
for
me
I
think.
Maybe
the
conclusion
is
that
that
will
be
the
you
know.
These
two
aspects
will
be
considered
together.
For
example,
we
discuss
each
kind
of
queuing
mechanism
and,
at
the
same
time
we
will
see
whether
these
kind
of
mechanisms
request
new
encapsulation,
for
example
in
IP,
header
or
other
other
kind
of
their
three
headers,
and
so
shall
we
make
it
another?
H
Meeting
that
maybe
people
is
is
is
requesting
some
some
encapsulation
that
may
can
cover
all
the
kinds
of
query
mechanisms
and
may
just
pick
the
the
shortest
the
simplest
common
part
of
different
gear
mechanisms
and
making
the
encapsulation
change
really
small
or
yeah
I.
Think
my
point
is
just
that
we
should
take
it
into
consideration
when
we
discuss
the
the
queue
mechanisms
and
evaluate
them.
B
I
think
it's
a
fine
consideration,
understanding
of
each
mechanism.
What
is
the
additional
data
that
that
that
is,
that
is
required
to
be
exchanged,
exchanged
if
any
I
think
I
think
or
call
at
least
one
mechanism
that
was
talking
about
not
needing
to
exchange
any
additional
data?
So
I
think
that's
a
fine
evaluation
consideration.
I
Yeah
hi
everyone
when
you're
discussing
the
queuing,
I,
think
there's
a
scalability
issue
which
hasn't
been
addressed
and
sorry
for
not
participating
in
this
process
and
just
dropping
in
here,
but
very
important.
The
unloading
you're
assuming
on
the
lines
and
on
the
devices
along
the
way,
if
you're,
assuming
that
the
loading
is
close
to
zero,
for
instance,
there's
nothing
else
on
the
line
at
all.
I
You
have
a
path
all
to
yourself,
then
the
queuing
doesn't
really
matter
once
your
loading
is
getting
high,
then
there's
a
big
difference
between
the
different
queuing
mechanisms
and
I
think
that
has
to
be
addressed
because
there
are.
There
are
certain
mechanisms,
like
our
TSN
friends
in
in
the
ethernet
World,
where
they
block
out
everything
else
and
worst
case.
B
I
I
My
own
personal
feeling
is
that
the
required
draft
goes
into
a
lot
of
detail
on
timing,
which
is
not
always
that
important
once
again,
depending
on
what
your
timing
errors
are.
But
if
you're
your
bounds
are
in
the
tens
of
milliseconds
and
your
timing,
errors
are
in
the
microseconds,
then
the
whole
discussion
is
moot.
B
F
This
is
more
about,
what's
suggested
by
shares.
Also
I.
Think
probably
we
can
add
a
the
second
bullet
to
item
C,
because
in
the
page
two
actually
would
you
please
sure
yeah
switch
to
page
two
yeah.
There
go
one
of
the
courses,
their
information
and
definition
that
will
be
common,
so
we
need
to
identify
whether
there
is
common
elements
or
not,
or
we
would
like
them
to
be
put
in
common
such
thing.
C
That's
that's
really
a
core
point,
and
if
you
have
any,
you
know,
suggestions
for
the
requirements
document,
please
bring
them
up,
be
happy
to
you
know,
consider
them
how
to
put
them
in.
In
my
opinion,
I
think
the
problem
is
a
little
bit
that
something
as
fundamental
as
you
know,
in
the
forwarding
plane,
data
plane
to
propose
and
put
better
mechanisms,
is
a
very
long
term
thing
and
and
therefore
a
lot
of
the
you
know.
C
C
But
you
know
I
can
say
from
what
I
would
feel
similar
experiences
with
the
you
know,
bringing
multicast
into
networks
and
and
also
having
the
same
discussion
right.
How
much
multicast
is
in
your
network
right
can't
you
simply,
you
know,
use
unicast
replication
which
to
me
would
be
the
equivalent
of
you
know,
use
better
diff,
surf
type
mechanism
to
solve
the
problem
right
that
that
always
ended
up.
You
know
with
customers
feeling
very
unsure
about
going
down
a
particular
path.
B
I
I
Are
we
having
a
Target
for
a
Bound
for
a
packet
to
arrive
at
Final
Destination,
but
let's
say
one
percent
of
the
time
it
might
not
meet
it,
and
if
that
means
that
the
application
has
to
drop
it,
then
it
contributes
what's
effectively
packet
loss,
since
this
can
be
packet
loss
on
the
network
anyway,
I
think
that's
something
relevant
and
once
again
it
changes
it.
It
extends
the
number
of
queuing
mechanisms
that
you
can
look
at
foreign.
B
I
would
definitely
prefer
to
look
at
a
broader
set
of
queuing
mechanisms
from
the
outset,
as
opposed
to
imposing
hard
real-time
requirements
up
front.
There
is
certainly
a
set
of
applications
that
have
hard
real-time
requirements,
but
that's
that
is
not
the
entire
set
of
applications.
That
net
is
aimed
at.
B
C
That
was
kind
of
their
golden
requirement.
So
I
would.
If,
if
we
go
down
the
road
of
software
targets,
then
let's
make
sure
that
we
don't
sneak
it
in
through
this
process,
but
make
it
more
obvious
and
ideally
give
it
a
somewhat
different
name
and
not
bounded
latency.
But
you
know
come
up
with
with
another
term
so
that
we
make
clear
that
this
is
an
extension
of
what
I
very
much
hope
you
agree
was
the
original
intent
which
is
hard
about,
but
yeah
I'm
I'm
certainly
happy
to
have
this
effort.
B
So
a
couple
comments:
the
first
bullet
under
open
working
meeting
goals
is
information,
definitions
and
I.
Think
we're
now
exploring
some
use.
Some
interesting
information
and
definitions
and
the
requirements
draft
already
has
some
material
in
it
on
different
levels
of
detnet
service
that
could
accommodate
this
pause.
E
D
E
But
what
I
have
learned
in
the
in
the
last
couple
of
years,
discussing
with
with
owners
of
use
cases
at
various
industrial
players,
is
that
sometimes
they
are
formulating
somebody
differently.
The
requirements
as
as
we
are
doing
in
the
in
the
turquo
and
in
the
ietf
environment
for
example.
So
industrial
player
can
also
say
that
I
have
control
cycles
and
that
should
be
at
least
one
of
the
control
cycles
of
two
that
we
control
Cycles,
error,
free
and-
and
that
is
something
differently
defined,
as
we
usually
have
requirements
in
in
ITF.