From nobody Tue Sep 14 05:11:48 2021 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251593A18BB; Tue, 14 Sep 2021 05:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.854 X-Spam-Level: X-Spam-Status: No, score=-0.854 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 142wF8_SVYPF; Tue, 14 Sep 2021 05:11:28 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FFB73A18B9; Tue, 14 Sep 2021 05:11:27 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id d21so12125058wra.12; Tue, 14 Sep 2021 05:11:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p7l4TMDShMguQy0AW7wkZoSDeT/D5rqm/G9RDGZmfdw=; b=QGpU1SI+JEH/wZj1iGjYO0N9fdDaWQkSENU/1HeF9H0F3CrPuWoCtU+X5gtFRNMeC/ v8EBsyLDCYpQHfxzrHaNaV4D0FFdFcKImfaPk/NyK/nBI26PqbxjrohQUUAtbZCn4fIk ulkyrLmNAbsU3+XO9CY1gMRnhQ669CCcA9tcgnZNhyzNn0/E3dUlIpx3teLn5WbqV1C1 QEScXPNbHWzWAKjYOZmwVh32oEJ6sMs9BBuDLE+cCuyQynahJidjswflkDBNQ8WubDyQ SOSYNfsnmXwVk4vIzHXhry/KtfsNMEDafDWswP8iSnjYJ+2dtxOnphuFnHcIRW8++BqX moLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=p7l4TMDShMguQy0AW7wkZoSDeT/D5rqm/G9RDGZmfdw=; b=tOssfK6P++acoRHImGRiAEx5QV4V7ML5HJCj8eiN57LhQUpET6Vw9aaDUbBv4y7qHH 2TivXYbmGvS/UxxGNNk2k9HvgJ6z1byQBkPAy/iUvXLGc4AxozQWaF1bT7VQB9LEE5iF MGW6dsXVQXYovfsczs+huwwRlzogeIuw4NuTCHLloyOQqpCnjBpRhg/JPzfDape39Nqb j/s7kooB4okYmuUrZDYCr9Q+Qr0eC04EcFtTSDEGI0fMnKZHHcP4+l2To+JEdfNR0Vwd 1SEfspy9wmQ78RTxOt6enNkUX7n3yUmY/ls3ZvaOqt5Xg6VolzORPFgsJm/bf/AmAKog YBmQ== X-Gm-Message-State: AOAM530VwU/4Ogs11NJ2GyulUWhUvw8ksX3L0cbD8az5FAuVlCC9e7p3 CrQhkobmaeZtNDv5rvauj8jOLlV1gNhybQvM6uo= X-Google-Smtp-Source: ABdhPJyYtnUzJE+wWD2Pp0EndB6N4z6TgN/M7ryUOY2xfQzELJp1LoaEBG4Aq3d8KA7t1t4uvKE2ttTSClHYJgJmHBU= X-Received: by 2002:a5d:5610:: with SMTP id l16mr18683491wrv.102.1631621484996; Tue, 14 Sep 2021 05:11:24 -0700 (PDT) MIME-Version: 1.0 References: <163104729716.18467.10737031683515271496@ietfa.amsl.com> In-Reply-To: <163104729716.18467.10737031683515271496@ietfa.amsl.com> From: Jensen Zhang Date: Tue, 14 Sep 2021 20:11:13 +0800 Message-ID: To: Spencer Dawkins Cc: art@ietf.org, IETF ALTO , draft-ietf-alto-unified-props-new.all@ietf.org, last-call@ietf.org Content-Type: multipart/alternative; boundary="000000000000056bc305cbf37bda" Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-alto-unified-props-new-18 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2021 12:11:35 -0000 --000000000000056bc305cbf37bda Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Spencer, Many thanks for your review. Please see my responses inline. Thanks, Jensen On Wed, Sep 8, 2021 at 4:41 AM Spencer Dawkins via Datatracker < noreply@ietf.org> wrote: > Reviewer: Spencer Dawkins > Review result: Ready with Issues > > I'm sorry for running late on this review, and please don't be concerned > about > the length - it includes a lot of draft text as part of the comments. > > Do The Right Thing, of course. > > In this text, > > 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, it is highly unlikely that > properties will be defined for every endpoint address. It is much > more likely that properties may be defined for only a subset of > endpoint addresses, and the specification of properties uses an > aggregation representation to allow enumeration. This is > particularly true if blocks of endpoint addresses with a common > prefix (e.g., a CIDR) have the same value for a property. Entities > in other domains may very well allow aggregated representation and > hence be enumerable as well. > > I wonder if it=E2=80=99s worth saying anything about the likely effect of= doing > something =E2=80=9Chighly unlikely=E2=80=9D, or perhaps something a bit m= ore likely, like > defining properties for a sufficiently large subset of endpoints to cause= a > problem. > Very good suggestion. How about the following revised text: NEW: [...] However, in practice, the number of endpoint addresses involved by an ALTO server can be quite large. To avoid enumerating a large number of endpoint addresses inefficiently, the ALTO server usually only define= s properties for a sufficiently large subset of endpoints and uses an aggregation representation to reference endpoints to allow efficient enumeration. [...] > > You might make an editing pass through the document looking for > occurrences of > =E2=80=9Cdomain name=E2=80=9D that (I think) refer to entity domain names= , such as > > * if an entity is an endpoint with example routable IPv4 address > "192.0.2.14", its identifier is associated with domain name "ipv4" > and is "ipv4:192.0.2.14", > > * if an entity is a PID named "mypid10" in network map resource > "netmap2", its identifier is associated with domain name > "netmap2.pid" and is "netmap2.pid:mypid10". > > I understand why you have the =E2=80=9Centity domain name=E2=80=9D termin= ology, but > dropping > the =E2=80=9Centity=E2=80=9D qualifier seems likely to lead to confusion. > Thanks for the suggestion. We will do it. > > In this text, > > Thus, if a property > "pid" is defined for entity "192.0.2.34" in two different network > maps "netmap1" and "netmap2", the value for this property will likely > be a different value in "netmap1" and "netmap2". > > Is =E2=80=9Clikely=E2=80=9D the right word? I think your point is that th= ere=E2=80=99s no reason to > expect they=E2=80=99d be the same, not that the reason people create anot= her > network > map is to store the values for properties that are different. I think > you=E2=80=99re > saying =E2=80=9Ccan be a different value=E2=80=9D, aren=E2=80=99t you? > Yes, good catch. We will change to "can be". > > In this text, > > * an entity domain named "netmap1.ipv4" includes the IPv4 addresses > that appear in the "ipv4" field of the endpoint address group of > each PID in the network map "netmap1", and that cannot be > recognized outside "netmap1" because, for instance, these are > local non-routable addresses, > > Is =E2=80=9Ccannot be recognized=E2=80=9D the right phrase here? My under= standing is that > this > is more like =E2=80=9Chave no meaning outside =E2=80=98netmap1=E2=80=99= =E2=80=9D. > Yes, you are right. We will change the words to "have no meaning". > > I=E2=80=99m confused about the use of the IPv4 literal address =E2=80=9C1= 92.0.2.34=E2=80=9D in this > document. I thought that https://datatracker.ietf.org/doc/html/rfc1166 > reserved > 192.0.2.0/24 for documentation, so when I see statements like this one: > > * if an entity is an endpoint with example routable IPv4 address > "192.0.2.14", its identifier is associated with domain name "ipv4" > and is "ipv4:192.0.2.14", > > I=E2=80=99m not sure what =E2=80=9Cexample routable IPv4 address=E2=80=9D= means - it=E2=80=99s not > routable, is > it? In general, I=E2=80=99m not sure what saying =E2=80=9Croutable=E2=80= =9D adds to statements like > > * an entity domain named "ipv4" is resource-agnostic and covers all > the routable IPv4 addresses. > > Isn=E2=80=99t that a convention that someone might use, rather than an in= variant > property of =E2=80=9Cipv4=E2=80=9D? It=E2=80=99s probably worth making an= editorial pass looking > for > these usages. And you might also look for similar issues using > =E2=80=9C2001:db8::1/48=E2=80=9D > - isn=E2=80=99t that reserved for documentation as well, by > https://datatracker.ietf.org/doc/html/rfc3849? > In this document, "routable" means that the address is reachable for the application client. In practice, it should be one of class A/B/C addresses. It depends on the network environment that the application runs on. But as the references that you listed above (RFC1166 and RFC3849), we just use the reserved addresses as examples for the documentation purpose. We assume that the application runs on a local network composed of those reserved addresses. If you think it may confuse people, we can add a note to clarify this. > > I was confused by this text: > > Each entity property type MUST be registered with the IANA, following > the procedure specified in Section 12.3 of this document. The > intended semantics of the entity property type MUST be specified at > the same time. > > Identifiers prefixed with "priv:" are reserved for Private Use > [RFC8126] without a need to register with IANA. 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. > > The first sentence of the first paragraph seems to be contradicted by the > first > sentence of the second paragraph - =E2=80=9Ceach MUST be registered, exce= pt for the > ones that don=E2=80=99t need to be registered=E2=80=9D. > Thanks for the catch. We will merge these two paragraphs to the following one: NEW: Identifiers prefixed with "priv:" are reserved for Private Use [RFC8126] without a need to register with IANA. 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", following the procedure specified in Section 12.3 of this document. The intended semantics of the entity property type MUST be specified at the same time. > > I do see reasonable usages of SHOULD in this document (=E2=80=9CSHOULD un= less=E2=80=9D), > but I > also see usages like this one - > > For each entity in the property map: > > * If the entity is in a resource-specific entity domain, the ALTO > server SHOULD only return self-defined properties and resource- > specific properties which depend on the same resource as the > entity does. The ALTO client SHOULD ignore the resource-specific > property in this entity if their mapping is not registered in the > ALTO Resource Entity Property Transfer Registry of the type of the > corresponding resource. > > Could you give an example of why the ALTO server might return properties > that > don=E2=80=99t conform to this SHOULD, or why the ALTO client might not ig= nore such > properties? > Good catch. We will change both "SHOULD" above to "MUST". > > * If the entity identifier is resource-agnostic, the ALTO server > SHOULD return the self-defined properties and all the resource- > specific properties that are defined in the property defining > information resources indicated, in the IRD, in the "mappings" > capability of the property map resource. > > Again, why might the ALTO server not return these properties? Or is this > answered by the next paragraph? We will append "unless the property value can be omitted by the inheritance rules" to this sentence. > > For efficiency, the ALTO server SHOULD omit property values that are > inherited rather than explicitly defined; if a client needs inherited > values, the client SHOULD use the entity domain's inheritance rules > to deduce those values. > > And if the client needs inherited values that are omitted, is there any > other > option besides using inheritance rules to deduce them? > Thanks for noticing this issue. For the first "SHOULD", maybe "is RECOMMENDED to" is more precise. The second "SHOULD" needs to be changed to "MUST". > > This > > * 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=3Dipv4:192.0.2.0/32 and v2 for A2=3Dipv4: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 =3D ipv4:192.0.2.0/31 SHOULD be > removed because A1 and A2 cover all the addresses in A. > > Is a great example of =E2=80=9CSHOULD do something unless you SHOULD do s= omething > else=E2=80=9D, but is it obvious why you shouldn=E2=80=99t remove A1 and = A2 from the > response, > because A covers all the addresses in A1 and A2? > Because A1 and A2 have different property values. They cannot be merged. > > These two paragraphs in the Security Considerations section > > Both Property Map and Filtered Property Map defined in this document > fit into the architecture of the ALTO base protocol, and hence the > Security Considerations (Section 15 of [RFC7285]) of the base > protocol fully apply: authenticity and integrity of ALTO information > (i.e., authenticity and integrity of Property Maps), potential > undesirable guidance from authenticated ALTO information (e.g., > potentially imprecise or even wrong value of a property such as geo- > location), confidentiality of ALTO information (e.g., exposure of a > potentially sensitive entity property such as geo-location), privacy > for ALTO users, and availability of ALTO services should all be > considered. > > ALTO clients using this extension should in addition be aware that > the entity properties they require may convey more details than the > 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. > Likewise, ALTO Servers expose entities and properties related to > specific parts of the infrastructure that reveal details on > capabilities, locations, or resource availability. These details may > be maliciously used for competition purposes, or to cause resource > shortage or undesired publication. > > Contain the only occurrences of the word =E2=80=9Cuser=E2=80=9D in the do= cument. Is it > defined > in a formal way anywhere? I can imagine that the second occurrence is =E2= =80=9CALTO > server=E2=80=9D, but I=E2=80=99m guessing, and the first occurrence seems= to be handwaving. > In this document, the word "user" has the same meaning as in RFC7285 ( https://datatracker.ietf.org/doc/html/rfc7285#section-15.4). An ALTO "user" means a person or an application running an ALTO client to communicate with an ALTO server. An ALTO client is just software without any subjective intent. A "user" can have the intent to protect privacy or attack others. --000000000000056bc305cbf37bda Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Spencer,

Many = thanks for your review. Please see my responses inline.

Thanks,
Jensen


On Wed, Sep 8, 2021 at 4:41 AM Spencer Dawkins via Datatracker = <noreply@ietf.org> wrote:
=
Reviewer: Spencer D= awkins
Review result: Ready with Issues

I'm sorry for running late on this review, and please don't be conc= erned about
the length - it includes a lot of draft text as part of the comments.

Do The Right Thing, of course.

In this text,

=C2=A0 =C2=A0At first, a map of endpoint properties might seem impractical,=
=C2=A0 =C2=A0because it could require enumerating the property value for ev= ery
=C2=A0 =C2=A0possible endpoint.=C2=A0 However, in practice, it is highly un= likely that
=C2=A0 =C2=A0properties will be defined for every endpoint address.=C2=A0 I= t is much
=C2=A0 =C2=A0more likely that properties may be defined for only a subset o= f
=C2=A0 =C2=A0endpoint addresses, and the specification of properties uses a= n
=C2=A0 =C2=A0aggregation representation to allow enumeration.=C2=A0 This is=
=C2=A0 =C2=A0particularly true if blocks of endpoint addresses with a commo= n
=C2=A0 =C2=A0prefix (e.g., a CIDR) have the same value for a property.=C2= =A0 Entities
=C2=A0 =C2=A0in other domains may very well allow aggregated representation= and
=C2=A0 =C2=A0hence be enumerable as well.

I wonder if it=E2=80=99s worth saying anything about the likely effect of d= oing
something =E2=80=9Chighly unlikely=E2=80=9D, or perhaps something a bit mor= e likely, like
defining properties for a sufficiently large subset of endpoints to cause a=
problem.

Very good suggestion. How abou= t the following revised text:

NEW:

<= /div>
=C2=A0 =C2=A0[...] However, in practice, the number of endpoint a= ddresses involved by
=C2=A0 =C2=A0an ALTO server can be quite lar= ge. To avoid enumerating a large number
=C2=A0 =C2=A0of endpoint = addresses inefficiently, the ALTO server usually only defines
=C2= =A0 =C2=A0properties for a sufficiently large subset of endpoints and uses = an aggregation
=C2=A0 =C2=A0representation to reference endpoints= to allow efficient enumeration. [...]
=C2=A0

You might make an editing pass through the document looking for occurrences= of
=E2=80=9Cdomain name=E2=80=9D that (I think) refer to entity domain names, = such as

=C2=A0 =C2=A0*=C2=A0 if an entity is an endpoint with example routable IPv4= address
=C2=A0 =C2=A0 =C2=A0 "192.0.2.14", its identifier is associated w= ith domain name "ipv4"
=C2=A0 =C2=A0 =C2=A0 and is "ipv4:192.0.2.14",

=C2=A0 =C2=A0*=C2=A0 if an entity is a PID named "mypid10" in net= work map resource
=C2=A0 =C2=A0 =C2=A0 "netmap2", its identifier is associated with= domain name
=C2=A0 =C2=A0 =C2=A0 "netmap2.pid" and is "netmap2.pid:mypid= 10".

I understand why you have the =E2=80=9Centity domain name=E2=80=9D terminol= ogy, but dropping
the =E2=80=9Centity=E2=80=9D qualifier seems likely to lead to confusion.

Thanks for the suggestion. We will do it= .
=C2=A0

In this text,

=C2=A0 =C2=A0Thus, if a property
=C2=A0 =C2=A0"pid" is defined for entity "192.0.2.34" i= n two different network
=C2=A0 =C2=A0maps "netmap1" and "netmap2", the value fo= r this property will likely
=C2=A0 =C2=A0be a different value in "netmap1" and "netmap2&= quot;.

Is =E2=80=9Clikely=E2=80=9D the right word? I think your point is that ther= e=E2=80=99s no reason to
expect they=E2=80=99d be the same, not that the reason people create anothe= r network
map is to store the values for properties that are different. I think you= =E2=80=99re
saying =E2=80=9Ccan be a different value=E2=80=9D, aren=E2=80=99t you?
<= /blockquote>

