Unaddressed Feedback from Reviews

[jiceatscion]

This issues lists all unaddressed feedback from reviews of the Control Plane draft before January 2024. New feedback is in dedicated issues

(Aggregated from https://github.com/scionassociation/standards/issues/79 and https://github.com/scionassociation/standards/issues/90)

General points:

• Write IANA Considerations Section #7
• Add Security Considerations (see also RFC 3552)
• Make sure the references are correct:
  - Extend introduction, add overview and remove/edit notes #14
  - gRPC & service discovery - dangling reference #15
  - Normative references: Needed for the specification; specification is based on it.
  - Informative references: Provide background/additional information
• Continue improving use of MUST and SHOULD according to rfc2119 and rfc8174 #12
• What text can be removed? Be concise. Make sure every word that is there must be there.
• If time allows, add related work (not too academical, just overview)
• Complete IPR disclosure process with Anapaya. See also: https://github.com/scionassociation/standards/issues/101
• Add section on scalability and convergence time #8
• Improve the definition of "endpoint"
• section 2.1: "Intra-ISD beaconing creates path segments from core ASes to non-
  core ASes." sounds a bit vague. We could rephrase with something like this text, that Matthias wrote for the documentation: "Every core AS originates PCBs at regular intervals, and sends these to all egress interfaces to connected neighbor ASes. An originated PCB sent to a neighboring core ASes initiates an inter-ISD beacon, ultimately resulting in a core-segment. An originated PCB sent to a child AS initiates the intra-ISD beacon creating an up/down segment."

ISE Feedback:

• Clarifications about AS interfaces and peering #17
• Add a section “Life of a routing advertisement”  #21
• Remind reader about critical terminology , as we introduce quite a lot of new acronyms. For some critical ones, we should remind reader what they mean along the document, so reader is reminded. THis especially for:
  “ISD” should be defined on first use.
  Same goes for PCB
• Clarify time synchronization dependency #18
• Interoperability: we should add something especially for data and CP. There could even be one separate document for the ISE on the topic. --> TO be handled in separate future documents
• Deployment: add what is needed to run SCION, we can leave a reference to scion.org, scion Association --> We are working on a separate draft for PANRG
• Add context to bullet points in 2.1.2 (Extending a PCB)  #19
• Manageability: what must an AS monitor (paths, links, certificates, …) and reference to deployment #20
• Get some third party review: do I have enough information to build SCION from the draft? Ask someone who is building SCION to check if the drafts are enough to build a SCION implementation.. Do they spot inconsistencies? Example: they are building a Bluetooth ALG, and the coders realized that there are some small divergencies..

Decision TC Standardisation

• Adapt Section on SCION AS Numbers #9

Eliot Lear (ISE IETF):

• Section 1.3 would benefit from a one or more simple diagrams that demonstrates an ISD, ASes, and the various types of links. Please keep the diagrams small. --> CdK: Added one relatively small figure of an ISD with all link types to section 1.3.
• I would like you to spend a bit more time on loop detection. In particular, I would like you to explain how loops are averted within richly connected cores. --> CdK: Added some additional text about avoiding loops to section 2.3.2.1.
• Along those same lines, classic routing geeks will look for two words in this draft and not find them: partition and healing. Partition occurs when one network is split into two because of a link failure. Healing is the process of recovery from partition.
• I find Section 1.5.2.1 confusing. You seem to be saying that for values greater than 232-1, you should represent them in colon-separated lower-case hex, but then you go on to say, “programs SHOULD always use the decimal representation for display.” I would say: pick a way you want things displayed and stick to it. --> CdK: Adapted the sentence about this in section 1.5.2.1 "Formatting" to make it more clear.
• In Section 1.6, please create normative references for both GRPC and protobufs. --> CdK: Done
• I hope this doesn't come as a shock to you, but Figure 2 in Section 2.1.4 is quite busy, and requires a more detail, flow-based explanation. Please give that some thought. --> CdK: Done
• The text below Figure 2 and above Figure 3 could be simplified to say that a PCB consists of one or more path segments at a given time T from the vantage point of a particular AS F. Also, I think there's an editorial error in that diagram, unless I'm confused. You label two segments "path segment 2" (the 2nd and the last). I am further confused by the terminology, given the diagram, in that the diagram seems to infer a link-state database. --> CdK: Done
• I think for 2.2.1, it helps to show a full example message, or otherwise link to one in the Appendix. --> CdK: Added an Appendix with a full example of one PCB in Protobuf message format.
• Section 2.2.1.4.3 is underspecified. It must be crystal clear how to sign a message and how to verify it. Now I think your intent is to have a separate document for that. If so, leave a forward reference for now. --> CdK: Added a mathematical formula and a reference to the relevant section in the SCION CP-PKI Internet-Draft.

Juan Garcia-Pardo:

• Can one ingress or egress be part of two different links? Refers to section 1.3 "Introduction > Paths and Links".
• Explain why there is a "next_isd_as" field in the signed component of an AS body element (PCB). Refers to section 2.4.2 "PCB > AS Entry Signed Component".
• Where do the suggested values for set size and propagation time of PCBs in section 2.3.1.1. "Storing and Selecting Candidate PCBs" come from? Do they depend on the network topology? Explain. --> This relates to scalability concerns, handled in Add section on scalability and convergence time #8

Roger Lapuh:

• Add an overview picture to section 2.2.1 "Paths and Links".
• Networking is very sensitive to flooding. So reading this as network engineer causes some concerns. In order to remove concerns the flooding terminology should always be supported with a statement along which path flooding is used and how flooding loops are prevented. CdK: I have replaced the term "flooded" with "sent".
• Explain why why 4030 ISDs is enough for public addressing. Refers to section 2.2.3 "Addressing > ISD Numbers"
  See Discuss managing the number of ISDs and core ASes scion-deployment_I-D#1
• Clarify path reversal for symmetric routing #22