Skip to main content

Minutes IETF110: dispatch
minutes-110-dispatch-00

Meeting Minutes Dispatch (dispatch) WG
Date and time 2021-03-08 12:00
Title Minutes IETF110: dispatch
State Active
Other versions plain text
Last updated 2021-03-10

minutes-110-dispatch-00
# DISPATCH Virtual Meeting @IETF-110

Monday, 8 March 2021
12:00-14:00 UTC

[MeetEcho](https://meetings.conf.meetecho.com/ietf110/?group=dispatch&short=&item=1)
[Notes](https://codimd.ietf.org/notes-ietf-110-dispatch)
[Jabber](xmpp:dispatch@jabber.ietf.org?join)

DISPATCH Meeting
----------------

### Status and Agenda Bash - Chairs and ADs (5 min)

* Kirsty presenting by herself to start off. Please note that the ART AREA of
the agenda is sharing of technology, just for information, not for dispatching.
* Bron Gondwana taking notes (AGAIN) because I'm a sucker for it, and whoever
writes the notes creates the history.

### Date and Time on the Internet (20 min)
Presenter: Ujjwal Sharma
[draft-ryzokuken-datetime-extended](https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-extended/)
[Messages](https://mailarchive.ietf.org/arch/msg/dispatch/ral4HWlVDw8mRRRmvMdSGPtGA0Y/)

* Works at a consultancy called Igalia
* [sound went bad - took about 2 min to fix]
* Described the "Temporal" type, first class timezones and calendars.
* Standard 3339 time: datetime+offset
* via Jabber: https://datatracker.ietf.org/doc/draft-bormann-cbor-time-tag/ is
also coming up this meeting.

### DISCUSSION:
* Pete Resnick: can you explain what happened in CALEXT?
* Bron: sure - generally positive but want it not to replace 3339, but also
there's complexity so we need to spend some time on it and have the right
people. * Pete: why do you need to know the details for a point in time? *
Bron: maintain context "9am in this calendar system, this day" is different
than just an offset. * Carsten: there is work being presented in CBOR (next)
for this including an information model and extensions beyond RFC3339 and
POSIX.  Need to ensure this is well coordinated. * Ujjwal: happy to coordinate,
let's talk after.

* dkg: (can't get sound)

* Ujjwal (replying to jabber chat) - if UTC offset and IANA label don't match
any more, the UTC offset is supposed to be the source of truth.  The labels can
be used by the client implementation to process additional context, but it's
not necessary to know the exact point in time.  Some implementations might not
even care (e.g. if not doing any localisation or dealing with any humans)

* Harald Alvestrand: question about which key values would be acceptable.
* Ujjwal, would be difficult to add to the set if you need a new RFC every time.
* Harald: would argue that the overhead for new stuff is far too low if you use
this system - people use too much stuff in that namespace without even telling
you how it's supposed to be interpreted.  If you want interoperability, you
don't want it to be too easy. * Dispatch: Harald suggests WG.

* John Klensin: likely needs a WG, involves enough complexity.  Getting a
little worried about a different time problem - ECMA and Java and ISO standards
which are all different.  End up with "the nice thing about standards".

* Ujjwal: idea in ECMA is to match their format to what the IETF does, so there
isn't a need to maintain multiple standards.  ECMA isn't the international
standard, the ISO document is.

* Kirsty (chair): Sounds like there's general agreement that a working group is
what's needed, we will take a final decision on the list and just confirm with
Patrick as co-chair before officially dispatching as such. The link to the
charter is on list too, please take a look and see if you think a BoF is needed
as the next step or a WG can begin right away.

### On Media-Types, Content-Types, and related terminology (20 min)
Presenter: Carsten Bormann
[draft-bormann-core-media-content-type-format](https://datatracker.ietf.org/doc/draft-bormann-core-media-content-type-format/)
[Messages](https://mailarchive.ietf.org/arch/msg/dispatch/LIBX0h4sYR0qMgnrYDoQfVxInSA/)

* Carsten - presenting slides, lots of RFCs use the media type terms, would be
good to have a good reference to point to. * Since this touches just about
everything in ART, decided to bring to DISPATCH since CORE isn't chartered for
this work.

### Discussion

* Mark Nottingham: different places have evolved in different directions. 
Would like to define terminology, but not more. * Carsten: of course we can do
all the things in the documents that use them, but think that defining the ABNF
in one place makes it more reusable. * Mark: would like to break the
terminology out into a separate document.

* Pete Resnick: (oops, I was arguing on Jabber)

* Cullen Jennings: unclear how much you want to clarify terminology.  Don't
think this is ready for dispatch. * Kirsty: what would you like to see? * Two
things - a purely terminology doc BCP-like, and extensions very simple and
crisp - since lots of things need to interoperate with any change we make. *
Carsten: what do you mean by extensions? * Cullen: I don't know, what do YOU
mean? * Carsten: only thing new is content format string * Cullen: that's only
a new name for a thing which already exists? * Carsten: it's something that new
things could also use - it's a general name for things that are extensions. *
Cullen: parts that are terminology vs new are hard to tell which is which. 
Don't think anyone has problems with clarifying terminology, and sometimes
defining a term for things we've been using is good - but that's different from
creating something which provides more information that transfers over the
wire.  Both good to do, but not the same thing.

* John Klensin: this is dangerous to do in a WG or AD sponsored without a clear
charter that says it covers this.  Can't do in CORE.

* Harald: implications of this document are not simple.  Making sure that we
don't add extensions without knowing what we're doing is not simple.  You have
not thought this through, recommend a working group. * Carsten: by saying "this
is not simple" you demonstrate that it's needed, because everything should be
simple.

* Kirsty: the decision we're coming to is there are some questions about scope,
a more clear problem statement would be helpful to revisit this and see what
the work is that you're trying to do - whether a WG is needed or if the
document is a bit more simple. There's general agreement that the work is
useful and we'd like to see the work progress, but first we need a more clear
problem statement and then we can discuss a working group, or see how simple
the doc would be and if it could be AD-sponsored instead. * Kirsty will discuss
with Patrick offline to confirm this dispatch result.

### HTTP content negotiation using profiles (10 min)
Presenter: Lars G. Svensson
[draft-svensson-profiled-representations](https://datatracker.ietf.org/doc/draft-svensson-profiled-representations/)

* Presentation - Ruben Verborgh.
* APIs will tell you that they're doing JSON, but not mention the specific
media type.  If clients code against that, they are making assumptions about
the JSON, i.e. assuming that there's a field called "username". * A solution is
minting very specific content types, but there's value in knowing that it's
JSON, or XML, or... there can be multiple dimensions of assumptions. * Today:
APIs either over-specified or under-specified. * Proposal: help services
indicate what extra constraints they conform to on top of just JSON - and
clients discover what constraints are supported. * Allow clients to request
specific constraints. * Allow clients to send specific constraints. * Reusing
existing RFC - profiles. * Allow clients to keep doing what they are doing and
upgrade.

### DISCUSSION

* Mark Nottingham: wanted this to come to DISPATCH because there's a lot of
unanswered questions about this. * while your usecase is APIs, this seems a
generic negotiation mechanism. * Wondering if there are API
implementers/practitioners who are asking for this? * Worried about overloading
HTTPAPI with this work.

* Chris Lemmons: agree on question: does this work outside of HTTP APIs?

* Timothy Panton: {bad sound}

* Rich Salz: as HTTPAPI co-chair, just figuring out what we're doing, could end
up being HTTPAPI but rather it didn't start right away, already got 5 drafts in
progress, and a group which is half new to the IETF. * Seeemed much more
generic than just APIs. * Kirsty: not hearing any clear idea about what we want
to do next - dispatch result is to continue discussion on the list to find next
steps. * Ruben: also, see it wider than APIs, this is much more generic.

[Patrick Arrives]

## ART AREA Meeting
----------------

### BoFs, updates and meetings of interest - ADs (5 min)

* see slides - lots of interesting things.
* Patrick notes again that the ART AREA of the agenda is sharing of technology,
just for information, not for dispatching.

### APN: Application-aware Networking (20 min)
Presenter: Shuping Peng/Zhenbin Li
[draft-peng-apn-scope-gap-analysis](https://datatracker.ietf.org/doc/draft-peng-apn-scope-gap-analysis)
[Messages](https://mailarchive.ietf.org/arch/browse/apn/)

* Zhenbin Li presenting
* Presenting to dispatch to clarify what APN group does and doesn't do, and
invite those interested to join.

* Ted Hardie: want to know if it's a tuple you want: application plus user, or
if there are groupings that are user specific or application specific that
don't care what user it is. * Zhenbin: application always asks for
authorization from the network, so you always get an ID for the user.

* Kirsty: have to cut discussion here - will take more discussion to list,
thanks for presentation.

### qlog (logging for QUIC, HTTP/3 events and other protocols) (20 min)
Presenter: Robin Marx
[draft-marx-qlog-main-schema](https://datatracker.ietf.org/doc/draft-marx-qlog-main-schema/)
[draft-marx-qlog-event-definitions-quic-h3](https://datatracker.ietf.org/doc/draft-marx-qlog-event-definitions-quic-h3/)
[Tools](https://qvis.quictools.info)
[Messages](https://mailarchive.ietf.org/arch/msg/dispatch/oGFtO7Zypgt_EgpzMu0ZOr7tpUE/)

* Robin presenting
* Used to be able to use Wireshark to track traffic, but it's harder with QUIC.
 Similar issues with encrypted APIs. * Idea: have a format to allow both ends
to log in a standard format so it's easy to process. * Have built tooling for
tracking packets at both ends. * most stacks support it

### DISCUSSION

* Phillip Hallam-Baker: want to encrypt my log files.  Using QLOG for payload,
but encryption whole thing.  Incremental encryption.

* Mark Nottingham: wondering what having a standard brings to the table?  This
is done in an ad-hoc or open-source way often.  Looks like you already have
good market share.  Wonder if this has some of the same properties of an API.

* Benjamin Schwartz: think we've lost a tradition.  IETF used to standardise
more file formats.  Seems like we've gotten out of the habit. * Will be
important to work out the edges of your standards domain - allow non-standard
information to be mixed in. * Robin: this is why we're using JSON - easy to add
new keys.

* Daniel Gillmor: Think there is value in standarising this - we've done APIs
and file formats in the past.  There's obvious interoperability value here. 
The process is a place for implementers to think clearly about the impact
(including privacy concerns) - identify which fields are more sensitive. 
Recommend data retention and destruction policies.  Recommend you don't log
this stuff unless you need it.  Scared about automatic retention of gigabytes
of log data.  Worth discussing best practices. * Kirsty: thank you for the
comments, the chat says this is interesting work - so this is a FYI to the
group, please continue the discussion and get involved going forward using the
links Robin provided.

### SDP Mapping into HTTP structured headers (10 min)
Presenter: James Gruessing
[draft-gruessing-sdp-http](https://datatracker.ietf.org/doc/draft-gruessing-sdp-http/)
[Messages](https://mailarchive.ietf.org/arch/msg/dispatch/a79ROoMZPrrYMKhLc6Ss_mfOjaA/)

* James Gruessing presenting
* DISPATCHING: jabber suggests WISH, not HTTPAPI.

* Eric Rescorla: seems like two things here.  Not persuaded that headers are
needed, structured format is good.  If you need to put it in a header, just
base 64 it. * Kirsty: continue lively discussions on list, thanks to James for
taking the time to come and present your work here today.

### SIP Extensions for High Availability and Load Balancing for Public Cloud 
(10 min) Presenter: Jonathan Rosenberg
[draft-rosenberg-dispatch-cloudsip](https://datatracker.ietf.org/doc/draft-rosenberg-dispatch-cloudsip/)

* Jonathan Rosenberg presenting

### DISCUSSION:

* none... no, wait
* Jonathan Lennox: how much needs to support this?
* A: upstream and downstream need to support it - assume downstream UA is under
same admin control as the system that runs the cluster. * Kirsty: will continue
discussion on list, thanks.

### AOB

## Summary:

* datetime needs a short-term WG, probably a BoF is not needed as it's not
controversial - will confirm on list.

* media types - simple document, but not as simple as we would hope.  Think WG
is needed, definitely not AD-sponsored as it's too complex. Will discuss
tighter scoping of the problem on list, result of that might be a BOF.

* negotiation work - sounds HTTPAPI-destined and more discussion on list
required to confirm this.

## AD notes

Murray Kucherawy: want to thank Barry for his work and for helping new ADs.

Barry Leiba: Thanks Murray and thanks everybody for your support, have enjoyed
working with you.  Will continue to be WG chair and etc.  Thanks.

Many more thanks in the jabber.