[alto] Chair review of unified-props (Part 2 of 2)

Vijay Gurbani <vijay.gurbani@gmail.com> Wed, 27 January 2021 16:28 UTC

Return-Path: <vijay.gurbani@gmail.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9FC503A0B48; Wed, 27 Jan 2021 08:28:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id cIPOXXHQpSYX; Wed, 27 Jan 2021 08:28:57 -0800 (PST)
Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) (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 97B493A0B44; Wed, 27 Jan 2021 08:28:57 -0800 (PST)
Received: by mail-yb1-xb35.google.com with SMTP id r32so2575460ybd.5; Wed, 27 Jan 2021 08:28:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=wCrSRErvkQvBga82xxJae8SzU2LzOpdpEslFaufn5Rw=; b=rxL1ntO4zP4rAdTrj8OIv13A+2aazEyXWzmgqFbDZAxqSm3ITbhUKQJNcCawqnfZ2Y yhrGnHk+TSc9XNzPN9zMT8N7/2yQA76KeFlAcpmau2wciKEzy/W6xhu7pVbH2fJhChpk ng/SnfJbzwLbhhoBchfaq812lNoe0JfxE8IqWPUfr4R6hdZLmib2zfuVTY/YAa12Lfyf 8yeGCsbaUZkPT8YpbCOtpOPgq6G0SAm4LUyGVX+e58erDp8tDa40j35etdcTJcleBu3K Qah6xWygxuh21Rt/hRzNPeyGmKplyl9azNlkNfDfvW4t+VKfwZ2fCrKrrwr+FOERcmme /P4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=wCrSRErvkQvBga82xxJae8SzU2LzOpdpEslFaufn5Rw=; b=Yw31KXxEcI2KVW4gUJZft3Si/EbCIwabi/Pj/lGVj5WKTdfPFIRe2OD4+Nzmdwq5Z9 UKNwycpneTEAnRiK9pJKzOtOZM94k3Yfrs1Kfp3fkPRoguDPHVSq3BSVQ1LSj/JbeiCe dEqZM6e3Ou+HweOoSS/zk7CdB8rWzJ6C3hzvoizErEcJ1Var3bwUlbXK+P2kc3G7cY7w CFxwOkf3uGJ5Q8DLcgxkPsjCmXmIabWydMiFwfNqqRVQonJ1Sh0Se1bPQ5mUdJmmGCcy fxRM/1v9oHgYgmpNKgW0SkrgL4fvdUOQWpogMAlTxn3P80XmdtZL8ktat3bhNuOCNngr CKIg==
X-Gm-Message-State: AOAM531/powK5wpvwQpMEH7leS8vyRyOyhggDefTYSi7vwsj/aExBH7V flDot1RPzu+10rgeXINyX7AjG7+rJELDRv06uQe5hrSEcPI=
X-Google-Smtp-Source: ABdhPJxkN/5RuLoXHYK9as8WHUDizm4D9ZwnajxcbKlnS+kKIKhvefKlz9cvPtBJnjwywU7cdKZfMUG6Lnf92GTD7OY=
X-Received: by 2002:a25:348d:: with SMTP id b135mr16586786yba.258.1611764936408; Wed, 27 Jan 2021 08:28:56 -0800 (PST)
MIME-Version: 1.0
From: Vijay Gurbani <vijay.gurbani@gmail.com>
Date: Wed, 27 Jan 2021 10:27:50 -0600
Message-ID: <CAMMTW_KN1b6hbTu4rqXkrTCaNfXNWW2vj=a0tTL3n4n_=m2g7Q@mail.gmail.com>
To: draft-ietf-alto-unified-props-new@ietf.org
Cc: IETF ALTO <alto@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007f01c105b9e4446f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/9_YFODK1EnXz0YNW-RT7hbAzTiU>
Subject: [alto] Chair review of unified-props (Part 2 of 2)
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jan 2021 16:29:00 -0000

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.


- 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
be used, then this should be an absolute condition (MUST NOT is the
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 '.'
out of bounds or say it is not, it seems weird to say that this document
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
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
name refers to a resource-agnostic entity domain or a resource-specific
domain."  Thus it seems to me that future extensions could run into trouble
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
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,
the status of this draft must say "Updates: 7285" at the top of the draft
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
rules of property map and filtered property map are distinct enough that
ALTO servers and clients will continue operations?  Please advise.

- S9.3: What does "little or no impact on other previously defined
mean?  Again, this appears wishy-washy for a standards document.  Either we
that there is some impact, and we document what the impact is, or we state
there is no impact.  But saying "little or no impact" is not helpful.
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
second order look at S9.3 is in order before publication to document the
on previously defined properties.

- S10: Please fill in all of the "###" for "Content-Length: ###" in all

- S11: Did anyone in the WG do a threat analysis of the information exposed
the property maps related to, say, domain type "ane"?  As the example in
demonstrates, there is a lot of information in the returned response that
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
time thinking about the information in the property maps and how it may be
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
that suffices, then that is fine.  Just wanted to make sure that the authors
have spent some time here.


- S5.1.3, last paragraph: I think you should append the following sentence
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


- Please run idnits; currently, it is reporting 3 errors having to do with
obsoleted references (RFCs 5226 and 7159) and a downref (RFC 7921).


- vijay