Thanks to our minute taker: Christian Amsüss

current document is draft-protocol-greasing  
collaboration welcome, Dave Thaler offered to join as co-author  
Discussed steps of:

*   Revising document based on feedback (adding Dave)
*   Sending out for community input prior to IAB adoption
*   Formally adopt by IAB

Lucas P summarized the current document

*   GREASE does TLS grease. Once 1-3 instances, we have a pattern. What
    can we extract? Own view focused on QUIC (not just code point --
    varying sizes, sequences).
*   Is it just interop testing? (?)
*   Things you can do / "do this"

QA:

HH: from dev perspective, hard to find out related RFCs, test data, etc.

Tommy P: What we do here is distilling advice to std authors. Gaps
beyond that, please point out.

HH: Look at not only short-term interop but also long-term, like what do
we have in 5y. For example, calendaring has organizing an event -- sends
EMail; migrating that data on the long run importing somewhere might
send new mails.  
TP: Kind of discussion is in scope. 9413 is good to read.

DKG: Super useful, also for reviewers not just authors. Have concrete
questions to ask for reviewers on new questions. Codepoints, grammar,
message sequencing. We should explicitly ask this, and ask explicitly
what interop has been done, and describe what good interop tests look
like. Had good experience in PGP but found issues from ages ago. Pull in
"running code" aspect.  
TP: Want to see this folded in here or parallel? How do we promote them?
Tooling issue, startup cost.  
DKG: Like startup cost in test-driven-development. Related to API work
-- can't do interop testing w/o functional API work.

Dhruv D: To HH. There was a document for finding related impl.
(https://datatracker.ietf.org/doc/draft-eckel-edm-find-code/) We can add
features in data tracker and discuss it in tools team meetings. Even
those meetings are open!

Dave T: Recapping from IETF117 why I'm involved. Two other IAB track
docs relevant: 8170 (planning for protocol adoption and transitions)
9170 (long term usability). This is another one in that series.  
DT: On technical side, this is currently just about preventing receiver
and middle boxes from crashing. Great, but should be wider scope. If all
you do is drop, nothing crashes, but nothing is gained. Should receiver
detect/log lack of grease?  
DT: Follow-up on that: If you can detect it, should you have feedback to
sender (did the greasing make it through)? Right now, silent on that --
should discuss.  
Lucas P responding: We have protocol extensions that allow talking to
intermediaries when they may drop things. How is the circle drawn around
"greasing should be ignored" and "should be acted on"?  
DT: Example was applying greasing to things like IPv6 extension headers
-- what could we have done? That's what I'm volunteering to contribute
text on.

Gorry F: We do APIs in some places. We should do it. Measuring, MAPRT
needs to be considered. See whether tests we do go through. Does GREASE
obfuscate or exercise that? What can visible GREASE do for MAP?

Brian Trammell: Also raised hand for "We don't do APIs" statement.
Similar to GF statement. Fuzzing \[...\]. What we do is similar to
protocol fuzzing -- it's fuzzing the dynamic system made by the
protocol. There's literature on that. \[...\]  
TP: Please send refrences.

Christopher Wood: PPM also spent some time on APIs helping with interop
(test runner interfaces, complicated but necessary). Link to come.  
CW: Is "we don't do APIs" still heard?  
(room): Not here.  
DT: I used to say that, sometimes still do. When v6 group wanted new
socket APIs -- we did an informational RFC because C sockets API is
POSIX thing, they do that. JavaScript APIs are owned by W3C, C++ APIs
are owned by ISO, etc. IETF won't do standards for languages. But we do
do abstract APIs. Like TAPS, and like GSS-API. Appropriate other bodies
can do language-specific bindings.

TP asking for clarification on DT's feedback loop proposal. For QUIC,
there are cases w/ E2E acknowledgement, so we know explicitly. In
discussion, distinguish where there is implicit acknowledgement and when
not (IP, HTTP), categorize.  
TP: Point out that it may be onerous to do the latter, not for everyone
(?).  
DT: Please review what

CA: Working on grease-for-edhoc. Thx for all this.  
TP: What do you take from here, what would you have done anyway?  
CA: Would have done ACK'ed codepoint ext's anyway. Keeping track of
things that fail the process completely would be curious.

LP: On interop testing. It only goes so far. \[...\]. It's about
concrete features / exchanges. Fan of interop, but does it fit in here
(is it part of the E, D or M?)  
LP: Exists RTP-over-QUIC which is great. Wanted to define error code
points w/ registry. Error space 0..2^62, use 0..5 items. Suggestion:
Grease there. \[...\] Terminology for it helps too (QUIC doesn't say
GREASE anywhere).  
TP: Let's have the suggested term (GREASE or any term) that's in
registries, and allow docs to point to this.

LP: CJ made points on being unconvinced that wide set of code points was
needed when small set works too. Can we pick at that?  
LP: Extension points have varying code space. How little is enough for
humungous space.  
Cullen J: Might be naive. If application is trying to actively ignore
grease -- those who want to do that can do this with a range anyway.
Against that, you won't win. Reserving a few or 25%, the range size
doesn't matter. Didn't find it convincing.

DKG: It's open question of whether reserved code points make sense --
because of that very risk. I hear CJ's concern as an example of this.  
LP: If not reserved, people unintentionally use points in ignored range.

CA jumping in: It's a sign of GREASE working. Hitting the range makes it
visible that someone is actively ignoring something rather than
automatically ignoring unknowns.

GF: Greasing at transport or higher is more straightforward than
greasing at network layer, which is more complicated with more issues to
think about.

Wes Hardaker: We've always have done APIs, but low-level stuff. In early
days to get draft interop was required. Had giant tables of impls vs
bits. Any part not interop tested was encouraged to drop things. \[...\]

TP: Needs to be >1 because 1 point is easily ignored. Could do some
analysis, eg. based on frequency of GREASE being sent, that could
influence amount of things reserved, and whether to reserve. E.g., for
HTTP headers, reserving strings doesn't make much sense.  
LP: In QUIC we allocate in a pattern \[...\]

David S: "Do something random" might collide w/ something that is in
use, and you might have sent garbage in security field. On the other end
of the spectrum, having every odd code grease achieves nothing. We need
this doc because it *is* subtle.  
DS: Looked at new protocols, encouraged doing GREASEing, and went back
and forth a lot giving interactive guidance. This will not help with
determined implementer that wants to single out GREASE, while silly
implementors can always do silly things.

Ali Rezaki: After GREASE work is over, plan to wrap the programme.  
TP: Potentially -- unless something comes up.  
AR: Connection w/ sustainability. Looked at that? Whatever this does to
add longevity to protocols also helps there.  
TP: Both are IAB programmes; good to bring up \[...\]. Anything concrete
in mind? Sharing with both list?  
DS: What makes IAB programmes and WGs sucessful is tight scope. For
items are between both it's fine.  
MK: We have the programmes b/w IAB wants input from experts, but the
input winds up in the IAB anyway.

*[DT]: Dave Thaler


*[HH]: Hans-Jörg Happel


*[TP]: Tommy Pauly


*[DkG]: Daniel Gillmor


*[DD]: Dhruv Dhody


*[GF]: Gorry Fairhust


*[CJ]: Cullen Jennings


*[LP]: Lucas Pardue