Subject: Re: [netmod] import by revision

From: Carl Moberg <[email-masked]>
Date: Fri, 1 Jun 2012 12:51:59 +0200

We use import by revision in the CableLabs CCAP project.

On May 31, 2012, at 23:00 PM, Martin Bjorklund wrote:

> Hi,
> 
> I think I agree with you.  I have never seen import by revision being
> used.  include by revision, however, is used, and useful.
> 
> Note that RFC 6087 says:
> 
>   The revision-date substatement within the imports statement SHOULD be
>   present if any groupings are used from the external module.
> 
> 
> 
> /martin
> 
> 
> 
> Andy Bierman <[email-masked]> wrote:
>> Hi,
>> 
>> I think the use-case for import-by-revision in sec. 5.1.1 is
>> really vague and the example is not clear.
>> 
>>   When the author of "a" publishes a new revision, the changes may not
>>   be acceptable to the author of "b".  If the new revision is
>>   acceptable, the author of "b" can republish with an updated revision
>>   in the "import" statement.
>> 
>> 
>> This is wrong.  Why wouldn't the changes to module "a" be acceptable
>> if the author follows the update rules in section 10?
>> 
>> The import exact revision rule is too fragile and does not match
>> any real use cases:
>> 
>>   7.1.5.1.  The import's revision-date Statement
>> 
>>       The import's "revision-date" statement is used to specify the exact
>>       version of the module to import.  The "revision-date" statement MUST
>>        match the most recent "revision" statement in the imported module.
>> 
>> The most common and important use case is to require "version>= X", not "version == X".
>> I know this can cause optional nodes to suddenly appear in expanded uses-stmts,
>> but this is actually a feature (reusing multiple versions of a complex type in
>> the same data model is a bad idea).
>> 
>> The relevant revision date is the one that the client or other data model starts
>> relying on the presence of a particular definition.  After that point, since
>> only legal changes are being made, the client or other data model can upgrade
>> to a new version without breaking anything.
>> 
>> 
>> Andy
>> 
>> 
>> _______________________________________________
>> netmod mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netmod
>> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

--
Carl Moberg, Tail-f Systems
mailto:[email-masked]
twitter: @cmoberg
http://www.tail-f.com/

---

From: Andy Bierman <[email-masked]>
Date: Fri, 01 Jun 2012 05:53:10 -0700

>   We use import by revision in the CableLabs CCAP project.

Do you have a use-case or you just wanted to make the
module as fragile as possible?

Do you really expect that when you update the imported module,
following the change rules in RFC 6020, that the importing module
will break?  Do you anticipate the need to change the imported
module in such a way that it would break the other module?

My point is that import exact version X is fragile because the
server has to advertise multiple versions of the same module
in order to upgrade module X for new objects, and still have
the exact version some import-by-revision module expects.

This is completely broken from a conformance POV.
2 versions of the same module implies 2 separate conformances
for the module -- which 1 does the client trust?  Which conformance
applies to which objects?   What if the new version obsoletes
an object?  Is the object implemented or not?

Import yb revision is broken because YANG conformance is broken.

Andy

>> Andy Bierman<[email-masked]>  wrote:
>>> Hi,
>>>

---

From: Carl Moberg <[email-masked]>
Date: Fri, 1 Jun 2012 15:03:35 +0200

> module as fragile as possible?

 Well, the expectation is that a specific (as published by CableLabs) version CCAP module imports well known revisions of modules from other sources so that the combination YANG modules as a whole is strictly defined. When the CCAP version is updated it's up to the editor(s) to update the import revisions if needed.

> module in such a way that it would break the other module?

 I (with CCAP module editor hat on) don't expect to update any imported module.

> the exact version some import-by-revision module expects.

 I (with CCAP module editor hat on) think that the "model stability/precision" provided by import by revision is beneficial for the consumers of the service (CCAP-specific client library developers, etc).

> an object?  Is the object implemented or not?

 I (still same hat) wouldn't expect several versions of the modules directly related to (as imported by revision) the CCAP module.

---

From: Andy Bierman <[email-masked]>
Date: Fri, 01 Jun 2012 06:29:23 -0700

> On Jun 1, 2012, at 14:53 PM, Andy Bierman wrote:

