Subject: [Netconf] request review of media type application/yang-data+json

From: Andy Bierman <[email-masked]>
Date: Tue, 28 Jun 2016 19:27:05 -0700

Hi,

Please review and provide feedback on the revised media type registration
for the RESTCONF protocol.

https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-11.3.2

thanks,
Andy

---

From: Sean Leonard <[email-masked]>
Date: Tue, 28 Jun 2016 20:07:31 -0700

For application/yang-data+json:

    Type name: application

    Subtype name: yang-data+json

    Required parameters: none

    Optional parameters: none

   // RFC Ed.: replace draft-ietf-netmod-yang-json with
   // the actual RFC reference for JSON Encoding of YANG Data,
   //  and remove this note.

   // RFC Ed.: replace draft-ietf-netmod-yang-metadata with
   // the actual RFC reference for JSON Encoding of YANG Data,
   //  and remove this note.

    Encoding considerations: 8-bit
       Each conceptual YANG data node is encoded according to
       [draft-ietf-netmod-yang-json]. A data annotation is
       encoded according to [draft-ietf-netmod-yang-metadata]

   // 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 YANG defined data structures.

    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

---

From: Sean Leonard <[email-masked]>
Date: Tue, 28 Jun 2016 20:22:57 -0700

(Mostly a duplicate of application/yang-data+xml)

Based on the discussion on media-types@ and netconf@ that I have 
observed, the registration is in pretty good substantive shape. I have 
no substantive comments except for the fragment identifier, which I 
understand is not of consequence to YANG processors. I won't repeat my 
comments from application/yang-data+xml. Therefore the only thing to 
talk about is the JSON fragment thing:

On 6/28/2016 8:07 PM, Sean Leonard wrote:
> ...

As with application/yang-data+xml, you are supposed to match the +json 
fragment with how JSON works. RFC 6839 Section 3.1. But currently it 
(+json) doesn't do anything, in contrast to +xml, which does some stuff 
with XPointer.

Regards,

Sean