[Tvr] Gorry Fairhurst's Discuss on draft-ietf-tvr-requirements-08: (with DISCUSS and COMMENT)

[Gorry Fairhurst via Datatracker <[e-mail]>]

Gorry Fairhurst has entered the following ballot position for
draft-ietf-tvr-requirements-08: 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/about/groups/iesg/statements/handling-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-tvr-requirements/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have many comments and curioisitis about this document, and would like to
DISCUSS the strengths of the recommendations, since the WG has requested
publication in the RFC-Series.

1) I see the Charter text calls for: "Requirements: This document should
include definitions, requirements, notes, rationales, and examples." - However,
the supplied document is mainly descriptive at present. Sections 2 and 3
describe broad use cases, but section 4 does not currently derive strong
requirements; such as a numbered set of precisely defined requirements. So,
is/could the document provide formal requirements using RFC2119 language in
section 4 to clearly indicate what is needed.

Here are some specific questions to discuss on the specific 'requirements"
below:

2)
/   A Manager should provide an advertisement methodology for responding
   to abnormal changes in the system./
-- It was not clear to me what was needed here, or what the exepected response
included - is it enough to log, might this imply alerting or taking action?

3) Recommended, optional or needed?
/   Systems must support proxy entities to help non-routing nodes
   implement information advertisement./
- this is specified as a "should", but the text above suggests this is
optional. Please clarify the position.

4) What would be compliant?
/   Systems must support system schedule changes.
   Systems must support time interval changes./
- What does the requirement imply as a constraint on the solution space? How
often is this needed? Is rollback needed in event of a fault, and how is this
authenticated? and /   Systems must support appropriate time tolerance./ - This
is a "must" - but what is actually required for a design to be conformant, and
how will this  be specified?... this seems a difficult conformance
requiremenrt, please indicate how it will be achieved?

5)
/   Resilience Against Malicious or Erroneous Inputs:  A TVR network must
      be resilient against the injection of incorrect or maliciously
      crafted scheduling information./
- How?
and
/TVR implementations should
      include fallback mechanisms to maintain network stability./
- Why is this not a requirement (MUST?)

6)
There are also presumably requirements for data integrity and timely delivery
of information - ought these also to be called out in the list of requirements
(even if the chosen way to mittigate these is to use strong security
mechanisms)?

Best wishes,
Gorry (WIT AD)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


Thank you for the TSV-ART review by Mirja Kühlewind, and the issues raised in
that review.

Minor: Section 1:
/This document is an informational specification meant to inform .../ -- is it
better to state: /This document was written to inform.../

Minor:
/orchestrator/ - ought this to be /Orchestrator/

Minor:
Why does an International document discuss GPS, whilst coordinated Universal
Time (UTC) is a primary time standard?

Minor:
Is a "MAC address" sufficient in Layer 2? - Does this document need to consider
a wider set, i.e. EUI-48, or EUI-64?