You seem to be saying that you will republish both the
importing and imported modules at the same time
if that is needed.  You control what goes into
a new version, and you can make sure every import of module X
in your system is an import-by-revision identifying the same revision.

The problems show up when you don't have publication control
over the imported module or every module in the system that
also happens to import module X.  Then the server can advertise
multiple versions of the same module in its <hello>.

The module capabilities are not a deterministic snapshot of
the data model a server is expected to support.  There are
lots of corner-cases, but 1 of the most obvious:

    - module A contains top-level typedefs intended for module A and some mandatory objects
    - module B is written later and needs the typedefs, so it imports A to reuse the data types.
    - platform acme-1000 needs to implement module B, but its <hello> says it also implements
      module A

Andy

---

From: Carl Moberg <[email-masked]>
Date: Fri, 1 Jun 2012 15:41:38 +0200

> in your system is an import-by-revision identifying the same revision.

 CableLabs will update the YANG module lock-step with their standard editorial cycle. At the point of publication the editors of the CCAP YANG module will decide if they want to import newer revisions of e.g. ietf-yang-types or if they want to stay with the existing revision.

> multiple versions of the same module in its <hello>.

 Agreed. It will be a design decision for the person responsible for the complete set of YANG modules exposed by the device.

>   - platform acme-1000 needs to implement module B, but its <hello> says it also implements

 All good observations of that it is indeed possible to make things very complicated with yang imports.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 01 Jun 2012 11:30:49 -0400

Andy, you seem to have mixed what is probably an accurate conclusion 
with some very misleading questions.
I would hope that the in designing a module (either one that imports 
others or one that is to be imported) that one does not ahve to figure 
out the answer to the question "what changes are likely in the future". 
  the answer has to be "any changes that are permitted by the standards 
are likely", as any other answer is just asking for trouble.

Yours,
Joel

---

From: <[email-masked]>
Date: Mon, 4 Jun 2012 11:44:35 +0100

Carl,

Your approach may be OK if the products are to be managed by a bespoke
client. But what is a system comprising many products needs to be
managed by a single management system? It would be far better not to
have to worry about specific revisions of imported modules to support
different products, but to know that, because of the rules relating to
updating modules, the latest will work fine with all.

Jonathan

> -----Original Message-----
> From: Carl Moberg [mailto:[email-masked]]
> Sent: 01 June 2012 14:42
> To: Andy Bierman
> Cc: [email-masked]
> Subject: Re: [netmod] import by revision
> 
> 
>  CableLabs will update the YANG module lock-step with their standard
> editorial cycle. At the point of publication the editors of the CCAP
YANG
> module will decide if they want to import newer revisions of e.g.
ietf-
> yang-types or if they want to stay with the existing revision.
> 
>  Agreed. It will be a design decision for the person responsible for
the
> complete set of YANG modules exposed by the device.
> 
> >   - module A contains top-level typedefs intended for module A and
some
> mandatory objects
> >   - module B is written later and needs the typedefs, so it imports
A to
> reuse the data types.
> >   - platform acme-1000 needs to implement module B, but its <hello>
says
> it also implements
> >     module A
> 
>  All good observations of that it is indeed possible to make things
very
> complicated with yang imports.
> 
> >
> >
> > Andy
> >
> >
> >
> >
> >
> >
> >
> >>  Well, the expectation is that a specific (as published by
CableLabs)
> version CCAP module imports well known revisions of modules from other
> sources so that the combination YANG modules as a whole is strictly
> defined. When the CCAP version is updated it's up to the editor(s) to
> update the import revisions if needed.
> >>
> >>  I (with CCAP module editor hat on) don't expect to update any
imported
> module.
> >>  I (with CCAP module editor hat on) think that the "model
> stability/precision" provided by import by revision is beneficial for
the
> consumers of the service (CCAP-specific client library developers,
etc).
> >>  I (still same hat) wouldn't expect several versions of the modules
> directly related to (as imported by revision) the CCAP module.
> >>
> >>>>>   The revision-date substatement within the imports statement
SHOULD
> be
> >>>>>>   When the author of "a" publishes a new revision, the changes
may
> not
> >>>>>>       The import's "revision-date" statement is used to specify
the
> exact
> >>>>>>        match the most recent "revision" statement in the
imported
> module.
> >>>>>>
> >>>>>> The most common and important use case is to require "version>=
X",
> not "version == X".
> >>>>>> I know this can cause optional nodes to suddenly appear in
expanded
> uses-stmts,
> >>>>>> The relevant revision date is the one that the client or other
data
> model starts
> >>>>>> only legal changes are being made, the client or other data
model
> can upgrade

