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

[David Harrington <[e-mail]>]

Hi,



>
>> > 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.
>
>OK

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.



> 
>> > 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.
>
>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. ;-)

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)