These all seem fine to me; thanks! On Tue, Feb 22, 2022 at 11:55 AM Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <[email protected]> wrote: > > Hello Erick, > > Thank you very much for your review and apologies for coming back to you so > late. > Please fine inline, answers and proposed updates upon your comments. > We look forward to having your feedback on our proposals. > Best regards, > Sabine and co-authors > > >-----Original Message----- > >From: Erik Kline via Datatracker <[email protected]> > >Sent: Tuesday, November 30, 2021 1:56 AM > >To: The IESG <[email protected]> > >Cc: [email protected]; [email protected]; > >[email protected]; Vijay Gurbani <[email protected]>; > >[email protected] > >Subject: Erik Kline's No Objection on draft-ietf-alto-unified-props-new-21: > >(with COMMENT) > > > >Erik Kline 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: > >---------------------------------------------------------------------- > > > >[S4.2, nit] > > > >* s/relatively to/relative to/, I think > [ [SR] ] thanks, we have corrected all the occurences > > > >[S4.3, nit] > > > >* s/be be/be/ > [ [SR] ] thanks, we have corrected > > > >[S4.4.2, comment] > > > >* I think the last sentence of the paragraph might be trying to say > > "may or may not inherit the property P...", because the inheritance > > rules for the property lowercase-must be defined? Also: lowercase must? > [ [SR] ] Would the proposed update clarify the text? > ==> > OLD > For instance, if a property P is defined only for the entity set > identified by address block "ipv4:192.0.1.0/24", the entity set > identified by "ipv4:192.0.1.0/30" and thus included in the former > set, may inherit the property P value from set "ipv4:192.0.1.0/24". > > NEW > For instance, suppose a property P is defined only for the entity set > defined by address block "ipv4:192.0.1.0/24". We know that entity > set "ipv4:192.0.1.0/30" is included in "ipv4:192.0.1.0/24". > Therefore, the entities of "ipv4:192.0.1.0/30" may inherit the value > of property P from set "ipv4:192.0.1.0/24", if an inheritance rule > from "ipv4" CIDR blocks to included "ipv4" CIDR blocks, is specified. > > > >[S6.1.2.2, comment] > > > >* I gather there is no value to allowing link-local scope identifiers to > > appear here. The current text does not support such a thing, but perhaps > > consider whether or not to explicitly note that "%25", "%eth0" are > > invalid. Maybe it doesn't need an explicit mention, though. > [ [SR] ] We propose to leave text as it is and not mention those invalid > identifiers. > > > >[S6.1.3, question] > > > >* Can this "undef" behavior be used to explicitly undefine an inherited > > property? > [ [SR] ] yes. This is reflected by item 1. Would the following be clearer? > OLD > "If that entity would inherit a value for that property, then the > ALTO server MUST return a "null" value for that property. In this > case, the ALTO client MUST recognize a "null" value as "no value" > and "do not apply the inheritance rules for this property." > NEW > "If entity X would inherit a value for property P, and if the ALTO server > decides to > say that "X has no value for P", then the > ALTO server MUST return a "null" value for that property on X. In this > case, the ALTO client MUST recognize a "null" value as "no value" > and interpret it as "do not apply the inheritance rules for this > property on X." > > > > For example, can "v4" be replaced with some "null" indicator in Figure 1 > > such that "ipv4:192.0.2.0/32" in Figure 2 becomes "(not defined)"? > [ [SR] ] As per item 1, if "v4" is replaced by "null", then ipv4:192.0.2.0/32 > gets the value "null" as well. > > > > If there is no such mechanism, should there be? > [ [SR] ] we believe such a mechanism, that decides to *not* apply inheritance > rules of a property P on a particular entity X that would otherwise inherit > the value of P is covered by item 1. > > > > >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