This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics United Kingdom Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus-free and the company does not accept liability or responsibility for such matters or the consequences thereof. General Dynamics United Kingdom Limited, Registered Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and Wales No: 1911653.

---

From: Carl Moberg <[email-masked]>
Date: Mon, 4 Jun 2012 13:21:17 +0200

Jonathan,

 Right, and in my experience, the requirements driving the design of the models will vary a lot across application areas and standards writing organizations. In the case of CableLabs and the CCAP specification there are well defined use cases, step by step, that describes the expected behavior of the system. This comes "before" the data model and obviously puts various requirements on it's design. This reflects the assumption that the clients will be "bespoke" if you wish, for the MSOs to manage cable modem terminating systems and not much else. There's even good reasons for the MSOs tool people/client developers to try and influence the module design to be as specific as possible since it will make their life easier. The decision to use import by revision was taken with all this in mind. I'm sure there are other environments where other requirements would have the module authors not import by revision.

---

From: Andy Bierman <[email-masked]>
Date: Mon, 04 Jun 2012 08:15:23 -0700

> updating modules, the latest will work fine with all.

Obviously a single-purpose embedded device is much more
likely to have a single naming authority than a large embedded
system or an open system.

I didn't say a server must not advertise 2 revisions of a module.
Actually the server should advertise all the modules it uses
directly or indirectly through imports.

The YANG module capabilities sent in the NETCONF <hello>
attempt to serve 2 functions, neither of which is does all that well:

  1) schema tree
      - each main module name, XML namespace, and revision date
        allows the client to identify the module to find (from the local
        modules it already knows about).
      - If <get-schema> is supported the client can guess .yang, and then .yin,
        and get the main module from the server.
     - if submodules are used, the client will either have them locally or use
<get-schema> as needed (by parsing all the main modules to find include-stmts).
       Submodules are not advertised in the NETCONF <hello>.

2) conformance
     - the features and deviations are patched into the exact modules/revisions
       the server advertised to determine all the supported data objects

Both are incomplete, and conflict with each other.  Doing (1) correctly
is likely to claim conformance to modules just imported for meta-data, not objects.
Doing (2) correctly is likely to leave out modules needed to build the schema tree.

Andy

---

From: Jernej Tuljak <[email-masked]>
Date: Tue, 05 Jun 2012 10:11:50 +0200

> directly or indirectly through imports.

But why would a server advertise both revisions if, in your words, only 
legal changes to the module were made. It makes no sense to do this and 
it's only confusing for the client. I think is unacceptable for a server 
to send such a hello message as it may lead to a world of pain.

> Doing (2) correctly is likely to leave out modules needed to build the 

If a hello message is a nondeterministic snapshot of the data model 
which a server supports then it is useless to a generic client. And if 
we add not using import by revision to the whole thing.... Consider this:
1. some modules on server use ietf-yang-types
2. a new typedef is added to ietf-yang-types and a new revision is published
3. a new module on server uses the new type
4. server advertises both revisions of ietf-yang-types and all the other 
modules
5. client decides to load the older revision of the two since import 
without revision is nondeterministic
6. new module fails client-side validation because a type is undefined

And what if the imported module defines a schema tree and both revisions 
of it are advertised? RCF6020 clearly states in 5.1.2. that top-level 
nodes of YANG modules are to be encoded as child XML elements in any 
order within NETCONF payloads. Thus a schema cannot be defined which 
could be used to validate XML content based on two modules which define 
the same top-level statements within the same namespace because it 
cannot be determined which element is to be matched against which YANG 
module top-level statement.

If this is what one might expect then hello messages don't just serve 
their purpose poorly, they too are broken. What good is a contract 
between two parties if they can both interpret it the way they please?

I think all of this would be fixed if revision-date in import statements 
would be used as the minimal required version and if servers would only 
be allowed to advertise a single revision of a module at a time plus 
some kind of a promise that no two modules are advertised by the server 
within the same namespace which also define top-level statements named 
the same way.

> Andy
Jernej

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 05 Jun 2012 10:31:44 +0200 (CEST)

