Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\))
Content-Type: text/plain;
	charset=us-ascii
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <516805330.145119.1761676288544@www.getmymail.co.uk>
Date: Tue, 28 Oct 2025 14:44:46 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <6E66C6C7-405F-4868-8DD2-728210283F00@pfrc.org>
References: <5BDA83D4-D934-4253-A6FD-65C1FDE1ED37@pfrc.org>
 <516805330.145119.1761676288544@www.getmymail.co.uk>
To: Adrian Farrel <adrian@olddog.co.uk>
Message-ID-Hash: UJPNL6VEWKL6TN5SQAM4YAENJFGQKTZ6
CC: idr <idr@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5BIdr=5D_Re=3A_IETF_124_-_non-IDR_presentations_of_interest?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/idr/0Ht7GVSI8P07AmSG0dIc4qEb51A>

Adrian,


> On Oct 28, 2025, at 2:31 PM, Adrian Farrel <adrian@olddog.co.uk> =
wrote:
>=20
> Hi Jeff,
> =20
> > =
https://datatracker.ietf.org/meeting/124/materials/agenda-124-cats-01
> >
> > - Distribution of Service Metadata in BGP FlowSpec. The material =
discusses blending flowspec, the metadata draft (which will have an =
update in cats as well), coloring mechanisms, and new path attributes.
> >
> >I didn't think cats was yet chartered to work on protocol extensions.
> =20
> It isn't, and seems unlikely ever to be unless:
> - there is a need for a totally new protocol
> - another WG wants to give away control of its protocol (which seems =
unlikely with IDR!)

I agree that we'll not want to give away such control specifically for =
CATS use cases.  Speaking for the usual joke, I suspect the DNS folk =
similarly wouldn't be interested. =20

> But, as the CATS Framework approaches last call, and as clarity is =
emerging on what the CATS metrics are, we are taking some time out to =
hear abput proposals being floated in other WGs that may be applicable =
to CATS.
> =20
> As cochair of CATS I am conscious that a balance is needed. CATS may =
need to show interest for a protocol WG to invest time, but it is =
important that "I presented in CATS" is not used as a false =
justification.
> =20
> This comment applies to any and all protocol drafts and is not =
specific to this I-D.

Thanks for the current status.  My goal for highlighting the CATS agenda =
point was to draw early attention to this discussion.

The existing work on the 5g metadata draft already highlighted a number =
of places where it was a "lumpy fit" for traditional BGP.  Discussion on =
that document raised points about how it's a limited domain solution, =
had interesting security considerations in terms of confining the new =
path attribute to that domain, and its impacts on BGP route selection =
and forwarding consistency. =20

Many of those points are likely to be general to the CATS work.

If CATS has reached the point where "does this fit into existing =
protocols" is the conversation point, I'd suggest soliciting specific =
talks about how CATS requirements and the protocol under consideration's =
defined behaviors are likely to interact.  In my opinion, it's much =
better to have those "lumpy fit" discussions more under the auspice of =
CATS requirements than seeing what can be pushed into the protocol of =
the day.=20

-- Jeff