Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25

[Robert Raszuk <[e-mail]>]

Hi Jeff,

I would like to just highlight one IMHO very cool property hidden in yr
note ... If we would use URL to carry a pointer to the information the URL
can be shortened to be a fixed length of a few characters which could be
really easy to process and presented  to users in a pretty uniformed way
across any receiver.

Thx.
R./



On Tue, Jan 10, 2023 at 11:22 PM Jeffrey Haas <[e-mail]> wrote:

> Donatas,
>
>
> On Jan 10, 2023, at 2:26 PM, Donatas Abraitis <
> [e-mail]> wrote:
>
> I'm proposing to be something like this:
> identifier = product ["/" product-version]
>
>
> Roughly the right idea, but your examples probably don't quite hit the
> level of specificity that you're looking for.  For example, Juniper has
> different products that ship as a given version number and may vary
> slightly by platform.
>
> There's some level of desire to have something that's easy to parse so you
> can more readily scrape things for comparison.  E.g., "what versions are
> all of my juniper model X boxes running?".
>
> Prior messages in this thread touched on URI or URL to cover the
> information.  Frankly, if you pointed to a given URL, that can be the
> location for more interesting structured data.  Examples of this sort of
> thing these days exists in "software bills of materials" (SBOM).  Here's a
> breadcrumb to an Internet-draft working on this area of technology.  You'll
> note that the current ISE, Elliot Lear, is one of the authors there.  I
> suspect he'd be happy to discuss this problem with you.
>
> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-sbom-access
>
> Focusing on your updated -10:
> - IANA Considerations: you have an unchanged use of capability here.
> - You have a start to unicode related gotchas in the draft.  Please take a
> look at RFC 9003 for text we've found useful in the past when talking about
> this stuff in BGP-land.
> - I'd strongly suggest making this feature require RFC 9072.
>
> -- Jeff
>
>
>
> Inline diff:
> https://author-tools.ietf.org/iddiff?url1=draft-abraitis-bgp-version-capability-09&url2=draft-abraitis-bgp-version-capability-10&difftype=--hwdiff
>
> On Tue, Jan 10, 2023 at 9:21 PM Robert Raszuk <[e-mail]> wrote:
>
>>
>> I am not worried about sender side ... much more the receiver side.
>>
>> First it is unrealistic that receiver will keep up and recognize zoo of
>> BGP code bases. So if you choose to segment available space it still needs
>> to be free form with some boundaries.
>>
>> Thx,
>> R.
>>
>>
>>
>>
>> On Tue, Jan 10, 2023 at 6:16 PM Donatas Abraitis <
>> [e-mail]> wrote:
>>
>>> >While nice for the sender may not be easy on the receiver. I would
>>> rather not hint on any formatting here if you choose not to make it as part
>>> of the spec.
>>> I'm thinking about something like HTTP User-Agent, e.g.: frrouting/8.2,
>>> ios/12.0.1, junos/..., etc. What do you think?
>>>
>>> This message and its attachments may contain privileged and confidential
>>> information. If you are not the intended recipient, do not use, copy, or
>>> disclose this information. Please notify the sender and permanently delete
>>> the message from your system.
>>
>>
>
> --
>
> *Donatas Abraitis*
> *Principal Systems Engineer*
> @: [e-mail]
> W: www.hostinger.com
>
>
> This message and its attachments may contain privileged and confidential
> information. If you are not the intended recipient, do not use, copy, or
> disclose this information. Please notify the sender and permanently delete
> the message from your system.
>
>
>