We aren't talking generically about TLV space here. When I raised the question I certainly intended it to be limited to times, as is the case here, where we are literally duplicating registries b/c they both refer to the same thing. I didn't realize that we'd already done this with SR IGP Algorithm registry.
I did also include talking about what (if anything) to do with the duplicated containing TLV, but it seems no one wants to go there, which is fine, and I happen to agree probably is going too far. Thanks, Chris. > On May 21, 2018, at 11:11 AM, Acee Lindem (acee) <[email protected]> wrote: > > Hi Peter, Chris, > > In this particular case, it may be ok as long as we just limit the code point > space to the 1 octet type (i.e., 0-255 with reserved values). However, for > all the reasons Peter and Les have already articulated, there will be cases > where the TLV or Sub-TLV registries cannot be common. So, I have to ask > myself just what are we gaining by here? The encodings are not going to be > identical (for all the previously mentioned reasons) and this leaves the door > open for time wasted on revisiting this issue... > > Thanks, > Acee > > On 5/20/18, 9:21 AM, "Peter Psenak (ppsenak)" <[email protected]> wrote: > > Chris, > > On 20/05/18 01:47 , Christian Hopps wrote: >> How about an option 2c >> >> 2c: Leave the encodings the way they are, and use a common registry to >> define the type/value semantics. > > having a combined registry that defines FAD Sub-TLVs types is fine with me. > > thanks, > Peter > > >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
