Re: [secdir] Review of draft-ietf-netmod-schema-mount-10

[Shawn Emery <[e-mail]>]

Hi Martin,

Ah, that would explain the disjointed text.  Thanks for the followup and
the reference.  I'm fine with the original text in this case, given the
scope of work otherwise.

Regards,

Shawn.
--
On Tue, Aug 7, 2018 at 2:56 AM, Martin Bjorklund <[e-mail]> wrote:

> Hi Shawn,
>
> As mentioned, this text comes from the YANG security template
> (https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) that
> has been approved by the security ADs.
>
> [This doesn't mean that the text can't be changed, but if it needs to
> be changed, the template should be changed (after being approved by
> the ADs).]
>
> But I brought this up in the WG, and a comment was made that *if* this
> change is made, we also need to change not just this sentence, but
> also the rest of the template; these are written as a list of data
> nodes/subtrees and their corresponding sensitivity/vulnerability. So,
> if the change is accepted, new drafts would need to be written as a
> list of sensitivities/vulnerabilities with the data nodes and subtrees
> to which they apply.
>
> So I suggest we keep the current text in this document.
>
>
> /martin
>
>
>
> Ladislav Lhotka <[e-mail]> wrote:
> > Hi Shawn,
> >
> > thank you for the review, please see my comment below.
> >
> > Shawn Emery <[e-mail]> writes:
> >
> > > Reviewer: Shawn M. Emery
> > > Review result: Ready with nits
> > >
> > > I have reviewed this document as part of the security directorate's
> > > ongoing effort to review all IETF documents being processed by the
> IESG.
> > > These comments were written primarily for the benefit of the security
> > > area directors. Document editors and WG chairs should treat these
> > > comments just like any other last call comments.
> > >
> > > This draft specifies a schema for YANG module mount points for yet
> another
> > > specified schema location.
> > >
> > > The security considerations section does exist and refers to transport
> > > security
> > > through SSH and HTTPS for NETCONF and RESTCONF, respectively.  For
> > > authorization, the spec refers to RFC 8341 for controlling NETCONF and
> > > RESTCONF user access.  Data that would be considered sensitive or
> subject
> > > to attack is briefly described and prescribes read access controls for
> said
> > > data.
> > > I agree with the authors' assertions.
> > >
> > > General comments:
> > >
> > > None.
> > >
> > > Editorial comments:
> > >
> > > OLD:
> > >
> > > These are the subtrees and data nodes and their
> sensitivity/vulnerability:
> > >
> > > NEW:
> > >
> > > The following should be considered for subtrees/data nodes and their
> > > corresponding
> > >
> > > sensitivity/vulnerability:
> > >
> >
> > The OLD formulation actually comes from RFC 6087, section 6.1 (Security
> > Considerations Section Template). Your NEW formulation indeed looks
> > better, so we will use it in the present draft, and I will also send it
> > to the netmod mailing list in order to apply this change in
> > draft-ietf-netmod-rfc6087bis.
> >
> > Thanks, Lada
> >
> > >
> > > Shawn.
> > > --
> >
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> >
>