Re: [alto] Benjamin Kaduk's Discuss on draft-ietf-alto-unified-props-new-21: (with DISCUSS and COMMENT) / updates on remaining COMMENTS

["Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[e-mail]>]

Hello Ben,

Again, thank you very much for your review and guidance.  While DISCUSS and COMMENTS on section 10 have been addressed in V22, we still owe you a reponse on the remaining comments.  
Please find inline how they have been addressed in V23.  
The text relating to DISCUSS and COMMENTS on Section 10 has been removed from this e-mail, for brevity.

The updates upon your remaining comments can be seen in V23
https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-23

Best regards,
Sabine

>-----Original Message-----
>From: Benjamin Kaduk via Datatracker <[e-mail]>
>Sent: Thursday, December 2, 2021 12:00 AM
>To: The IESG <[e-mail]>
>Cc: [e-mail]; [e-mail];
>[e-mail]; Vijay Gurbani <[e-mail]>;
>[e-mail]
>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/
>
>
>
>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>I suggest noting somewhere early-ish that the (semi-)formal notation defined
>in Section 8.2 of RFC 7285 will be used.
>
[ [SR] ] Section 1.1 "Terminology" has been renamed "Terminology and notation" with the following appended paragraph   
"This document uses the semi-formal notation defined in Section 8.2 of RFC 7285."

>Section 1
>
>   properties.  Furthermore, recent ALTO use cases show that properties
>   of entities such as network flows [RFC7011] and routing elements
>   [RFC7921] are also useful.  Such cases are documented in
>   [I-D.gao-alto-fcs].  The current EPS however is restricted to
>
>This is probably more relevant as a comment on draft-gao-alto-fcs than this
>document, but putting the ALTO server in a position to know about individual
>flows seems like a big privacy risk, especially in the face of pervasive
>monitoring (per RFC 7258).  It's not really clear that this is actually a good idea
>to do, and thus whether we want to mention it here.
>
[ [SR] ] agree. This paragraph now refers to [I-D.ietf-alto-path-vector]  and has been updated as follows:
OLD
 Furthermore, recent ALTO use cases show that properties
   of entities such as network flows [RFC7011] and routing elements
   [RFC7921] are also useful.  Such cases are documented in
   [I-D.gao-alto-fcs]. 
NEW
 Furthermore, recent ALTO use cases show that properties
   of entities such as abstracted network elements as defined in
      [I-D.ietf-alto-path-vector] are also useful. 
REFERENCE removed: [RFC7011]  and [I-D.gao-alto-fcs].

>Section 3.2.2
>
>There seems to be an unfortunate risk of conflation of parsing as ((entity
>domain) name) vs (entity (domain name)), with domain name being the
>widely-used term (see, e.g., RFC 8499).  Could we find some alternate
>terminology that doesn't suffer from this potential confusion?
>
[ [SR] ] We start section 3.2.2.  Entity Domain Name with the following paragraph. 
OLD
   "The name of an entity domain is defined in the scope of an ALTO
   server.  An entity domain name can sometimes be identical to the name
   of its relevant entity domain type.  ..."
NEW
In this document, the identifier of an entity domain is mostly called "entity domain name". 
The identifier of an entity domain is defined in the scope of an ALTO server. 
An entity domain identifier can sometimes be identical to the identifier 
of its relevant entity domain type...  "

>Section 4.4
>
>   For some domain types, entities can be grouped in a set and be
>   defined by the identifier of this set.  This is the case for domain
>
>>From a mathematical/set-theoretic perspective, this statement is
>trivially true for all domain types; that's just how sets work.  I think what we
>want to say here is that they can be efficiently grouped by utilizing an
>underlying structure for the entities in the given domain type.  That might
>become, for example, "For some domain types, there is an underlying
>structure that allows entities to efficiently be grouped into a set and be
>defined by the identifier of this set".
>
[ [SR] ] Thanks for this proposal. We replaced with your text.
OLD
   For some domain types, entities can be grouped in a set and be
   defined by the identifier of this set. 
NEW
For some domain types, there is an underlying structure that allows entities to 
efficiently be grouped into a set and be defined by the identifier of this set.

>Section 4.6
>
>   Besides, it is also necessary to inform a Client about which
>   associations of specific resources and entity domain types are
>   allowed, because it is not possible to prevent a Server from exposing
>   inappropriate associations.  [...]
>
>This reasoning is a bit hard for me to follow.  It's not possible to prevent a
>server from exposing nonsensical things, sure.  But often we would just define
>the correct operation of the protocol to be only exposing things that make
>sense, and if the server is noncompliant to the spec, things break accordingly.
>
[ [SR] ] This section means to help the Client prevent query failures, by detecting beforehand when the IRD erroneously exposes invalid associations. The Client will prevent failures by just ignoring the erroneously exposed associations. 
We have updated parag. 2 (after the items) as follows
OLD
   Besides, it is also necessary to inform a Client about which
   associations of specific resources and entity domain types are
   allowed, because it is not possible to prevent a Server from exposing
   inappropriate associations. 
NEW
Besides, it is not possible to prevent a Server from mistakenly exposing inappropriate associations of information resources and entity domain types. To prevent failures due to invalid queries, it is necessary to inform the Client about which associations are allowed.  

>Section 4.6.1
>
>   The defining information resource of a resource-specific entity
>   domain D is unique and has the following specificities:
>   [...]
>   *  its media type is unique and equal to the one that is specified
>      for the defining information resource of an entity domain type.
>
>I find this definition worrisom, as it seems to imply that the given resource
>only has one media type, implicily precluding the server from ever exposing
>the representation of that resource via a different media type.  This does not
>mesh well with my understanding of the HTTP ecosystem and the guidelines
>for using HTTP as a substrate for building other protocols.  For example, in
>draft-ietf-httpbis-semantics, we see that the notion of an HTTP resource is in
>some sense an abstract resource, and HTTP only conveys representations of
>that resource.  There can inherently be multiple representations of a given
>resource, and there is a media-type negotiation to determine what
>representation is returned.  Likewise, in
>https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-bcp56bis#section-4.16
>we see that it is an expected part of protocol evolution to define new media
>types that enable new functionality by virtue of the new format, even if the
>abstract resource being provided remains the same.
>
[ [SR] ] Indeed, this needed clarification, as pointed as well by Francesca's comment. 
We have updated this item as follows:
OLD
its media type is unique and equal to the one that is specified
      for the defining information resource of an entity domain type.
NEW
its media type is equal to the one that is specified for the
      defining information resource of an entity domain type.

>   A fundamental attribute of a defining information resource is its
>   media type.  There is a unique association between an entity domain
>
>Similarly here -- the media type is not a property of the resource, but rather of
>a representation that is conveyed over HTTP.
>[For brevity, I will try to not make further comments on this topic, though I
>think that the theme continues in other locations in the document.]
>
[ [SR] ] we use media-type as a characteristic of an ALTO information resource. We have changed the text as follows: 
OLD
A fundamental attribute of a defining information resource is its media type.  
NEW
A fundamental characteristic of a defining information resource is its media type.  

>I think that what ALTO wants is a new conceptual "ALTO resource type"
>that is distinct from an (HTTP) media type.  Unfortunately, I see that RFC 7285
>has already placed a strong emphasis on media types specifically, so
>addressing this topic might best be done as a separate work item.
>
[ [SR] ] all right, got it

>Section 5.1.1
>
>   [RFC8126] without a need to register with IANA.  All other entity
>   domain types appearing in an HTTP request or response with an
>   "application/alto-*" media type MUST be registered with the IANA,
>
>That's a rather unusually specific requirement to have it conditioned solely on
>the application/alto-* media type.  Often when we have such a requirement
>we would consider adding a note to the registry to help remind reviewers that
>the requirement exists, but I would rather advocate for removing the media-
>type specificity of the requirement, here.
>(Also in §5.2.1.)
>
[ [SR] ] OK, we have updated as follows. 
Note that this update is combined with other ones in this section to address other comments related to ":" and "priv:".  
OLD
All other entity
   domain types appearing in an HTTP request or response with an
   "application/alto-*" media type MUST be registered with the IANA,
NEW 
All entity domain types  that are not prefixed with "priv:" MUST be registered with the IANA,
in the "ALTO Entity Domain Type Registry", defined in Section 12.3,

Likewise we updated  5.2.1.  Entity Property Type, parag. 2
OLD
All other
   identifiers for entity property types appearing in an HTTP request or
   response with an "application/alto-*" media type MUST be registered
   in the "ALTO Entity Property Type Registry", defined in Section 12.3.
NEW (now in parag. 4, with section nb 12.4, due to IANA section changes)
All other 
   identifiers for entity property types MUST be registered
   in the "ALTO Entity Property Type Registry", defined in Section 12.4.

>   A Private Use entity domain type identifier and its associated
>   internal specification MUST apply to all the property maps of an IRD.
>
>I don't think I understand what this requirement is trying to say.  The best
>reading I can come up with so far is that it says "if there is a private use type
>identifier presented in an IRD, that entity domain type must be present in all
>of the property maps in the IRD.  On the face of it, that seems like an absurd
>requirement to meet, though, since even the primary types we're defining in
>this document are not going to all apply to all property maps.
>(Also in §5.2.1.)
>
[ [SR] ] agree, this needed clarification. We updated the sentence as follows:
OLD
A Private Use entity domain type identifier and its associated internal
   specification MUST apply to all the property maps of an IRD.
NEW
 The definition of a private use entity domain type MUST apply 
the same way in all property maps of an IRD where it is present.

Similarly, we updated  5.2.1.  Entity Property Type
OLD - parag. 3
A Private
   Use entity property type identifier and its associated internal
   specification MUST apply to all property maps of an IRD.
NEW - parag. 5
The definition of a private use entity property type MUST 
apply the same way in all property maps of an IRD where it is present.

>   identifier) to reduce potential collisions.  The format of the entity
>   identifiers (see Section 5.1.3) in that type of entity domain, as
>   well as any hierarchical or inheritance rules (see Section 5.1.4) for
>   those entities, MUST be specified at the same time.
>
>What does "specified at the same time" mean?  In the same document?
>
[ [SR] ] we have clarified as follows:
OLD 
MUST be specified at the same time.
NEW
MUST be specified in the IANA registration.

