Re: [netmod] Compatibility of config=false data

[Italo Busi]

Balazs,

Few questions for clarification

In case 3, is it required to deviate the schema node to not-supported or would 
it be also possible to deviate it as mandatory=false?

How would you consider the definition of some "special" value (e.g., 0 in case 
of integer or "unknown" in case of enumeration) as a way to report "fake" data?

Are these rules written or planned to be written somewhere?

Thanks, Italo

> -Original Message-
> From: Balázs Lengyel [mailto:balazs.leng...@ericsson.com]
> Sent: mercoledì 21 aprile 2021 16:48
> To: Juergen Schoenwaelder 
> Cc: Andy Bierman ; Sterne, Jason (Nokia - CA/Ottawa)
> ; netmod@ietf.org
> Subject: Re: [netmod] Compatibility of config=false data
> 
> Hello Juergen,
> IMHO the server should in the order of preference:
> 1) ALWAYS report mandatory state data - this is the correct thing; it should
> happen most of the times
> 2) Report real data in some of the cases and deviate the mandatory=true
> statement to mandatory=false. - This means I deviate from the real module,
> but at least I publish a contract I adhere to
> 3) Never report the data and deviate the schema node to not-supported . -
> This means I strongly deviate from the real module, but at least I publish a
> contract I adhere to
> 4) Not deviate the module as described above, but do not report data
> 5) Report fake data - I agree that this is the worst
> 
> I consider 4) and 5) to violate the YANG standard.
> Regards Balazs
> 
> -Original Message-
> From: Juergen Schoenwaelder 
> Sent: 2021. április 21., szerda 12:32
> To: Balázs Lengyel 
> Cc: Andy Bierman ; Sterne, Jason (Nokia - CA/Ottawa)
> ; netmod@ietf.org
> Subject: Re: Compatibility of config=false data
> 
> RFC 7950 section 8:
> 
>Several YANG statements define constraints on valid data.  These
>constraints are enforced in different ways, depending on what type of
>data the statement defines.
> 
>o  If the constraint is defined on configuration data, it MUST be
>   true in a valid configuration data tree.
> 
>o  If the constraint is defined on state data, it MUST be true in a
>   valid state data tree.
> 
> The main difference between configuration data and state data is that a server
> can keep the configuration data in a valid state by rejecting any changes that
> make the configuration data invalid. If, however, a server reports an invalid
> state data tree, then obviously the server did choose to do so and the clients
> may have to deal with it (which includes the option of the client to reject 
> all
> state data since it is invalid, but that might not always be the best or most
> desirable option).
> 
> If there is a mandatory state leaf that the server can't implement, what 
> should
> the server do? The worst of all possible solutions is to report a fake leaf. 
> This
> has happened quite a bit in the history of SNMP and this is really really bad.
> Instead of reporting fake values, it is far better to not report the leaf so 
> that
> the deviation is clear. Ideally, the server formally declare the deviation 
> and all
> is good.
> 
> When the NMDA document was put together, the intention was to say that
> we want the state data to be as close as possible to the ground truth and we
> rather do not want systems to report fake leafs.
> 
> /js
> 
> On Wed, Apr 21, 2021 at 08:45:02AM +, Balázs Lengyel wrote:
> > Hello Andy,
> >
> > While NMDA states “it is possible that constraints MAY be violated under
> some circumstances”
> >
> > *   this was never declared for non-NMDA systems, so IMHO a client can
> reasonably assume that if mandatory=true for a config=false node was
> declared the reason is that it will always be present; otherwise it should 
> simply
> be mandatory=false.
> > *   IMHO this allowance for the operational datastore is for extra-ordinary
> situations. In the normal case as defined in the NMDA-RFC“
> SHOULD conform to any constraints specified”.
> >
> >
> >
> > Regards Balazs
> >
> >
> >
> > From: Andy Bierman 
> > Sent: 2021. április 20., kedd 20:21
> > To: Juergen Schoenwaelder ;
> > Balázs Lengyel ; Sterne, Jason (Nokia -
> > CA/Ottawa) ; Andy Bierman
> > ; netmod@ietf.org
> > Subject: Re: Compatibility of config=false data
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Apr 20, 2021 at 9:26 AM Juergen Schoenwaelder
> mailto:j.schoenwaelder@jacobs-
> university.de> > wrote:
> >
> > My understanding is that a  returns the leafs that exist and that
> > are not filtered.
> >
> >
> >
> > Yes -- this is what clients expect.
> >
> > It is not clear that real client apps rely too much on YANG validation
> > of
> >
> > the config=false nodes in .
> >
> >
> >
> > The validation of server provided monitoring data was not a focus of YANG.
> >
> > It may not be valid to assume every sentence that applies to
> > config=true
> >
> > also applies to config=false.
> >
> >
> >
> > Even the NMDA RFC ignores YANG validation of config=false nodes.
> >
> > There is a paragraph that says it SHOULD be

