danielkinguk / tvr-requirements

Other
1 stars 0 forks source link

Address comments from Tony Li #22

Closed danielkinguk closed 6 months ago

danielkinguk commented 10 months ago

Received via TVR list:

[WG chair hat: OFF] Hi Authors, Thank you for your work on the requirements document. I have a few comments.

Substantive comments:

1) Given that this is an informational document and that you’ve invoked RFC 2119/8174, I’m a bit confused by your use of normative verbs. I think that you’re trying to express requirements for the solutions. We normally use the normative verbs to express requirements on the solutions, in documents that are on the standards track.

I would suggest that you consider dropping the normative verbs and explicitly list requirements on a solution.

2) Section 3.4.2. Even if path computation is distributed, that does NOT imply that scheduling must be (or should be) distributed by the routing protocol. It could instead be distributed through a management plane mechanism, such as NETCONF or gnmi.

3) Section 4.1. Will other per-use-case requirements be forthcoming? If not, perhaps this could be generalized. Requirement 3 seems unclear. Perhaps more text that would explain the context a bit more might be helpful.

4) Section 8.1. You write: "In Time-Variant Routing, scheduling of the system are as expected.” Could you please expound a bit? That sentence seems very vague.

5) Section 8.2. Please consider using the term ‘proxy’.

6) Section 8.3. You write: "If the system cannot timely identify and classify in a processing manner after the entity properties change, …”. Please clarify, I’m not able to parse this. You’ve described a requirement here that is "discovery and resolving methodology for the identification and classification of entity properties”. I don’t understand this. Aren’t the properties part of the schedule?

7) Section 8.4. You write: “… requiring of to be reconfigured …”. I can’t parse this, please reword. Aren’t time interval changes a subset of schedule changes?

8) Section 8.5. Accuracy is not an absolute value. In the real world, everything is necessarily inaccurate at some level. Normally this is described as a tolerance. What are you really asking for?

Editorial comments:

1) Section 3.4. You use the word ‘livelyness’. I think you want ‘liveness’. s/computating/computing/

2) Section 3.4.1. s/a Orchestrator/an Orchestrator/. s/entuty/entity. Note that the usual term for this case is a Path Computation Element (PCE).

3) Section 6. By convention, the security considerations section is at the end of the document, typically right in front of IANA considerations.

4) Section 8.1. s/A entity/An entity/. s/If/if/ s/a advertisement/an advertisement/

Regards, Tony

danielkinguk commented 10 months ago

I will respond to Tony via the list, I'll also queue up the changes/updates for a new version of the Requirements ID.