we did the same update in section 5.2.1

>Section 5.1.2.1
>
>   A resource-specific entity domain is identified by an entity domain
>   name constructed as follows.  It MUST start with a resource ID using
>   the ResourceID type defined in Section 10.2 of [RFC7285], followed by
>   the '.' separator (U+002E), followed by a string of the type
>   EntityDomainType specified in Section 5.1.1.
>
>This seems to disallow using the "priv:" form for (the "type" part of) resource-
>specific entity domain names.  Is that really intended?
>
[ [SR] ] Upon similar comments, the text of 5.1.1 has been revised to allow ":" on an entity domain type identifier with some constraints, namely:
 *  The colon (':', U+003A) character MUST NOT appear more than once,

   *  The colon character MUST NOT be used unless within the string
      "priv:",

   *  The string "priv:" MUST NOT be used unless it starts the string
      that identifies an entity domain type,

   *  For an entity domain type identifier with the "priv:" prefix , an
      additional string (e.g., company identifier or random string) MUST
      follow "priv:", to reduce potential collisions.

>Section 5.1.2.3
>
>   A self-defined entity domain can be viewed as a particular case of
>   resource-specific entity domain, where the specific resource is the
>   current resource that uses this entity domain.  In that case, for the
>   sake of simplification, the component "ResourceID" SHOULD be omitted
>   in its entity domain name.
>
>Why do we need the flexibility of allowing both X.X and .X to represent the
>same information?  Wouldn't it be simpler to only allow one form?
>Having a single well-specified procedure tends to result in more secure
>implementations.
>
[ [SR] ] Agree. To secure implementations, the SHOULD has been replaced with a MUST

>Section 5.2.1
>
>      However, when applied to an entity in a "pid" domain type, the
>      property would indicate the location of the center of all hosts in
>      this "pid" entity.
>
>I'd consider saying something less specific, like "would indicate a location
>representative of all hosts in this "pid" entry", avoiding the term "center" that
>invites questions of how it is computed.  (Similarly,
>§9.3 mentions the "barycenter" of a set of addresses.)
>
[ [SR] ] We have updated as follows:
Section 5.2.1
OLD
      However, when applied to an entity in a "pid" domain type, the
      property would indicate the location of the center of all hosts in
      this "pid" entity.
NEW
      However, when applied to an entity in a "pid" domain type, the
      property would indicate a location representative of all hosts in this "pid" entity"

Section 9.3.  Impact on Other Properties
OLD
a property such as fictitious "geo-location",
   defined on a set of IP addresses would have a value corresponding to
   the barycenter of this set of addresses.
NEW
a property such as fictitious "geo-location",
   defined on a set of IP addresses would have a value corresponding to
   a location representative of all the addresses in this set.

>Section 5.2.2
>
>   EntityPropertyName ::= [ResourceID]'.'[priv:]EntityPropertyType
>
>Should the "priv:" component be quoted here as a literal?
[ [SR] ] "priv:" is now implicitly integrated in the entity property type indentifier format, which is now 
EntityPropertyName ::= [[ResourceID]'.']EntityPropertyType

