[alto] Erik Kline's No Objection on draft-ietf-alto-path-vector-19: (with COMMENT)
Erik Kline has entered the following ballot position for draft-ietf-alto-path-vector-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/ -- COMMENT: -- [S1; question] * I assume that all of this querying is inherently asymmetric? By that I mean that if an app wants to truly estimate bidirectional flow usage between "a" and "b" it needs to query for "a->b" and "b->a", in case there's some fundamental asymmetry in flow characteristics. [S4.2.1; nit] * s/QEB/QEP/g ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
[alto] Benjamin Kaduk's Discuss on draft-ietf-alto-performance-metrics-20: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-alto-performance-metrics-20: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-alto-performance-metrics/ -- DISCUSS: -- These should all be trivial to resolve -- just some minor internal inconsistencies that need to be fixed before publication. The discussion of percentile statistical operator in §2.2 is internally inconsistent -- if the percentile number must be an integer, then p99.9 is not valid. Also, the listing of "cost-source" values introduced by this document (in §5.1) does not include "nominal", but we do also introduce "nominal". Similarly, in §3.1.3 we refer to the "-" component of a cost metric string, that has been generalized to an arbitrary statistical operator. -- COMMENT: -- All things considered, this is a pretty well-written document that was easy to read. That helped a lot as I reviewed it, especially so on a week with a pretty full agenda for the IESG telechat. Section 2.2 Should we say anything about how to handle a situation where a base metric identifier is so long that the statistical operator string cannot be appended while remaining under the 32-character limit? min: the minimal value of the observations. max: the maximal value of the observations. [...] Should we say anything about what sampling period of observations is in scope for these operators? Section 3.x.4 If we're going to be recommending that implementations link to external human-readable resources (e.g., for the SLA details of estimation methodology), does the guidance from BCP 18 in indicating the language of the text come into play? It's also a bit surprising that we specify the new fields in the "parameters" of a metric just in passing in the prose, without a more prominent indication that we're defining a new field. Section 3.1.4 "nominal": Typically network one-way delay does not have a nominal value. Does that mean that they MUST NOT be generated, or that they should be ignored if received, or something else? (Similarly for the other sections where we say the same thing.) This description can be either free text for possible presentation to the user, or a formal specification; see [IANA-IPPM] for the specification on fields which should be included. [...] Is the IANA registry really the best reference for what fields to include? Tpically we would only refer to the registry when we care about the current state of registered values, but the need here seems to effectively be the column headings of the registry, which could be obtained from the RFC defining the registry. Section 3.3.3 Intended Semantics: To specify spatial and temporal aggregated delay variation (also called delay jitter)) with respect to the minimum delay observed on the stream over the one-way delay from the specified source and destination. The spatial aggregation level is specified in the query context (e.g., PID to PID, or endpoint to endpoint). I do appreciate the note about how this is not the normal statistics variation that follows this paragraph, but I also don't think this is a particularly clear or precise specification for how to produce the number that is to be reported. It also doesn't seem to fully align with the prior art in the IETF, e.g., RFC 3393. It seems like it would be highly preferrable to pick an existing RFC and refer to its specification for computing a delay variation value. (To be clear, such a reference would then be a normative reference.) Section 3.4.3 Intended Semantics: To specify the number of hops in the path from the specified source to the specified destination. The hop count is a basic measurement of distance in a network and can be exposed as the number of router hops computed from the routing protocols originating this information. [...] It seems like this could get a little messy if there are multiple routing protocols in use (e.g., both normal IP routing and an overlay network, as for service function chaining or other overlay schemes). I don't have any suggestions for disambiguating things, though, and if the usage is consistent within a given ALTO Server it may not have much impact on the clients. Section 3.4.4 "sla": Typically hop count does not have an SLA value.
Re: [alto] Francesca Palombini's Discuss on draft-ietf-alto-performance-metrics-20: (with DISCUSS)
Hi Francesca,
Thank you so much for the review! Please see inline.
On Wed, Dec 1, 2021 at 4:57 PM Francesca Palombini via Datatracker <
nore...@ietf.org> wrote:
> Francesca Palombini has entered the following ballot position for
> draft-ietf-alto-performance-metrics-20: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-alto-performance-metrics/
>
>
>
> --
> DISCUSS:
> --
>
> Thank you for the work on this document.
>
> Many thanks to Christian Amsüss for his review:
> https://mailarchive.ietf.org/arch/msg/art/owYhcoFnl1vEipZ2D62cWiiE-LA/ ,
> and
> thanks to the authors for addressing it.
>
> I am holding a DISCUSS to make sure the examples are fixed before
> publication.
Additionally, I agree with Christian that the line "Content-Length: TBA" in
> all
> the examples is not really helpful to the reader, and I suggest to either
> remove it or replace TBA with the actual content length for each example.
>
>
Thank you for the reminder. We will double-check that the examples are
fixed. In our
updated version---to be uploaded soon, will use the actual content length,
to be
conforming to HTTP.
> Francesca
>
> 1. -
>
> {
>"meta": {
> "cost type": {
> "cost-mode": "numerical",
> "cost-metric":"hopcount"}
> }
>},
> "endpoint-cost-map": {
> "ipv4:192.0.2.2": {
> "ipv4:192.0.2.89" : 5,
> "ipv4:198.51.100.34": 3
> }
>}
> }
>
> FP: JSON doesn't validate. There is one "}" too many after "hopcount".
>
Thank you for catching it. It is fixed in the running version.
>
> 2. -
>
>{
> "meta": {
> "cost type": {
>"cost-mode": "numerical",
>"cost-metric":"tput"
>}
> }
> "endpoint-cost-map": {
>"ipv4:192.0.2.2": {
> "ipv4:192.0.2.89" : 256000,
> "ipv4:198.51.100.34": 128000
> }
>}
>
> FP: JSON doesn't validate. I believe there is 2 errors: after the second
> "}"
> after "tput" there is a missing "," , and it is also missing a final "}"
> at the
> end.
>
> Yep. You are right and they are fixed.
> 3. -
>
> {
> "meta": {
>"cost-type" {
> "cost-mode": "numerical",
> "cost-metric": "bw-residual"
>}
> },
> "endpoint-cost-map" {
>"ipv4:192.0.2.2" {
> "ipv4:192.0.2.89" :0,
> "ipv4:198.51.100.34": 2000
>}
> }
>}
>
> FP: JSON doesn't validate - there is a bunch of missing ":" all over.
>
>
Fixed.
> 4. -
>
> {
>"cost-type" { "cost-mode": "numerical",
> "cost-metric": "bw-maxres"},
>"endpoints": {
> "srcs": [ "ipv4 : 192.0.2.2" ],
> "dsts": [
>"ipv4:192.0.2.89",
>"ipv4:198.51.100.34"
> ]
>}
> }
>
> FP: JSON doesn't validate: missing ":" after "cost-type"
>
> Got it and fixed.
> 5. -
>
> {
> "meta": {
>"cost-type": {
> "cost-mode": "numerical",
> "cost-metric": "bw-maxres"
>}
> },
> "endpoint-cost-map": {
>"ipv4:192.0.2.2" {
> "ipv4:192.0.2.89" :0,
> "ipv4:198.51.100.34": 2000
>}
> }
>}
>
> FP: JSON doesn't validate: missing ":" after "ipv4:192.0.2.2"
>
> Fixed.
>
Thank you so much!
Richard
>
>
>
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
[alto] Erik Kline's No Objection on draft-ietf-alto-performance-metrics-20: (with COMMENT)
Erik Kline has entered the following ballot position for draft-ietf-alto-performance-metrics-20: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-alto-performance-metrics/ -- COMMENT: -- [S3.4.2; comment] * I would recommend specifying a maximum value as well. It's not clear how values greater than the 8-bit TTL/HopLimit fields can carry should be interpreted. I would recommend max 254, as 255 tends to have special interpretation. ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
[alto] Benjamin Kaduk's Discuss on draft-ietf-alto-unified-props-new-21: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-alto-unified-props-new-21: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/ -- DISCUSS: -- (1) Section 8.6 seems to have some conflicting requirements. The filtered property map response "MUST include all the inherited property values for the requested entities and all the entities which are able to inherit property values from the requested entities." We then go on to say that to do this, the server MAY follow three rules, that themselves include SHOULD-level guidance, but don't say how the MUST is achieved if the SHOULDs or MAY are ignored. I was expecting to see a construction of the form "SHOULD do X, but if not, MUST do Y". (2) Many of the examples in Sections 10.X do not seem to match up with the prose that describes them and the previous data tables that they are intended to illustrate (see COMMENT). We should make sure that the examples are internally consistent. (3) Section 4.6.2 says: * Last, the entity domain types "asn" and "countrycode" defined in [I-D.ietf-alto-cdni-request-routing-alto] do not have a defining information resource. Indeed, the entity identifiers in these two entity domain types are already standardized in documents that the Client can use. But earlier we said that "the defining information resource of a resource-specific entity domain D is unique", but this seems to be saying that the defining information resource of domains of the "asn" and "contrycode" type are *not* unique, by virtue of not existing at all. How can we rectify these two statements? -- COMMENT: -- I suggest noting somewhere early-ish that the (semi-)formal notation defined in Section 8.2 of RFC 7285 will be used. Section 1 properties. Furthermore, recent ALTO use cases show that properties of entities such as network flows [RFC7011] and routing elements [RFC7921] are also useful. Such cases are documented in [I-D.gao-alto-fcs]. The current EPS however is restricted to This is probably more relevant as a comment on draft-gao-alto-fcs than this document, but putting the ALTO server in a position to know about individual flows seems like a big privacy risk, especially in the face of pervasive monitoring (per RFC 7258). It's not really clear that this is actually a good idea to do, and thus whether we want to mention it here. Section 3.2.2 There seems to be an unfortunate risk of conflation of parsing as ((entity domain) name) vs (entity (domain name)), with domain name being the widely-used term (see, e.g., RFC 8499). Could we find some alternate terminology that doesn't suffer from this potential confusion? Section 4.4 For some domain types, entities can be grouped in a set and be defined by the identifier of this set. This is the case for domain >From a mathematical/set-theoretic perspective, this statement is trivially true for all domain types; that's just how sets work. I think what we want to say here is that they can be efficiently grouped by utilizing an underlying structure for the entities in the given domain type. That might become, for example, "For some domain types, there is an underlying structure that allows entities to efficiently be grouped into a set and be defined by the identifier of this set". Section 4.6 Besides, it is also necessary to inform a Client about which associations of specific resources and entity domain types are allowed, because it is not possible to prevent a Server from exposing inappropriate associations. [...] This reasoning is a bit hard for me to follow. It's not possible to prevent a server from exposing nonsensical things, sure. But often we would just define the correct operation of the protocol to be only exposing things that make sense, and if the server is noncompliant to the spec, things break accordingly. Section 4.6.1 The defining information resource of a resource-specific entity domain D is unique and has the following specificities: [...] * its media type is unique and equal to the one that is specified for the defining information resource of an entity domain type. I find this definition worrisom, as it seems to imply that the given resource only has one media type, implicily precluding t
Re: [alto] Artart last call review of draft-ietf-alto-cdni-request-routing-alto-16
Thomas: thank you very much for this review! And thanks to the authors for addressing it. I balloted DISCUSS to get the JSON in one of the examples fixed, and to encourage the authors to send the media type registrations to the media-type mailing list for review before the document moves forward. Thanks, Francesca From: last-call on behalf of Thomas Fossati Date: Tuesday, 7 September 2021 at 19:08 To: Jensen Zhang Cc: a...@ietf.org , draft-ietf-alto-cdni-request-routing-alto@ietf.org , IETF ALTO , Thomas Fossati , last-c...@ietf.org Subject: Re: [Last-Call] [alto] Artart last call review of draft-ietf-alto-cdni-request-routing-alto-16 Hi Jensen, Thanks very much for addressing my review. Your proposed changes generally look very good to me. Some more (very minor) comments in-lined below. cheers! On 07/09/2021, 12:04, "Jensen Zhang" wrote: > > On Sat, Aug 28, 2021 at 8:28 AM Thomas Fossati via Datatracker > > wrote: > > It is not clear to a newcomer why a RESTful design is listed as one > > of the criteria for choosing ALTO. Please be more specific about > > the advantages. E.g., it's a good fit with the rest of the CDNI > > suite and therefore reduces the cognitive dissonance for users and > > developers alike? It allows at least some level of code reuse? > > Thanks for the suggestion. We will add the following sentence into > this bullet to make the benefit clear: > >[...] It can provide the consistent >client-server interaction model for other existing CDNI interfaces >or potential future extensions and therefore reduce the learning >cost for both users and developers, although they are not in the >scope of this document. A CDNI FCI interface ... That's great. Although, I'd argue that developers are certainly in scope :-) and -- to a smaller extent -- users too. > We will add the following note before Sec 3.1: > >Note that the encoding of BaseAdvertisementObject exactly reuses >the one defined in [RFC8008] and therefore also follows the >recommendations of I-JSON (Internet JSON) [RFC7493], which is >required by [RFC8008]. Great. (Maybe you could drop "exactly".) > > # Section 3.2 > > > > Is there any specific recommendation regarding caching of these > > resources? > > Can you explain more? ALTO is based on HTTP and therefore can reuse > HTTP cache control. Is it what you are looking for? Yes, I was wondering whether you have any specific recommendation for the cache control settings associated with the resources you define. > > I am having a hard time parsing this text: > > > >Note: Further optimization of BaseAdvertisement objects to > >effectively provide the advertisement of capabilities with > >footprint restrictions is certainly possible. > > > > what optimisation are hinted here? And what is their relation with > > the examples? Are those associated with the use of altopid? If so, > > you should consider adding a forward reference to section 4.1 here. > > Example 1 contains two BaseAdvertisementObject objects for delivery > protocol http/1.1 and https/1.1 respectively. > But they have the same footprint constraints. > Example 2 merges them to a single BaseAdvertisementObject. > It has not been associated with altopid yet. > Do you think we need to illustrate the examples more? The examples are pretty clear to me. The thing that I couldn't understand was what "further optimization [...] is certainly possible". Is this referring to the merged example? > >[...] a filtered CDNI Advertisement request is invalid if: > > > > o the value of "capability-type" is null; > > > > o the value of "capability-value" is null; > > > > What if one of capability-type or capability-value is missing? What > > if one of them is the empty value for the type or if any mandatory > > fields are missing? What if the value in "capability-type" is not > > known? It'd seem to me that the conditions that can make a request > > invalid can be many more than those currently listed. And in > > general I'd leave the decision to the server. > > Here we just discuss the E_INVALID_FIELD_VALUE error because this is > the only case that [RFC7285] does not define how to commonly handle. > > For missing field cases, the ALTO server returns E_MISSING_FIELD. For > other cases, the ALTO server returns E_INVALID_FIELD_TYPE. WFM, and thanks for the explanation! My comment was obviously missing the wider ALTO context. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- last-call mailing list last-c...@ietf.org https://www.ietf.org/mailman/listinfo/last-call ___ alto mailing list alto@ietf.org https://www.i
[alto] Roman Danyliw's Discuss on draft-ietf-alto-cdni-request-routing-alto-17: (with DISCUSS and COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-alto-cdni-request-routing-alto-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-alto-cdni-request-routing-alto/ -- DISCUSS: -- The security consideration is silent on how to handle client (uCDN) authentication for this specific CDN use case. Hence, the default guidance from Section 15.13.2 of RFC7285 seems to apply -- that HTTP Digest Authentication or TLS client authentication could be used. If I understand the use case right, it seems like the uCDNs and dCDNs should know about each other, and there wouldn’t be an unreasonably large number of them to prevent credentials existing for peers. Is there a reason why there isn’t a normative guidance requiring some kind of peer authentication given this narrow use case? If not, why is ok given the significance of this ALTO data in FCI model. -- COMMENT: -- Thanks to Klaas Wierenga for the SECDIR review. ** Abstract. Typo? RFC 8008 defines precisely the semantics of FCI and provides guidelines on the FCI protocol, but the exact protocol is specified Shouldn’t this read, “but the exact protocol is _NOT_ specified”? ** Section 8. For authenticity and integrity of ALTO information, an attacker may disguise itself as an ALTO server for a dCDN, and provide false capabilities and footprints to a uCDN using the CDNI Advertisement service. -- I don’t follow the intent of the first clause. Why is an _attacker_ concerned with the authenticity and integrity of the ALTO information? -- What role can TLS, an associated server certificate (for the dCDN) and configured knowledge of this certificate at the uCDN mitigate some of this risk? Shouldn’t the uCDNs only be communicating with a collection of known dCDNs with which it has some out-of-band negotiated arrangement? ** Section 8. For availability of ALTO services, an attacker may conduct service degradation attacks using services defined in this document to disable ALTO services of a network. Again, operating under the assumption that the dCDN (ALTO Server) would only be working with a known (prearranged) set of uCDNs and they would have authenticated somehow (per the DISCUSS), couldn’t repeated requested be rate limited and after attribution, filtered to minimize impact? ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
[alto] Francesca Palombini's Discuss on draft-ietf-alto-cdni-request-routing-alto-17: (with DISCUSS)
Francesca Palombini has entered the following ballot position for
draft-ietf-alto-cdni-request-routing-alto-17: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-alto-cdni-request-routing-alto/
--
DISCUSS:
--
Thank you for the work on this document.
Many thanks to Thomas Fossati for his in-depth review:
https://mailarchive.ietf.org/arch/msg/art/MKG2Cdin96WLcksnA6nAu6pvThM/ , and
thanks to the authors for addressing it.
I have two comments that need to be addressed before publication.
As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion; I really think that the
document would be improved with a change here, but can be convinced otherwise.
Francesca
1. -
data: },
data: { "op": "add",
data: "/cdni-advertisement/capabilities-with-footprints
/0/footprints/0/footprint-value/-",
data: "value": "192.0.2.0/24"
data: }
data: ]
FP: JSON doesn't validate. The key "path": is missing.
2. -
Media type registration
FP: I haven't seen the media type registrations being reviewed by the
media-type mailing list, as requested by RFC 6838. Before progressing the
document, I would really appreciate the authors to post the registrations to
the media-type mailing list for review. Note that people there might also weigh
in to the point Thomas made about the media type name, and if it's worth
specifying a more detailed media type name, or not in this case.
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
Re: [alto] [art] Artart last call review of draft-ietf-alto-performance-metrics-17
Christian: thank you very much for this review! I balloted DISCUSS to make sure some issues with JSON in the examples are fixed before publication. I was happy to see almost all your comments were addressed by the authors. Francesca From: art on behalf of Christian Amsüss Date: Monday, 18 October 2021 at 16:15 To: a...@ietf.org , last-c...@ietf.org , alto@ietf.org , draft-ietf-alto-performance-metrics@ietf.org Subject: Re: [art] Artart last call review of draft-ietf-alto-performance-metrics-17 Hello, On Mon, Oct 18, 2021 at 07:02:08AM -0700, Christian Amsüss via Datatracker wrote: > ## Summary for the IoT Directorate I performed the review with the wrong hat on, sorry for the mixup. Refocusing on the ART review criteria brings up nothing new -- but the point about the formal language used with metric-identifier deserves more emphasis. Likewise, the point about registration of the stat-typed metric identifiers (and the possible structuring of the registry into registered prefixes and per-prefix semantics for what is behind a colon) now falls more directly into the scope of the review. Otherwise, what was said with focus on the IoT applies likewise to the use of HTTP and other general ART topics: > As for conventions around the Internet of Things, this makes no choices -- if > follows the path set out by ALTO, and adds terms and considerations for > metrics > established outside of ALTO. Best regards Christian -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
[alto] Francesca Palombini's Discuss on draft-ietf-alto-performance-metrics-20: (with DISCUSS)
Francesca Palombini has entered the following ballot position for
draft-ietf-alto-performance-metrics-20: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-alto-performance-metrics/
--
DISCUSS:
--
Thank you for the work on this document.
Many thanks to Christian Amsüss for his review:
https://mailarchive.ietf.org/arch/msg/art/owYhcoFnl1vEipZ2D62cWiiE-LA/ , and
thanks to the authors for addressing it.
I am holding a DISCUSS to make sure the examples are fixed before publication.
Additionally, I agree with Christian that the line "Content-Length: TBA" in all
the examples is not really helpful to the reader, and I suggest to either
remove it or replace TBA with the actual content length for each example.
Francesca
1. -
{
"meta": {
"cost type": {
"cost-mode": "numerical",
"cost-metric":"hopcount"}
}
},
"endpoint-cost-map": {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89" : 5,
"ipv4:198.51.100.34": 3
}
}
}
FP: JSON doesn't validate. There is one "}" too many after "hopcount".
2. -
{
"meta": {
"cost type": {
"cost-mode": "numerical",
"cost-metric":"tput"
}
}
"endpoint-cost-map": {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89" : 256000,
"ipv4:198.51.100.34": 128000
}
}
FP: JSON doesn't validate. I believe there is 2 errors: after the second "}"
after "tput" there is a missing "," , and it is also missing a final "}" at the
end.
3. -
{
"meta": {
"cost-type" {
"cost-mode": "numerical",
"cost-metric": "bw-residual"
}
},
"endpoint-cost-map" {
"ipv4:192.0.2.2" {
"ipv4:192.0.2.89" :0,
"ipv4:198.51.100.34": 2000
}
}
}
FP: JSON doesn't validate - there is a bunch of missing ":" all over.
4. -
{
"cost-type" { "cost-mode": "numerical",
"cost-metric": "bw-maxres"},
"endpoints": {
"srcs": [ "ipv4 : 192.0.2.2" ],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34"
]
}
}
FP: JSON doesn't validate: missing ":" after "cost-type"
5. -
{
"meta": {
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "bw-maxres"
}
},
"endpoint-cost-map": {
"ipv4:192.0.2.2" {
"ipv4:192.0.2.89" :0,
"ipv4:198.51.100.34": 2000
}
}
}
FP: JSON doesn't validate: missing ":" after "ipv4:192.0.2.2"
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
Re: [alto] [art] Artart last call review of draft-ietf-alto-unified-props-new-18
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 on behalf of Spencer Dawkins via Datatracker Date: Tuesday, 7 September 2021 at 22:42 To: a...@ietf.org Cc: draft-ietf-alto-unified-props-new@ietf.org , alto@ietf.org , last-c...@ietf.org 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
[alto] Francesca Palombini's Discuss on draft-ietf-alto-unified-props-new-21: (with DISCUSS and COMMENT)
Francesca Palombini has entered the following ballot position for draft-ietf-alto-unified-props-new-21: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/ -- DISCUSS: -- Thank you for the work on this document. Many thanks to Spencer Dawkins for his thoughtful review: https://mailarchive.ietf.org/arch/msg/art/BcZimefF1WXXgcmg0qjc3P__EGg/ , and thanks to the authors for addressing it. I have two blocking comments, and some non blocking comments (to which I would still appreciate answers) below. Francesca 1. - Media type registration FP: I haven't seen the media type being reviewed by the media-type mailing list, as requested by RFC 6838. Before progressing the document, I would really appreciate the authors to post the registrations to the media-type mailing list for review. 2. - Sections 4.6.1, 12.2.2 and 12.3 FP: The use of the term "unique" when referred to media types and entity domains (or properties) is confusing - it makes it sound as if the authors mean that each different entity domain (or property) is to be associated with a different unique media type, which doesn't seem to be the intent. As this is related to the media type registration, I believe this should be clarified and possibly checked with the media type experts (so it would be good to copy paste the relevant text in the email to the media-type mailing list). -- COMMENT: -- 3. - identifier. In this case, inheritance rules must specify how entities in "subsets" inherit property values from their "superset". For instance, if a property P is defined only for the entity set identified by address block "ipv4:192.0.1.0/24", the entity set identified by "ipv4:192.0.1.0/30" and thus included in the former set, may inherit the property P value from set "ipv4:192.0.1.0/24". FP: Are the sets inverted in the paragraph above? (should it be "ipv4:192.0.1.0/24" inherits from "ipv4:192.0.1.0/30") 4. - Sections 5.1.1, 5.2.1 FP: As it is defined now, all Private Use type identifiers are not valid, because they contain ":". I understand the intention, but it would be good to clarify in the text. 5. - Section 5.1.2 FP: Please add a note specifying the syntax used and a reference to it (it's enough to just mention it the first time it appears, so in this section). 6. - they have the same value of the "ASN" property. The same rule applies to the entities "ipv4:192.0.3.0/28" and "ipv4:192.0.3.0/28". FP: I believe the second one should be "ipv4:192.0.3.16/28" 7. - "properties" : [ "default-network-map.pid", "alt-network-map.pid ] FP: I validated the JSON examples (which I recommend to do) and this one is the only one that didn't validate as this is missing a closing " after "alt-network-map.pid. ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
Re: [alto] Éric Vyncke's No Objection on draft-ietf-alto-path-vector-19: (with COMMENT)
Hello Kai, Thank you for your prompt reply and your actions on the document. Please find some further comment below, look for EV> Regards -éric On 30/11/2021, 18:01, "kai...@scu.edu.cn" wrote: Hi Éric, Thanks for the review and please see the responses inline. Best, Kai > -Original Messages- > From: "Éric Vyncke via Datatracker" > Sent Time: 2021-11-29 18:59:54 (Monday) > To: "The IESG" > Cc: draft-ietf-alto-path-vec...@ietf.org, alto-cha...@ietf.org, alto@ietf.org, vijay.gurb...@gmail.com, vijay.gurb...@gmail.com > Subject: Éric Vyncke's No Objection on draft-ietf-alto-path-vector-19: (with COMMENT) > > Éric Vyncke has entered the following ballot position for > draft-ietf-alto-path-vector-19: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/ > > > > -- > COMMENT: > -- > > Thank you for the work put into this document. > > Please find below some non-blocking COMMENT points (but replies would be > appreciated even if only for my own education), and some nits. > > Special thanks to Vijay Gurbani for the shepherd's write-up as it seems to > indicate a low number of WGLC reviews. > > I hope that this helps to improve the document, > > Regards, > > -éric > > While it seems clear that knowledge of the path to some endpoints can help the > applications to select the "most suitable" endpoints to connect to, I wonder > whether knowledge about a single ISP will be enough. Assuming that a single ISP > is the topic of this I-D as the singular form "ISP" is used rather than "ISPs". Yes, this document is targeting the single ISP case. For arbitrary queries, a single ISP may not have the knowledge of the full Internet paths. However, there are cases where the two endpoints are inside the same "ISP", for example, ISP-hosted CDN/edge, tenant interconnection in a single public cloud platform, SDN, etc. Some scenarios are discussed in previous ALTO sessions, including the ISP-hosted CDN service in Telefonica, and edge-assisted data transfer of Tencent (content provider) and China Telecom (ISP). Also, there are approaches that generate the path vectors from end-to-end measurement data that do not even require knowledge from an ISP. Thus, we believe this extension can still be useful. EV> this is indeed quite logical and sensible. I would suggest mentioning this in the introduction with a sentence EV> like "This document is mainly applicable when there is a single ISP between the ALTO client, ALTO server, and the content server". > > Nothing bad of course, but I read this IETF draft more like an IRTF draft, > i.e., it reads more like research and conjectures. > Fair enough. Any suggestion how we can cook more IETF gradient into the document? EV> Not really except deep rewriting > As only "max-reservable-bandwidth" is actually specified to this document, I > wonder whether other characteristics/properties could also have been defined, > e.g., max-latency, max-packet-drop, ... ? > Good question. We choose these two initial properties as they are taken from use cases that we already see or are pushing forward the deployment of. Note the max-reservable-bandwidth is important to identify bottlenecks inside a network that can be crucial to determine the end-to-end reservation. But for latency and loss rate, the end-to-end result (i.e., using the base ALTO protocol) is usually sufficient to select endpoints. > -- Section 3 -- > May I assume that the first paragraph should be removed before publication? If > so, then please add a note to the RFC Editor. You are right. The paragraph is intended to be a note to the RFC editor and should be removed before publication. We will make this clear by changing "Note" to "Note to the RFC Editor". > > -- Section 4.2.1 -- > On figure 5, please use consistently "v" or "V" but not a mix. Unsure whether > "f1" label (?) should be in the picture as it brings nothing. Good catch! We will use lowercase "v" for consistency and remove "f1" in the next revision. > > -- Section 4.2.2 -- > I find amusing to see
[alto] Opsdir telechat review of draft-ietf-alto-path-vector-19
Reviewer: Tim Chown Review result: Ready Hi, I have reviewed this document (draft-ietf-alto-path-vector-19) as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This draft proposes an extension to the ALTO protocol to allow the definition of Abstract Network Elements (ANEs) on a path between two endpoints that can be considered when orchestrating connectivity between those endpoints, rather than just computing based on the abstract cost of a path. A Path Vector allows a set of such ANEs to be defined for a path. Caveats: I previously reviewed the -17 version of the draft; this review focuses on how the points from that review have been addressed. Overall: The authors have addressed my comments from the previous review of -17. The comments on my review from Kai were very helpful. I believe the document is now Ready for publication from my perspective. General comments: The new bottleneck and service edge resource examples in 4.2, and the new text in 5.1, are useful additions to the draft, helping clarify the form of the ANEs. The clarifications made are also useful, e.g. on the use of “domain”, around the information exposed regarding topology, and regarding exposing potential capacity available rather than actually making specific reservations of capacity. I think it would still be useful to add further text on the single “entity domain” concept, and to be explicit about what that means in practice. The new text in 6.2 is useful, but stating clearly what the practical implication is would be helpful. Nit: The authors have addressed my comments about use cases, SENSE and WLCG in 4.2.1, though where they say “Applications such as large-scale data analytics” I would expect to see “Applications which need to perform large scale data transfers” rather than explicit saying “analytics”. It’s the transfer that needs the capacity rather than the resulting analysis / computation on the data. Then you might add something saying “such as the WLCG”, as that is currently the largest example of a distributed computation collaboration in the R&E world. Tim ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
