Subject: Re: [netmod] Y45 - imports

From: Randy Presuhn <[email-masked]>
Date: Mon, 23 Mar 2015 17:24:20 -0700 (GMT-07:00)

Hi -

>From: Ladislav Lhotka <[email-masked]>
>Sent: Mar 23, 2015 4:31 PM
>To: Randy Presuhn <[email-masked]>
>Cc: NETMOD Working Group <[email-masked]>
>Subject: Re: [netmod] Y45 - imports
>
>
>> On 23 Mar 2015, at 18:06, Randy Presuhn <[email-masked]> wrote:
>> 
>> Hi -
>> 
>>> From: Ladislav Lhotka <[email-masked]>
>>> Sent: Mar 23, 2015 3:37 PM
>>> To: Andy Bierman <[email-masked]>
>>> Cc: NETMOD Working Group <[email-masked]>
>>> Subject: Re: [netmod] Y45 - imports
>> ...
>>>> The best match revision may be different from server to server.
>>>> Even within 1 server, the best match can change from 1 day
>>>> to the next.
>>> 
>>> No, the revision is fixed by the importing module, ideally form
>>> the revision-date. It doesn’t differ from server to server, and
>>> server implementors should use that revision.
>> 
>> I think the presumes an unrealistic level of omniscience on the
>> part of the designers / implementors of the importing code.
>
>I don’t think so. The developer of the importing module must have
>used a particular revision of the imported module, and this revision
>should be clear from the importing module.

Not really, if the importing module doesn't specify a specific
revision.  Under the proposed rules, the latest version prior
to the date of the importer would be used.  What seems vague
about the proposal is that it doesn't make clear that there's
a strong assumption that the developer of the importing module
*must* somehow know that the version they've imported is in
fact the most recent one.

>All users of the importing module have to use that revision.

This makes it a hard requirement for all implementators to
have access to a guaranteed up-to-date repository of all
potentially importable definitions.

...
>> Consider this case:
>>  - a series of dates, D1..D5
>>  - ImporterA[D2], ImporterB[D5]
>>  - Imported[D1], Imported[D3], Imported[D4]
>
>I assume that if module A imports revision D2,

Sorry, I was unclear.  The context of the discussion
was imports which did not specify a revision.
By the notation ImporterA[D2] I meant to
indicate that the *date* of A was D2.

> then D2 has to be used whenever (that particular revision)
> of module A is used. Using Di for i!=2 means that typedefs
> or groupings may be different from those that the author of
> A used - and this is IMO unacceptable and can lead to
> interoperability problems.

Agreed, but that's not the scenario I was trying to describe.
I think the issue is still real: the specifier of ImporterB,
time-stamped D5, could potentially have missed the new version
of Imported created at D4.  It's a classic race condition.

>I think that making sure all existing revisions of a module are
> available is not that difficult (although it is not the case for
> the existing GitHub repository).

For *all* vendors?

Randy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 24 Mar 2015 11:31:47 -0500

> On 23 Mar 2015, at 19:24, Randy Presuhn <[email-masked]> wrote:
> 
> Hi -
> 

This assumption is acceptable for IETF models, I agree it can be more difficult in other cases. So the moral of the story is to always use explicit revisions, and my proposed rule is just a fallback for modules that don’t do that. I think that rule is better than having the revision undefined.

> potentially importable definitions.

Yes, but the alternative is to admit that the data models used on the client and server side may be different, or require that groupings and typedefs essentially don’t change from one revision to another.

>> the existing GitHub repository).

Vendors who want to contribute reliable data models should be able to do that, otherwise things may break.

Lada

> 
> Randy
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C