[Last-Call] Artart last call review of draft-ietf-cdni-capacity-insights-extensions-06

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Reviewer: Carsten Bormann
Review result: Ready with Nits

I am not an expert in CDNI technologies, so I just read this from a
general ART perspective.

The document specifies extensions to a data model that is defined in
RFC 8008, published 2016.  Appropriately, it uses the English language
description technique of the document that it extends.

It extends RFC 8008 via the extension point provided by the IANA
registry "CDNI Payload Types" as defined by RFC 7736 and follows the
template of RFC 8008 (whose term "Encoding" is somewhat confusing).
I don't have a reference to any record of the review required by
Section 2.2 of RFC 7736.
(I probably lack context to understand the text at the start of
Section 2 that describes *how* the extension point is exercised.)

## Major

2.1.1.1 seems to presume a registry of valid Telemetry Source Object
types.  I don't find that in the IANA considerations.
(The one "type" value that seems to be defined is spelled both as
"Generic" [once] and "generic" [four times], the latter being used in
the example in 2.1.2.)

"Additional limits would need to be specified and extended into this
list." -- Similar to 2.2.1.1, i.e., also looks like a candidate for a
registry: unless it is foreseen that this list will only be extended
by an RFC updating this RFC.

## Minor

1.3 starts with a sentence stating "... has been defined".
It this a recap of something that happened somewhere else?
If yes, please state this and add references.

2.1 makes "sources" mandatory to specify.  "sources" is a JSON array
that can be empty.  (Not necessarily a bug, just an observation.)

2.1.1.1: I can't parse

           The intention of
           this type registry is to allow for to reference a to another
           specification,

2.1.1.2: time-granularity probably is intended to be at least
non-negative, likely positive
2.2.1.1: I would expect these all are non-negative integers?
(The specification says just "integer").

## Nits

### general

Please aid the reader by using section references for passages such as
"Section 5 of [RFC8008]".

The examples are labeled as "artwork" in the XML; they should be
sourcecode (probably labeled "json", even if they only contain the
syntax for a single member of a JSON object).

The tables could use titles for the captions.

### Section 3.1

The IANA registration text could mention the name of the registry
group (Content Delivery Network Interconnection (CDNI) Parameters).

### typos

1.3: amount of traffic may be delegated
➔ amount of traffic that may be delegated

long lived
➔ long-lived

datasource
➔ data source

2.2.1.2 source of an Telemetry Capability
an ➔ a

3.1.1, 3.1.2:
section Section
➔ section


### xml2rfc nits

draft-ietf-cdni-capacity-insights-extensions-06.xml(14): Warning:
Expected a title or title abbreviation of not more than 40 character
for the page header, found 49 characters

The RPC will fix the addresses broken in the plaintext (and remove the
superfluous spaces).

### idnits

  == Unused Reference: 'RFC7336' is defined on line 637, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC8007' is defined on line 647, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC8804' is defined on line 652, but no explicit
     reference was found in the text


Title will be expanded by the RFC editor to:
  Content Delivery Network Interconnection (CDNI) Capa...
in title, abstract, and introduction (first use).


### cddl

This section is for information only.
(I tend to read an English language data model by creating a CDDL data
model; I'm supplying this in case it might be helpful to the authors
or other reviewers.)

capins-sources = {
  sources: [* telemetry-source]
}

telemetry-source = {
  id: text
  type: $telemetry-source-type
  metrics: [* telemetry-source-metric]
  ? configuration: { * text => any }
}

$telemetry-source-type /= "generic"

telemetry-source-metric = {
  name: text
  ? time-granularity: uint
  ? data-percentile: 0..100
  ? latency: uint
}

capins-limits = {
  limits: [* capacitylimit]
}

capacitylimit = {
  limit-type: $capacitylimit-type
  ? id: text
  maximum-hard: int
  ? maximum-soft: int
  ? current: int
  ? telemetry-source: capacitylimit-telemetry-source
}

$capacitylimit-type /= "egress"
$capacitylimit-type /= "requests"
$capacitylimit-type /= "storage-size"
$capacitylimit-type /= "storage-objects"
$capacitylimit-type /= "sessions"
$capacitylimit-type /= "cache-size"

capacitylimit-telemetry-source = {
  ; must be a capabilities.capability-value.sources.*.id
  id: text
  ; must be a capabilities.capability-value.sources.*.metrics.*.name
  metric: text
}



-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux