Re: [media-types] [Netconf] request review of media type application/yang-patch+json

[Sean Leonard <[e-mail]>]

Sorry I did not respond to this before.

Looks good. Same comments as application/yang-data+json. The template is 
copied and pasted below for mailing list reference.

Sean

On 6/28/2016 7:32 PM, Andy Bierman wrote:
> Hi,
>
> Please review and provide feedback on the media type registration
> for  the YANG Patch media type for the PATCH method.  This is used by
> the RESTCONF protocol.
>
>
> https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-09#section-4.2.2
>

       Type name: application

       Subtype name: yang-patch+json

       Required parameters: none

       Optional parameters: none

      // RFC Ed.: replacedraft-ietf-netmod-yang-json 
<https://tools.ietf.org/html/draft-ietf-netmod-yang-json>  with
      // the actual RFC reference for JSON Encoding of YANG Data,
      //  and remove this note.

      // RFC Ed.: replacedraft-ietf-netmod-yang-metadata 
<https://tools.ietf.org/html/draft-ietf-netmod-yang-metadata>  with
      // the actual RFC reference for JSON Encoding of YANG Data,
      //  and remove this note.

      // RFC Ed.: replace 'XXXX' with the real RFC number,
      // and remove this note

       Encoding considerations: 8-bit
          Each conceptual YANG data node is encoded according to
          [draft-ietf-netmod-yang-json 
<https://tools.ietf.org/html/draft-ietf-netmod-yang-json>]. A data annotation is
          encoded according to [draft-ietf-netmod-yang-metadata 
<https://tools.ietf.org/html/draft-ietf-netmod-yang-metadata>]
          In addition, the "yang-patch" YANG data template found
          in [RFCXXXX] defines the structure of a YANG Patch request.

      // RFC Ed.: replace 'NN' in Section NN of [RFCXXXX] with the
      // section number for Security Considerations
      // Replace 'XXXX' in Section NN of [RFCXXXX] with the actual
      // RFC number, and remove this note.

       Security considerations: Security considerations related
          to the generation and consumption of RESTCONF messages
          are discussed in Section NN of [RFCXXXX].
          Additional security considerations are specific to the
          semantics of particular YANG data models. Each YANG module
          is expected to specify security considerations for the
          YANG data defined in that module.

      // RFC Ed.: replace XXXX with actual RFC number and remove this
      // note.

       Interoperability considerations: [RFCXXXX] specifies format of
          conforming messages and the interpretation thereof.

      // RFC Ed.: replace XXXX with actual RFC number and remove this
      // note.

       Published specification: RFC XXXX

       Applications that use this media type: Instance document
         data parsers used within a protocol or automation tool
         that utilizes the YANG Patch data structure.

       Fragment identifier considerations: The fragment field in the
          request URI has no defined purpose.

       Additional information:

         Deprecated alias names for this type: n/a
         Magic number(s): n/a
         File extension(s): .json
         Macintosh file type code(s): "TEXT"

      // RFC Ed.: replace XXXX with actual RFC number and remove this
      // note.

       Person & email address to contact for further information: See
          Authors' Addresses section of [RFCXXXX].

       Intended usage: COMMON

       (One of COMMON, LIMITED USE, or OBSOLETE.)

       Restrictions on usage: n/a

      // RFC Ed.: replace XXXX with actual RFC number and remove this
      // note.

       Author: See Authors' Addresses section of [RFCXXXX].

       Change controller: Internet Engineering Task Force
          (mailto:iesg&ietf.org).

       Provisional registration? (standards tree only): no