Thanks a lot for this review Spencer! It really did improve the document. Thanks to the authors for answering as well.
I have balloted DISCUSS because of the IANA media type registrations, which as far as I can tell haven’t been sent to the media-types mailing list, and it should before the document moves forward.
Thanks,
Francesca
From: art <art-bounces@xxxxxxxx> on behalf of Spencer Dawkins via Datatracker <noreply@xxxxxxxx>
Date: Tuesday, 7 September 2021 at 22:42
To: art@xxxxxxxx <art@xxxxxxxx>
Cc: draft-ietf-alto-unified-props-new.all@xxxxxxxx <draft-ietf-alto-unified-props-new.all@xxxxxxxx>, alto@xxxxxxxx <alto@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>
Subject: [art] Artart last call review of draft-ietf-alto-unified-props-new-18
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’s worth saying anything about the likely effect of doing
something “highly unlikely”, or perhaps something a bit more likely, like
defining properties for a sufficiently large subset of endpoints to cause a
problem.
You might make an editing pass through the document looking for occurrences of
“domain name” 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 “entity domain name” terminology, but dropping
the “entity” qualifier seems likely to lead to confusion.
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 “likely” the right word? I think your point is that there’s no reason to
expect they’d be the same, not that the reason people create another network
map is to store the values for properties that are different. I think you’re
saying “can be a different value”, aren’t you?
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 “cannot be recognized” the right phrase here? My understanding is that this
is more like “have no meaning outside ‘netmap1’”.
I’m confused about the use of the IPv4 literal address “192.0.2.34” 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’m not sure what “example routable IPv4 address” means - it’s not routable, is
it? In general, I’m not sure what saying “routable” adds to statements like
* an entity domain named "ipv4" is resource-agnostic and covers all
the routable IPv4 addresses.
Isn’t that a convention that someone might use, rather than an invariant
property of “ipv4”? It’s probably worth making an editorial pass looking for
these usages. And you might also look for similar issues using “2001:db8::1/48”
- isn’t that reserved for documentation as well, by
https://datatracker.ietf.org/doc/html/rfc3849?
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 - “each MUST be registered, except for the
ones that don’t need to be registered”.
I do see reasonable usages of SHOULD in this document (“SHOULD unless”), 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’t conform to this SHOULD, or why the ALTO client might not ignore such
properties?
* 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?
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?
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=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.
Is a great example of “SHOULD do something unless you SHOULD do something
else”, but is it obvious why you shouldn’t remove A1 and A2 from the response,
because A covers all the addresses in A1 and A2?
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 “user” in the document. Is it defined
in a formal way anywhere? I can imagine that the second occurrence is “ALTO
server”, but I’m guessing, and the first occurrence seems to be handwaving.
_______________________________________________
art mailing list
art@xxxxxxxx
https://www.ietf.org/mailman/listinfo/art
|
