> On 08 Mar 2016, at 16:20, Acee Lindem (acee) <a...@cisco.com> wrote: > > > > On 3/8/16, 6:35 AM, "Ladislav Lhotka" <lho...@nic.cz> wrote: > >> >>> On 08 Mar 2016, at 12:08, Acee Lindem (acee) <a...@cisco.com> wrote: >>> >>> >>> >>> On 3/8/16, 1:55 AM, "Martin Bjorklund" <m...@tail-f.com> wrote: >>> >>>> Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> wrote: >>>>> On Tue, Mar 08, 2016 at 01:23:50AM +0000, Acee Lindem (acee) wrote: >>>>>> >>>>>> The thing about the static route definition for IPv4 and IPv6 is that >>>>> their RIBs will have pretty much the same structure other than >>>>> differences in address type. For other AFs, there may be other >>>>> differences as well. For every augmentation, we’re essentially >>>>> doubling >>>>> the specification effort. >>>>>> >>>>> >>>>> One benefit of having separate augmentations is that the data types >>>>> are tighter. For example, the data model does not allow an IPv6 next >>>>> hop for an IPv4 prefix, i.e., you can't mess up address families since >>>>> the data model forces a clear separation (and generic validation will >>>>> catch that in contrast to having the runtime catching inconsistent >>>>> address family data). >>>>> >>>>> How much that matters likely can be debated. But somehow it feels like >>>>> keeping things separate allows for independent evolution, which may >>>>> proof to be very handy in the future. I kind of liked Lada's approach >>>>> to maintain the architectural separation in the data model. >>>> >>>> I agree. I think the model is more clear this way. I guess I don't >>>> understand why Acee wants to have a single module? >>> >>> I was trying to eliminate the effort of updating both modules with the >>> exact same augmentations. However, I guess I’m ready to relent on this >>> point. >> >> OK, thanks. Do we want to post another revision before IETF 95? If so, we >> should probably do most preparations this week because I will be on >> vacation next week. > > I think we should at least try and get the structural changes posted > before IETF 95. We can meet on next hops at IETF 95.
OK, so let's do it. Thanks, Lada > > Thanks, > Acee > > > >> >> Lada >> >>> >>> >>> Thanks, >>> Acee >>> >>> >>> >>>> >>>> >>>> /martin >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod