Re: [Last-Call] Artart last call review of draft-ietf-alto-unified-props-new-18

"Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <sabine.randriamasy@xxxxxxxxxxxxxxxxxxx> · Mon, 25 Oct 2021 17:57:17 +0000

Hello Spencer and Mike,

Thanks a lot for your comments and guidance.

Please see inline how your comments have been addressed,
starting with the ones from Mike and continuing with the 2^nd feedback from Spencer.
We hope the updates meet your expectations and look forward to having your feedback,
Best regards,
Sabine and co-authors

From: Mike Bishop <mbishop@xxxxxxxxxxxx>

Sent: Wednesday, September 15, 2021 4:27 AM

To: Spencer Dawkins at IETF <spencerdawkins.ietf@xxxxxxxxx>; Jensen Zhang <jingxuan.n.zhang@xxxxxxxxx>

Cc: art@xxxxxxxx; IETF ALTO <alto@xxxxxxxx>; last-call@xxxxxxxx; draft-ietf-alto-unified-props-new.all@xxxxxxxx

Subject: Re: [Last-Call] Artart last call review of draft-ietf-alto-unified-props-new-18

> If the first paraphrase is more correct, the BCP 14 language would be "MAY", but "is allowed to" or "can" are often used. 

If I can jump in, I think there is a slight distinction between the two. In my experience, a BCP 14 MAY has an implicit MUST to it -- if one party MAY take an action, the other parties MUST allow
 for that possibility and handle it gracefully, even if that counterpart isn't always written down.

If it's merely a possibility that exists, with no obligation on other parties, then the sentence is a statement of fact and "can" is more appropriate. It's also a statement if the ability follows
 from an explicitly stated MUST on some other party.

Here, if one party MAY omit records, the other party MUST NOT assume those records will be present.

I don't pretend to know this draft well enough to suggest which it is in this case, however.
[ [SR] ] To make sure a Client knows what to to, we have opted for the following revision:
OLD
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.

NEW
The ALTO server MAY omit property values that are inherited rather than

explicitly defined, in order to achieve more compact encoding. As a consequence,
the ALTO Client MUST NOT assume inherited property values will all be present.

If the Client needs inherited values, it MUST use the entity domain's inheritance rules to deduce those values.

Sent from 
Nine

From: Spencer Dawkins at IETF <spencerdawkins.ietf@xxxxxxxxx>

Sent: Tuesday, September 14, 2021 9:14 PM

To: Jensen Zhang

Cc: art@xxxxxxxx; IETF ALTO; 
last-call@xxxxxxxx; 
draft-ietf-alto-unified-props-new.all@xxxxxxxx

Subject: Re: [Last-Call] Artart last call review of draft-ietf-alto-unified-props-new-18

Hi, Jensen, 

On Tue, Sep 14, 2021 at 7:11 AM Jensen Zhang <jingxuan.n.zhang@xxxxxxxxx> wrote:

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@xxxxxxxx> 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’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.

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 defines

   properties for a sufficiently large subset of endpoints and uses an aggregation

   representation to reference endpoints to allow efficient enumeration. [...]

This works better for me. 
[ [SR] ] done

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.

Thanks for the suggestion. We will do it.
[ [SR] ] we need to double-check whether we left some unattended expressions of “domain name”

Thanks!

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?

Yes, good catch. We will change to "can be".

Thanks!
[ [SR] ] done

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’”.

Yes, you are right. We will change the words to "have no meaning".

Thanks!
[ [SR] ] done

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?

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.

Fortunately the IESG has people who can tell you that something isn't confusing in general just because it confuses Spencer :-)

But let me back up here, and see if I can help unconfuse myself, in a way that will help other people be unconfused.

The first use of these prefixes are in this text: 

4.1.  Entity Identifier and Entity Domain Name

   In [RFC7285], an endpoint has an identifier that is explicitly

   associated with the "ipv4" or "ipv6" address domain.  Examples are

   "ipv4:192.0.2.14" and "ipv6:2001:db8::12".

This is, I think, correct - these examples are from prefixes reserved for documentation, but they are ipv4/ipv6 addresses. Let me suggest that you add pointers to the relevant RFCs that make those reservations - something like this: 

4.1.  Entity Identifier and Entity Domain Name

   In [RFC7285], an endpoint has an identifier that is explicitly

   associated with the "ipv4" or "ipv6" address domain.  Examples are

   "ipv4:192.0.2.14" and "ipv6:2001:db8::12".

   In this document, example ipv4 and ipv6 addresses and prefixes are taken from the address ranges reserved for documentation by [RFC5737] and [RFC3849]. 
