Hi Vijay,
Thanks again for your revision of version 15.
I still owe to you and the WG an inline response by Jensen and myself to your
comments.
For the moment, I have the attached text file that integrates them with your
comments.
Most of your comments were hopefully correctly addressed and we still have
thoughts on comments regarding sections:
4.7.1, 4.4.3, 9.3, 11.
I will send an “integrated” response tomorrow to the list.
Thanks,
Sabine
From: Vijay Gurbani <[email protected]>
Sent: Saturday, February 27, 2021 9:18 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
<[email protected]>
Cc: [email protected]
Subject: Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-16.txt
Dear Sabine: Thank you. I will look over the changes and move the draft ahead.
I plan to do so next week.
- vijay
On Mon, Feb 22, 2021 at 6:49 PM Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
<[email protected]<mailto:[email protected]>>
wrote:
Dear all,
This version 16 addresses most of Vijay's review comments part 1 and 2.
We will come back in a few days with details on how the comments have been
addressed.
Thanks,
Sabine
>-----Original Message-----
>From: alto <[email protected]<mailto:[email protected]>> On Behalf Of
>[email protected]<mailto:[email protected]>
>Sent: Tuesday, February 23, 2021 1:01 AM
>To: [email protected]<mailto:[email protected]>
>Cc: [email protected]<mailto:[email protected]>
>Subject: [alto] I-D Action: draft-ietf-alto-unified-props-new-16.txt
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>This draft is a work item of the Application-Layer Traffic Optimization WG of
>the
>IETF.
>
> Title : ALTO extension: Entity Property Maps
> Authors : Wendy Roome
> Sabine Randriamasy
> Y. Richard Yang
> Jingxuan Jensen Zhang
> Kai Gao
> Filename : draft-ietf-alto-unified-props-new-16.txt
> Pages : 57
> Date : 2021-02-22
>
>Abstract:
> This document extends the base Application-Layer Traffic Optimization
> (ALTO) Protocol by generalizing the concept of "endpoint properties"
> as applied to endpoints as defined by IP addresses to endpoints
> defined by a wider set of objects. Further, these properties are
> presented as maps, similar to the network and cost maps in the base
> ALTO protocol. The protocol is extended in two major directions.
> First, from endpoints restricted to IP addresses to entities covering
> a wider and extensible set of objects; second, from properties on
> specific endpoints to entire entity property maps. These extensions
> introduce additional features allowing entities and property values
> to be specific to a given information resource. This is made
> possible by a generic and flexible design of entity and property
> types.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-16
>https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-16
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-16
>
>
>Please note that it may take a couple of minutes from the time of submission
>until the htmlized version and diff are available at
>tools.ietf.org<http://tools.ietf.org>.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>
>_______________________________________________
>alto mailing list
>[email protected]<mailto:[email protected]>
>https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/alto
=== Chair review of unified-props (Part 1 of 2) ===
Major:
- Abstract: "...by generalizing the concept of "endpoint properties" to generic
type of entities..." ==> Note that the antecedent ("endpoint properties") and
the consequent ("type of entities") do not match. Perhaps better to say: "...by
generalizing the concept of "endpoint properties" as applied to endpoints
defined by IP addresses to endpoints a wider set of objects..."
More concretely:
OLD:
This document extends the base Application-Layer Traffic Optimization
(ALTO) Protocol by generalizing the concept of "endpoint properties"
to generic types of entities, and by presenting those properties as
maps, similar to the network and cost maps in the base ALTO protocol.
NEW:
This document extends the base Application-Layer Traffic Optimization
(ALTO) Protocol by generalizing the concept of "endpoint properties"
as applied to endpoints as defined by IP addresses to endpoints defined
by a wider set of objects. Further, these properties are presented
as maps, similar to the network and cost maps in the base ALTO protocol.
[Jensen] It looks good to me. Done.
- S3.2.1: "An entity domain type is expected to be registered at the IANA" ==>
you mean "MUST be registered with IANA"? Or "SHOULD be registered with IANA"?
Best to use normative language here, unless you have a specific reason not
to.
[Jensne] We changed "is expected to" to "MUST". Thanks for pointing it out.
I don't see any reason not to do it.
- S3.2.2: What does this mean: "As a consequence, entities in such
domains may be defined in a resource handling this domain type but
not in other resources handling this same domain type."? I am unable to
parse this, I think you are saying that of all the resources handling a
particular domain type, the entity must be defined in only one of them. If
so, perhaps best to reword; something like:
OLD:
As a consequence, entities in such domains may be defined in a
resource handling this domain type but not in other resources handling
this same domain type.
NEW:
As a consequence, of all the resources defining a particular domain
type, the entity must be defined in only one resource.
(Sabine)
the point is rather to say that a domain can contain entities defined
relatively to an information resource. In this case, the domain needs to have a
name that ensures that the entities of the domain can all be retrieved and that
with no ambiguities.
For instance: we may have 2 domains, "netmap1.pid" = {"mypidP", "mypidB",
"mypidS"} and "netmap2.pid" = {"mypidP", "mypidB", "mypidL"} . "mypidP" may or
may not point to the same addresses in "netmap1" and "netmap2". This is not
problematic as long as, when the Client queries "mypidP" defined in "netmap1"
or "netmap2", it gets what is defined in these network maps for "mypidP".
The text has been rephrased in this direction. Please let us know if it is
clear enough.
- S4.2.2, first paragraph: Is this example valid? From my experience, ASN's
contain IPv4 addresses defined by a CIDR block. I think it is highly unlikely
that a service provider will define a CIDR block (192.0.1.0/24) and have that
block span ASNs, but perhaps I am mistaken. Perhaps someone from network
operations may want to look at this example and bless it, or if you are sure
that networks are architected in such a manner, then we can let it stay.
(Sabine)
Agree. Property "ASN" has been replaced with dummy property value "P".
- S4.6.2: "When an ANE has a persistent identifier, say, "entity-4", the
latter", here what do you mean by "latter"? In this sentence, I do not see two
things that can be characterized as "former" and "latter"...?
[Jensen] New sentence: "An ANE may have a persistent identifier, say,
"entity-4",
that is provided by the Server as a value of the "persistent-entity-id"
property of this ANE."
(sabine)
the following sentence was also clarified as follows:
OLD
Further properties may be queried on an ANE with a persistent entity ID.
NEW
Further properties may then be queried on an ANE by using its persistent entity
ID
- S4.7.1: This subsection appears as an afterthought; it is not "defining
resource media-types" as much as simply "listing resource media-types". It does
not appear to be comprehensive since it only includes two examples, which leads
me to think that perhaps these examples are best put in parts of the text that
refer to these property types. Furthermore, the media type for property "pid"
is already defined in RFC7285, so if you want to give an example here, simply
refer to RFC7285 for it. And, the media type "alto-cdnifci+json" is defined in
draft-ietf-alto-cdni-request-routing-alto, not in this section. My advice would
be to remove this subsection, I don't think it is comprehensive and just adds to
the confusion.
(Sabine) *****
Actually we removed 4.7.1 and the text of 4.7 (not the title yet).
Most of the text of 4.7 was moved to 4.6.1 last paragraph, as 4.7 âlookedâ
too small.
However, even if the text of 4.7 is short,
it is important, as it introduces fields that must be specified at the IANA, as
specified in section 12.3.
So we may just put the text back in 4.7.
Minor:
- S3.1: in the bullet items, please be consistent when using "IPv4 or IPv6"
versus "ipv4 or ipv6". Both forms are used, best to choose one and be
consistent in the section. (I recognize that lower case "ipv4" and "ipv6" are
used elsewhere in the document to define entity domains, that is okay; just be
consistent in S3.1.)
[Jensen] Thanks for noticing this issue. Done.
- S3.1, last bullet item: What os a "routable network node"? Is a network node
that performs the routing function (a router)? or is it a network node that is
the recipient of a packet routed to it (an endpoint)?
[Jensen] It should be the former one. The term "routable network node" may be
confusing.
We will just use "router" instead.
- S4.4.3: s/sets in the upper level./subsets./
Rationale: "Upper level" of a set consists of elements that are subsets. Since
you are using set theory here, perhaps best to use nomenclature in that
domain. (You may edit it as "subsets (upper levels)." if that helps.
- S4.4.3: Similarly, "lower level" is "superset".
(sabine) *****
the text has been updated and uses "subsets" (upper level) and "superset"
(lower level).
However we are not sure this reflects the rationale for property inheritance in
a hierarchical entity set.
What we mean is that a set S1 at a given "upper" level of the hierarchy covers
more values than a set S2 defined at a "lower" level of the hierarchy.
Therefore, S2 at "lower" level is a subset of S1 at "upper" level.
Therefore, we would rather use: supersets (upper levels), subsets (lower
levels)
For instance: What we mean is that a set S1 defined by address bloc 1.2.3.4/24
which is defined at a given "upper" level of the hierarchy contains more
address values than a set S2 defined by address bloc 1.2.3.4/30, defined at a
"lower" level of the hierarchy. Therefore, S2 at "lower" level is a subset of
S1 at "upper" level.
Nits:
- S1: s/which is also not globally/that may not be globally/
[Jensen] Done.
- S3.2.2: s/A PID is defined relatively to a network map./A PID is defined
relative to a network map./
[Jensen] Done.
- S3.4: s/thus conveying values of all property values/thus conveying all
property values/
[Jensen] Done.
- S4.3: s/So that if/Thus, if/
[Jensen] Done.
- S4.5: s/ALTO Server may just not provide a/ALTO Server may choose not to
provide a/
[Jensen] Done.
- S4.6: s/define them, that is, the set of addresses included in this
PID./define the set of addresses included in this PID./
[Jensen] Done.
=== Chair review of unified-props (Part 2 of 2) ===
Major:
- S5.1.1: "The '.' separator MUST NOT be used unless specifically indicated in a
further extension document." ==> I don't understand this. If the '.' must not
be used, then this should be an absolute condition (MUST NOT is the normative
strength in the sentence). If this document allows the '.' to be used in a
further extension document, then this is a relative --- not absolute ---
condition, and thus a normative SHOULD NOT seem to be better. However, as
currently written, this sentence seems rather wishy-washy. Either say '.' is
out of bounds or say it is not, it seems weird to say that this document does
not use it, but others can.
One way to achieve this is to replace that sentence with:
The '.' separator is not used by this document, however, future
extensions may use it. For the purpose of this document, the
strings "ipv4", "ipv6", and "pid" are valid entity domain
types, while "ipv4.anycast", and "pid.local" are invalid.
However, even then, I am not sure if the above is correct. Later, in S5.1.2,
you go on to say that "Note that the '.' separator is not allowed in
EntityDomainType and hence there is no ambiguity on whether an entity domain
name refers to a resource-agnostic entity domain or a resource-specific entity
domain." Thus it seems to me that future extensions could run into trouble if
they allow '.' in the EntityDomainType.
This needs to be resolved before publication.
[Jensen] Thanks for noticing this bug. The '.' separator is not allowed even in
an extension document.
The paragraph has been revised to the following:
An entity domain has a type, which is uniquely identified by a string
that MUST be no more than 64 characters, and MUST NOT contain
characters other than US-ASCII alphanumeric characters
(U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A), the hyphen ('-',
U+002D), or the low line ('_', U+005F).
- S5.1.2, last paragraph: "Note that the resource ID format defined in Section
10.1 of [RFC7285]..." ==> Section 10.1 of RFC 7285 defines "PID Name", not
"Resource ID", which is defined in the next section. Please clarify.
[Jensen] New paragraph rephrasing now:
Note also that Section 10.1 of [RFC7285] specifies the format of the PID
Name which is
the format of the resource ID including the following specification: ...
- S9.1: "...it is RECOMMENDED that the EPS be deprecated in favour of ..." ==>
This is very important: If this draft is recommending a change in RFC 7285, then
the status of this draft must say "Updates: 7285" at the top of the draft (it
currently does not). This will cause the RFC Editor to enter a "Updated by:
RFCXXXX" in the masthead of RFC7285.
Further, I presume that since this update is a recommendation, the processing
rules of property map and filtered property map are distinct enough that legacy
ALTO servers and clients will continue operations? Please advise.
[Jensen] We do not intend to update RFC7285 to deprecate EPS.
This recommendation is more like suggesting that the new ALTO servers that
support UP
should also provide the EPS to be backwards compatible with legacy clients.
Since the keyword "RECOMMENDED" has a specific meaning, let's not use this
keyword here.
The paragraph has been changed as follows:
NEW
Since the Property Map and the Filtered Property Map defined in this
document provide a functionality that covers the Endpoint Property
Service (EPS) defined in Section 11.4 of [RFC7285], ALTO servers may
prefer to provide Property Map and Filtered Property Map in place of
EPS. However, for the legacy endpoint properties, it is recommended
that ALTO servers also provide EPS so that legacy clients can still
be supported.
- S9.3: What does "little or no impact on other previously defined properties"
mean? Again, this appears wishy-washy for a standards document. Either we know
that there is some impact, and we document what the impact is, or we state that
there is no impact. But saying "little or no impact" is not helpful. Please
state where there is impact and whether this impact will cause backwards
compatibility problems.
I note that S12.2.1 further expands on this "little or no impact". Perhaps a
second order look at S9.3 is in order before publication to document the impacts
on previously defined properties.
(sabine) Agree.
We have skipped this unclear first sentence and focused on the impact on the
property semantics.
***** (Note: I did not find the text in 12.2.1 of version 15 that expands on
this "little or no impact")
The paragraph was updates as follows:
NEW
In the present extension, properties can now be defined on sets of entity
addresses, rather than just individual endpoint addresses as is is the case in
RFC7285. This might change the semantics of a property. These sets can be for
example hierachical IP address blocs. For instance, 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.
- S10: Please fill in all of the "###" for "Content-Length: ###" in all
examples.
[Jensen] done
- S11: Did anyone in the WG do a threat analysis of the information exposed by
the property maps related to, say, domain type "ane"? As the example in S10.9
demonstrates, there is a lot of information in the returned response that will
be of interest to malicious actors.
I note that there is a blanket paragraph in this section ("A particular
fundamental ... URI to provide the information.") that appears to address such a
scenario, but I don't see a well thought out threat-model that drives the
discussion in this section. At the very least, the authors should spend some
time thinking about the information in the property maps and how it may be used
if it fell in the hands of a malicious actor. If after reflection they come to
the conclusion that the second blanket paragraph outlines a mitigation strategy
that suffices, then that is fine. Just wanted to make sure that the authors
have spent some time here.
(sabine) ***** agree
we will further check in the WG, especially with operators and applications and
hope to get back with new text better reflecting protection strategies,
possibly see whether access to such information can be restricted.
Minor:
- S5.1.3, last paragraph: I think you should append the following sentence to
the paragraph:
Such equivalences should be established by the object represented
by DomainTypeSpecificEntityID, for example, [RFC5952] establishes
equivalence for IPv6 addresses, while [RFC4632] does so for IPv4
addresses.
[Jensen] Thanks. I like this suggestion. Done.
Nits:
- Please run idnits; currently, it is reporting 3 errors having to do with using
obsoleted references (RFCs 5226 and 7159) and a downref (RFC 7921).
[Jensen] Done.
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