Yes, good catch. We will change to "ca= n be".
=C2=A0

In this text,

=C2=A0 =C2=A0*=C2=A0 an entity domain named "netmap1.ipv4" includ= es the IPv4 addresses
=C2=A0 =C2=A0 =C2=A0 that appear in the "ipv4" field of the endpo= int address group of
=C2=A0 =C2=A0 =C2=A0 each PID in the network map "netmap1", and t= hat cannot be
=C2=A0 =C2=A0 =C2=A0 recognized outside "netmap1" because, for in= stance, these are
=C2=A0 =C2=A0 =C2=A0 local non-routable addresses,

Is =E2=80=9Ccannot be recognized=E2=80=9D the right phrase here? My underst= anding is that this
is more like =E2=80=9Chave no meaning outside =E2=80=98netmap1=E2=80=99=E2= =80=9D.

Yes, you are right. We will cha= nge the words to "have no meaning".
=C2=A0

I=E2=80=99m confused about the use of the IPv4 literal address =E2=80=9C192= .0.2.34=E2=80=9D in this
document. I thought that https://datatracker.ietf.org/d= oc/html/rfc1166 reserved
192.0.= 2.0/24 for documentation, so when I see statements like this one:

=C2=A0 =C2=A0*=C2=A0 if an entity is an endpoint with example routable IPv4= address
=C2=A0 =C2=A0 =C2=A0 "192.0.2.14", its identifier is associated w= ith domain name "ipv4"
=C2=A0 =C2=A0 =C2=A0 and is "ipv4:192.0.2.14",

I=E2=80=99m not sure what =E2=80=9Cexample routable IPv4 address=E2=80=9D m= eans - it=E2=80=99s not routable, is
it? In general, I=E2=80=99m not sure what saying =E2=80=9Croutable=E2=80=9D= adds to statements like

=C2=A0 =C2=A0*=C2=A0 an entity domain named "ipv4" is resource-ag= nostic and covers all
=C2=A0 =C2=A0 =C2=A0 the routable IPv4 addresses.

Isn=E2=80=99t that a convention that someone might use, rather than an inva= riant
property of =E2=80=9Cipv4=E2=80=9D? It=E2=80=99s probably worth making an e= ditorial pass looking for
these usages. And you might also look for similar issues using =E2=80=9C200= 1:db8::1/48=E2=80=9D
- isn=E2=80=99t that reserved for documentation as well, by
https://datatracker.ietf.org/doc/html/rfc3849?
<= /blockquote>

In this document, "routable" mean= s that the address is reachable for the application client.
In pr= actice, it should be one of class A/B/C addresses. It depends on the networ= k environment that the application runs on.
But as the references= that you listed above (RFC1166 and RFC3849), we just use the reserved addr= esses as examples for the documentation purpose.
We assume that t= he application runs on a local network composed of those reserved addresses= .
If you think it may confuse people, we can add a note to clarif= y this.
=C2=A0

I was confused by this text:

=C2=A0 =C2=A0Each entity property type MUST be registered with the IANA, fo= llowing
=C2=A0 =C2=A0the procedure specified in Section 12.3 of this document.=C2= =A0 The
=C2=A0 =C2=A0intended semantics of the entity property type MUST be specifi= ed at
=C2=A0 =C2=A0the same time.

=C2=A0 =C2=A0Identifiers prefixed with "priv:" are reserved for P= rivate Use
=C2=A0 =C2=A0[RFC8126] without a need to register with IANA.=C2=A0 All othe= r
=C2=A0 =C2=A0identifiers for entity property types appearing in an HTTP req= uest or
=C2=A0 =C2=A0response with an "application/alto-*" media type MUS= T be registered
=C2=A0 =C2=A0in the "ALTO Entity Property Type Registry", defined= in Section 12.3.

The first sentence of the first paragraph seems to be contradicted by the f= irst
sentence of the second paragraph - =E2=80=9Ceach MUST be registered, except= for the
ones that don=E2=80=99t need to be registered=E2=80=9D.

Thanks for the catch. We will merge these two paragraphs t= o the following one:

NEW:

=C2=A0 =C2=A0Identifiers prefixed with "priv:" are reserved for = Private Use
=C2=A0 =C2=A0[RFC8126] without a need to register with IAN= A.=C2=A0 All other
=C2=A0 =C2=A0identifiers for entity property types ap= pearing in an HTTP request or
=C2=A0 =C2=A0response with an "applic= ation/alto-*" media type MUST be registered
=C2=A0 =C2=A0in the &qu= ot;ALTO Entity Property Type Registry",=C2=A0 following
=C2=A0 =C2=A0the procedure specified in Section 12.3 of this d= ocument.=C2=A0 The
=C2=A0 =C2=A0intended semantics of the entity propert= y type MUST be specified at
=C2=A0 =C2=A0the same time.
=C2=A0
=

I do see reasonable usages of SHOULD in this document (=E2=80=9CSHOULD unle= ss=E2=80=9D), but I
also see usages like this one -

=C2=A0 =C2=A0For each entity in the property map:

=C2=A0 =C2=A0*=C2=A0 If the entity is in a resource-specific entity domain,= the ALTO
=C2=A0 =C2=A0 =C2=A0 server SHOULD only return self-defined properties and = resource-
=C2=A0 =C2=A0 =C2=A0 specific properties which depend on the same resource = as the
=C2=A0 =C2=A0 =C2=A0 entity does.=C2=A0 The ALTO client SHOULD ignore the r= esource-specific
=C2=A0 =C2=A0 =C2=A0 property in this entity if their mapping is not regist= ered in the
=C2=A0 =C2=A0 =C2=A0 ALTO Resource Entity Property Transfer Registry of the= type of the
=C2=A0 =C2=A0 =C2=A0 corresponding resource.

Could you give an example of why the ALTO server might return properties th= at
don=E2=80=99t conform to this SHOULD, or why the ALTO client might not igno= re such
properties?

Good catch. We will change = both "SHOULD" above to "MUST".
=C2=A0

=C2=A0 =C2=A0*=C2=A0 If the entity identifier is resource-agnostic, the ALT= O server
=C2=A0 =C2=A0 =C2=A0 SHOULD return the self-defined properties and all the = resource-
=C2=A0 =C2=A0 =C2=A0 specific properties that are defined in the property d= efining
=C2=A0 =C2=A0 =C2=A0 information resources indicated, in the IRD, in the &q= uot;mappings"
=C2=A0 =C2=A0 =C2=A0 capability of the property map resource.

Again, why might the ALTO server not return these properties? Or is this answered by the next paragraph?=C2=A0

We wi= ll append "unless the property value can be omitted by the inheritance= rules" to this sentence.
=C2=A0

=C2=A0 =C2=A0For efficiency, the ALTO server SHOULD omit property values th= at are
=C2=A0 =C2=A0inherited rather than explicitly defined; if a client needs in= herited
=C2=A0 =C2=A0values, the client SHOULD use the entity domain's inherita= nce rules
=C2=A0 =C2=A0to deduce those values.

And if the client needs inherited values that are omitted, is there any oth= er
option besides using inheritance rules to deduce them?

Thanks for noticing this issue.
For the first &qu= ot;SHOULD", maybe "is RECOMMENDED to" is more precise.
=
The second "SHOULD" needs to be changed to "MUST".=
=C2=A0

This

