On Tue, Dec 22, 2015 at 7:24 AM, Nadeau Thomas <[email protected]> wrote:
> > > On Dec 22, 2015:10:23 AM, at 10:23 AM, Ladislav Lhotka <[email protected]> > wrote: > > > > > >> On 22 Dec 2015, at 16:06, Juergen Schoenwaelder < > [email protected]> wrote: > >> > >> On Tue, Dec 22, 2015 at 11:34:41AM +0100, Ladislav Lhotka wrote: > >>> > >>>> On 22 Dec 2015, at 11:06, Juergen Schoenwaelder < > [email protected]> wrote: > >>>> > >>>> On Mon, Dec 21, 2015 at 08:09:13PM +0100, Ladislav Lhotka wrote: > >>>>> > >>>>>> > >>>>>> That's why the definition what 'published' means in the IETF is in > the > >>>>>> guidelines document. On the other hand, since this is an IETF > >>>>>> document, I also do not find it problematic to define IETF rules > >>>>>> here. Others should be able to skip over this. There are really more > >>>>>> important problems to solve. > >>>>> > >>>>> It is not clear at all from sec. 10 that data modellers outside IETF > may skip over this. I am not even sure that everybody in this WG agrees > with your interpretation. > >>>>> > >>>> > >>>> You are wrong. > >>>> > >>>> - Section 10 in RFC 6020 applies to all published modules. > >>> > >>> The bullets specifying the rules are introduced with this sentence: > >>> > >>> 'A definition may be revised in any of the following ways:' > >>> > >>> so IMO it is intended to apply to *all* modules. Are you saying that > it actually means > >>> > >>> 'A definition in a module published by IETF may be revised in any of > the following ways:'? > >>> > >> > >> A definition in a published module may be revised [...] > >> > >>>> - The definition of what turns a module into a published module is > >>>> specific to the different organizations publishing modules. > >>> > >>> So it means that such an organization may also decide to ignore the > rules entirely or replace them with its own rules. > >>> > >> > >> No. > >> > >>> If the WG can agree on this and make the corresponding changes in sec. > 11 of 6020bis, then I have no more objections. > >> > >> The rules are there to ensure interoperability. Interoperability is an > >> issue for published modules (but not for modules under development). > > > > This doesn't make much sense unless you give an objective definition of > "published". For example, are proprietary modules (developed by vendors) > ever published? > > And that is the point I made the other day. Simply saying that > definition is The IETF’s > definition forms a rather circular argument. > > Each SDO may have its own definition of work-in-progress vs published-for-use. It doesn't seem that hard to figure out without help from the IETF. > —Tom > Andy > > > > > >> The IETF certainly has a history to care about interoperability. I > >> expect that other organizations care about interoperability as well. > > > > That's their business. > > > > Lada > > > >> > >> /js > >> > >> -- > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >> Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