>
>Section 6.1.1.2
>
>   Individual addresses are strings as specified by the IPv4Addresses
>   rule of Section 3.2.2 of [RFC3986]; Hierarchical addresses are
>   prefix-match strings as specified in Section 3.1 of [RFC4632].  To
>
>The referenced section of RFC 4632 does not refer to "prefix-match strings" at
>all (and only once to "match" at all, not directly related to prefixes).  Please
>use the terminology of the referenced document to indicate the functionality
>that is being integrated.
>
[ [SR] ] we have update as follows
OLD
   Individual addresses are strings as specified by the IPv4Addresses
   rule of Section 3.2.2 of [RFC3986]; Hierarchical addresses are
   prefix-match strings as specified in Section 3.1 of [RFC4632].  
NEW
 Individual addresses are strings as specified by the IPv4address
   rule of Section 3.2.2 of [RFC3986]; Hierarchical addresses are
   strings as specified by the prefix notation of Section 3.1 of [RFC4632].

>Section 6.1.2.2
>
>   Individual addresses are strings as specified by Section 4 of
>   [RFC5952]; Hierarchical addresses are prefix-match strings as
>   specified in Section 7 of [RFC5952].  To define properties, an
>
>Is this the right reference for prefix-matching IPv6 addresses?  Section
>7 of RFC 5952 is quite short...
>
[ [SR] ] we have update as follows
OLD
   Individual addresses are strings as specified by Section 4 of
   [RFC5952]; Hierarchical addresses are prefix-match strings as
   specified in Section 7 of [RFC5952]. 
NEW
   Individual addresses are strings as specified by Section 4 of
   [RFC5952];
Hierarchical addresses are
   strings as specified by the IPv6 address prefixes notation in Section 2.3 of [RFC4291]

>Section 6.1.3
>
>   Both Internet address domains allow property values to be inherited.
>   Specifically, if a property P is not defined for a specific Internet
>   address I, but P is defined for a hierarchical Internet address C
>   which prefix-matches I, then the address I inherits the value of P
>   defined for the hierarchical address C.  If more than one such
>
>I think there's some room for tightening up the terminology around
>"hierarchical" addresses.  While we do use the term in some earlier parts of
>the document, it's not specifically defined anywhere that I found.  The usage
>in this section, on the other hand, seems like it would be easy to replace with
>discussion of "prefix"es and avoid the need for a new term.  If we do want to
>keep the "hierarchical" concept, I strongly suggest adding some terminology
>section that specifically defines what we use it to mean.
>
[ [SR] ] The term "hierarchical entity identifier" is introduced in section 4.4.1 Entity Hierarchy. 
At the end of parag 1, of 4.4.1, we added the following sentence
OLD
For example, the CIDR "ipv4:192.0.1.0/24" includes all the
   individual IPv4 entities identified by the CIDR "ipv4:192.0.1.0/26".