Re: [netmod] Compatibility of config=false data

[Andy Bierman]

On Wed, Apr 21, 2021 at 7:48 AM Balázs Lengyel 
wrote:

> Hello Juergen,
> IMHO the server should in the order of preference:
> 1) ALWAYS report mandatory state data - this is the correct thing; it
> should happen most of the times
> 2) Report real data in some of the cases and deviate the mandatory=true
> statement to mandatory=false. - This means I deviate from the real module,
> but at least I publish a contract I adhere to
> 3) Never report the data and deviate the schema node to not-supported . -
> This means I strongly deviate from the real module, but at least I publish
> a contract I adhere to
> 4) Not deviate the module as described above, but do not report data
> 5) Report fake data - I agree that this is the worst
>
>

IMO mandatory-stmt has no meaning for config=false.
In fact, validation for config=false was never properly considered and it
has 2 major flaws:

1) mandatory means nothing for config=false data nodes

The server doesn't get to decide "maybe I will return /foo counter values
today"
because mandatory=false.  I brought this issue up years ago and Martin
clarified
the issue (can't find it now).

Mandatory-stmt does not alter module conformance.
Only if-feature=false can do that (and deviations of course).
Unless a filter or NACM removes the data node, then a  on

is supposed to return the requested data if it exists. Period.

 Constraints on Data

   Several YANG statements define constraints on valid data.  These
   constraints are enforced in different ways, depending on what type of
   data the statement defines.

   o  If the constraint is defined on configuration data, it MUST be
  true in a valid configuration data tree.

   o  If the constraint is defined on state data, it MUST be true in a
  valid state data tree.

   o  If the constraint is defined on notification content, it MUST be
  true in any notification data tree.

   o  If the constraint is defined on RPC or action input parameters, it
  MUST be true in an invocation of the RPC or action operation.

   o  If the constraint is defined on RPC or action output parameters,
  it MUST be true in the RPC or action reply.



It is not clear that bullet 5 really applies to content within the 
parameter.
It clearly applies to the nodes specified in the rpc or action "output"
statement.
It seems that bullet 2 does not apply because the client does not have the
state data tree, it has an  element.


2) must-stmt constraints are purely theoretical in the rpc-reply XPath
context

Again, it is not clear at all that constraints defined in YANG models are
part of the
validation within an .  Clearly the output parameters are
validated but
not at all clear whether a state data tree can exist in an  or
only in a server.

Since the XPath context allows config and state data from OUTSIDE the
,
it is clearly impossible for a client to have BOTH the server state data
tree
and the  from the same moment in time.  This conceptual
evaluation
is never actually done on the server, but that is how the constraint is
defined.

Since these constraints are rare it is not an urgent issue, but it should
be addressed
if yang-next is ever chartered.




> I consider 4) and 5) to violate the YANG standard.
> Regards Balazs
>


Andy


