Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"

Julien,

On 24/05/17 12:08 , Julien Meuric wrote:
> 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 - ppsenak@cisco.com:
>> 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.

my point is that if people were implementing this, they would figure the 
missing IANA allocations.

regards,
Peter

>
>>
>> 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 - acee@cisco.com:
>>>> 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 <ospf-bounces@ietf.org <mailto:ospf-bounces@ietf.org>> on
>>>> behalf of Acee Lindem <acee@cisco.com <mailto:acee@cisco.com>>
>>>> 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
>>> OSPF@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ospf
>>> .
>>>
>>
> .
>