Re: [alto] Murray Kucherawy's Discuss on draft-ietf-alto-cost-mode-04: (with DISCUSS and COMMENT)
On Thu, Jun 2, 2022 at 12:16 AM wrote: > Deal! > > > > As you can see at > https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-cost-mode-05, went with > a more verbose text to insist on this + add a MUST for implementations. > Ship it! -MSK ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
Re: [alto] Murray Kucherawy's Discuss on draft-ietf-alto-cost-mode-04: (with DISCUSS and COMMENT)
On Wed, Jun 1, 2022 at 11:54 PM wrote: > [Med] That wording was on purpose. We could easily turn that text into the > following: > > NEW: > If the definition of a cost mode does not indicate whether it > applies to a subset of cost metrics, ALTO implementations > MUST be prepared to accept that cost mode for any cost metric. > > ... but there is a high risk that this behavior will overlooked and thus > the default mode will be the rule. This would have interoperability > implications as it is likely that some modes can't be associated with all > cost metrics. > > The SHOULD is some sort of authors guideline to assess the applicability > and record it. > Hi Mohamed, Understood. I suggest using "should" rather than "SHOULD", and then saying something like what you just said here to underscore why it's important for future documents to go into this. -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-unified-props-new-21: (with COMMENT)
Thanks! Looks good to me. On Mon, Feb 28, 2022 at 12:07 PM Randriamasy, Sabine (Nokia - FR/Paris-Saclay) wrote: > Hello Murray, > > > > The V24 is up now, for your review > > Thanks, > > Sabine > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/ > > > > There is also an htmlized version available at: > > https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-24 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-24 > > > > > > > > *From:* Murray S. Kucherawy > *Sent:* Monday, February 28, 2022 4:09 PM > *To:* Randriamasy, Sabine (Nokia - FR/Paris-Saclay) < > sabine.randriam...@nokia-bell-labs.com> > *Cc:* The IESG ; draft-ietf-alto-unified-props-...@ietf.org; > alto-cha...@ietf.org; alto@ietf.org; Vijay Gurbani < > vijay.gurb...@gmail.com> > *Subject:* Re: Murray Kucherawy's No Objection on > draft-ietf-alto-unified-props-new-21: (with COMMENT) > > > > Thanks, those all sound like improvements to me. If you let me know when > -24 is up, I can review it once more. > > > > On Mon, Feb 28, 2022 at 6:38 AM Randriamasy, Sabine (Nokia - > FR/Paris-Saclay) wrote: > > Hello Murray, > Thank you very much for your review and guidance. > I apologize as I realized I have not integrated all of the related updates > in the v23 that has been posted. > To avoid confusion for the other reviewers, please find inline our related > proposed updates. > A v24 integrating these updates is ready to be posted. > We refer to V24 for comments that are reflected in the V24 to be posted. > Please let us know whether they meet your expectations. > Thanks, > Sabine and co-authors > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/ > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-23 > > >-Original Message- > >From: Murray Kucherawy via Datatracker > >Sent: Sunday, December 5, 2021 8:21 AM > >To: The IESG > >Cc: draft-ietf-alto-unified-props-...@ietf.org; alto-cha...@ietf.org; > >alto@ietf.org; Vijay Gurbani > >Subject: Murray Kucherawy's No Objection on draft-ietf-alto-unified-props- > >new-21: (with COMMENT) > > > >Murray Kucherawy has entered the following ballot position for > >draft-ietf-alto-unified-props-new-21: 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-unified-props-new/ > > > > > > > >-- > >COMMENT: > >-- > > > >I support Francesca's DISCUSS. > > > [ [SR] ] This issue has been solved in version 22 and you may refer to > Francesca's feedback > > >The shepherd writeup says: > > > > The chair has received IPR declarations from Richard Yang, Sabine > >Randriamasy, > > Jensen Zhang, Wendy Roome, and Kai Gao. During the discussion of this > I-D > > in the working group, no IPR issues has been raised to the best of my > > knowledge. > > > >Just to be clear, I presume what the chair actually received was > affirmations of > >compliance with BCP 78 and 79 from those people, and not declarations of > the > >existence of IPR. > > > [ [SR] ] Indeed, the chairs have received in November 2020, from the > authors a message saying "To the best of my knowledge, all IPR related to > the Unified Properties document has been disclosed.". I am not aware of any > existence of IPR related to this draft. Maybe Med and Qin can confirm. > > >The "Interoperability considerations" part of Section 12.1 doesn't seem > to be a > >complete answer to the corresponding guidance in Section 6.2 of RFC 6838. > > > [ [SR] ] In V23, the content for this part has been set to "n/a" in > sections 12.1 and 12.2. Please note that Section 12.1 of V21 is now split > in 2
Re: [alto] Murray Kucherawy's No Objection on draft-ietf-alto-unified-props-new-21: (with COMMENT)
Thanks, those all sound like improvements to me. If you let me know when -24 is up, I can review it once more. On Mon, Feb 28, 2022 at 6:38 AM Randriamasy, Sabine (Nokia - FR/Paris-Saclay) wrote: > Hello Murray, > Thank you very much for your review and guidance. > I apologize as I realized I have not integrated all of the related updates > in the v23 that has been posted. > To avoid confusion for the other reviewers, please find inline our related > proposed updates. > A v24 integrating these updates is ready to be posted. > We refer to V24 for comments that are reflected in the V24 to be posted. > Please let us know whether they meet your expectations. > Thanks, > Sabine and co-authors > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/ > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-23 > > >-Original Message- > >From: Murray Kucherawy via Datatracker > >Sent: Sunday, December 5, 2021 8:21 AM > >To: The IESG > >Cc: draft-ietf-alto-unified-props-...@ietf.org; alto-cha...@ietf.org; > >alto@ietf.org; Vijay Gurbani > >Subject: Murray Kucherawy's No Objection on draft-ietf-alto-unified-props- > >new-21: (with COMMENT) > > > >Murray Kucherawy has entered the following ballot position for > >draft-ietf-alto-unified-props-new-21: 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-unified-props-new/ > > > > > > > >-- > >COMMENT: > >-- > > > >I support Francesca's DISCUSS. > > > [ [SR] ] This issue has been solved in version 22 and you may refer to > Francesca's feedback > > >The shepherd writeup says: > > > > The chair has received IPR declarations from Richard Yang, Sabine > >Randriamasy, > > Jensen Zhang, Wendy Roome, and Kai Gao. During the discussion of this > I-D > > in the working group, no IPR issues has been raised to the best of my > > knowledge. > > > >Just to be clear, I presume what the chair actually received was > affirmations of > >compliance with BCP 78 and 79 from those people, and not declarations of > the > >existence of IPR. > > > [ [SR] ] Indeed, the chairs have received in November 2020, from the > authors a message saying "To the best of my knowledge, all IPR related to > the Unified Properties document has been disclosed.". I am not aware of any > existence of IPR related to this draft. Maybe Med and Qin can confirm. > > >The "Interoperability considerations" part of Section 12.1 doesn't seem > to be a > >complete answer to the corresponding guidance in Section 6.2 of RFC 6838. > > > [ [SR] ] In V23, the content for this part has been set to "n/a" in > sections 12.1 and 12.2. Please note that Section 12.1 of V21 is now split > in 2 sections (i) 12.1. application/alto-propmap+json Media Type and (ii) > 12.2. alto-propmapparams+json Media Type > > >I'm bothered by the dangling SHOULD in Section 12.2.2. If you're going to > >include that, I suggest including some guidance about when it would be > >legitimate to omit that information from a registration and still expect > it to go > >through. > > > [ [SR] ] V24 - (now Section 12.3.2 in v23-24) Agreed. Thanks for noticing > this. In V24, to be consistent with Section 5.1.1, the SHOULD has been > replaced with MUST. > > >The second-last paragraph in Section 12.3 appears to be broken. > > > [ [SR] ] in V24, the "It" has been removed, thanks > > >For Sections 12.2 and 12.3, I suggest not including a registry entry for > "priv:" > >because that's not an identifier, but everything else is. It's fine to > leave in > >prose saying nothing can be registered using "priv:" as a prefix, as > those are > >meant to indicate private use. > > > [ [SR] ] the "priv" entry has been removed from Table 2 and Table 3 in v23 > >[I-D.gao-alto-fcs] has expired. What's the plan here? It's an > informative > >reference. > > > [ [SR] ] in V23 the reference has been removed > > >I had the same thought as Ben did about the use of "GET-mode" and "POST- > >mode". > > > [ [SR] ] in v23, we updated item 3 of parag 5 as follows > OLD > The former is a GET-mode resource that > returns the property values for all entities in one or more entity > domains, and is analogous to a network map or a cost map in > Section 11.2 of [RFC7285]. The latter is a POST-mode resource > that returns... > NEW > The former a
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 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
