►
From YouTube: Kubernetes SIG Network Bi-Weekly Meeting 20221208
Description
Kubernetes SIG Network Bi-Weekly Meeting 20221208
A
C
B
B
D
Just
came
out
of
a
question
from
obian
kubernetes
people.
They're,
saying
like
you
know,
so,
is
a
deny
all
policy
expected
to
deny
cluster
Ingress
traffic,
since
we
don't
specify
a
lot
about
cluster
Ingress
traffic
and
I
felt
like
yes,
even
though
we
don't
specify
what
you
can
allow
in
in
terms
of
cluster
Ingress,
we
we
do
specify
what
you
can
deny
and
that's
all
of
it.
E
E
D
D
C
D
Basically,
there
was
a
test:
some
of
the
the
ede
test
runs
run
with
Min
sync
period
equals
10
seconds,
meaning
once
you
create
a
service,
it
may
take
up
to
10
seconds
for
the
IP
tables
rules
to
be
there
and
right.
Some
of
the
tests
were
assuming
that
changes
that
they
made
would
be
applied
in
less
than
10
seconds.
Okay,
there
there
was
some
debate
over
like
the
the
correct
timeout
to
be
using
and
and
exactly
and
then
Antonio
changed
his
mind
about
something
at
the
end
and
but
I.
F
B
F
F
G
B
B
G
G
C
B
B
Excellent
all
right
we're
now
into
issues
from
October,
which
is
good.
So
if
we
need
to
stop
Casey,
keep
us
honest,
UDP
traffic
loss
observed
during
start
of
service
pod
run.
External
traffic
policy
is
local.
There
was
some
chatter
on
this.
I
didn't
absorb
all
of
it
and
oh
Lars
updated
it
this
morning.
H
B
H
B
B
B
D
F
F
I
No
I
was
gonna
say
that
we
are
planning
to
deprecate
these
things
on
increasing
Gen
X,
at
least
because
building
them
doesn't
pay
for
like
people
using
that.
So
I
would
say
that,
maybe
in
our
case,
I
would
like
that
IBM
use
that,
because
usually
in
our
case
at
least
in
English,
we
spend
a
lot
of
time
and
a
lot
of
CPU
building.
Those
teams,
and
almost
no
one
uses
that
so
I'm
not
sure.
If
this
is
the
same
case
for
us.
F
B
We'll
leave
this
open
for
now
we
can
revisit
it
in
two
weeks
and
see
if
it
or
whenever
we
have
our
next
meeting
and
see
if
there's
any
updates
on
it.
This
is
the
last
one.
So,
let's
squeeze
it
in
before
Casey
kicks
us
off.
Oh,
is
this:
this
is
an
old
one.
This
is
one
where
I
pinged
Dan
a
month
ago,
yep.
A
F
Oh
I
almost
forget
I
think
that
we
we
it
seems
that
the
in
the
old
days
of
kubernetes
that
only
a
few
persons
remember
they
were
using
external
IPS
at
the
fall
and
most
of
the
people
now
prefer
to
use
internal
because
external
have
caused
and
may
they
are
not
really
needed.
So
I
think
that
was
I.
Don't
remember
nowadays,
but
I.
Think
that,
because
we
are
going
to
suggest,
is
to
prefer
internal
IP
first
or
before
testing.
G
J
J
But
basically
there
is
this
end:
user,
kubernetes
Community
called
data
on
kubernetes
and
they
there's
a
lot
of
members
there
who
are
basically
database
vendors
and
they
go
and
Trade
Practices
best
practices
on
how
to
run
stateful
workloads
on
kubernetes.
They
also
and
operators,
and
things
like
that.
So
they've
written
a
lot
of
operators
and
best
practices
of
operators.
J
I
am
planning
on
sort
of
starting
a
regular
sort
of
Round
Table
session
between
that
end,
user,
community
and
kubernetes
maintainers,
and
hopefully
we
can
use
this
to
sort
of
facilitate
feedback
directly
from
the
end
users
on
sort
of
What
kinds
of
things,
they'd
like
to
see
in
kubernetes
to
help
them
run
the
state
four
workloads
more
smoothly.
So
if
anyone
here
is
interested
in
sort
of
joining
that
Forum
I
started
a
doc
to
collect
a
bunch
of
names
and
we're
gonna
try
to
schedule
the
first
meeting
in
around
January
sometime
in
January.
B
J
K
I
wanted
to
bring
up
a
just
kind
of
talk
about
an
issue
we
talked
about
in
the
mailing
list
a
couple
weeks
ago
and
there's
an
open
issue
for
donating
a
repository
for
those
of
you
who
I'm
going
to
do
a
quick
recap
of
what
it
is
for.
Those
of
you
who
may
have
not
seen
it,
but
bleaks
is
what
it's
called
originally
started
as
an
experimental
layer,
4
load
balancer
using
ebpf
for
the
data
plane
at
Kong
where
I
work.
K
So
last
we
left
off.
We
had
I
think
three
issues
which
I
think
we've
got
like
three
concerns
about
taking
it
on
which
I
think
we've
covered.
The
first
concern
was
support
surface.
We
absolutely
don't
want
it
to
be
a
production,
any
kind
of
production
support
service
for
this
and
I
think
we've
covered
that
with
the
combination
of
the
writing
on
the
wall,
plus
the
fact
that
we
are
in
the
thread.
K
We
talked
about
being
committed
to
having
some
kind
of
technical
mechanism
to
actually
stop
people
from
using
it
in
production,
as
opposed
to
saying
don't
use
it
in
production
and
then
later
they
do.
It
literally
stop
them
today.
That
is,
it
only
works
with
kindness
and
in
the
future.
We're
open
to
things
like
having
a
shutdown,
timer,
so
I
think
that
one's
resolved
and
then
the
naming
I
think
no
nobody's
worried
about
that.
K
But
if
they
are,
we
can
adjust
the
name
and
then
the
fact
that
it
includes
rust
was
the
third
one
and
I.
We
didn't
get
a
whole
lot
of
feedback
on
that
one,
but
I
I
think
that
Nick
Young
made
a
comment
to
the
effect
of
it's
really
low-key
and
if
we're
going
to
start
somewhere
potentially
that
we
should
just
not
worry
too
much.
But
that's
kind
of
what
I
wanted
to
bring
up
for
discussion
was.
Were
there
any
lingering
concerns
about
I?
K
L
Yeah
I'll
just
add
my
I
think
I've
commented
on
the
issue
and
the
threat
as
well
and
I
I'm.
Supportive
of
this
we've
been
really
trying
to
push
L4
through
for
Gateway
API,
and
a
project
like
this
is
going
to
be
very
helpful
to
at
least
you
know,
run
some
proof
of
Concepts
ensure
the
apis.
We're
building
actually
make
sense
and
are
usable.
L
A
The
next
topic
was
actually
me.
I
wanted
to
bring
this
up.
I
am
planning
on
stepping
down
from
the
chair
position
versus
network,
been
in
the
spot
for
a
long
time
and
want
to
give
an
opportunity
to
someone
else
to
take
over
this
role.
So
I
wanted
to
bring
that
up
here
and
see
if
anyone
was
interested
in
that
or
if
anyone
has
any
their
thoughts
on
that.
That
sort
of
succession
I
think
this
is
the
first
time
to
my
knowledge
that
we've
done
a
succession
in
Sig
Network.
B
B
B
It's
helping,
make
sure
things
run
and
get
keeping
the
meetings
in
order
and
organizing
and
finding
the
right
people
and
making
contact
so
I
think
it's
a
great
opportunity
for
somebody
who
wants
to
get
more
involved,
but
you
know
maybe
doesn't
want
to
be
owning
all
the
the
design
and
code
problems
you
can
do
both
if
you
want,
but
it's
an
opportunity,
I
Know,
Dan
Williams
is
all
right.
Dan
are
you
here
still.
A
B
Is
now
here
today,
okay,
Dan
made
similar
noises,
so
I
don't
want
to
speak
for
him
yet,
but
here's
an
opportunity
for
new
Opera
new
new
people
to
step
up
in
an
interesting
way
and
take
some
more
Community
leadership.
So
you
don't
need
to
sign
up
right
now
right,
but
if
you're
interested
in
this,
let
me
or
Casey
or
Dan
Williams
know
that
you're
interested
and
we
can
talk
about
it.
A
And
I'll
say:
I'm
like
I'm,
not
falling
off
the
face
of
the
Earth,
so
I'll
be
around
to
answer
questions
and
help.
If
anybody
decides
to
pick
this
up
unless
they
must
be
super
helpful
and
everybody
here
is
very
helpful
and
and
supporting
you
in
that
role.
So
it's
not
something
to
be
super
stressed
about.
C
Yeah
I
would
suggest
it
would
be
a
great
idea
to
help
people
understand
if
they
are
interested
or
they're
trying
to
make
a
case
to
their
employers
to
how
why
they
should
spend
the
time
they
probably
would
want
to
go
into
that
discussion
with
an
idea
of
the
both
the
time
commitment
and
am
I
signing
on
for
one
year
three
years
forever
like
defining.
That
might
be.
You
know,
Sig
specific,
but
also
useful,
for
people
trying
to
make
decisions.
B
Yeah
I
mean
honestly,
like
we
should
probably
formalize
this
and
say
like
if
you're
signing
up
you
know
every
year
or
or
18
months
or
something
we
will
offer
this
to
new
people
if
they
want
to
take
it
right.
So
nobody
feels
like
they're
stuck
because
there's
nobody
no
succession
plan
and
that
they
can't
get
out
of
it
like
nobody
should
feel
that
way.
This
should
not
be
an
obligation.
I
M
Casey
I
think
it
will
help
a
lot
of
people
if
you
do
an
FAQ
somewhere
of
the
things
you
do
today
and
the
time
load
on
you,
and
so
people
who
want
to
volunteer
can
say:
okay,
it
will
look.
I
will
obviously
not
committing.
It
will
be
the
same,
but
it
will
look
almost
like
what
you
have
in
your
area.
There
are
key
questions
that
everybody
else
in
like
how
long
does
it
take?
What's
that,
what
do
I
do?
B
You
know
to
the
to
Andrew
to
your
point.
Thank
you
for
reminding
me.
We
we
I
started
a
conversation
a
number
of
weeks,
even
months
back
about
formalizing
the
recognition
of
more
roles
within
the
Sig
and
and
building
towards
more
formal
succession
plans
and
then
I
totally.
Let
it
fall
off
my
radar,
so
I
will
try
to
find
that
discussion
and
bring
it
back
if.
A
E
E
It
includes
some
really
nice
resources,
video
on
the
birth
Network
policy,
with
our
own
Tim
and
Dan
and
other
folks,
and
this
came
up
in
the
network
policy
API
subgroup
meeting
on
Monday
and
the
general
Vibe
with
it
was
like
kind
of
it's
kind
of
confusing
right.
So
this
website
is
literally
Network
policy.
I
o
it's
preaching
like
a
fully
Upstream
Network
policy
object,
but
there's
a
network
policy
editor
on
the
front
page
that
is
not
fully
open
source
that
I
could
find.
E
I
could
be
wrong
if
there's
other
selling
folks
on
the
page,
so
we
were
kind
of
discussing
like
what
we
could
do
with
this
to
kind
of
bring
it
into
the
fold
like
rewinding,
even
more
like
the
network
policy,
API
subgroup,
like
kind
of
want
all
these
random
Network
policy
resources
to
kind
of
live
in
one
place.
So
we
can,
you
know,
make
it
easier
for
users
who
want
to
figure
out
our
policy
and
may
have
trouble
understanding,
just
the
default
Upstream
documentation.
E
B
If
we,
if
we
were
to
repatriate
this
like,
would
we
take?
Oh
would
we
want
to
take
over
the
site?
First
of
all,
it's
owned
by
psyllium
right,
so
I'm
not
signing
psyllium
up
to
give
it
to
us,
but
suppose,
hypothetically
that
they
were
like
yeah
sure
go
right
ahead.
Take
it
over
is
that
what
we
want
to
do,
I.
E
Don't
think
so
we
have
a
website
already,
so
it
would
be
more
like
kind
of
taking
the
resources
that
are
here
and
putting
them
in
our
website
and
deprecating
this
website
or
making
it
less
of
like
a
generic.
This
is
Network
policy
because
it
looks
like
an
official
Upstream
kubernetes
Network
policy
kind
of
site
like
and
we
had
someone
come
and
ask
if
it
was
and
I
was
like.
E
No,
we
don't
own
this,
and
then
he
was
like
I
was
confused
because
I
thought
this
was
generic
Upstream
Network
policy,
but
then
I
realized
the
network
policy.
Editor
was
actually
part
of
psyllium
and
it
was
just
like
creating
some
confusion,
so
I
think
the
goal
would
be.
Maybe
they
make
this
and
to
ask
them
to
possibly
make
this
into
more
of
like
this
is
psyllium
Network
policy
editor
like
this
is
great
and
we
put
the
generic
like
Network
policy
related
resources
in
an
upstream
repo.
Does
that
make
sense.
B
Yeah
I
mean
it,
it
makes
sense.
We
should
go,
ask
the
question.
Ultimately,
we
don't
have
a
trademark
on
network
policy,
and
so
we
can't
prevent
anybody
from
doing
this.
If,
if
the
psyllium
folks
want
to
maintain
this
because
it's
valuable
for
them
and
their
customers,
that's
great,
we
could
ask
them
to
make
it
clearer
that
it's
not
officially
Affiliated
or
something.
If
we
think
that
that's
what
we
want
to
do,
but
we
can
have
the
discussion
I,
don't
think
anyone
from
psyllium
is
here
on
a
regular
basis.
B
A
B
B
The
the
cycle
starts
to
go
back
to
the
the
kept
kept
phase
of
the
cycle.
Although
you
know
officially,
we
don't
really
have
a
cycle,
but
this
is
how
it
works.
In
practice,
I
sent
out
a
note
to
Signet
about
how
I'm
going
to
try
to
manage
my
own
time
around
reviewing
stuff,
because
I
I
feel,
like
I've,
been
giving
people
an
unsatisfactory
experience.
Lately,
cramming
everything
in
right
at
the
last
second,
so
I'm
going
to
try
to
do
better
at
spreading
that
out
over
time.
B
B
B
Please
let
me
know
earlier
rather
than
later,
so
we
can
discuss
it
and
if
there
are
big
ones,
I'm
happy
to
make
time
to
sit
on
a
zoom
call
on
a
regular
basis
and
talk
about
you
know
incremental
progress
as
opposed
to
dropping
giant
PR
bombs
at
the
end
foreign,
that's
I'm,
setting
this
up
for
myself.
Personally,
if
other
people
want
to
follow
suit,
that's
totally
fine
I'm,
not
imposing
it
on
anybody.
This
is
how
I'm
trying
to
manage
my
time.
C
A
B
What's
changed
in
the
last
couple
of
weeks
as
you've
evolving?
This
thing
I
can
review
commits
on
your
own
Branch
or
on
a
shared
branch
that
we
use
to
figure
out
how
to
do
incremental
reviews
I'm
making
it
up
as
I
go
here
like
what
I
know
is
what
we've
been
doing,
isn't
working
and
so
I'm
gonna
just
try
something
anything
different.
In
fact,
I
might
try
three
or
four
different
things
with
different
people
and
see
what
what
does
and
doesn't
work
better.
B
B
I
wanted
to
go
for
something
low
touch
like
put
it
in
your
own
Branch
somewhere
and
just
rather
than
Force,
pushing
your
branch,
send,
commits
and
or
send
PRS
against
your
own
branch
and
like
tag
me
in
so
I
can
look
at
them
right
and
then,
when
it
comes
to
that
final
merge,
it
might
still
be
a
mega
PR,
but
it
won't
be
something
that
I've
never
seen
before.
Right.
M
M
B
M
For
the
sake
of
this
discussion,
I
am
all
right,
I
guess
it's
part
of
showing
up
right,
so
I
am
and
I'm
quite
sure
a
lot
of
people
will
be
as
well,
so,
let's
just
spin
over,
so
we
don't
have
to
funnel
everything
so
one
person
or
a
few
persons
like
the
more
the
more
the
merrier.
As
long
as
we
know
like
we
maintain
a
certain
level
of
quality
and
consistency,
we
should
be
fine.
A
F
F
Have
this
in
in
openshift
and
I,
see
this
in
Syrian
and
and
you
see
that
with
topology
people
comes
to
us
for
more
features,
but
they
are
couponing
features
and
I
really
think
that's
about
the
experience
having
a
an
API
that
works
all
in
one
places
and
doesn't
work
in
others
and
and
I
thought
that
well
maybe
the
solution
is
to
add
conformance
and
I,
take
it
to
with
kmpa
kpng
too,
and
and
they
have
some
failing
things
that
are
not
working.
So
my
point
here
is
I.
F
Don't
think
that
conformance
always
is
going
to
fix
things
because
some
people
just
skip
it.
I
see
that
in
in
some
implementation
skip
the
test,
so
they
don't
Implement
that
they
skip
to
this.
So
my
question
is
moving
forward
as
I
see.
How
do
we
want
to
do
this?
I
mean
to
have
to
not
grow
organically,
on
qproxy
or
in
some
custom,
significant
that
enables
and
nobody
have
implemented,
or
it's
only
hard
to
implement.
M
I,
this
is
a
very
deep
like
thought
like.
It
always
goes
to
my
nerve.
The
topic
right
and
I
think
I've
talked
to
stem
so
many
times
about
this
and
I've
granted
about
it
so
many
times
what
we
have
is
a
system
that
has
n
by
n
by
n
number
of
capabilities
in
it
that
the
end
user
has
no
way
to
tell
that
the
thing
I'm
about
to
push
to
the
API
server
will
actually
succeed
by
the
same
that
implements
it.
I
might
use
this
example
about
policies.
M
Let's
take
a
network
policy
Network
API
Gateway
has
many
many
sharp
edges
where
oh
I
deployed
something
from
something
somebody,
but
the
thing
doesn't
support
grpc,
all
right
or
whatever,
so
the
API
server
has
no
way
to
say
your
request
will
will
likely
work
right,
Beyond,
API,
static
validation
and
the
stuff
we're
doing
conversion
and
all
of
that
stuff,
which
is
fair.
But
what
this
thing
the
entire-
and
this
goes
by
the
way
to
disks
it
goes
to
gpus.
It
goes
to
like.
M
Oh
I,
don't
want
the
gpus
that
can
split
or
whatever
GPU
do
these
days.
There
is
no
way
you
can
tell
that
the
driver
that
supports
the
GPU
actually
can
do
the
feature
you
want.
What
I'm
trying
to
say
is
we're
lacking
kind
of
capability
enumeration
like
we
cannot
show
up
to
a
system
and
talk
kubernetes
and
say:
hey:
can
you
do
policy
of
type
whatever
or
hey?
Can
you
do
desk
of
type
whatever
or?
And
this
is
because
we
don't
have
that
API
server,
except
many.
M
M
So
that's
that's
that
that's
beyond
conformance,
because
conformances
is
a
commitment
of
oh
hey,
I,
I,
I'm,
a
Gateway,
API
and
I
can
do
these
things
all
right,
but
that
deploy
the
deployment
the
snowflakes
deployment
that
the
user
have
by
adding
more
add-ons
to
their
system
or
not
what
people
run
the
conformance
against,
but
not
what
we
confirm
against
all
right.
So
that's
that's!
That's!
That
has
been
an
ongoing
line
of
hope
that
I'm
I've
been
involved
in
anyway,
I
I
in
the
floor.
D
F
K
H
D
B
E
Is
is
the
answer
like
maintaining
I,
don't
know
some
infrastructure
that
runs
conformance,
that
where
we
run
conformance
on
certain
implementations,
so
that
we
can
say
this
implementation
is
conforming
to
our
spec
like
right.
Now
we're
just
trusting
that
Downstream
implementations
run
our
tests,
but
they
can
skip
them
like
Antonio
said
they
do
whatever
like?
Is
it
for
us
to
maintain
a
as
a
community
to
maintain
a
list
of
conformant
implementations
and
keep
that
in
date,
up
to
date.
F
B
Should
also
be
careful
that
you
know
the
way
Cube
proxy
implements
things,
isn't
necessarily
what
the
specification
is
right.
Like
Cube
proxy
may
say,
we
publish
all
endpoints
right
or
I'll
pick
on
topology
since
Rob
is
on
my
screen.
You
know
the
way
that
topology
is
implemented
between
Cube
proxy
and
the
API
server
is
not
the
only
way
that
it
could
be
implemented
and
would
a
different
implementation
be
valid
or
invalid.
If
it's
different
from
what
we
do
right.
B
B
L
Yeah
I
I
would
say
that
topology
is
a
good
example,
but
likely
not
the
only
one
of
features
we
have
made
with
the
limitations
of
our
current
implementation
of
Coupe
proxy
in
mind.
That
may
not
apply
to
all
other
proxy
implementations
in
the
kubernetes
ecosystem,
so
maybe
we're
not
making
the
best
spec
decisions.
I
mean
we
don't
yeah,
agreeing
with
everything.
That's
been
said,
but
Shane
you've
got
a
hand.
K
F
I,
don't
think
that
that
way,
I
don't
own
on
that
problem.
You
know
in
in
so
what
I'm
saying
is
what
I
really
I
think
that
didn't
say
this
through
two
or
three
years
ago,
is
that
we
should
freeze
Q
proxy
and
stop
adding
feature
based
on
YouTube,
proxy
and
I
start
thinking
more
holistically,
based
on
specs
and
kind
of
things.
L
F
D
F
K
Go
ahead
Antonio,
it
sounded
to
me,
like
maybe
I,
misunderstood
what
you're
saying
it
sounded.
It
sounded
to
me,
like
you,
started
off
with
being
worried
about
people
coming
in
and
building
Coupe
proxy
like
things
but
not
meeting,
conformance,
plus
your
added
thing
that
you
don't
know
that
conformance
testing
really
is
the
thing
that
solves
that.
But
then
you're
talking
about
like
wanting
to
freeze
Koop
proxy,
which
these
seem
kind
of
like
different
issues,.
F
F
Miss
anything
the
the
thing
is,
let
me
let
me
so.
The
thing
that
they
see
is
that
Services
is
growing
and
we
keep
adding
features.
Okay
and
right
now
we
have
a
a
big
portfolio
features
in
Q,
proxy
and
people
keep
the
money
more
fit
to
some
more
advanced
features
and
what
I
don't
see
that
sustainable,
because,
yes,
the
other
implementation.
There
are
no
many
many
services.
F
Implementation
cannot
keep
up
with
Q
process
right
now
and
if
we
keep
developing
this
way,
we
are
going
to
keep
making
the
Gap
bigger
and
what
I
I
feel
is
that
Services
is
overwhelming
and
cannot
keep
us
more
than
it
is
doing
in,
and
we
still
keep
working
on
having
more
things
on
services.
So
I
think
that
we
are
in
a
busy
cycle
with
qproxy,
and
this
is
also
affecting
how
people
use
services
and
and
I
don't
know,
I
mean
it's.
B
So
we
should
be
clear
that
there's
two
at
least
two
different
categories
of
stuff:
there's
API
impacting
stuff,
which
you
know
like
adding
some
new
thing
to
the
API.
We
try
really
hard
not
to
add
a
lot
to
the
service
API.
But
you
know
adding
service
types
right,
like
is
a
big
deal
right,
because
we
know
that
every
implementation
has
to
understand
that
and
there's
non-api
impacting
things
like
topology,
which,
strictly
speaking,
should
be
invisible
to
most
users,
except
that
it
makes
their
system.
B
B
Whatever
information
you've
got
to
make
smart
decisions,
sort
of
situation
and
then
for
API
impacting
stuff,
I
I
think
we
have
done
and
need
to
continue
doing
the
I
know
it's
not
going
to
sound
great,
but
the
ietf
sort
of
multiple
conform
or
multiple
interoperable
implementations
must
exist
right,
and
we
can't
finish
it
until.
We
know
that
there
are
interoperable
implementations
and
I
chose
interoperable
instead
of
conformant,
because
I'm
not
sure
we
want
to
put
a
stamp
on
it.
B
B
You
know,
strictly
speaking,
we
said
from
the
beginning:
services
are
an
optional
API
in
kubernetes.
You
don't
have
to
run
Cube
proxy.
You
don't
have
to
offer
DNS.
Those
were
optional.
In
fact,
DNS
was
in
the
add-ons
directory
for
a
long
time
right
that
it
was
because
it
was
this
thing
that
you
could
put
on
top
of
your
kubernetes
cluster
to
make
it
more
useful.
B
B
B
E
F
B
So
I
have
to
drop
off.
I
need
a
couple
minutes
to
prep
for
my
next
meeting,
so
I'm
going
to
drop
off,
but
you
guys
can
keep
going.
If
you
want
to.
This
is
great
I'll
be
around
in
two
weeks.
Hopefully,
I'll
see
some
of
you.
If
not
everybody
have
an
amazing
holidays.
Take
some
time
off
and
we'll
see
you
in
January.