Re: [alto] Chair review of unified-props (Part 2 of 2)
Hello Vijay,
Thank you for your review of Entity Property Maps. As promised, please find
inline the answers from Jensen and myself on how your comments have been
addressed, prefixed respectively by “[jensen]” and “(sabine)”.
Responses on sections 9.3 and 11, with “*”, request further feedback from
you.
Thanks,
Sabine
From: Vijay Gurbani
Sent: Wednesday, January 27, 2021 5:28 PM
To: draft-ietf-alto-unified-props-...@ietf.org
Cc: IETF ALTO
Subject: Chair review of unified-props (Part 2 of 2)
Chair review from Section 5 - end (inclusive).
Please go through the Major review points, they require some attention.
This concludes my review of this document. Overall a well-written document
covering a range of important extensions to ALTO.
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.
[ [SR] ] [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.
[ [SR] ] [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:
RFC" 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.
[ [SR] ] [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
seco
Re: [alto] Chair review of unified-props (Part 2 of 2)
Hi Vijay,
Thanks a lot again for part 2 of your review.
We will pay particular attention to your major points,
that indeed require to update the specifications.
Best regards,
Sabine
From: Vijay Gurbani
Sent: Wednesday, January 27, 2021 5:28 PM
To: draft-ietf-alto-unified-props-...@ietf.org
Cc: IETF ALTO
Subject: Chair review of unified-props (Part 2 of 2)
Chair review from Section 5 - end (inclusive).
Please go through the Major review points, they require some attention.
This concludes my review of this document. Overall a well-written document
covering a range of important extensions to ALTO.
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.
- 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.
- 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:
RFC" 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.
- 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.
- S10: Please fill in all of the "###" for "Content-Length: ###" in all
examples.
- 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.
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.
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).
Thanks,
- vijay
__
[alto] Chair review of unified-props (Part 2 of 2)
Chair review from Section 5 - end (inclusive).
Please go through the Major review points, they require some attention.
This concludes my review of this document. Overall a well-written document
covering a range of important extensions to ALTO.
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.
- 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.
- 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:
RFC" 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.
- 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.
- S10: Please fill in all of the "###" for "Content-Length: ###" in all
examples.
- 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.
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.
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).
Thanks,
- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
