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

[Mahesh Jethanandani <[e-mail]>]

Alexey,

Andy has addressed your Comment on the document, either by updates in -13 of the document or by responding to this e-mail. However there is one issue which needs your attention. See below:

> On Nov 2, 2016, at 6:44 AM, Andy Bierman <[e-mail]> wrote:
> 
> 
> 
> On Tue, Nov 1, 2016 at 7:17 AM, Mahesh Jethanandani <[e-mail] <mailto:[e-mail]>> wrote:
> And Alexey's comments too.
> 
> Mahesh Jethanandani
> [e-mail] <mailto:[e-mail]>
> 
> > On Oct 29, 2016, at 12:53 PM, Alexey Melnikov <[e-mail] <mailto:[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 <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/ <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.
> 
> 
> 
>  
> >
> >      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.
> 
>  
> > 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?

Andy asked this question, but did not get a response on it. Do you still feel the need to register a new file extension for this media type?

> 
> 
> >
> 
> 
> Andy
> 

Mahesh Jethanandani
[e-mail]