Re: [OPSAWG] WGLC draft-ietf-opsawg-management-stds

["Ersue, Mehmet (NSN - DE/Munich)" <[e-mail]>]

Hi Juergen,

thank you for the long list of concrete and useful comments.
However, a few of them need some tuning. See below.

Mehmet 

 
> b) The definition of MIB module can probably be improved. I suggest to
align
>    with the definition found in RFC 3410 section 6.2.
> 
>    OLD:
> 
>    o  MIB module: A MIB definition, typically for a particular network
>       technology feature, that constitutes a subtree in an object
>       identifier tree.  A MIB that is provided by a management agent
is
>       typically composed of multiple instantiated MIB modules.
> 
>    NEW:
> 
>    o  MIB module: MIB modules usually contain object definitions, may
>       contain definitions of event notifications, and sometimes
include
>       compliance statements in terms of appropriate object and event
>       notification groups.  MIB modules are defined by using the
>       data modeling language SMI. A MIB that is provided by a
management
>       agent is typically composed of multiple instantiated MIB
modules.

I would suggest to remove the sentence on SMI as it does not add
anything 
substantial to the definition of the term MIB module and is also not
mentioned 
in RFC 3410 section 6.2.

> e) This text can probably go without losing anything important for
>    the target audience (but if people believe this is important...)
> 
>    OLD:
> 
>    The SNMPv3 Framework extends the architectural principles of SNMPv1
>    and SNMPv2 by:
> 
>    o  building on these three basic architectural components, in some
>       cases incorporating them from the SNMPv2 Framework by reference,
>       and
> 
>    o  by using the same layering principles in the definition of new
>       capabilities in the security and administration portion of the
>       architecture.
> 
>    NEW:

I tend to believe this would be useful as it describes exactly what the
title 
of the subchapter aims.

> j) Remove unclear and unneeded reference to "this architecture".
... 
>    OLD:
> 
>    There are two threats against which a Security Model within this
>    architecture does not protect, since they are deemed to be of
lesser
> 
>    NEW:
> 
>    There are two threats against which a Security Model
>    does not protect, since they are deemed to be of lesser

NEW:
There are two threats against which SNMP Security Model 
does not protect, since they are deemed to be of lesser
 
> k) I fail to see why these are two different things. In particular,
>    the example given in the first bullet seems to be a perfect fit for
>    the second bullet. Here is a proposal for a shorter version:
> 
>    OLD:
> 
>    [...] An agent
>    entity can restrict access to its MIB for a particular manager
entity
>    in two ways:
> 
>    o  The agent entity can restrict access to a certain portion of its
>       MIB, e.g., an agent may restrict most manager principals to
>       viewing performance-related statistics and allow only a single
>       designated manager principal to view and update configuration
>       parameters.
> 
>    o  The agent can limit the operations that a principal can use on
>       that portion of the MIB.  E.g., a particular manager principal
>       could be limited to read-only access to a portion of an agent's
>       MIB.
> 
>    NEW:
> 
>    [...] An agent
>    entity can restrict access to a certain portion of its MIB for a
>    particular manager principal, an agent may restrict some manager
>    principals to viewing performance-related statistics and allow only
>    a single designated manager principal to view and update
>    configuration parameters. Some other manager principals may not
>    even be allowed to read the performance-related statistics.

I generally agree but would prefer a formulation which highlights that 
these are examples.

NEW: 
An agent entity can restrict access to a certain portion of its MIB,
e.g. 
restrict some manager principals to view performance-related statistics,

allow only a single designated manager principal to view or update 
configuration parameters or disallow other manager principals to read 
the performance-related statistics.
 
> l) I think this is wrong because my understanding is that there is a
>    single community-based security model that is used by both SNMPv1
>    and SNMPv2.
> 
>    OLD:
> 
>    The SNMP Transport Security Model [RFC5591] is an alternative to
the
>    existing SNMPv1 Security Model [RFC3584], the SNMPv2c Security
Model
>    [RFC3584], and the User-based Security Model [RFC3414].
> 
>    NEW:
> 
>    The SNMP Transport Security Model [RFC5591] is an alternative to
the
>    existing SNMPv1/SNMPv2 Community-based Security Model [RFC3584] and
>    the User-based Security Model [RFC3414].

It might be the case that SNMPv1 and SNMPv2 use a similar community-
based security model. However, RFC3585 makes a differentiation between 
the two and states that they are not identical. 

NEW:
The SNMP Transport Security Model [RFC5591] is an alternative to the
existing SNMPv1 and SNMPv2 Community-based Security Models [RFC3584] 
and the User-based Security Model [RFC3414].

> o) This seems to be wrong: RFC 5426 says "TLS transport [7] is
>    REQUIRED to implement and RECOMMENDED for general use." Sure, it
>    would be kind of stupid to implement SYSLOG without UDP support but
>    the standard clearly says TLS.
> 
>    OLD:
> 
>    number of transport mappings.  However, for interoperability
>    purposes, SYSLOG protocol implementers are required to support the
>    transmission of SYSLOG Messages over UDP as defined in [RFC5426].
> 
>    NEW:
> 
>    number of transport mappings.  However, for interoperability
>    purposes, SYSLOG protocol implementers are required to support the
>    transmission of SYSLOG Messages over TLS as defined in [RFC5426].

