Chairs: Kevin J. Ma, Chris Lemmons and Sanjay Mishra
IETF 120 Agenda: https://datatracker.ietf.org/meeting/120/agenda
Tuesday, 23rd July 2024, 13:00-15:00 US/Canada Pacific Day Time, Room:
Plaza A, 2nd floor, Hyatt Regency Vancouver
Francesca: Christoph: please answer the ADs reviews (even if no change)
when you can, that helps me track everything and make sure everything is
addressed.
Christoph: Ok.
Francesca: I don't have a strong opinon here, but IANA registries are
cheap. The registry is a cleaner solution here.
Ben: I'd be interested in learning more about that.
Chris: (No Hats) I'll commit to reviewing the new changes.
Sanjay: What do you mean by "should we reference it directly" on the
slide about the PatternMatch object?
Alfonso: We're using the same definition as in RFC 8006. Kevin Ma's
comment was that we should not be redefining the same structure in
multiple places. So the question is "should we reference the
PatternMatch object in RFC 8006.
Sanjay: I agree that you should reference RFC 8006.
Sanjay: So you're going to take it to the list?
Alfonso: Yes, we're going to discuss the organization of the example on
the list.
Sanjay: For now, you can leave it as is in your doc.
Glenn: When we show the Cache Control metadata doc, the way we've put
the example in the doc that does nothing more than shows the basic
object. But at the end of the doc, we have a lot more involved examples.
Pankaj: Regarding Kevin's thoughts on the list, the long term intent is
to not just provide the KeepAlive, but also other things, like Packet
Pacing. We've kept it simple with just this one for now, but it's
expected to expand in the future. Not everyone needs this object. That's
why it's optional.
Chris: I suggest you align your language with what is used in the HTTP
Semantics document: RFC 9110
Chris: The MEL reference is a downreference to an SVTA doc. That's going
to be a problem.
Glenn: We can switch that to a reference to the I-D.
Chris: Yes, that's appropriate and represents the dependency you are
defining here. That does mean this document can't progress unless and
until the MEL draft is adopted.
(Lots of back and forth between Chris and Pankaj about his feedback on
the doc.)
Sanjay: Please respond back on the list.
Sanjay: Clarifying question on the picture (Slide 9). I see references
to a number of other documents here, are they dependencies?
Alan: No, they are just examples.
Francesca to discuss with the IETF legal and share the response
Arnon not present. Can be discussed on the mailing list