Hi,

A server should not advertise a module unless it implements the
module's schema tree, rpcs, and notifications (*).  There is no reason
for advertising a module for its typedefs, groupings etc.

Now, suppose module A imports module T, which only contains typedefs.
T is imported w/o import-by-revision.  The server advertises A.  How
does the client know which version of T is used by the server?  (Note
that this is the situation with MIBs).  The client can check the
/netconf-state/schemas list for the complete list of modules used by
the server, including submodules etc and find T.

If A imports T by revision, the client knows exactly which version of
T A used.

(*) Modulo features.  You might think that this is a too coarse
conformance mechanism.  Maybe we need something more fine-grained.
But this is really an orthogonal problem.

/martin

---

From: Jernej Tuljak <[email-masked]>
Date: Tue, 05 Jun 2012 11:26:01 +0200

> But this is really an orthogonal problem.
I think a client should always know exactly what is implemented on a 
server regardless of whether ietf-netconf-monitoring is implemented on 
either side. Especially if this has bearing on XML payloads that may be 
sent between it and the server (and typedefs sure do). One should never 
assume that clients are to be implemented by the same people who 
implemented the server nor that the client has a static implementation 
which was known before hand. For generic clients which must resolve such 
problems dynamically on the fly - form payloads based on loaded modules 
- it is vital to know everything AND to be informed properly without 
confusing information. The current mechanism does not provide this 
unless certain conditions are met as observed by our examples.

As I said before, I wouldn't mind import by minimal revision in a 
combination with not allowing servers to advertise incompatible schema 
trees.

Why do both confd and netconfd advertise non-schema tree modules such as 
ietf-inet-types out of the box if there is no reason to do this? :)

Jernej

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 05 Jun 2012 13:25:33 +0200 (CEST)

Jernej Tuljak <[email-masked]> wrote:
> I think a client should always know exactly what is implemented on a server
> regardless of whether ietf-netconf-monitoring is implemented on either
> side. Especially if this has bearing on XML payloads that may be sent between
> it and the server (and typedefs sure do). One should never assume that clients
> are to be implemented by the same people who implemented the server nor that
> the client has a static implementation which was known before hand. For generic
> clients which must resolve such problems dynamically on the fly - form payloads
> based on loaded modules - it is vital to know everything AND to be informed
> properly without confusing information. The current mechanism does not provide
> this unless certain conditions are met as observed by our examples.
> 
> As I said before, I wouldn't mind import by minimal revision in a combination
> with not allowing servers to advertise incompatible schema trees.

I don't think this solves the problem.  If A imports T >= rev1 and B
imports T >= rev2, and A is compiled with T of rev1, and B with T of
rev2, which version of T would the server advertise?

(ietf-netconf-monitoring doesn't solve this either).

In order to handle this, you would either have to advertise the
revision of each imported module in each capability:

   <capability>...?module=A&imports=T@rev1,U@rev2,...</capability>

or you would say that the server must "use" exactly one version of
each module, so A and B MUST be compiled with the same version of T.

But this doesn't work today.

> ietf-inet-types out of the box if there is no reason to do this? :)

Good question!  They probably shouldn't.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 05 Jun 2012 06:00:25 -0700

> for advertising a module for its typedefs, groupings etc.

This means the client will not have a complete set of modules used
and will not build an accurate schema tree for the server.
The reason the advertise the types modules is so the client
uses the correct one.  Using the wrong grouping, typedef, identity, etc.
can have an impact on the user and the network.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 05 Jun 2012 06:18:32 -0700

On 06/05/2012 04:25 AM, Martin Bjorklund wrote:
> Jernej Tuljak<[email-masked]>  wrote:
> I don't think this solves the problem.  If A imports T>= rev1 and B
> imports T>= rev2, and A is compiled with T of rev1, and B with T of

What if the foo-types modules changes?
What if foo-type is range "1..100" in 1 version and "1..1000"
in version 2?  Which range is actually used?

What if there is another foo-types module that has a different XML namespace?
Remember in YANG the module name only needs to be unique within
a given server, but XML namespaces are supposed to be globally unique.
The server needs to advertise the complete module set so the client doesn't
just guess the versions or the namespaces.

Note that YANG conformance is completely broken unless import/include
by revision is used everywhere OR unless all the revisions of all the modules
used is advertised in the <hello>.

