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

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 1 Nov 2016 07:17:52 -0700

And Alexey's comments too.

Mahesh Jethanandani
[email-masked]

> On Oct 29, 2016, at 12:53 PM, Alexey Melnikov <[email-masked]> 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"
> 
>      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".
> 
>      Fragment identifier considerations: Fragment identifiers
>         for this type are not defined.
> 
> I suggest you just say "The same as for application/xml".
> 
> It would be good if you register a new file extension for this media
> type.
> 
>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 1 Nov 2016 15:44:59 -0700

On Tue, Nov 1, 2016 at 7:17 AM, Mahesh Jethanandani <[email-masked]
> wrote:

> > https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-patch/

OK

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

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

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

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 11 Nov 2016 22:12:55 +0800

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 <[email-masked]> wrote:
> 
> 
> 
> On Tue, Nov 1, 2016 at 7:17 AM, Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> 
> > On Oct 29, 2016, at 12:53 PM, Alexey Melnikov <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> > https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-patch/ <https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-patch/>
> >
> >
> >
> We were planning to change the registration to say 'None' for file extensions.
> 

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?

Mahesh Jethanandani
[email-masked]

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 11 Nov 2016 17:11:34 +0200

Hi Andy,

> On 2 Nov 2016, at 00:44, Andy Bierman <[email-masked]> wrote:
> 
>> On Tue, Nov 1, 2016 at 7:17 AM, Mahesh Jethanandani <[email-masked]> wrote:

Then it might be broken too.
> and fragments are only sent by a server, so there is no requiement

How do you know?

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

> Does anybody have a proposal for the file extension for this media type?

Just a good practice.

---

From: Andy Bierman <[email-masked]>
Date: Fri, 11 Nov 2016 09:14:57 -0800

> Then it might be broken too.

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

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

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

Andy

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 12 Nov 2016 10:57:28 +0900

Andy,

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

Different people on IESG are experts in different things. What you effectively said is that no bug can be accepted after the fact. It doesn't matter in this case, but I do find your attitude disturbing.

Best Regards,
Alexey

---

From: Andy Bierman <[email-masked]>
Date: Sat, 12 Nov 2016 02:13:39 -0800

On Fri, Nov 11, 2016 at 5:57 PM, Alexey Melnikov <[email-masked]>
wrote:

> Different people on IESG are experts in different things. What you
> effectively said is that no bug can be accepted after the fact. It doesn't
> matter in this case, but I do find your attitude disturbing.
>
Best Regards,

I do not see why RESTCONF and YANG Patch are broken because the
media types say 8-bit.  Please explain what breaks.

Andy

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 12 Nov 2016 23:03:38 +0900

Hi Andy,

> On 12 Nov 2016, at 19:13, Andy Bierman <[email-masked]> wrote:
> 
>> On Fri, Nov 11, 2016 at 5:57 PM, Alexey Melnikov <[email-masked]> wrote:
>> Andy,
>> 

I think you misunderstood: I didn't say that RESTCONF and YANG Patch are broken, I just said that the IANA registration template is slightly incorrect.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 13 Nov 2016 00:07:57 +0900

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

If you really dislike suggesting one, that is fine. It was only a comment.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Sat, 12 Nov 2016 23:57:31 +0800

> On Nov 12, 2016, at 11:07 PM, Alexey Melnikov <[email-masked]> wrote:
> 

Thanks. Will remove it from the list of issues holding up the draft. 

Mahesh Jethanandani 
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Sat, 12 Nov 2016 13:31:05 -0800

Hi,

Here are some examples of registrations:

cellml+xml

The charset parameter of application/cellml+xml is handled in the
same fashion as for application/xml, as specified in Section 3.2
of [RFC3023]. However, per conformance rule 4 of
[CELLML-UMBRELLA], valid CellML Umbrella documents MUST be in the
UTF-8 character set. If the charset parameter is present, it MUST
take the value "utf-8". CellML processing software SHOULD check
the charset field, and if it is present but not equal to "utf-8",
MAY attempt to recover from the error by processing the document
in the specified character set.

3gpdash-qoe-report+xml

Encoding considerations: 8bit
The utf-8 charset is always used for this type.

several use this text:

Encoding considerations:  Uses XML, which can employ 8-bit
   characters, depending on the character encoding used.  See RFC
   3023 [RFC3023], Section 3.2.

YANG data and YANG patch use UTF-8.
The UTF-16 charset is not used.
Can you suggest a registry entry that we should follow
to properly convey this requirement?

Andy

On Sat, Nov 12, 2016 at 6:03 AM, Alexey Melnikov <[email-masked]>
wrote:

> I think you misunderstood: I didn't say that RESTCONF and YANG Patch are
> broken, I just said that the IANA registration template is slightly
> incorrect.
>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 21 Nov 2016 15:47:12 -0800

Alexey,

> On Nov 12, 2016, at 6:03 AM, Alexey Melnikov <[email-masked]> wrote:
> 
> Hi Andy,
> 
> On 12 Nov 2016, at 19:13, Andy Bierman <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> On Fri, Nov 11, 2016 at 5:57 PM, Alexey Melnikov <[email-masked] <mailto:[email-masked]>> wrote:
>> Andy,
>> 
>> On 12 Nov 2016, at 02:14, Andy Bierman <[email-masked] <mailto:[email-masked]>> wrote:
>> 

Would it help if we said that RESTCONF supports media type of 8-bit by default, and that support for any other encoding can be added later, if need be?

Mahesh Jethanandani
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Nov 2016 15:55:19 -0800

On Mon, Nov 21, 2016 at 3:47 PM, Mahesh Jethanandani <
[email-masked]> wrote:

> Would it help if we said that RESTCONF supports media type of 8-bit by
> default, and that support for any other encoding can be added later, if
> need be?
>
>
I do not know how to write that text.
There is no "by default". There is only utf-8 required.
The charset parameter is not even supported in RESTCONF.
We cannot speculate in this version of YANG Patch as to
what charsets future versions of RESTCONF will require.

Andy

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 21 Nov 2016 22:19:14 -0800

Alexey, you consider the current media registration to be broken. However, Andy has given two examples of other media registrations which say something similar. Do you still consider the current template to be broken? If so, how would you suggest the entry should be modified? 

Thanks.

> On Nov 21, 2016, at 3:55 PM, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> On Mon, Nov 21, 2016 at 3:47 PM, Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>> wrote:
> Alexey,
> 
>> On Nov 12, 2016, at 6:03 AM, Alexey Melnikov <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Andy,
>>