NEW
For example, the CIDR "ipv4:192.0.1.0/24" includes all the
   individual IPv4 entities identified by the CIDR "ipv4:192.0.1.0/26".
This document will sometimes use the term "hierarchical address" 
to refer to a hierarchical entity identifier. 
We besides hope that the term "hierarchical" addresses has been correctly defined in our 2 abovementionned updates.

Additionally, we have removed the term "prefix-match" in this paragraph, to keep the wording consistent, and updated as follows:
OLD 
   Both Internet address domains allow property values to be inherited.
   Specifically, if a property P is not defined for a specific Internet
   address I, but P is defined for a hierarchical Internet address C
   which prefix-matches I, ...
NEW
 Both Internet address domains allow property values to be inherited.
   Specifically, if a property P is not defined for a specific Internet
   address I, but P is defined for a hierarchical Internet address C
   which represents a set of addresses containing I, …

>Section 7.5
>
>   The "uses" field of a property map resource in an IRD entry specifies
>   dependent resources of this property map.  It is an array of the
>   resource ID(s) of the resource(s).
>
>This doesn't seem to add anything above the definition of the "uses"
>field from RFC 7285; shouldn't we be saying something about the defining
>information resource for resource-specific domains/properties (in addition to
>any other dependent resources)?
>
[ [SR] ] In RFC  7285, the "uses" field does not appear for the endpoint property service. We have rephrased as follows. 
OLD
   The "uses" field of a property map resource in an IRD entry specifies
   dependent resources of this property map.  It is an array of the
   resource ID(s) of the resource(s).
NEW
   The "uses" field of a property map resource in an IRD entry specifies
   the resources in this same IRD on which this property map directly depends. It is an array of 
   resource ID(s). This array identifies the defining information resources associated with 
 the resource-specific entity domains and properties that are  indicated in this resource.  

>Section 8.3
>
>                          If it is absent, the Server returns an empty
>      property value '{}' for all the entity IDs of the "entities" field
>      on which at least one property is defined.
>
>Is that the literal string "{}" or an empty JSON object?
[ [SR] ] it is literal "{}"
>Given the SHOULD-level guidance we give elsewhere to assume that the
>response is a string (or JSON null value, which both {} and "{}" are not), it
>seems important to provide clarity on this matter.
>
[ [SR] ] ===> We have updated as follows:
OLD
 If it is absent, the Server returns an empty
 property value '{}' for all the entity IDs of the "entities" field
 on which at least one property is defined.
NEW
 If it is absent, the Server returns a 
 property value equal to the literal string "{}" for all the entity IDs of the "entities" field
 on which at least one property is defined.

>Section 8.6
>
>Given that there are identifiers that can be interpreted as both an entity name
>and a property name, and we have the same error code for invalid entity
>identifier and invalid property name (with guidance to return the invalid
>identifier in the error message), are we setting up for a situation where the
>error message is ambiguous about which interpretation of the string was
>invalid?
>
[ [SR] ] we have added the following text after parag 2, (before "The response to a valid request...")
NEW
Some identifiers can be interpreted as both an entity name and a property name, 
as it is the case for "pid" if it would be erroneously used alone.
In such a case, the Server SHOULD follow Section 8.5.2 of RFC 7285, that says: 
"For an E_INVALID_FIELD_VALUE
   error, the server may include an optional field named "field" in the
   "meta" field of the response, to indicate the field that contains the
   wrong value."

>   *  The response only includes the entities and properties requested
>      by the client.  If an entity in the request is identified by a
>      hierarchical identifier (e.g., a "ipv4" or "ipv6" prefix), the
>      response MUST cover properties for all identifiers in this
>      hierarchical identifier.
>
>Just to check: the intent here is that we return all properties that are present
>on any address covered by the prefix, even though some of those properties
>may not be present on all addresses covered by the prefix?
>
[ [SR] ] yes. We have updated with your wording, which is clearer 
OLD
   *  The response only includes the entities and properties requested
      by the client.  If an entity in the request is identified by a
      hierarchical identifier (e.g., a "ipv4" or "ipv6" prefix), the
      response MUST cover properties for all identifiers in this
      hierarchical identifier.
