Hi Les, > it is quite permissible to restrict the meaning of a given term
Yes you are correct. It sure is. But I just do not get why we are coming with counter intuitive terms in key specifications. Kind regards, R. On Wed, Jul 13, 2022 at 11:07 PM Les Ginsberg (ginsberg) <[email protected]> wrote: > Robert – > > > > I have replied to Shraddha’s post – pointing out that there is an explicit > definition of “application” in the documents. > > > > I have nothing more to add in response to your comments other than to > reemphasize that it is quite permissible to restrict the meaning of a given > term when used in the scope of a document so long as we have a clear > definition – which we do. > > > > Les > > > > > > > > *From:* Robert Raszuk <[email protected]> > *Sent:* Wednesday, July 13, 2022 12:25 AM > *To:* Shraddha Hegde <[email protected]> > *Cc:* Les Ginsberg (ginsberg) <[email protected]>; [email protected] > *Subject:* Re: [Lsr] New Version Notification for > draft-ginsberg-lsr-rfc8919bis-01.txt > > > > Hello, > > > > Yes I very much support Shraddha's msg. > > > > The term "application" should not even be (re)defined up front, but > completely removed from the document. Likewise ASLA should be renamed too. > I thought we had the agreement in subsequent documents to do so. Why not > fix it across the board ? > > > > If we look at the dictionary: > > > https://dictionary.cambridge.org/dictionary/english/application > > > > I do not see any definition which would even closely fit the real use case > for this term here. Application is a computer program not a network > forwarding/protection mechanism like RSVP-TE, SRv6, LFA etc ... > > > > If someone who is writing real applications - say ticker forwarder - and > he takes such RFC she or he will be super confused and will start expecting > his application to have its own bit to be identified directly in the ASLA > bit mask. > > > > Thx, > > R. > > > > On Wed, Jul 13, 2022 at 7:52 AM Shraddha Hegde <shraddha= > [email protected]> wrote: > > Authors, > > Thanks for the bis version of RFC 8919 and the clarifying text on errata. > The issues raised with respect to the errata have been addressed well in > the bis version. > However, I believe that the bis version is also an opportunity for us to > address any other ambiguities and clarifications and not just restrict it > to > the raised errata. RFC 8919 is going to serve as base document for many > future applications /attributes and a clear definition and documentation > is necessary for interoperable implementations as well as for future > evolution of the protocol. > > I have below comments on the document > > 1. The definition of what constitutes an application in the scope of this > document is not > clearly defined in the document. Currently RSVP,SR-TE, LFA, Flex-algo > have been defined > so it appears that any application that uses TE attributes can be > defined as a separate application. > The TE mechanisms like RSVP, SR-TE and flex-algo have been defined > as separate applications > and it appears features having significantly different > forwarding plane is defined as new application. It is not clear if > SRv6 would be > qualified as a new application. > LFA for different forwarding planes such as IP, MPLS, SRv6 are not > separate applications > but LFA is defined as a single application. > I have also seen many drafts confusing application specific to be > user application. > I suggest to add a section and describe what is an application > clearly in the draft that should provide > sufficient input on what can be defined as an application from > ASLA context in future. > > > 2. " When SABM or UDABM Length is non-zero and the L-flag is NOT set, all > applications specified in the bit mask MUST use the link attribute > advertisements in the sub-TLV." > Applications such as RSVP, SR-TE, LFA already use legacy > advertisements. > This document suggests that if any attribute is advertised with an > application bit set in ASLA > ASLA advertisements MUST be used by that application. > Implementations may support ASLA for only some applications. > I suggest to add below text. > > Until all nodes upgraded to support ASLA for a particular application, > different values of link attributes > MUST NOT be advertised for that application in legacy advertisement and > ASLA advertisements. > > > Rgds > Shraddha > > > Juniper Business Use Only > > -----Original Message----- > From: Lsr <[email protected]> On Behalf Of Les Ginsberg (ginsberg) > Sent: Tuesday, June 21, 2022 8:59 AM > To: [email protected] > Subject: [Lsr] FW: New Version Notification for > draft-ginsberg-lsr-rfc8919bis-01.txt > > [External Email. Be cautious of content] > > > Folks - > > Please note V01 of the RFC8919bis draft has been posted. > > This version incorporates comments received from Bruno. > > Les > > -----Original Message----- > From: [email protected] <[email protected]> > Sent: Monday, June 20, 2022 8:22 PM > To: John Drake <[email protected]>; Les Ginsberg (ginsberg) < > [email protected]>; Peter Psenak (ppsenak) <[email protected]>; Stefano > Previdi <[email protected]>; Wim Henderickx <[email protected]> > Subject: New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt > > > A new version of I-D, draft-ginsberg-lsr-rfc8919bis-01.txt > has been successfully submitted by Les Ginsberg and posted to the IETF > repository. > > Name: draft-ginsberg-lsr-rfc8919bis > Revision: 01 > Title: IS-IS Application-Specific Link Attributes > Document date: 2022-06-20 > Group: Individual Submission > Pages: 25 > URL: > https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ginsberg-lsr-rfc8919bis-01.txt__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlB5e_NMk$ > <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ginsberg-lsr-rfc8919bis-01.txt__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlB5e_NMk$> > Status: > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ginsberg-lsr-rfc8919bis/__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlMHc2Gn4$ > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ginsberg-lsr-rfc8919bis/__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlMHc2Gn4$> > Html: > https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ginsberg-lsr-rfc8919bis-01.html__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlABYFZnP$ > <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ginsberg-lsr-rfc8919bis-01.html__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlABYFZnP$> > Htmlized: > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ginsberg-lsr-rfc8919bis__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlJxHVgye$ > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ginsberg-lsr-rfc8919bis__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlJxHVgye$> > Diff: > https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-ginsberg-lsr-rfc8919bis-01__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlEG5hZVF$ > <https://urldefense.com/v3/__https:/www.ietf.org/rfcdiff?url2=draft-ginsberg-lsr-rfc8919bis-01__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlEG5hZVF$> > > Abstract: > Existing traffic-engineering-related link attribute advertisements > have been defined and are used in RSVP-TE deployments. Since the > original RSVP-TE use case was defined, additional applications (e.g., > Segment Routing Policy and Loop-Free Alternates) that also make use > of the link attribute advertisements have been defined. In cases > where multiple applications wish to make use of these link > attributes, the current advertisements do not support application- > specific values for a given attribute, nor do they support indication > of which applications are using the advertised value for a given > link. This document introduces new link attribute advertisements > that address both of these shortcomings. > > This document obsoletes RFC 8919. > > > > > The IETF Secretariat > > > _______________________________________________ > Lsr mailing list > [email protected] > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlGfn5wMH$ > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlGfn5wMH$> > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
