Hi Ketan, > 2) IPR disclosure #4044 (Arista Networks, submitted 5 March 2020, patents > US15945038 and US16752245, "Dynamic Flooding for Link State Protocols, > Computation Of Network Flooding Topologies") > > The licensing declaration is conditioned throughout on adoption > as a standard: "If technology in this document is included in a standard > adopted by IETF ..." and "If this standard is adopted, Arista will not > assert ...". An Experimental RFC is not a standard. I am not offering a > reading of what that implies for implementers of this document; I am noting > that the condition is there, and that it interacts with the experimental > status. Whether it is worth pursuing is for the WG to decide. Given the > response about discussion related to IPR in the shepherd report Q12, I > would have expected that there is specific polling of the WG in this > regards and perhaps this is brought to the attention of the IPR holder if > they wish to update their disclosure. This not being published as a standard > would have implications for any implementers of this document and therefore > the WG chairs and the responsible AD should double check if this is all > good.
This issue has been raised with Arista. As I am no longer associated with them, I can do nothing further. > Please find below some further comments on this document inline in the idnits > output of v04. Lookout for the <EoRv04> tag at the end to ensure you are > seeing > the full review. > > 30 We are not currently proposing that this algorithm be standardized, > 31 nor that the working group use this as a basis for further > 32 standardization work, however we have no objections if the working > 33 group chooses to do so. This document is published as an > 34 Experimental RFC to gain operational and implementation experience > 35 with the specified dynamic flooding algorithm. The intent is to > 36 assess the suitability of this algorithm for advancement to the > 37 Standards Track as a Proposed Standard, pending sufficient deployment > 38 experience and feedback from the community. > > <major> This entire paragraph should be removed from the Abstract. > > It contradicts itself. The first two sentences say the algorithm is not being > proposed for standardization and that the WG is not being asked to use it as a > basis for standardization work; the last two say the intent is to assess its > suitability for advancement to Proposed Standard. This is not contradictory. It is simple, accurate truth. I’m sorry you have a problem with it, but I do not understand your objection. The text is clear. It is not currently being proposed for PS. It may be in the future. > Also, RFC 9667 is itself Experimental and is this document's only normative > reference, and the algorithm's output is usable only through the RFC 9667 > centralized mode encodings. Advancing this document to Proposed Standard while > RFC 9667 remains Experimental would produce a Standards Track document whose > entire operational basis is Experimental. We are not asking for PS at this time. > This paragraph can be simply dropped from the abstract. The experimental > character of the work belongs in the Abstract as an adjective on the proposal > itself rather than as a paragraph about status and future advancement - for > example, describing it as an experimental algorithm for obtaining a sparse > subgraph from a dense graph, which a centralized Area Leader can use to > compute a flooding topology for dynamic flooding. I disagree. It is important to record where we are and where we are going. Agreement on this was necessary to make progress in the WG. > The same advancement narrative then needs to come out of Section 1.1, which > frames the experiment as a step prior to considering the algorithm for > advancement to the Standards Track, and out of Section 1.1.2, which frames its > list as criteria for advancement to Proposed Standard. The substance of both > sections can stay - what goes is the claim about a future status change. > Section 1.1.2 reads better as what would count as a successful experiment than > as a set of promotion criteria. > > 100 1. It should include all nodes in the area. This ensures that LSPs > 101 can reach all nodes. Section 1.1.2 says that the document will be considered for advancement if the criteria are met. These are necessary conditions, not sufficient conditions. The WG could still dislike some newly discovered arbitrary issue, for example. > <minor> s/all nodes in the area/all reachable nodes in the area Ok, this makes the second sentence superfluous, so I’ve removed it. > 241 1. It covers all nodes in the area. Fixed > 262 Together with the encoding scheme in [RFC9667], this algorithm can be > 263 used to implement centralized dynamic flooding. The area leader can > 264 build the base graph from its link-state database (LSDB), apply this > 265 algorithm to compute the flooding topology, and then encode it into > 266 the IS-IS Flooding Path TLV or OSPF Flooding Path TLV defined by > 267 [RFC9667], depending on the protocol. In a topology change event, > 268 the area leader can repeat the above process and send out the new > 269 flooding topology. > > <minor> The Flooding Path TLV carries indices rather than node identifiers, so > the Area Node IDs TLV in IS-IS, or the Area Router IDs TLV in OSPF, has to be > advertised as well. > > s/encode it into the IS-IS Flooding Path TLV or OSPF Flooding Path TLV defined > by [RFC9667]/encode it into the IS-IS Area Node IDs TLV and IS-IS Flooding > Path > TLV, or the OSPF Area Router IDs TLV and OSPF Flooding Path TLV, defined by > [RFC9667] Fixed, with a few more articles. > 292 We propose to select a starting node and then search a path that ends > 293 at this node. We suggest selecting the node with the highest degree > 294 as the starting node. The degree of each node can be easily > 295 determined when the base graph is constructed from the LSDB. > > <major-editorial> The document is written in the first person throughout - in > the Abstract and in every section from Section 1 through Section 5 - for the > authors' own proposals, intentions and choices: what we propose, what we > suggest, what our aim is, what we do not intend to do, what we may select. In > a > paper presented by its authors that reads naturally. In a product of an IETF > working group it is ambiguous, because the reader cannot tell whether a given > "we" is the two authors, the LSR WG, or an implementation following the > algorithm, and those three carry very different weight. > > The lines above are the sharpest case. "We propose to select a starting node" > and "We suggest selecting the node with the highest degree" are describing > what > an implementation of this algorithm actually does, which is the one reading > that "we" cannot carry. > > Please recast in the impersonal, or in terms of the actor. Where the sentence > describes the algorithm, name the algorithm or the Area Leader - "the node > with > the highest degree is selected as the starting node", or "the Area Leader > selects ...". Where it describes a design decision, attribute it to the > document - "this document does not attempt to find the theoretically optimal > solution". This needs a pass over the whole document rather than a list of > instances, so I am pointing out this one example only. I have made a pass through the document and resolved the cases that I think were an issue. I disagree with your position. I do not find impersonal writing to somehow be better. Rather, it makes it drier and more difficult to consume while adding no value to the actual description. I also question whether such style issues are the purview of the IESG. Isn’t that the RFC editor’s job? Regards, Tony _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
