[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.
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