Extend introduction and remove/edit notes

[elear]

The following text needs to be reworked as you are not publishing some of these:

*Note:* This is the very first version of the SCION Data Plane
document. We are aware that the draft is far from perfect, and hope
to improve the content in later versions of the document. To reach
this goal, any feedback is welcome and much appreciated. Thanks!

*Note:* It is assumed that readers of this draft are familiar with
the basic concepts of the SCION next-generation inter-domain network
architecture. If not, please find more detailed information in the
IETF Internet Drafts [I-D.scion-overview], [I-D.scion-components],
[I-D.scion-cppki], and [I-D.scion-cp], as well as in [CHUAT22],
especially Chapter 2. A short description of the SCION basic terms
and elements can be found in Section 1.1 below.

Also,

From: Ron Bonica
The problem statement is weak. Before describing forwarding plane details, you need to tell the readers why they should deploy SCION. You say that the design advantages are:

• It provides control and transparency over forwarding paths the endpoints.        
• It simplifies the packet-processing at routers: Instead of having to perform longest-prefix matching on IP addresses, which requires expensive hardware and substantial amounts of energy, a router can simply access the next hop from the packet header, after having verified the authenticity of the hop field's MAC.

      Is there any benefit in switching, as opposed to routing, at the AS boundary? Yes, routing is expensive. But the router is already there. There is no incremental cost. By contrast, you would have to add a SCION device.
Is the real motivation to support new settlement models?

Same issue in other drafts:

• CPPKI Extend introduction and remove/edit notes scion-cppki_I-D#29
• CP Extend introduction, add overview and remove/edit notes scion-cp_I-D#14

[nicorusti]

Regarding problem statement, we can reuse some text from the overview draft section 1.2, stressing aspects that mostly pertain tom the data plane:

• Address needs of organizations or ecosystems exchanging sensitive information, such as financial institutions, healthcare providers, universities, multinationals, governments, critical and transportation infrastructure operators, which can not always be addressed by leveraging public Internet
• Providing availability inter-domain (e.g. quick reaction to link failure)
• Avoiding reflection attacks
• Provide visibility to endpoints as a base for trust-enhanched networking
• Simplified routing tables

etc.

[nicorusti]

"allowed" is also used in the CP draft:

• The :: zero-compression feature of IPv6 is NOT allowed. The feature has very limited use in a 48-bit address space and would only add more complexity.

[nicorusti]

This has been addressed in #24 and in other PRs for the other drafts.

[nicorusti]

Following discussion with Eliot, Clarify:

• Should this be IETF work instead of ISE? → Make it clear why these documents are being published. Two reasons: documenting existing implementation, discuss where it is implemented. Bring new concepts to industry that can be further improved with future versions of this work (or versions that can be valuable over time). Don’t make it looks like a standard.

[nicorusti]

Resolved in #67