[ [SR] ] Done. After parag 1: inserted sentence
“In this document, example ipv4 and ipv6 addresses and prefixes are taken
          from the address ranges reserved for documentation by

          <xref target="RFC5737" format="default"/> and

            <xref target="RFC3849" format="default"/>. »

So, that takes care of the "reserved" part of my comment. For the "routable" part - the problem is that the addresses/prefixes reserved for documentation are explicitly NOT routable. But if I understand
 your response, you're using "routable" to mean "reachable", and the string "routable" appears only four times in the draft. I'd suggest for the first occurrence, 

   *  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",

removing "example" and "routable" - neither is needed to make your point - and in the other three occurrences, substitute "reachable" for "routable". 
[ [SR] ] OK

4.2.  Resource-Specific Entity Domain Name

   Some entities are defined and identified uniquely and globally in the

   context of an ALTO server.  This is the case for instance when

   entities are endpoints that are identified by a 
routable IPv4 or IPv6

   address.  The entity domain for such entities can be globally defined

   and named "ipv4" or "ipv6".  Those entity domains are called

   resource-agnostic entity domains in this document, as they are not

   associated with any specific ALTO information resources.

   *  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,
[ [SR] ] changed text as follows:
OLD 
… local non- routable addresses
NEW
local addresses that are not reachable outside some private network

   *  an entity domain named "ipv4" is resource-agnostic and covers all

      the routable IPv4 addresses.
[ [SR] ] DONE : replaced “routable” with “reachable”

After thinking about this for a minute, private addresses aren't "routable", either, but they can be "reachable", if you're in the right private network, so the updated text handles that case as well. 
[ [SR] ] therefrom the above mentioned text

Does this make sense?

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”.

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.

Perfect. 
[ [SR] ] DONE

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?

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

Thanks!
[ [SR] ] SHOULD has been changed to MUST in the first sentence.
In the 2^nd sentence, the text has been updated as follows:
OLD 

The ALTO client MUST 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.

NEW
"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. "

   *  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.

Perfect. 
[ [SR] ] OK : appended the sentence "unless property values can be omitted upon some inheritance rules"

   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.

You're using BCP14 terms here, and RFC 2119 (part of BCP14) treats "SHOULD" and "RECOMMENDED" as equivalent:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there

   may exist valid reasons in particular circumstances to ignore a

   particular item, but the full implications must be understood and

   carefully weighed before choosing a different course.

So, that's not the right answer, but please help me make a suggestion here. 

Is it more correct to say

   For efficiency, the ALTO server is allowed to omit property values that are

   inherited rather than explicitly defined; 

or 

   The ALTO server 
MUST omit property values that are

   inherited rather than explicitly defined in 
order to achieve efficiency; 

If the first paraphrase is more correct, the BCP 14 language would be "MAY", but "is allowed to" or "can" are often used. 

If the second paraphrase is more correct, and you really think ALTO servers ought to do this unless the implementers are crazy, MUST would be correct. 

If neither of these paraphrases say what you want to say, perhaps explaining what the decision is based on is better (I'm assuming that you mean "more compact encoding" when you say "efficiency" - if I'm confused about that, please help
 me understand what the benefit is). 

   The ALTO server can omit property values that are inherited rather than explicitly defined,
in order to achieve more compact encoding;

Does that make sense?

The second "SHOULD" needs to be changed to "MUST".

Thanks!
[ [SR] ] Thanks a lot for the guidance and suggestion. Please see how this was resolved on top of this e-mail , in response to Mike Bishop

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?

Because A1 and A2 have different property values. They cannot be merged.

Ah. Thanks for helping me understand. 
[ [SR] ] OK

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.

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.

Thanks for the background here. 

I took a quick look through https://datatracker.ietf.org/doc/html/rfc7285, and it seemed that the previous document distinguished between "users" and "applications" (for example,
 in https://datatracker.ietf.org/doc/html/rfc7285#section-3.2

   ALTO information may be useful to a large number of applications and

   users.  

But I do think I should let the SEC reviewers, GEN reviewers, and ADs decide whether this is all fine in the document under review, rather than trying to figure that out in an ART review!
[ [SR] ] Thanks for this comment. We have received the SECDIR review and may further elaborate on the definition of “user” upon the GENART review.

Thanks for your quick and helpful responses, and good luck with your draft.
[ [SR] ] again, many thanks for your thorough review and helpful guidance

Best,

Spencer

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call