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

[Alexey Melnikov <[e-mail]>]

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/statement/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.
>  
>> >
>> >      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.

How do you know?

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

>> > 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
>