I¹m if I looked hard enough I'd find it. However, I imagine many others will have the same question.
Where is Wiki or format URL where the boilerplate will be maintained? Thanks, Acee On 3/17/17, 11:36 AM, "netmod on behalf of Kent Watsen" <netmod-boun...@ietf.org on behalf of kwat...@juniper.net> wrote: > >Adding a final thought to this, I found it strange when I copied the >Security guidelines into some of my YANG-model focused drafts, that >I suddenly had to add Informative References for some transport >protocols. Why should a YANG model care about transport protocols? >Are we going to extend this statement to include all future protocols >too (CoAP, gRPC, etc.)? Not to mention YANG modules that only define >an artifact (i.e. rc:yang-data). Where does it end? > >I think the 90% of the guidelines are okay, putting focus on select >readable nodes, writable nodes, and RPCs is good. It's just the >first paragraph I have issue with. The more I think about it, the >more I think the first paragraph should, for the most part, disappear. > >K. // contributor > > > >-----ORIGINAL MESSAGE----- > >Kent Watsen <kwat...@juniper.net> writes: > >> A couple comments: >> >> 1) drilling down on the mandatory-to-implement NC/RC protocols >> is somewhat missing the point. The important bit is that >> *all* protocols transporting YANG-modeled data *only* have >> secure transport layers. More specifically, YANG-modeledq >> data may be transported over other protocols (e.g., coap), >> and also one of the protocols have an insecure transport >> protocol (e.g., it doesn't much help to talk about HTTPS >> being mandatory-to-implement if RESTCONF allowed HTTP). > >I agree, and it will become even more relevant if we make YANG >protocol-independent. In fact, data models may be useful even without >any network transport involved, e.g. for a local CLI implementation. > >> >> 2) just stating that there are secure transport layers still >> isn¹t sufficient, as these protocols must also require >> mutual authentication in order to be secure, and for >> statements regarding NACM to make sense. The text I posted >> before had a statement like this in it. > >Right, security considerations attached to data models should deal with >security aspects of the static data (which items are security-sensitive >etc.) and not with transport security. > >Lada > >> >> I'm beginning to become a fan of the idea of defining a generic >> "Requirements for Protocols Transporting YANG-modeled Data" >> document - that would not only discuss security aspects, but >> also generic protocol operations, that documents like NC, RC, >> CoAP, etc. can point to...and even YANG (RFC 7950), rather than >> pointing directly at NETCONF as it does today... >> >> Kent // contributor >> >> >> On 3/16/2017 8:56 AM, Juergen Schoenwaelder wrote: >>> On Thu, Mar 16, 2017 at 08:37:39AM +0100, Benoit Claise wrote: >>>> Latest proposal: >>>> >>>> The YANG module defined in this document is designed to be >>>>accessed >>>> via network management protocols such as NETCONF [RFC6241] or >>>> RESTCONF [RFC8040]. The lowest NETCONF layer is the secure >>>>transport >>>> layer, >>>> and mandatory-to-implement secure transport 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]. >>> Picking wording from Section 12 of RFC 8040 to replace your second >>> sentence I get this: >>> >>> The YANG module defined in this document is designed to be >>> accessed via network management protocols such as NETCONF >>> [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the >>> secure transport layer, and the mandatory-to-implement secure >>> transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF >>> layer is HTTPS, and the mandatory-to-implement secure transport is >>> 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. >> Yes, thank you. >> >> Regards, B. >>> >>> /js >>> >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > >-- >Ladislav Lhotka, CZ.NIC Labs >PGP Key ID: 0xB8F92B08A9F76C67 > > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