NEW
   *  The response only includes the entities and properties requested
      by the client.  If an entity in the request is identified by a
      hierarchical identifier (e.g., a "ipv4" or "ipv6" prefix), the
      response MUST  return all properties that are present on any address 
    covered by the prefix, even though some of those properties may not 
   be present on all addresses covered by the prefix.

***************************
>Section 10.x
[ [SR] ]  Comments removed: addressed in V22
***************************
>
>Section 11
>
>   endpoint properties conveyed by using [RFC7285].  Client requests may
>   reveal details on their activity or plans thereof, that a malicious
>   user may monetize or use for attacks or undesired surveillance.
>
>This would be a malicious Server that's in a position to do so, right (vs.
>"user")?
>
[ [SR] ] yes, actually. We have updated as follows:
OLD
that a malicious
   user may monetize or use for attacks or undesired surveillance.
NEW
that a malicious Server, that is in a position to do so,
may monetize or use for attacks or undesired surveillance.

>Section 12.1
>
>   Security considerations:
>      Security considerations related to the generation and consumption
>      of ALTO Protocol messages are discussed in Section 15 of
>      [RFC7285].
>
>I think we should also reference Section 11 of this document as having
>relevant considerations.
>
[ [SR] ] We have updated the 2 new sections, each corresponding the a new media-type
12.1.  application/alto-propmap+json Media Type
12.2.  alto-propmapparams+json Media Type
NEW
... ALTO Protocol messages are discussed in Section 15 of [RFC7285] and 
Section 11 in this document.

>Section 12.2, 12.3
>
>Should we write "priv:*" or some other wildcard to indicate that this entry is
>for the class of identifiers beginning with that prefix, and not the literal
>identifier "priv:"?
>
[ [SR] ] Upon other review comments, entries with "priv*" have been removed from Table 2 and Table 3.

>Section 14.1
>
>The RFC 5246 is unused (in favor of RFC 8446, thanks!).
>
[ [SR] ] the ref has been removed

>Section 14.2
>
>If it's RECOMMENDED to use the RFC 8895 mechanisms, that seems to
>promote 8895 to be a normative reference, per
>https://www.ietf.org/about/groups/iesg/statements/normative-informative-
>references/
>
[ [SR] ] RFC 8895 has been moved to the normative references

>NITS
>
>Section 1
>
>   and IPv6 addresses.  It is reasonable to think that collections of
>   endpoints, as defined by CIDRs [RFC4632] or PIDs, may also have
>
>We haven't defined PIDs yet.
>
[ [SR] ] OLD
It is reasonable to think that collections of
   endpoints, as defined by CIDRs [RFC4632] or PIDs, may also have
   properties.
NEW
It is reasonable to think that collections of
   endpoints or Provider-Defined Identifiers (PIDs), may also have
   properties.

>   At first, a map of endpoint properties might seem impractical,
>   because it could require enumerating the property value for every
>   possible endpoint.  However, in practice, the number of endpoint
>   addresses involved by an ALTO server can be quite large.  To avoid
>
>This doesn't seem like a "however" that contrasts the previous point; rather, it
>seems like an "in particular" that expounds on the scale of impracticality.
>
[ [SR] ] we have updated as follows:
OLD
 However, in practice, the number of endpoint
   addresses involved by an ALTO server can be quite large.  
NEW
 In particular, the number of endpoint
   addresses involved by an ALTO server can be quite large.  To avoid

>      and Filtered Property Map, detailed in Section 8.  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 [RFC7285].  The latter is a POST-mode
>
>The terms "GET-mode" and "POST-mode" don't seem to be defined or used in
>RFC 7285, so we probably need to introduce them here if we're going to use
>them.
>
[ [SR] ] we have updated the text 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 resource that is requested using the HTTP GET method,
      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 resource 
      that is requested using the HTTP POST method, returns...

>Section 4.4
>
>   grouped in blocks.  When a same property value applies to a whole
>   set, a Server can define a property for the identifier of this set
>   instead of enumerating all the entities and their properties.  This
>
>s/a same/the same/
>
[ [SR] ] DONE, thanks

