Hey Ketan, Ok so take RFC8667 as example. Let's assume implementation of SID/Label Binding TLV is optional (is it really :) ?
So yes it has few MUSTs there ... but those MUSTs apply to protocol encoding in the context of this TLV. And no implementation can cherry pick to implement some MUSTs in this TLV and not the others. So I am really confused on Joel's point. Implementation report should here focus on which TLVs or sub-TLVs are implemented .. never dive into which MUSTs of given TLVs/sub-TLVs got implemented. Many thx, Robert On Fri, Aug 19, 2022 at 5:56 PM Ketan Talaulikar <ketant.i...@gmail.com> wrote: > 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 <rob...@raszuk.net> 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 <ketant.i...@gmail.com> >> 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 <rob...@raszuk.net> 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 <j...@joelhalpern.com> >>>> 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. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
