Re: [netmod] security considerations boilerplate updates to cover RESTCONF

[Benoit Claise <[e-mail]>]

Dear all,

[copying the security ADs to make sure the new security section is fine]
Let's separate the two issues

1. the multiple URLs in draft-ietf-netmod-rfc6087bis-12.txt
Basically, I agree with Jürgen
I see section 4.7:

        This section MUST be patterned after the latest approved template
        (available athttp://trac.tools.ietf.org/area/ops/trac/wiki/
    <http://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines>
        yang-security-guidelines
    <http://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines>).Section 7.1
    <https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-12#section-7.1>  contains the security
        considerations template dated 2013-05-08.  Authors MUST check the WEB
        page at the URL listed above in case there is a more recent version
        available.

Then, I see section 7:

       The following section contains the security considerations template
        dated 2010-06-16.

Not sure why it contains this cut/paste? It should just say: the latest 
version is at this URL.
Then, I see in the same section:

    This section MUST be patterned after the latest approved
        template (available at

         http://www.ops.ietf.org/netconf/yang-security-considerations.txt

This page is not found.
This should be corrected in rfc6087bis.


2. the new security guidelines must include RESTCONF.
At this point, this is a blocking factor for the publication of YANG 
module. As an example,
draft-ietf-lmap-yang-11 
<https://datatracker.ietf.org/doc/draft-ietf-lmap-yang/>, A YANG Data 
Model for LMAP Measurement Agents, on the telechat tomorrow.
As mentioned the most up to date version is 
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines

Here is the proposal, discussed on the YANG doctors list:


             OLD

        The YANG module defined in this memo is designed to be accessed
        via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is
        the secure transport layer, and the mandatory-to-implement
        secure transport is Secure Shell (SSH) [RFC6242]. The NETCONF
        access control model [RFC6536] provides the means to restrict
        access for particular NETCONF users to a pre-configured subset
        of all available NETCONF protocol operations and content.

        NEW

        The YANG module defined in this memo is designed to be accessed
        via the NETCONF [RFC6241] or RESTCONF [RFC8040] protocol. The
        lowest NETCONF layer is the secure transport layer, and
        mandatory-to-implement is Secure Shell (SSH) [RFC6242], while
        the lowest RESTCONF layer is HTTP, and the
        mandatory-to-implement secure transport is Transport Layer
        Security (TLS) [RFC5246].
        The NETCONF access control model [RFC6536] provides the means to
        restrict access for particular NETCONF or RESTCONF users to a
        pre-configured subset of all available NETCONF or RESTCONF
        protocol operations and content.

Any objections?
Have covered all that we need for the new RESTCONF protocol?

Regards, Benoit


> Hi,
>
> this came up during IESG processing of a YANG module - is there a new
> security guideline boilerplate text covering RESTCONF? This was
> briefly discussed on the yang-doctors but somehow the discussion
> stopped because RESTCONF was not published yet at that time. I think
> this affects draft-ietf-netmod-rfc6087bis-12.txt.
>
> draft-ietf-netmod-rfc6087bis-12.txt has several pointers to read
> online documents - why do we need several points? I think some are
> also not working. Ideally, there should be a single stable URL.
>
> /js
>