=C2=A0 =C2=A0*=C2=A0 If there are entities covered by a requested entity bu= t having
=C2=A0 =C2=A0 =C2=A0 different values for the requested properties, the res= ponse SHOULD
=C2=A0 =C2=A0 =C2=A0 include all those entities and the different property = values for
=C2=A0 =C2=A0 =C2=A0 them.=C2=A0 For example, considering a request for pro= perty P of entity
=C2=A0 =C2=A0 =C2=A0 A (e.g., ipv4:192.0.2.0/31), if P has value v1 for
=C2=A0 =C2=A0 =C2=A0 A1=3Dipv4:192.0.2.0/32 and v2 for A2=3Dipv4:192.0.2.1/32, = then, the
=C2=A0 =C2=A0 =C2=A0 response SHOULD include A1 and A2.

=C2=A0 =C2=A0*=C2=A0 If an entity identifier in the response is already cov= ered by
=C2=A0 =C2=A0 =C2=A0 other entities identifiers in the same response, it SH= OULD be
=C2=A0 =C2=A0 =C2=A0 removed from the response, for the sake of compactness= .=C2=A0 In the
=C2=A0 =C2=A0 =C2=A0 previous example, the entity A =3D ipv4:192.0.2.0/31 SHO= ULD be
=C2=A0 =C2=A0 =C2=A0 removed because A1 and A2 cover all the addresses in A= .

Is a great example of =E2=80=9CSHOULD do something unless you SHOULD do som= ething
else=E2=80=9D, but is it obvious why you shouldn=E2=80=99t remove A1 and A2= from the response,
because A covers all the addresses in A1 and A2?

<= /div>
Because A1 and A2 have different property values. They cannot be = merged.
=C2=A0

These two paragraphs in the Security Considerations section

=C2=A0 =C2=A0Both Property Map and Filtered Property Map defined in this do= cument
=C2=A0 =C2=A0fit into the architecture of the ALTO base protocol, and hence= the
=C2=A0 =C2=A0Security Considerations (Section 15 of [RFC7285]) of the base<= br> =C2=A0 =C2=A0protocol fully apply: authenticity and integrity of ALTO infor= mation
=C2=A0 =C2=A0(i.e., authenticity and integrity of Property Maps), potential=
=C2=A0 =C2=A0undesirable guidance from authenticated ALTO information (e.g.= ,
=C2=A0 =C2=A0potentially imprecise or even wrong value of a property such a= s geo-
=C2=A0 =C2=A0location), confidentiality of ALTO information (e.g., exposure= of a
=C2=A0 =C2=A0potentially sensitive entity property such as geo-location), p= rivacy
=C2=A0 =C2=A0for ALTO users, and availability of ALTO services should all b= e
=C2=A0 =C2=A0considered.

=C2=A0 =C2=A0ALTO clients using this extension should in addition be aware = that
=C2=A0 =C2=A0the entity properties they require may convey more details tha= n the
=C2=A0 =C2=A0endpoint properties conveyed by using [RFC7285].=C2=A0 Client = requests may
=C2=A0 =C2=A0reveal details on their activity or plans thereof, that a mali= cious
=C2=A0 =C2=A0user may monetize or use for attacks or undesired surveillance= .
=C2=A0 =C2=A0Likewise, ALTO Servers expose entities and properties related = to
=C2=A0 =C2=A0specific parts of the infrastructure that reveal details on =C2=A0 =C2=A0capabilities, locations, or resource availability.=C2=A0 These= details may
=C2=A0 =C2=A0be maliciously used for competition purposes, or to cause reso= urce
=C2=A0 =C2=A0shortage or undesired publication.

Contain the only occurrences of the word =E2=80=9Cuser=E2=80=9D in the docu= ment. Is it defined
in a formal way anywhere? I can imagine that the second occurrence is =E2= =80=9CALTO
server=E2=80=9D, but I=E2=80=99m guessing, and the first occurrence seems t= o be handwaving.

In this document, the = word "user" has the same meaning as=C2=A0in RFC7285 (https://datatrac= ker.ietf.org/doc/html/rfc7285#section-15.4).
An ALTO "us= er" means a person or an application running an ALTO client to communi= cate with an ALTO server.
An ALTO client is just=C2=A0software wi= thout any subjective intent. A "user" can have the intent to prot= ect privacy or attack others.
=C2=A0
--000000000000056bc305cbf37bda--