Looks good to me. 

However, I think we should change:

s/and mandatory-to-implement is Secure Shell/

and the mandatory-to-implement secure transport is Secure Shell/

 

Mehmet

 

From: netmod [mailto:[email protected]] On Behalf Of Benoit Claise
Sent: Wednesday, March 15, 2017 5:45 PM
To: [email protected]
Cc: [email protected]
Subject: Re: [netmod] security considerations boilerplate updates to cover
RESTCONF

 

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 at http://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
 

 

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to