The statements in RFC5426 could be interpreted as conflicting. However, 
there are two different pov.:

"for interoperability purposes, syslog protocol implementers are
required
to support this transport mapping." 

and if congestion control and reliability is a concern
"This is why the syslog TLS transport [7] is REQUIRED to implement and 
RECOMMENDED for general use."

I think if reliability is not a concern UDP transport can be used for
interoperability. 
Taking some text on UDP usage from RFC5426:

NEW:
The SYSLOG protocol layered architecture provides support for a number 
of transport mappings. For interoperability purposes and especially in 
managed networks, where the network path has been explicitly provisioned

for UDP syslog traffic, SYSLOG protocol can be used over UDP [RFC5426]. 
To support congestion control and reliability [RFC5426] recommends 
the use of the TLS transport.
 
> v) Is this history of any use for the target audience? Note that RFC
>    1229 was obsoleted in 1994, 18 years ago. I suggest to shrink this
>    as follows:
> 
>    OLD:
> 
>    The Interfaces Group MIB [RFC2863] builds on MIB II [RFC1229] and
is
>    used as a primary MIB for managing and monitoring the status of
>    network interfaces (e.g.  SNMP linkdown and linkup notifications).
>    The 'interfaces' group in MIB II [RFC1229] defines a generic set of
>    managed objects and provides the means for additional managed
objects
>    specific to particular types of network interfaces, such as
Ethernet.
>    Extensions to the 'interfaces' group for media-specific management
>    can be defined based on these managed objects.  Experience with
>    media-specific MIB modules has shown that the model defined by
MIB-II
>    is too simplistic and static for some types of media-specific
>    management.  The Interfaces Group MIB incorporates the interfaces
>    group extensions documented in MIB II and standardizes an evolution
>    to this model as well as fills in the detected gaps.
> 
>    NEW:
> 
>    The Interfaces Group MIB [RFC2863] defines a generic set of managed
>    objects for network interfaces and it provides the infrastructure
>    for additional managed objects specific to particular types of
>    network interfaces, such as Ethernet.

You are right, however people outside of IETF still refer to MIB II very

often. We need to get those people where they are and provide a
reference. 
I shortened as:

NEW:
The Interfaces Group MIB [RFC2863] builds on the old standard for MIB II

[STD17] and is used as a primary MIB for managing and monitoring the 
status of network interfaces.  The Interfaces Group MIB [RFC2863]
defines a 
generic set of managed objects for network interfaces and it provides 
the infrastructure for additional managed objects specific to particular

types of network interfaces, such as Ethernet.

> x) I doubt these are in any way practically relevant nor am I sure
>    about the support agreement argument. This neither RFC3165 nor
>    RFC4011 seem to be used in practice, I would rather drop these
>    three paragraphs.
> 
>    OLD:
> 
>    [RFC3165] supports the use of user-written scripts to delegate
>    management functionality.
> 
>    Policy Based Management MIB [RFC4011] defines objects that enable
>    policy-based monitoring using SNMP, using a scripting language, and
a
>    script execution environment.
> 
>    Few vendors have implemented MIB modules that support scripting.
>    Some vendors consider running user-developed scripts within the
>    managed device as a violation of support agreements.
> 
>    NEW:

I agree that they are not that important. Especially RFC4011 can be
skipped. 
However, RFC3165 seems to be still in use in some SNMP tools (e.g.
CIAgent 
from snmp.com). If there is nobody in the WG who speaks up for it we 
can skip it too.

> z) Why do we have text for something that according to RFC 6248 has
>    seen no usage?
> 
>    OLD:
> 
>    The IPPM working group has defined [BCP108][RFC4148] "IP
Performance
>    Metrics (IPPM) Metrics Registry".  The IANA-assigned registry
>    contains an initial set of OBJECT IDENTITIES to currently defined
>    metrics in the IETF as well as defines the rules for adding IP
>    Performance Metrics that are defined in the future.  However, the
>    current registry structure has been found to be insufficiently
>    detailed to uniquely identify IPPM metrics.  Due to the ambiguities
>    between the current metrics registrations and the metrics used, and
>    the apparent non-adoption of the registry in practice, it has been
>    proposed to reclassify [RFC4148] as Obsolete.
> 
>    Note: With the publication of [RFC6248] the latest IANA registry
for
>    IPPM metrics and [RFC4148] have been declared Obsolete and IANA
>    prevents registering new metrics.  Actual users can continue using
>    the current registry and its contents.
> 
>    NEW:

I believe it is the exact aim of this document, to highlight what is 
recommended to use but also to explicitly state what shouldn't be 
used anymore. As such I agree with Benoit and would like to reduce 
the text but keep a note like below.	

NEW:
The IPPM working group has defined [RFC4148] "IP Performance Metrics 
(IPPM) Metrics Registry".  
Note that with the publication of [RFC6248], [RFC4148] and the
corresponding 
IANA registry for IPPM metrics have been declared Obsolete and shouldn't
be used.