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

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 5 Jul 2016 08:28:25 -0700

Andy requested a review on the update to media type registration for YANG patch. Note, there are two reviews, one for XML and another one for JSON.

Unless we hear otherwise by end of this week, we will go ahead with the suggested changes.

Thanks.

> On Jun 28, 2016, at 7:29 PM, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 
> Please review and provide feedback on the media type registration
> for  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.1 <https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-09#section-4.2.1>
> 
> 
> thanks,
> Andy

Mahesh & Mehmet

---

From: Sean Leonard <[email-masked]>
Date: Wed, 6 Jul 2016 11:53:38 -0700

Sorry I did not respond to this before.

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

Sean

On 6/28/2016 7:29 PM, Andy Bierman wrote:
> https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-09#section-4.2.1
>
>
> thanks,
> Andy

       Type name: application

       Subtype name: yang-patch+xml

       Required parameters: none

       Optional parameters: none

      // RFC Ed.: replacedraft-ietf-netmod-rfc6020bis 
<https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis>  with
      // the actual RFC reference for YANG 1.1, 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
          XML Encoding Rules and Canonical Format for the specific
          YANG data node type defined in [draft-ietf-netmod-rfc6020bis 
<https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis>].
          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): .xml
         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