>
> -Original Message-
> From: Juergen Schoenwaelder 
> Sent: 2021. április 21., szerda 12:32
> To: Balázs Lengyel 
> Cc: Andy Bierman ; Sterne, Jason (Nokia - CA/Ottawa) <
> jason.ste...@nokia.com>; netmod@ietf.org
> Subject: Re: Compatibility of config=false data
>
> RFC 7950 section 8:
>
>Several YANG statements define constraints on valid data.  These
>constraints are enforced in different ways, depending on what type of
>data the statement defines.
>
>o  If the constraint is defined on configuration data, it MUST be
>   true in a valid configuration data tree.
>
>o  If the constraint is defined on state data, it MUST be true in a
>   valid state data tree.
>
> The main difference between configuration data and state data is that a
> server can keep the configuration data in a valid state by rejecting any
> changes that make the configuration data invalid. If, however, a server
> reports an invalid state data tree, then obviously the server did choose to
> do so and the clients may have to deal with it (which includes the option
> of the client to reject all state data since it is invalid, but that might
> not always be the best or most desirable option).
>
> If there is a mandatory state leaf that the server can't implement, what
> should the server do? The worst of all possible solutions is to report a
> fake leaf. This has happened quite a bit in the history of SNMP and this is
> really really bad. Instead of reporting fake values, it is far better to
> not report the leaf so that the deviation is clear. Ideally, the server
> formally declare the deviation and all is good.
>
> When the NMDA document was put together, the intention was to say that we
> want the stat

Re: [netmod] Compatibility of config=false data

[Balázs Lengyel]

Hello Juergen,
IMHO the server should in the order of preference:
1) ALWAYS report mandatory state data - this is the correct thing; it should 
happen most of the times
2) Report real data in some of the cases and deviate the mandatory=true 
statement to mandatory=false. - This means I deviate from the real module, but 
at least I publish a contract I adhere to
3) Never report the data and deviate the schema node to not-supported . - This 
means I strongly deviate from the real module, but at least I publish a 
contract I adhere to
4) Not deviate the module as described above, but do not report data 
5) Report fake data - I agree that this is the worst

I consider 4) and 5) to violate the YANG standard.
Regards Balazs

-Original Message-
From: Juergen Schoenwaelder  
Sent: 2021. április 21., szerda 12:32
To: Balázs Lengyel 
Cc: Andy Bierman ; Sterne, Jason (Nokia - CA/Ottawa) 
; netmod@ietf.org
Subject: Re: Compatibility of config=false data

RFC 7950 section 8:

   Several YANG statements define constraints on valid data.  These
   constraints are enforced in different ways, depending on what type of
   data the statement defines.

   o  If the constraint is defined on configuration data, it MUST be
  true in a valid configuration data tree.

   o  If the constraint is defined on state data, it MUST be true in a
  valid state data tree.

The main difference between configuration data and state data is that a server 
can keep the configuration data in a valid state by rejecting any changes that 
make the configuration data invalid. If, however, a server reports an invalid 
state data tree, then obviously the server did choose to do so and the clients 
may have to deal with it (which includes the option of the client to reject all 
state data since it is invalid, but that might not always be the best or most 
desirable option).

If there is a mandatory state leaf that the server can't implement, what should 
the server do? The worst of all possible solutions is to report a fake leaf. 
This has happened quite a bit in the history of SNMP and this is really really 
bad. Instead of reporting fake values, it is far better to not report the leaf 
so that the deviation is clear. Ideally, the server formally declare the 
deviation and all is good.

When the NMDA document was put together, the intention was to say that we want 
the state data to be as close as possible to the ground truth and we rather do 
not want systems to report fake leafs.

/js

On Wed, Apr 21, 2021 at 08:45:02AM +, Balázs Lengyel wrote:
> Hello Andy,
> 
> While NMDA states “it is possible that constraints MAY be violated under some 
> circumstances” 
> 
> * this was never declared for non-NMDA systems, so IMHO a client can 
> reasonably assume that if mandatory=true for a config=false node was declared 
> the reason is that it will always be present; otherwise it should simply be 
> mandatory=false.
> * IMHO this allowance for the operational datastore is for extra-ordinary 
> situations. In the normal case as defined in the NMDA-RFC“ 
> SHOULD conform to any constraints specified”.
> 
>  
> 
> Regards Balazs
> 
>  
> 
> From: Andy Bierman 
> Sent: 2021. április 20., kedd 20:21
> To: Juergen Schoenwaelder ; 
> Balázs Lengyel ; Sterne, Jason (Nokia - 
> CA/Ottawa) ; Andy Bierman 
> ; netmod@ietf.org
> Subject: Re: Compatibility of config=false data
> 
>  
> 
>  
> 
>  
> 
> On Tue, Apr 20, 2021 at 9:26 AM Juergen Schoenwaelder 
>   > wrote:
> 
> My understanding is that a  returns the leafs that exist and that 
> are not filtered.
> 
>  
> 
> Yes -- this is what clients expect.
> 
> It is not clear that real client apps rely too much on YANG validation 
> of
> 
> the config=false nodes in .
> 
>  
> 
> The validation of server provided monitoring data was not a focus of YANG.
> 
> It may not be valid to assume every sentence that applies to 
> config=true
> 
> also applies to config=false.
> 
>  
> 
> Even the NMDA RFC ignores YANG validation of config=false nodes.
> 
> There is a paragraph that says it SHOULD be done, but it really refers
> 
> to how operational values of config=true MAY not pass validation.
> 
>  
> 
>  
> 
> /js
> 
>  
> 
> Andy
> 
>  
> 
> 
> On Tue, Apr 20, 2021 at 03:35:28PM +, Balázs Lengyel wrote:
> > Hello Juergen,
> > https://tools.ietf.org/html/rfc7950#section-7.6.5 states: 
> > 
> > If "mandatory" is "true", the behavior of the constraint depends on
> >the type of the leaf's closest ancestor node in the schema tree that
> >is not a non-presence container (see Section 7.5.1):
> >o  If no such ancestor exists in the schema tree, the leaf MUST
> >   exist.
> >o  Otherwise, if this ancestor is a case node, the leaf MUST exist if
> >   any node from the case exists in the data tree.
> >o  Otherwise, the leaf MUST exist if the ancestor node exists in the
> >   data tree.
> > 
> > Let's take the simplest example a 

Re: [netmod] Last Call: (A YANG Grouping for Geographic Locations) to Proposed Standard

[Christian Hopps]

> On Apr 19, 2021, at 4:14 PM, Erik Kline  wrote:
> 
> 
> 
> Are the vector components expected to be accessed by name in applications, or 
> is it possible some applications might have to handle a 3-tuple of doubles?

By name only.

Thanks,
Chris.

> 
> I only ask this super-nitty question because in my (admittedly limited) 
> experience, ENU order (or NED for that matter) was more familiar since it 
> forms a coordinate system that aligns with the right hand rule.
> 
> NEU->ENU conversion is obviously trivial.  I was just thinking of possible 
> errors where the members of the vector aren't accessed by name but by 
> position.
> 
> -ek
> 
> On Mon, Apr 19, 2021 at 7:07 AM The IESG  > wrote:
> 
> The IESG has received a request from the Network Modeling WG (netmod) to
> consider the following document: - 'A YANG Grouping for Geographic Locations'
>as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> last-c...@ietf.org  mailing lists by 2021-05-03. 
> Exceptionally, comments may
> be sent to i...@ietf.org  instead. In either case, 
> please retain the beginning
> of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>This document defines a generic geographical location object YANG
>grouping.  The geographical location grouping is intended to be used
>in YANG models for specifying a location on or in reference to Earth
>or any other astronomical object.
> 
> 
> 
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/ 
> 
> 
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> 
> 
> 
> ___
> IETF-Announce mailing list
> ietf-annou...@ietf.org 
> https://www.ietf.org/mailman/listinfo/ietf-announce 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod



signature.asc
Description: Message signed with OpenPGP
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Compatibility of config=false data

[Juergen Schoenwaelder]

RFC 7950 section 8:

   Several YANG statements define constraints on valid data.  These
   constraints are enforced in different ways, depending on what type of
   data the statement defines.

   o  If the constraint is defined on configuration data, it MUST be
  true in a valid configuration data tree.

   o  If the constraint is defined on state data, it MUST be true in a
  valid state data tree.

