Christian Hopps <cho...@chopps.org> writes: > Ladislav Lhotka <lho...@nic.cz> writes: > >> On Tue, 2018-02-27 at 09:31 +0100, Juergen Schoenwaelder wrote: >>> On Mon, Feb 26, 2018 at 04:09:21PM +0100, Martin Bjorklund wrote: >>> > Hi, >>> > >>> > Christian Hopps <cho...@chopps.org> wrote: >>> > > >>> > > Hi Rob, >>> > > >>> > > You do realize that no-one trying to actually deploy and run networks >>> > > cares about live-discovery of different schema per datastore for the >>> > > same mount point right? Like 99.999% of the clients know where things >>> > > are supposed to reside and expect them to be there. >>> > >>> > But then why advertise anything at all? We can do a *much* simpler >>> > solution by just having the mountpoint extension, and nothing else. >>> > Clients will know what to find anyway. >>> > >>> >>> So it this a possible way out of the current situation? We publish a >>> trimmed down document that just defines the mount point extension and >>> we do an update of this document that adds all the details needed to >>> obtain the schema information? >> >> I would say so. It would be immediately usable for the inline case. > > This still requires that we pull the routing NI work from the RFC ED > queue, change normative text (the document specifically states that > use-schema MUST be present, although it does mention that that may be > relaxed in the future) as well as the examples listing the > schema/modules, this is going to require at least another run through > WGLC. It's slightly less obnoxious than the original proposal as its > simply removing stuff and losing functionality vs. changing > functionality.
As I already said, a reasonable alternative for me would be to proceed with -08 and then do the YLbis and other changes as independent work. This way, we could also hope in some feedback from NI/LNE implementation. Lada > > Thanks, > Chris. > >> Lada >> >>> >>> /js >>> > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