>Section 4.4.1
>
>   An entity domain may allow using a single identifier to identify a
>   set of individual entities.  For example, a CIDR block can be used to
>
>I suggest "set of related individual entities".
>
[ [SR] ] DONE, thanks

>Section 5.2.2
>
>
>   The specific information resource of an entity property may be the
>   current information resource itself, that is, the property map
>   defining the property.  In that case, the ResourceID in the property
>   name SHOULD be ignored.  For example, the property name ".asn"
>
>I think s/ignored/omitted/.
>
[ [SR] ] DONE, thanks

>Section 6.1.3
>
>   Hierarchical addresses can also inherit properties: if a property P
>   is not defined for the hierarchical address C, but is defined for a
>   set of hierarchical addresses, where each address C' in the set
>   covers all IP addresses in C, and C' has a shorter prefix length than
>
>I think the usage of "set" and "covers" is unclear here.
>(Also, pedantically, the empty set is a set, and any statement of the form "<X>
>holds for each element of the set" is true for the empty set, but there is no C'
>in the empty set to have a shorter prefix length than
>C.)
>
[ [SR] ] we replaced "covers" with "contains"

>   *  If that entity would inherit a value for that property, then the
>      ALTO server MUST return a "null" value for that property.  In this
>
>This is the JSON "null" value, at least for the currently defined media types,
>right?  That might be worth clarifying (while retaining the generic nature not
>tied to a JSON representation).
>
[ [SR] ] we have updated as follows (also upon other review comments)
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
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 the JSON "null" value for that property on X. In this

>   *  If the entity would not inherit a value, then the ALTO server MAY
>      return "null" or just omit the property.  In this case, the ALTO
>      client cannot infer the value for this property of this entity
>      from the Inheritance rules.  So the client MUST interpret that
>      this property has no value.
>
>This probably doesn't need to be a BCP 14 keyword, as the behavior follows
>from the other required parts of the spec.
>
[ [SR] ] Although this may be redundant, we prefer here to keep the normative rules for clarity.

>Section 7.6
>
>      entity does.  The ALTO client MUST ignore any resource-specific
>      property for this entity if its mapping is not indicated, in the
>      IRD, in the "mappings" capability of the property map resource.
>
>The pronoun "its" might be anti-helpful here, as (if I understand
>correctly) we mean to say that the the entity domain that's the defining
>information resource for this resource-specific property is what's listed in the
>capabilities map, but "its" leaves the exact relation a bit under-specified.
>
[ [SR] ] we have updated as follows
OLD
      entity does.  The ALTO client MUST ignore any resource-specific
      property for this entity if its mapping is not indicated, in the
      IRD, in the "mappings" capability of the property map resource.
NEW
      entity does.  The ALTO client MUST ignore any resource-specific
      property for this entity if the mapping between this resource-specific 
      property and this entity is not indicated, in the
      IRD, in the "mappings" capability of the property map resource.

>Section 8
>
>   query.  To support such a case, the filtered property map provides a
>   light weight response, with empty property values.
>
>This might be (mis?)read as saying that the filtered property map
>*always* provides a response with empty property values.  So I'd suggest
>adding a qualifier, like "provides a facility for" or "supports a lightweight
>response".
>
[ [SR] ] thanks, we have opted for "supports a lightweight response"

>Section 8.1
>
>   The media type of a property map resource is "application/alto-
>   propmap+json".
>
>Do we want "filtered" here?
>
>Section 8.3
>
>   ReqFilteredPropertyMap.  The design of object ReqFilteredPropertyMap
>   supports the following cases of client requests:
>
>The grammar seems off, here -- maybe "the object" or just
>"ReqFilteredPropertyMap is designed to support"?
>
[ [SR] ] thanks, we updated as follows
OLD
 The design of object ReqFilteredPropertyMap
   supports the following cases of client requests:
NEW
ReqFilteredPropertyMap is designed to support 
the following cases of client requests:

>Section 8.6
>
>   *  When the input member "properties" is absent from the client
>      request, the Server returns a property map containaing all the
>
>s/containaing/containing/
>
[ [SR] ] thanks , done
>