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

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 26 Jan 2012 13:12:16 +0100

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.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 26 Jan 2012 15:49:44 +0100

> substantial to the definition of the term MIB module and is also not

OK
 
> I tend to believe this would be useful as it describes exactly what the

If you believe this is important...

> does not protect, since they are deemed to be of lesser

Since the whole section is about SNMP and the term Security Model is
SNMP specific, I do not think repeating SNMP is needed (but it also
can't hurt).

> the performance-related statistics.

OK

> and the User-based Security Model [RFC3414].

I am fine with the proposed text.
 
> the use of the TLS transport.

I can accept the text since it seems to better reflect todays
deployments. But I also note that RFC 5424 is pretty clear in stating
the requirements:

   All implementations of this specification MUST support a TLS-based
   transport as described in [RFC5425].

   All implementations of this specification SHOULD also support a
   UDP-based transport as described in [RFC5426].

   It is RECOMMENDED that deployments of this specification use the TLS-
   based transport.

This is not a conditional recommendation. But perhaps this text was
the only way to get through the IESG. ;-)
  
> types of network interfaces, such as Ethernet.

OK

> from snmp.com). If there is nobody in the WG who speaks up for it we 

Cool, I did not know RFC3165 is still being used in products. Now I am
biased. ;-)

> IANA registry for IPPM metrics have been declared Obsolete and shouldn't

OK

/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/>

---

From: David Harrington <[email-masked]>
Date: Sat, 28 Jan 2012 12:29:51 -0500

Hi,

>> the performance-related statistics.

I agree with making the text examples. I think one example should be that
some managers might only be allowed read-only access while others are
allowed read-write access.
The new text mixes operations and specific views (perf stats), so the RO
vs RW example is not very clearly shown.

>the only way to get through the IESG. ;-)

RFC5426 reflects IETF consensus (not just IESG consensus) and is correctly
formulated to meet the IETF-consensus about strong security found in BCP61
(RFC3365). 
Sometimes IETF consensus and industry deployment are not consistent (e.g.,
IPv6, syslog/tls, snmpv3 vs snmpv1, writable MIBs, netconf, YANG, and so
on); that doesn't mean you can just ignore IETF consensus in your IETF
documents.

Please do NOT write your document to override the IETF consensus.

David Harrington
Director, Transport Area
(and chair of the concluded syslog WG)

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 30 Jan 2012 20:30:41 +0100

Hi David,

> vs RW example is not very clearly shown.

Would this work for you? If not please provide some NEW text.

NEW: 
An agent entity can restrict access to a certain portion of its MIB,
e.g. restrict 
some manager principals to view only performance-related statistics, or
disallow 
other manager principals to read those performance-related statistics. 
An agent entity can also restrict to monitoring (read-only) as opposed
to monitoring 
and configuration (read-write) of a certain portion of its MIB, e.g.
allowing only a 
single designated manager principal to update configuration parameters.

Cheers,
Mehmet

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 31 Jan 2012 11:49:43 +0100

Sorry to jump in with a detail terminology question, but what does
exactly 'manager principal' mean, where does this term come from? It is
not used in the current version of the document AFAICT, possibly I
missed something in the discussion.  

Thanks and Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ersue, Mehmet (NSN - DE/Munich)
> Sent: Monday, January 30, 2012 9:31 PM
> To: ext David Harrington
> Cc: [email-masked]
> Subject: Re: [OPSAWG] WGLC draft-ietf-opsawg-management-stds
> 
> Hi David,
> 
> > >> NEW:
> > The new text mixes operations and specific views (perf stats), so
the
> RO
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 31 Jan 2012 12:09:46 +0100

Hi Dan,

STD62 uses the term principal to describe:
securityName  - the principal on whose behalf access is requested

Cheers, 
Mehmet 

> From: ext Romascanu, Dan (Dan) [mailto:[email-masked]]
> Sent: Tuesday, January 31, 2012 11:50 AM
> To: Ersue, Mehmet (NSN - DE/Munich); ext David Harrington
> Cc: [email-masked]
> Subject: RE: [OPSAWG] WGLC draft-ietf-opsawg-management-stds
> 
> > > >> configuration parameters or disallow other manager principals
to
> > read
> > > I agree with making the text examples. I think one example should
be
> > that

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 31 Jan 2012 12:11:41 +0100

Can you please explain this and provide the reference in the text? 

Thanks and Regards,

Dan

> From: Ersue, Mehmet (NSN - DE/Munich) [mailto:[email-masked]]
> Sent: Tuesday, January 31, 2012 1:10 PM
> To: Romascanu, Dan (Dan); ext David Harrington
> Cc: [email-masked]
> > > > >> An agent entity can restrict access to a certain portion of
> its
> > > MIB,
> > > > >> e.g.
> > > > some managers might only be allowed read-only access while
others
> > are
> > > some manager principals to view only performance-related
> statistics,
> > or
> > > disallow

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 31 Jan 2012 12:22:27 +0100

I would think that "principal" is good enough, and
that "manager principal" or "managers principals"
is a weird term. I do not think STD62 speaks
about "manager principal" or "server principal"
but just about "principal".

Not that I will loose any sleep over it though.

Bert