The main difference between configuration data and state data is that
a server can keep the configuration data in a valid state by rejecting
any changes that make the configuration data invalid. If, however, a
server reports an invalid state data tree, then obviously the server
did choose to do so and the clients may have to deal with it (which
includes the option of the client to reject all state data since it is
invalid, but that might not always be the best or most desirable
option).

If there is a mandatory state leaf that the server can't implement,
what should the server do? The worst of all possible solutions is to
report a fake leaf. This has happened quite a bit in the history of
SNMP and this is really really bad. Instead of reporting fake values,
it is far better to not report the leaf so that the deviation is
clear. Ideally, the server formally declare the deviation and all is
good.

When the NMDA document was put together, the intention was to say that
we want the state data to be as close as possible to the ground truth
and we rather do not want systems to report fake leafs.

/js

On Wed, Apr 21, 2021 at 08:45:02AM +, Balázs Lengyel wrote:
> Hello Andy,
> 
> While NMDA states “it is possible that constraints MAY be violated under some 
> circumstances” 
> 
> * this was never declared for non-NMDA systems, so IMHO a client can 
> reasonably assume that if mandatory=true for a config=false node was declared 
> the reason is that it will always be present; otherwise it should simply be 
> mandatory=false.
> * IMHO this allowance for the operational datastore is for extra-ordinary 
> situations. In the normal case as defined in the NMDA-RFC“ 
> SHOULD conform to any constraints specified”.
> 
>  
> 
> Regards Balazs
> 
>  
> 
> From: Andy Bierman  
> Sent: 2021. április 20., kedd 20:21
> To: Juergen Schoenwaelder ; Balázs 
> Lengyel ; Sterne, Jason (Nokia - CA/Ottawa) 
> ; Andy Bierman ; netmod@ietf.org
> Subject: Re: Compatibility of config=false data
> 
>  
> 
>  
> 
>  
> 
> On Tue, Apr 20, 2021 at 9:26 AM Juergen Schoenwaelder 
>   > wrote:
> 
> My understanding is that a  returns the leafs that exist and that
> are not filtered.
> 
>  
> 
> Yes -- this is what clients expect.
> 
> It is not clear that real client apps rely too much on YANG validation of
> 
> the config=false nodes in .
> 
>  
> 
> The validation of server provided monitoring data was not a focus of YANG.
> 
> It may not be valid to assume every sentence that applies to config=true
> 
> also applies to config=false.
> 
>  
> 
> Even the NMDA RFC ignores YANG validation of config=false nodes.
> 
> There is a paragraph that says it SHOULD be done, but it really refers
> 
> to how operational values of config=true MAY not pass validation.
> 
>  
> 
>  
> 
> /js
> 
>  
> 
> Andy
> 
>  
> 
> 
> On Tue, Apr 20, 2021 at 03:35:28PM +, Balázs Lengyel wrote:
> > Hello Juergen,
> > https://tools.ietf.org/html/rfc7950#section-7.6.5 states: 
> > 
> > If "mandatory" is "true", the behavior of the constraint depends on
> >the type of the leaf's closest ancestor node in the schema tree that
> >is not a non-presence container (see Section 7.5.1):
> >o  If no such ancestor exists in the schema tree, the leaf MUST
> >   exist.
> >o  Otherwise, if this ancestor is a case node, the leaf MUST exist if
> >   any node from the case exists in the data tree.
> >o  Otherwise, the leaf MUST exist if the ancestor node exists in the
> >   data tree.
> > 
> > Let's take the simplest example a top level leaf. If it is mandatory=true ->
> > the leaf MUST exist. The above statements do not differentiate between
> > config=true or config=false leaves. 
> > 
> > If the leaf exists, for me, it is trivial that the reply to a get/get-data
> > operation MUST return it.  (assuming it is not filtered out)
> > Anything else would be counter-intuitive and IMHO contradict RFC 7950.
> > 
> > Do you agree? 
> > If not, could you please describe what does a mandatory=true statement mean
> > for a config=false leaf in your interpretation?
> > 
> > ---
> > IMHO we never stated that 
> > 
> > 
> > Regards Balazs
> > 
> > -Original Message-
> > From: Juergen Schoenwaelder  >  > 
> > Sent: 2021. április 14., szerda 17:08
> > To: Balázs Lengyel  >  >
> > Cc: Sterne, Jason (Nokia - CA/Ottawa)  >  >; Andy

