Re: [alto] Murray Kucherawy's No Objection on draft-ietf-alto-cdni-request-routing-alto-17: (with COMMENT)
Hi Murray, A new version that echoes the replies already provided in this thread is available: URL:https://www.ietf.org/archive/id/draft-ietf-alto-cdni -request-routing-alto-18.txt Status: https://datatracker.ietf.org/doc/draft-ietf-alto-cdni -request-routing-alto/ Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-alto-cdni -request-routing-alto-18 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-cdni -request-routing-alto-18.txt Some more context is provided inline for some changes made in this version to better address your comments. Please let me know if you still have any comments. Thanks. Cheers, Jensen On Fri, Dec 10, 2021 at 12:05 AM Murray S. Kucherawy wrote: > On Wed, Dec 8, 2021 at 3:44 AM Jensen Zhang > wrote: > >> >> What your text tells me is that your document describes what a valid >>> instance of this media type's payload looks like. That's sort of obvious >>> though. What RFC 6838 is asking for goes beyond that, and gives a few >>> examples of what you might want to discuss here. >>> >>> If there were no prior versions of this media type, and it has no known >>> incompatibilities with other protocols or character sets, etc., you can >>> simply put "None" in this part of the form. Or if there is something that >>> should be considered, this part of the form should include such a >>> discussion. >>> >> >> Many thanks for your clarification. As far as I know, the new registered >> media types do not have any prior versions. They do neither have any known >> incompatibility issues. Are you suggesting that we should explicitly put >> such statements in the paragraph? >> > > OK, so I think your "Interoperability Considerations" section should just > be "None". The text you have makes it unclear to me whether there are (or > are not) any concerns like what RFC 6838 anticipates. "None" is actually > more definitive. > Thanks. To make it consistent with other sections of the form, I change "Interoperability Considerations" to "n/a". I hope it addresses your concern. > > -MSK > ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
Re: [alto] Murray Kucherawy's No Objection on draft-ietf-alto-cdni-request-routing-alto-17: (with COMMENT)
On Wed, Dec 8, 2021 at 3:44 AM Jensen Zhang wrote: > > What your text tells me is that your document describes what a valid >> instance of this media type's payload looks like. That's sort of obvious >> though. What RFC 6838 is asking for goes beyond that, and gives a few >> examples of what you might want to discuss here. >> >> If there were no prior versions of this media type, and it has no known >> incompatibilities with other protocols or character sets, etc., you can >> simply put "None" in this part of the form. Or if there is something that >> should be considered, this part of the form should include such a >> discussion. >> > > Many thanks for your clarification. As far as I know, the new registered > media types do not have any prior versions. They do neither have any known > incompatibility issues. Are you suggesting that we should explicitly put > such statements in the paragraph? > OK, so I think your "Interoperability Considerations" section should just be "None". The text you have makes it unclear to me whether there are (or are not) any concerns like what RFC 6838 anticipates. "None" is actually more definitive. -MSK ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
Re: [alto] Murray Kucherawy's No Objection on draft-ietf-alto-cdni-request-routing-alto-17: (with COMMENT)
On Wed, Dec 8, 2021 at 3:02 PM Murray S. Kucherawy
wrote:
> On Tue, Dec 7, 2021 at 4:03 AM Jensen Zhang
> wrote:
>
>>
>> The "Interoperability considerations" part of Section 7.1 doesn't seem to
>>> be a
>>> complete answer to the corresponding guidance in Section 6.2 of RFC 6838.
>>>
>>>
>> The authors will be appreciated if you can give any further comments or
>> suggestions on this.
>> For our understanding, the referenced sections in the registration table
>> ("Specification" column) have described the structure and parsing of the
>> corresponding messages. Are they not enough for the "Interoperability
>> considerations"? Could you give any tips about what is missing here? Many
>> thanks.
>>
>
> Sure. The paragraph I'm citing in RFC 6838 says this about
> Interoperability Considerations:
>
> Any issues regarding the interoperable use of types employing this
> structured syntax should be given here. Examples would include
> the existence of incompatible versions of the syntax, issues
> combining certain charsets with the syntax, or incompatibilities
> with other types or protocols.
>
> Your document has this text:
>
> This document specifies formats of conforming messages and the
> interpretation thereof.
>
> What your text tells me is that your document describes what a valid
> instance of this media type's payload looks like. That's sort of obvious
> though. What RFC 6838 is asking for goes beyond that, and gives a few
> examples of what you might want to discuss here.
>
> If there were no prior versions of this media type, and it has no known
> incompatibilities with other protocols or character sets, etc., you can
> simply put "None" in this part of the form. Or if there is something that
> should be considered, this part of the form should include such a
> discussion.
>
Many thanks for your clarification. As far as I know, the new registered
media types do not have any prior versions. They do neither have any known
incompatibility issues. Are you suggesting that we should explicitly put
such statements in the paragraph?
Jensen
>
> -MSK
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
Re: [alto] Murray Kucherawy's No Objection on draft-ietf-alto-cdni-request-routing-alto-17: (with COMMENT)
On Tue, Dec 7, 2021 at 4:03 AM Jensen Zhang
wrote:
>
> The "Interoperability considerations" part of Section 7.1 doesn't seem to
>> be a
>> complete answer to the corresponding guidance in Section 6.2 of RFC 6838.
>>
>>
> The authors will be appreciated if you can give any further comments or
> suggestions on this.
> For our understanding, the referenced sections in the registration table
> ("Specification" column) have described the structure and parsing of the
> corresponding messages. Are they not enough for the "Interoperability
> considerations"? Could you give any tips about what is missing here? Many
> thanks.
>
Sure. The paragraph I'm citing in RFC 6838 says this about
Interoperability Considerations:
Any issues regarding the interoperable use of types employing this
structured syntax should be given here. Examples would include
the existence of incompatible versions of the syntax, issues
combining certain charsets with the syntax, or incompatibilities
with other types or protocols.
Your document has this text:
This document specifies formats of conforming messages and the
interpretation thereof.
What your text tells me is that your document describes what a valid
instance of this media type's payload looks like. That's sort of obvious
though. What RFC 6838 is asking for goes beyond that, and gives a few
examples of what you might want to discuss here.
If there were no prior versions of this media type, and it has no known
incompatibilities with other protocols or character sets, etc., you can
simply put "None" in this part of the form. Or if there is something that
should be considered, this part of the form should include such a
discussion.
-MSK
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
Re: [alto] Murray Kucherawy's No Objection on draft-ietf-alto-cdni-request-routing-alto-17: (with COMMENT)
Hi Murray,
Thanks for your comments. Please see the authors' response inline.
Thanks,
Jensen
On Mon, Dec 6, 2021 at 3:44 PM Murray Kucherawy via Datatracker <
nore...@ietf.org> wrote:
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-alto-cdni-request-routing-alto-17: No Objection
>
> 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/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-alto-cdni-request-routing-alto/
>
>
>
> --
> COMMENT:
> --
>
> I concur with Francesca's DISCUSS.
>
> Please provide at least one complete sentence in Sections 3.3, 3.4, 5.4,
> 6.1.1.1, and 6.1.2.1. For example:
>
> There are no applicable Accept Input parameters.
>
That makes sense. We have added such sentences in the coming revision.
Thanks.
>
> The "Interoperability considerations" part of Section 7.1 doesn't seem to
> be a
> complete answer to the corresponding guidance in Section 6.2 of RFC 6838.
>
>
The authors will be appreciated if you can give any further comments or
suggestions on this.
For our understanding, the referenced sections in the registration table
("Specification" column) have described the structure and parsing of the
corresponding messages. Are they not enough for the "Interoperability
considerations"? Could you give any tips about what is missing here? Many
thanks.
>
>
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
