Hi, Ben:
I would like to ping your feedback on Sabine's response, thanks in advance. The
new version will come soon after getting your feedback.
-Qin (On behalf of chairs)
-邮件原件-
发件人: Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
[mailto:sabine.randriam...@nokia-bell-labs.com]
发送时间: 2021年12月21日 22:23
收件人: Benjamin Kaduk ; The IESG
抄送: draft-ietf-alto-unified-props-...@ietf.org; alto-cha...@ietf.org;
alto@ietf.org; Vijay Gurbani
主题: RE: Benjamin Kaduk's Discuss on draft-ietf-alto-unified-props-new-21: (with
DISCUSS and COMMENT) - DISCUSS + COMMENTS on section
Hello Benjamin,
Thank you very much for your thorough review and guidance.
The present e-mail addresses your DISCUSS points and COMMENTS on section 10, as
they relate to a DISCUSS point.
Please see the responses inline.
The other COMMENTS and NITS will be addressed in a separate e-mail.
Best regards,
Sabine, Jensen, Kai, Richard
>-Original Message-
>From: Benjamin Kaduk via Datatracker
>Sent: Thursday, December 2, 2021 12:00 AM
>To: The IESG
>Cc: draft-ietf-alto-unified-props-...@ietf.org; alto-cha...@ietf.org;
>alto@ietf.org; Vijay Gurbani ;
>vijay.gurb...@gmail.com
>Subject: Benjamin Kaduk's Discuss on draft-ietf-alto-unified-props-new-21:
>(with DISCUSS and COMMENT)
>
>Benjamin Kaduk has entered the following ballot position for
>draft-ietf-alto-unified-props-new-21: Discuss
>
>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/
>
>
>
>--
>DISCUSS:
>--
>
>(1) Section 8.6 seems to have some conflicting requirements. The
>filtered property map response "MUST include all the inherited property
>values for the requested entities and all the entities which are able
>to inherit property values from the requested entities." We then go on
>to say that to do this, the server MAY follow three rules, that
>themselves include SHOULD-level guidance, but don't say how the MUST is
>achieved if the SHOULDs or MAY are ignored. I was expecting to see a
>construction of the form "SHOULD do X, but if not, MUST do Y".
>
[ [SR] ]
Indeed the requirements need to set clear rules. We propose to update the text
as follows:
OLD
...
To achieve this goal, the ALTO server MAY follow three rules:
* If a property for a requested entity is inherited from another
entity not included in the request, the response SHOULD include
this property for the requested entity. For example, A full
property map may skip a property P for an entity A (e.g.,
ipv4:192.0.2.0/31) if P can be derived using inheritance from
another entity B (e.g., ipv4:192.0.2.0/30). A filtered property
map request may include only A but not B. In such a case, the
property P SHOULD be included in the response for A.
* If there are entities covered by a requested entity but having
different values for the requested properties, the response SHOULD
include all those entities and the different property values for
them. For example, considering a request for property P of entity
A (e.g., ipv4:192.0.2.0/31), if P has value v1 for
A1=ipv4:192.0.2.0/32 and v2 for A2=ipv4:192.0.2.1/32, then, the
response SHOULD include A1 and A2.
* If an entity identifier in the response is already covered by
other entities identifiers in the same response, it SHOULD be
removed from the response, for the sake of compactness. In the
previous example, the entity A = ipv4:192.0.2.0/31 SHOULD be
removed because A1 and A2 cover all the addresses in A.
NEW
...
To achieve this goal, the ALTO server MUST follow two rules:
* If a property for a requested entity is inherited from another
entity not included in the request, the response MUST include
this property for the requested entity. For example, A full
property map may skip a property P for an entity A (e.g.,
ipv4:192.0.2.0/31) if P can be derived using inheritance from
another entity B (e.g., ipv4:192.0.2.0/30). A filtered property
map request may include only A but not B. In such a case, the
property P MUST be included in the response for A.
* If there are entities covered by a requested entity but having
different values for the requested properties, the response MUST
include all those entities and the different property values for
them. For example, considering a request for property P of entity
A (e.g.,
