Re: [babel] Murray Kucherawy's No Objection on draft-ietf-babel-source-specific-07: (with COMMENT)

[Toke Høiland-Jørgensen <[e-mail]>]

Murray Kucherawy via Datatracker <[e-mail]> writes:

> Murray Kucherawy has entered the following ballot position for
> draft-ietf-babel-source-specific-07: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-babel-source-specific/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> What's an example of when one might deviate from the SHOULD in Section
> 4?

Only thing I can think of is that if someone already implemented a
disambiguation like that suggested in the second bullet, and the
underlying platform then adds native support, one could conceivably
continue using the disambiguation instead of switching to the native
support.

The Linux kernel is an example of this: in ancient times there was no
native support for source-specific routing, but it was possible to use
the generic policy routing mechanism to achieve this. When the native
support was added, it came with a new UAPI, so a routing daemon would
have to change to support it, while the old policy-based way would still
work. Or maybe an implementation wants to support ancient kernels with
the same code and keeps using the policy-routing based way; it would
likely be somewhat painful, but in principle I suppose it could work.

-Toke