Re: [spring] Proposed policy on reporting implementation and interoperability

[Ketan Talaulikar <[e-mail]>]

Hi Robert,

Indeed, writing implementation reports for architecture documents (which is
what we mostly do in SPRING WG) is more challenging than protocol specs.
This was my point as well. For an operator, considering a solution
deployment, perhaps the implementation report for the protocol spec is as
important (if not more) than the architecture.

Coming to your question, we can consider RFC8667 which has several
TLVs/sub-TLVs for different segment-type advertisements. For example,
features like SRMS or Mirror SID are optional, but should one implement
their support, they would need to deal with some MUST clauses specific to
those advertisements and their processing.

Thanks,
Ketan


On Fri, Aug 19, 2022 at 9:18 PM Robert Raszuk <[e-mail]> wrote:

> Thx Ketan.
>
> Yes indeed but this is an architecture document ... In such type of
> documents it is hard to imagine an implementation report. You implement
> protocol specification not an architecture.
>
> I was more curious how many protocol extension RFCs say from IDR or LSR
> WGs have such "issue".
>
> Thx,
> R.
>
> On Fri, Aug 19, 2022 at 5:43 PM Ketan Talaulikar <[e-mail]>
> wrote:
>
>> Hi Robert,
>>
>> Let us consider RFC8402 which has a whole bunch of MUST clauses. An
>> implementation may choose not to support IGP Anycast Segment. The spec does
>> not say that any of the Segments are mandatory for SR. However, there are
>> some MUST clauses to follow should implementation support it.
>>
>> I hope that clarifies.
>>
>> Thanks,
>> Ketan
>>
>>
>> On Fri, Aug 19, 2022 at 9:01 PM Robert Raszuk <[e-mail]> wrote:
>>
>>> Hi Joel,
>>>
>>> Would you mind providing a few such examples of reality in the published
>>> standard track RFCs coming via Routing Area ?
>>>
>>> Many thx,
>>> Robert
>>>
>>>
>>>
>>> On Fri, Aug 19, 2022 at 5:23 PM Joel Halpern <[e-mail]>
>>> wrote:
>>>
>>>> While what you propose may be cleaner, what Ketan asked about is a
>>>> common practice.  So it seems useful to recognize that reality.
>>>>
>>>> Yours,
>>>>
>>>> Joel
>>>> On 8/19/2022 10:58 AM, Robert Raszuk wrote:
>>>>
>>>> Joel,
>>>>
>>>>> I would be interested in hearing from the WG on this.  My expectations
>>>>> is that if someone says they implement optional feature X, and X has MUSTs
>>>>> conditioned on it, then they have to explain whether they comply with those
>>>>> MUSTs.
>>>>>
>>>> When I look at BCP-14 or RFC2119 I do not see any distinction for
>>>> categorizing MUSTs into main MUSTs or MUSTs under optional features.
>>>>
>>>>
>>>> *1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
>>>>    definition is an absolute requirement of the specification.*
>>>>
>>>> While technically sound I am not even sure if any optional feature can
>>>> have any mandatory MUSTs which apply only when someone chooses to
>>>> implement such a feature.
>>>>
>>>> In such cases IMO it would be much cleaner to just separate those
>>>> features into separate documents and still MUST be a top level normative
>>>> clause.
>>>>
>>>> Many thx,
>>>> R.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>