If module A requires the foo-type with range 1..100, and the foo-types module is upgraded
for any reason, the conformance will change for module A because now
the server is expected to accept 1..1000 (unless import-by-revision is used
to force version 1.  If module B does not use import-by-revision for foo-types, it will use
version 2.  This is 1 way the server can advertise both foo-types.1 and foo-types.2.

Andy

Andy

---

From: Jernej Tuljak <[email-masked]>
Date: Tue, 05 Jun 2012 16:15:00 +0200

Dne 5.6.2012 15:18, piše Andy Bierman:
>>> server
>>> combination

I agree with Andy that the entire set of modules should be advertised 
because of the namespace uri. It is however irrelevant to the client if 
a range of a type changes during a proper module evolution (RFC6020 
10.). This is because no matter which foo-types revision is used the 
client cannot generate an invalid payload based on it. If it believes 
that a leaf has a a range of 1..100 but the server actually supports a 
range of 1..1000 then nothing is wrong with that.
However if A were to change and require a newly defined typedef which 
only appears in newer revisions of foo-types it would be a different story.

I'm not a server-side guy, but why would anyone bother to maintain code 
for two different revisions of the same module on a server? Why can't 
the entire server be re-compiled with newest versions of modules? No 
change could have been made that would break any of the modules. When I 
said "prevent server from advertising different revisions of the same 
module" I actually meant this. Of course combined with import by min 
revision.

I still think a server should never advertise two revisions of the same 
module. It should not even list such modules in ietf-netconf-monitoring. 
Perhaps it doesn't matter for non-schema tree modules, but if a module 
defines a schema tree (top-level schema nodes), bad things are bound to 
happen when this is done.

Jernej

---

From: Andy Bierman <[email-masked]>
Date: Tue, 05 Jun 2012 07:41:06 -0700

....
> I agree with Andy that the entire set of modules should be advertised because of the namespace uri. It is however irrelevant to the client if a range of a type changes during a proper module 
> evolution (RFC6020 10.). This is because no matter which foo-types revision is used the client cannot generate an invalid payload based on it. If it believes that a leaf has a a range of 1..100 but 
> the server actually supports a range of 1..1000 then nothing is wrong with that.
> However if A were to change and require a newly defined typedef which only appears in newer revisions of foo-types it would be a different story.
>

It is not irrelevant in the new-client/old-server scenario.
It is not irrelevant to the YANG module designer who wants to specify
precise server conformance requirements for interoperability.

If a new client (who knows about range 1..1000) receives no advertisement,
or incorrect advertisement of the foo-types module version in use, it will
send values 101..1000 to the server but this is wrong.

   1) the conformance for module "A" (when it was written) was for range 1..100
   2) the server will correctly reject the requests for 101..1000 because the
       range it implements is 1..100

> I'm not a server-side guy, but why would anyone bother to maintain code for two different revisions of the same module on a server? Why can't the entire server be re-compiled with newest versions 
> of modules? No change could have been made that would break any of the modules. When I said "prevent server from advertising different revisions of the same module" I actually meant this. Of course 
> combined with import by min revision.

What makes you think the constants in the server instrumentation code for module "A"
are dynamically derived from YANG modules?

>
> I still think a server should never advertise two revisions of the same module. It should not even list such modules in ietf-netconf-monitoring. Perhaps it doesn't matter for non-schema tree 
> modules, but if a module defines a schema tree (top-level schema nodes), bad things are bound to happen when this is done.

This scenario can't happen in YANG.
Once the module defines node /foo, further attempts to define it will fail.
Even top-level uses-stmt for an external grouping is restricted to
1 expansion (or else duplicate node name error).

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 5 Jun 2012 10:47:29 -0700

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "Martin Bjorklund" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, June 05, 2012 6:18 AM
...
> used is advertised in the <hello>.

Refer back to Martin's earlier point: the syntax of the advertisement
doesn't provide sufficient information.   There isn't enough information there
to know which versions imported which versions - what is needed is a tree,
rather than a list, particularly for typedefs or aspect-oriented designs.  In
open, multi-vendor, or extensible systems this lack of information might
be more of an issue than in single-vendor non-extensible products. 

Randy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 05 Jun 2012 19:50:47 -0700

