Bluesheets:

1. Martin Duke (Google)
2. Will Law (Akamai)
3. Alan Frindell (Meta)
4. Ian Swett (Google)
5. Victor Vasiliev (Google)
6. Mathis Engelbart (TUM)
7. Cullen Jennings (Cisco)
8. Dinesh Adhithya (Zoho)
9. Sebastain Rust (Technical University Darmstadt)
10. Suhas Nandakumar (Cisco)

Scribe (Will)

Alan - Objectives - Chairs and Editors have triaged issues, many need
PRs. Want to cut draft in two weeks. Please take look. Will send note to
list to remind.

Alan - Hybrid interim - set agenda ahead for last. Need to fix fetch at
next interim. What do we need to do to make the successfull

Suhas - I have an alt fetch proposal.

Victor - I was meant to write a PR for fetch.
Alan - want to hear proposals for fetch , and have at least a week in
advance.

Will - what about slides?

Martin - one pager, or slides, or well written PR would be fine.

Cullen - slides would be most effective.

Alan - need to define problem.

Will - should define what "fetch" means. Fetch is a solution.

Ian - saying same thing. Only obvious issues are flow control, back
pressure, if you request 1GB of old data, what happens? I think we have
solved most of old fetch issues. need for fetch is different.

Victor - defining loss is difficult.

Ian - missing objects are important. When are they needed.

Suhas - in last meeting, group wanted separation between fetch and
subscribe.

Alan - we need alignment on the problem to be solved.

Will - pose problem as an issue

Victor - PR is a better way forward.

Suhas - i can work with Victor to make one slide to define problem.

Martin - assigned Suhas to define issue.

Will - there are several camps, should have particpants from each.

Suhas - I can keep it broad and not only focused on RT media.

Alan - assign Suhas will synthesize problem statement as a new issue.
You can make a new document, or an issue, whatever is easier for you.
Slides are fine too. We can comment on those. Then will issue call for
proposals for Boston.

Suhas - will reach out to few folks who have been active.

Alan - one week deadline ?

Suhas - will try.

**Ian issue #508 - Do we need a track name? **

Alan - Wildcard subscribe is a different problem. You don't know what
will match. How does track alias work across wildcards?

Will - we could use subscribe ID and track ID together, with
server-seelcted trackID.

Ian - can we punt wildcard to later as it adds complexity?

Alan - let's collapse, but not address wildcard for now.

Ian - anyone not supporting? No replies.

Alan - in future, if ANNOUNCE announces N tuples and subscribe contains
an N-tuple.

Will - annoucne the min prefix of your tracks

Cullen, if I annoucne a,b,c, any subscribe that matches that prefix goes
to that publisher.

Alan - current draft does not solve the problem of people annoucing the
same thing.

Cullen - just care that we don't have holes in our subscribes.

Alan - speak up if you want holes? No advocates. What happens if two
subscribes goes to two different publishers? My relay says last announce
wins.

Suhas - we should allow annoucing same names. Subscribe should be
forwarded to both.

Cullen - we should nto allow two objects with the same name and
different data. Problem with last wins, coordinating who is last across
distributed set is a difficult problem.

Alan - let's agree on behavior now for duplicate announces. Topday
annouces contains 1 - tuple, name has 2-tuple. What happens when
subscribe matches more than one announce?

Cullen - we should address at next interim.

Will - volunteered to write slides for interim.

Issue #517 - changing priproties underdefined?

Victor - arrival or delivery of an object can affect the priority of
every other object in a subscription. proposal - make pub priority apply
to individual peeps instead of having a time varying single priority per
track. i.e. subscriber priority > publisher priority > group ordering.

Cullen - I dont understand. Please redescribe.

Victor - re-described. You can assign different pub priority in atrack
to different peeps.

Martin - current process is doable but clunky and inefficient. Every
time a new peep arrives with a lower priroity arrives, re-orders
priority of other streams. Sect 4 - priority is min of pending objects.

Cullen - core problem was deciding what to send next. Not sounding like
what we agreed too.

Alan - do you need some book-keeping anyway? Need similar data
structure.

Victor - for subscriber priority it is easier. For publisher, you need
two passes to update pending streams.

Suhas - no comment. Can we please rename it? I like subgroup.

Martin - this can be a sidebar at the interim. Any objections to a PR in
this space of changing priorities. Will Victor write a PR related to

517?

Time up. Have a good day everyone.