Hi Peter, Please be aware that my comment applies beyond the scope of this single I-D.
Talking about this one, see [JM] below. Thanks, Julien May. 24, 2017 - [email protected]: > Julien, > > - I don't know if there is any implementation that uses the solution > proposed in RFC 4203. I sent a query to the WG list and so far I have > not heard about a single one. [JM] I have seen, but we cannot use an unanswered 2-week poll on the OSPF list as if it were an RFC deprecating section 3 of RFC 4203. > > - there is not even IANA registry created for the Sub-TLVs of the Link > Local TLVs and there is no IANA value reserved for Link Local Identifier > TLV as defined in RFC4203. [JM] You are right: there may be a hole in IANA's registry, probably missed during publication process. But the RFC is clear: "The only TLV defined here is the Link Local Identifier TLV, with Type 1". Only the request for registry creation was missed, which could be very easily fixed. > > So at the end we may not even have any duplication at all. > > regards, > Peter > > On 24/05/17 10:54 , Julien Meuric wrote: >> Hi Acee, >> >> There is indeed overwhelming support on the feature. However, reading >> this brand new -01 (thanks for the advertisement) and the necessary >> backward compatibility section it had to include, I wonder if this I-D >> is specifying a solution to a problem vs. creating new issues... >> >> More generally, we should clarify how much we, as community, are ready >> to duplicate protocol extensions/codepoints on a solely "repurposing" >> basis. If there is a risk of redefining all extensions originally >> specified for the TE use-case, we must right now discuss where to >> globally draw the line between what we may accept and what we will not. >> Otherwise, we will jump onto a controversy each time a new parameter set >> is tackled in a dedicated I-D. >> >> Please note there are some other ways forward in the Routing area. For >> (random) example, PCEP has been repurposed from a its original scope to >> encompass capabilities to push state. To do so, some features and >> objects had to be repurposed, but the specification managed to reuse the >> original ones, avoiding any backward compatibility considerations... >> >> Regards, >> >> Julien >> >> >> May. 23, 2017 - [email protected]: >>> The WG adoption poll has concluded and there is overwhelming support >>> for this document. >>> >>> Additionally, >>> https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-01.txt >>> addresses >>> the comments received the adoption poll. >>> >>> Authors, >>> >>> Please republish the document as >>> draft-ietf-ospf-lls-interface-id-00.txt. >>> >>> Thanks, >>> Acee >>> >>> From: OSPF <[email protected] <mailto:[email protected]>> on >>> behalf of Acee Lindem <[email protected] <mailto:[email protected]>> >>> Date: Thursday, May 4, 2017 at 2:45 PM >>> >>> >>> This draft was presented in Chicago and there was acknowledgment >>> that a solution was needed. The authors have asked for WG adoption >>> and we are now doing a WG adoption poll. Please indicate your >>> support or objection by May 20th, 2017. >>> >>> Thanks, >>> Acee >>> >>> >> >> _______________________________________________ >> OSPF mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ospf >> . >> > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