Re: [netmod] Compatibility of config=false data

[Balázs Lengyel]

Hello Andy,

While NMDA states “it is possible that constraints MAY be violated under some 
circumstances” 

*   this was never declared for non-NMDA systems, so IMHO a client can 
reasonably assume that if mandatory=true for a config=false node was declared 
the reason is that it will always be present; otherwise it should simply be 
mandatory=false.
*   IMHO this allowance for the operational datastore is for extra-ordinary 
situations. In the normal case as defined in the NMDA-RFC“ SHOULD 
conform to any constraints specified”.

 

Regards Balazs

 

From: Andy Bierman  
Sent: 2021. április 20., kedd 20:21
To: Juergen Schoenwaelder ; Balázs 
Lengyel ; Sterne, Jason (Nokia - CA/Ottawa) 
; Andy Bierman ; netmod@ietf.org
Subject: Re: Compatibility of config=false data

 

 

 

On Tue, Apr 20, 2021 at 9:26 AM Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de> > wrote:

My understanding is that a  returns the leafs that exist and that
are not filtered.

 

Yes -- this is what clients expect.

It is not clear that real client apps rely too much on YANG validation of

the config=false nodes in .

 

The validation of server provided monitoring data was not a focus of YANG.

It may not be valid to assume every sentence that applies to config=true

also applies to config=false.

 

Even the NMDA RFC ignores YANG validation of config=false nodes.

There is a paragraph that says it SHOULD be done, but it really refers

to how operational values of config=true MAY not pass validation.

 

 

/js

 

Andy

 


On Tue, Apr 20, 2021 at 03:35:28PM +, Balázs Lengyel wrote:
> Hello Juergen,
> https://tools.ietf.org/html/rfc7950#section-7.6.5 states: 
> 
> If "mandatory" is "true", the behavior of the constraint depends on
>the type of the leaf's closest ancestor node in the schema tree that
>is not a non-presence container (see Section 7.5.1):
>o  If no such ancestor exists in the schema tree, the leaf MUST
>   exist.
>o  Otherwise, if this ancestor is a case node, the leaf MUST exist if
>   any node from the case exists in the data tree.
>o  Otherwise, the leaf MUST exist if the ancestor node exists in the
>   data tree.
> 
> Let's take the simplest example a top level leaf. If it is mandatory=true ->
> the leaf MUST exist. The above statements do not differentiate between
> config=true or config=false leaves. 
> 
> If the leaf exists, for me, it is trivial that the reply to a get/get-data
> operation MUST return it.  (assuming it is not filtered out)
> Anything else would be counter-intuitive and IMHO contradict RFC 7950.
> 
> Do you agree? 
> If not, could you please describe what does a mandatory=true statement mean
> for a config=false leaf in your interpretation?
> 
> ---
> IMHO we never stated that 
> 
> 
> Regards Balazs
> 
> -Original Message-
> From: Juergen Schoenwaelder   > 
> Sent: 2021. április 14., szerda 17:08
> To: Balázs Lengyel   >
> Cc: Sterne, Jason (Nokia - CA/Ottawa)   >; Andy Bierman
> mailto:a...@yumaworks.com> >; netmod@ietf.org 
>  
> Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13
> 
> On Wed, Apr 14, 2021 at 01:55:04PM +, Balázs Lengyel wrote:
> 
> > *   On the other hand, changing a state leaf from mandatory false to
> true means always including the leaf in a  response.
> 
> Where do you get this from?
> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103
>  28-0d304a28a3dae2f9&q=1&e=81180de4-8958-40ba-aeb8-c689e3da33e8&u=https%3A%2F
> %2Fwww.jacobs-university.de 
> 
>  %2F>



-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 
 >



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod