Hi Bruno, We are still waiting to hear whether or not you are in favor of adopting this document.
One might infer your intentions, but the chairs need it to be explicit. Regards, Tony > On Nov 22, 2023, at 5:37 AM, bruno.decra...@orange.com wrote: > > Hi authors, > > Please find below some specific comments on the document. > > Thank you for the effort put in the IANA section. (to indicate wo which > (sub-) TLV MPL applies to). > > §1 > “However, this has not been done for many legacy TLVs, leaving the situation > somewhat ambiguous.” > To me the current situation is not ambiguous. The behavior is defined in the > spec/RFC. If a behavior is not defined, then it’ is not specified and not > allowed. > Please rephrase. > -- > “The intent of this document is to clarify and codify the situation by > explicitly making multiple occurences of a TLV the mechanism for scaling TLV > contents, except where otherwise explicitly stated.” > Similar comment. :s/clarify/specify > > -- > “The mechanism described in this document has not been documented for all > TLVs previously” > Similar comment. > :s/documented/specified > > -- > OLD: so it is likely that some implementations would not interoperate > correctly if these mechanisms were used without caution. > NEW: so non compliant implementations would not interoperate correctly with > compliant implementations > (alternatively, that part could be just removed) > > -- > “The mechanism described in this document has been used explicitly by some > implementations, so this document is not creating an unprecedented mechanism.” > Proprietary non-compliant implementations are not an excuse for RFC. > If you need an introduction, you could to the existing TLV specified with MP. > (but since this is already stated at the beginning of this section IMO we can > just remove that part) > > -- > > §4.1 > “It is RECOMMENDED that the link identifiers be the first sub-TLVs.” > > For my information, why is so? > As currently formulated implementations MUST support any order > What the benefit of the ordering given that implementations MUST parse all > sub-TLVs? > > -- > §4.1 > > “Optionally one or more of the following identifiers:” > […] > “The key information MUST be replicated identically.” > Do you mean that all identifiers MUST be replicated? > If so, could you please make this point even more explicit e.g., “(i.e., > with all identifiers”) > > -- > 5. Procedure for Receiving Multi-part TLVs > > “If the internals of the TLV contain key information, then replication of the > key information should be taken to indicate that subsequent data MUST be > processed as if the subsequent data were concatenated after a single copy of > the key information.” > > Given that this section is the key normative part, I’m not found of the > “should”. I would suggest :s/should be/is (but “MUST” also works for me) > -- > §6 > “The lack of explicit indication of applicability of Multi-Part TLV > procedures to all codepoints to which such procedures could be applied > contributes to potential interoperability problems if/when the need arises to > advertise more than 255 bytes of information for such a codepoint.” > Same comment. If it’s not specified in the existing RFC this is not > supported/compliant. This is not a “lack of indication of applicability”. > > -- > “This document makes explicit the applicability of Multi-Part TLV procedures > for all existing codepoints” > :s/makes explicit/specify > > -- > §7.2 MP-TLV Capability Advertisement > > “It is presumed that if such support is provided that it applies to all > relevant TLVs. It is understood that in reality, a given implementation might > limit MP-TLV support to particular TLVs based on the needs of the deployment > scenarios in which it is used.” > > Let’s not presume anything. Let’s specify it. And we need to specify a clear > meaning for the capability, otherwise it has limited value. > My preference would be that the meaning is “supports MP-TLV” for TLV x, y, z. > (or all TLVs). Alternatively, the value would carry the list of TLV > supporting MP-TLV (more complex but since it seems that no implementation > will act on the content that seems easy to implement). Alternatively, if > there is no clear meaning, let’s not bother with the capability. > > Thanks, > Regards, > --Bruno > > > Orange Restricted > From: DECRAENE Bruno INNOV/NET > Sent: Tuesday, November 21, 2023 1:51 PM > To: 'Yingzhen Qu' <yingzhen.i...@gmail.com <mailto:yingzhen.i...@gmail.com>>; > draft-pkaneria-lsr-multi-...@ietf.org > <mailto:draft-pkaneria-lsr-multi-...@ietf.org> > Cc: lsr <lsr@ietf.org <mailto:lsr@ietf.org>> > Subject: RE: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv > (11/17/2023 - 12/09/2023) > > Hi all, > > > I have some concerns with regards to the deployment of this extension in > brownfield multi-vendor networks as this could result in the formation of > persistent forwarding loops. > > As a constructive proposal, and as mitigations, I would like the document be > improved with the following changes: > a) Sending MUST be controlled by configuration [1] > b) For existing TLVs (and “any level of sub-TLVs”), details the TLV which > could be advertised with no risks for the network and TLVs which must not be > advertised before all nodes be upgraded. > c) Given this document typically may require global support before this > be enabled, I think this draft would be a good candidate for the addition of > the relevant yang module as per draft-qgp-lsr-isis-pics-yang [3]. I > personally don’t see a problem with adding a normative reference to an > individual draft, but if I’m wrong, an option for the chairs to consider > would be to pause this adoption call and start an adoption call for > draft-qgp-lsr-isis-pics-yang. > > Some of those comments are not new and have already been expressed on this > list [2] > > I would welcome the feedback of authors on the above proposals before the end > of this WG adoption call. > > Thanks, > Regards > Bruno > > [1] > OLD: It is RECOMMENDED that implementations which support the sending of > MP-TLVs provide configuration controls to enable/disable generation of > MP-TLVs. > NEW: It is REQUIRED that implementations which support the sending of MP-TLVs > provide configuration controls to enable/disable generation of MP-TLVs. > > [2] https://mailarchive.ietf.org/arch/msg/lsr/WIxRR2ZlOJHjxulfXP6Z8nZtKeU/ > > [3] https://datatracker.ietf.org/doc/html/draft-qgp-lsr-isis-pics-yang > > From: Lsr <lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>> On Behalf Of > Yingzhen Qu > Sent: Friday, November 17, 2023 6:24 PM > To: draft-pkaneria-lsr-multi-...@ietf.org > <mailto:draft-pkaneria-lsr-multi-...@ietf.org>; lsr <lsr@ietf.org > <mailto:lsr@ietf.org>> > Subject: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - > 12/09/2023) > > Hi, > > This begins a WG adoption call for draft-pkaneria-lsr-multi-tlv: > draft-pkaneria-lsr-multi-tlv-04 - Multi-part TLVs in IS-IS (ietf.org) > <https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/> > > Please send your support or objection to the list before December 9th, 2023. > An extra week is allowed for the US Thanksgiving holiday. > > Thanks, > Yingzhen > > Orange Restricted > ____________________________________________________________________________________________________________ > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you.
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
