Subject: [Netconf] review request for media type application/yang-patch

From: Andy Bierman <[email-masked]>
Date: Fri, 8 Jul 2016 16:10:48 -0700

Hi,

Here is the revised application/yang-patch media type registration request
(was application/yang-patch+xml)

      Type name: application

      Subtype name: yang-patch

      Required parameters: None

      Optional parameters: None

     // RFC Ed.: replace 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 the
         XML Encoding Rules and Canonical Format for the specific
         YANG data node type defined in [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 the 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 utilize 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

      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

---

From: Sean Leonard <[email-masked]>
Date: Tue, 19 Jul 2016 04:10:01 -0700

My feedback remains that these ought to remain application/yang-patch+xml and application/yang-data+xml.

I would be happy to be rebuked (with appropriate justifications), but have not heard compelling reasons to vary from that course.

Three observations:
1. If you occupy application/yang-patch as the XML variant now, what happens when you have CBOR or some other fancy format du jour? Now you’ve used up the “main one”.

2. Consider that image/svg+xml uses +xml, but doesn’t use XPointer for fragment identifiers. It uses “SVG barenames” or “SVG views”. See <http://www.w3.org/TR/SVG/mimereg.html>.

3. If the fragment identifier syntax is what’s causing the stumbling block, how about application/yang-patch-xml and application/yang-data-xml ? That keeps the format front-and-center but avoids the (perceived) fragment identifier stumbling block.

Best regards,

Sean

> On Jul 8, 2016, at 4:10 PM, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 
>          (mailto:
> iesg&ietf.org
> ).
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf