Subject: Re: [alto] Erik Kline's No Objection on draft-ietf-alto-unified-props-new-21: (with COMMENT)

From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Tue, 22 Feb 2022 19:55:49 +0000

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-masked]>
>Sent: Tuesday, November 30, 2021 1:56 AM
>To: The IESG <[email-masked]>
>Cc: [email-masked]; [email-masked];
>[email-masked]; Vijay Gurbani <[email-masked]>;
>[email-masked]
>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.

---

From: Erik Kline <[email-masked]>
Date: Tue, 22 Feb 2022 18:16:22 -0800

These all seem fine to me; thanks!

On Tue, Feb 22, 2022 at 11:55 AM Randriamasy, Sabine (Nokia -