should we use forward reference?

[falko-strenzke]

Falko's original remark

In Section 4.2.3 we have a forward reference to Section 4.3.2. I think normally in a specification one would only make backwards references to things already defined. Thus the referenced section specifying the packet structure should better be moved in front IMO.

(Section 4.2.4 also has a similar forward reference)

Comment on this from Aron (from previous issue):

forward reference

I personally don't have anything against forward references. I usually like even the backrefs, so that you can navigate the spec in both directions. Generally, when implementing, I don't use the spec linearly

[falko-strenzke]

Meeting 2023-01-19:

• Aron: circle reference not avoidable for data generation and their encoding
• Stavros: do we have many forward references?
• Aron: a couple in the context of packet formats
• Falko: agreed to the circular dependency problem
• All: generally we should make it without forward references
• Stavros: will read through and check for forward references again

[fluppe2]

Non-local forward references:

§1.2.3 --> §9.1 §1.3.3 --> Table 6, 7, 11 §1.4.2 --> §3.2 and §3.4 §4.2.1 --> §8.2 §4.2.3 --> §4.3.1 and §4.3.2 §4.2.4 --> §4.3.1 and §4.3.2 §5.2.2 --> §5.3.1 §6.1.2 --> §8.3

To summarize the types of forward references:

• Pointing to "considerations" in 8,9
• From introductory section to later descriptions, i.e. §1.x.y --> see above
• Procedural before packet description §4.2.x --> §4.3.y and and §5.2.x --> §5.3.y

[TJ-91]

We have a circular reference for the wrapped session key between ({#ecc-kyber-pkesk} and {#ecc-kyber-encryption} (5.3.1. and 5.2.4). Both say "as specified in" or "as described in" the respective other section.

I think it's not a real problem and it's easy enough to understand as it is, but we might consider to resolve such circular references.

[falko-strenzke]

Meeting 2023-06-05:

• JRH will resolve the only critical point he pointed out above.