On 06/05/2012 10:47 AM, Randy Presuhn wrote:
> Hi -
>
>> From: "Andy Bierman"<[email-masked]>
>> To: "Martin Bjorklund"<[email-masked]>
>> Cc:<[email-masked]>
>> used is advertised in the<hello>.

You're right.
IMO, a real conformance-statement is needed which captures
the conformance for a specific version so it cannot be misinterpreted
over time, under any circumstances.  I guess that would be a dependency tree,
i.e., something that can be parsed recursively.

Just because module X-1 augments a node in module X,
the server may not intend to conform to module X, just X-1.
The import is only needed to make augment work.
The client needs to import X in order to parse X-1, so the
server needs to advertise it.

The module designer may need multiple conformance statements,
not 1 per module.  Anybody who has read the ietf-ipfix-psamp.yang
module can appreciate how hard it is to read a module with 3 separate use-cases
and 17 optional features.  Use cases change over time.  Changing/adding more
if-feature-stmts is not a good solution.

Some dartboard material:

module X-1:

    import X { prefix X; }

    conformance X-1-sample {
        revision-date 2012-04-03;
        use-module X {
            module-conformance X:X-1-rev1;
        }

        // syntax for conformance TBD....
        required  "/foo-list";

     }

module X:

    conformance X-rev1 {
        revision-date 2012-02-02;  // for this version of module X
        use-module foo-types {
            // no module-conformance  means this conformance to module X
            // does not require any objects from foo-types.
            use-revision 2011-04-22;   // version must be >= this date
        }
     }

Andy

---

From: Jernej Tuljak <[email-masked]>
Date: Wed, 06 Jun 2012 09:57:29 +0200

> server needs to advertise it.

How does a client know when a module was advertised in order for another 
module to be parsed and not conform to it?

I think augmentation is not a good example for this. When a module 
augments another module the intention of a YANG developer is always to 
conform to the augmented module (X-1 must conform to X but with some 
additional nodes). Augmentation represents composition not aggregation 
(X-1 cannot exist without X). What if X-1 contains a leafref to an 
augmented node which resides somewhere in the subtree of X for example? 
If someone wishes to import X-1 just for it's top-level typedefs, 
groupings, etc. AND at the same time not conform to X however, then this 
is bad module design. Definitions intended for reuse should always 
reside inside non-schema tree modules. IMO, forcing this somehow would 
not be a bad idea. Perhaps by differentiating between "header modules" 
and "implementation modules" (presence of schema nodes).

> use-revision 2011-04-22; // version must be >= this date

The hello message would still need to be adjusted in order for this to 
work. Modules alone would not contain enough information to determine a 
list of modules that are actually used by the server (I think).

Jernej

---

From: Andy Bierman <[email-masked]>
Date: Wed, 06 Jun 2012 07:25:34 -0700

On 06/06/2012 12:57 AM, Jernej Tuljak wrote:
> How does a client know when a module was advertised in order for another module to be parsed and not conform to it?

It doesn't know with the current RFCs.

>
> I think augmentation is not a good example for this. When a module augments another module the intention of a YANG developer is always to conform to the augmented module (X-1 must conform to X but 
> with some additional nodes). Augmentation represents composition not aggregation (X-1 cannot exist without X). What if X-1 contains a leafref to an augmented node which resides somewhere in the 
> subtree of X for example? If someone wishes to import X-1 just for it's top-level typedefs, groupings, etc. AND at the same time not conform to X however, then this is bad module design. 
> Definitions intended for reuse should always reside inside non-schema tree modules. IMO, forcing this somehow would not be a bad idea. Perhaps by differentiating between "header modules" and 
> "implementation modules" (presence of schema nodes).

The issue is how much of the augmented module must be implemented
in order to claim conformance to the augmenting module.  The answer "all of it"
is too course-grained, like the rest of YANG conformance specification.

> The hello message would still need to be adjusted in order for this to work. Modules alone would not contain enough information to determine a list of modules that are actually used by the server 
> (I think).
>

correct -- advertisement of the module set used by the server
and advertisement of the module conformances could be done together:

      http://example.com/ns/foo?module=foo&revision=2012-06-06&conformance=foo-basic

BTW, there is conformance to data types like ietf-yang-types.yang.
The typedefs have syntax and some semantics that need to be implemented
correctly, just like a list or a leaf.

Andy