Re: [Netconf] Alexey Melnikov's Yes on draft-ietf-netconf-yang-patch-12: (with COMMENT)

[Andy Bierman <[e-mail]>]

On Fri, Nov 11, 2016 at 7:11 AM, Alexey Melnikov <[e-mail]>
wrote:

> Hi Andy,
>
> On 2 Nov 2016, at 00:44, Andy Bierman <[e-mail]> wrote:
>
> On Tue, Nov 1, 2016 at 7:17 AM, Mahesh Jethanandani <
> [e-mail]> wrote:
>
>> And Alexey's comments too.
>>
>> Mahesh Jethanandani
>> [e-mail]
>>
>> > On Oct 29, 2016, at 12:53 PM, Alexey Melnikov <[e-mail]>
>> wrote:
>> >
>> > Alexey Melnikov has entered the following ballot position for
>> > draft-ietf-netconf-yang-patch-12: Yes
>> >
>> > When responding, please keep the subject line intact and reply to all
>> > email addresses included in the To and CC lines. (Feel free to cut this
>> > introductory paragraph, however.)
>> >
>> >
>> > Please refer to https://www.ietf.org/iesg/stat
>> ement/discuss-criteria.html
>> > for more information about IESG DISCUSS and COMMENT positions.
>> >
>> >
>> > The document, along with other ballot positions, can be found here:
>> > https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-patch/
>> >
>> >
>> >
>> > ----------------------------------------------------------------------
>> > COMMENT:
>> > ----------------------------------------------------------------------
>> >
>> > Thank you for a well written document. A couple of small nits in your
>> > media type registration:
>> >
>> > 4.2.1.  Media Type application/yang-patch+xml
>> >
>> >      Subtype name: yang-patch
>> >
>> > Should be "yang-patch+xml"
>> >
>>
>
> OK
>
>
>
>> >      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 [RFC7950].
>> >         In addition, the "yang-patch" YANG Patch template found
>> >         in [RFCXXXX] defines the structure of a YANG Patch request.
>> >
>> > If you are allowing any of UTF-16 encodings, then the above is not
>> > correct and should say "Binary".
>>
>
>
> I don't think we are supporting anything outside of what RESTCONF supports.
> The media type registrations in RESTCONF say 8-bit.
>
>
> Then it might be broken too.
>

It was approved already, so take it up with th IESG



>
>
>> >
>> >      Fragment identifier considerations: Fragment identifiers
>> >         for this type are not defined.
>> >
>> > I suggest you just say "The same as for application/xml".
>> >
>>
>
> OK.  This media type is never sent by the server, only the client,
> and fragments are only sent by a server, so there is no requiement
> to support XPointer.
>
>
>

>

> Why limit how it is used? Remember, this is also used when emailing files,
> etc.
>


It is only defined to be used within RESTCONF
Current draft says 'same as application/xml' anyway.


Andy


>
>

> > It would be good if you register a new file extension for this media
>> > type.
>> >
>>
>
>
> We asked the WG and nobody wanted a file extension for these media types.
> We were planning to change the registration to say 'None' for file
> extensions.
>
> Does anybody have a proposal for the file extension for this media type?
>
>
> Just a good practice.
>
>
> >
>>
>
>
> Andy
>
>