[Raw] Roman Danyliw's Abstain on draft-ietf-raw-ldacs-13: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-raw-ldacs-13: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-raw-ldacs/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Russ Housley for the SECDIR review.

Thank you to the authors for their response to my original ballot
(https://mailarchive.ietf.org/arch/msg/raw/O-oD5YszJPL8ia1RCoVgNHqykLk/)

I am changing my ballot from DISCUSS to ABSTAIN.  This change is not because my
DISCUSS feedback have been addressed but because subsequent revisions of the
document (-11 to -13) now makes clear that there is no IETF protocol behavior
to review.  My feedback was either on actual or planned work being done in
other SDOs.

This content and the process to arrive at consensus as enumerated in Alvaro’s
ballot leads me to share his concerns on the ability to meet the rough
consensus bar set by RFC8789 to become an IETF stream RFC.

Finally, as I noted in my original DISCUSS position, I do not believe this work
is in scope for the WG.

==[ DISCUSS on -10

** With the upfront acknowledgement that I have little familiarity with LDACS,
I had significant difficulty in assessing the alignment of most this document
to the defined charter of RAW.  It appears to me that only a narrow portion of
the document is in-charter scope. References were provided for LDACS (e.g.,
[ICAO2015]), but as they were behind a paywall I was not able to review them. 
Relying primarily on Section 7.3 and Figure 3 of the [MAE20192], it appears
that LDACS is a series of technologies that operate below layer-3.  Operating
on top of LDACS at layer3+ is the FCI.  Section 4 reminds us that “The IPv6
architecture for the aeronautical telecommunication network is called the FCI.”

Per the RAW charter, “RAW will stay abstract to the radio layers underneath,
addressing the Layer 3 aspects in support of applications requiring high
reliability and availability.”  With that in mind, I was looking for the in
scope RAW work items to produce “Use Cases, Requirements,
Architecture/Framework Aspects for a Wireless Network, and an Evaluation of
Existing IETF Technologies and Gap Analysis” for technologies at or above layer
3.  In Section 5.2.3, I first found specifics on FCI that appear to a use cases
within that scope.  In Section 7.3.3,  there is text on the SNP which describes
activity germane to handling layer-3 services.  However, this section also
excludes this work as out of scope -- “[t]his work is ongoing and not part of
this document.”

In my assessment the overwhelming majority of the text in this document is
describing technologies and architecture not in RAW’s in-scope remit of layer
3+.

If the WG finds documenting this otherwise paywalled information in an
information document valuable, I see no issue keeping this material in an
Appendix.  However, the framing of this document needs to be clearer to
highlight the in-scope materials around FCI.

** Section 9.  Please explicitly document the Security Considerations of FCI
(i.e., the IPv6/layer behaviors).  Is that Section 9.2?

-- Section 9, Per “These requirements imply that LDACS must provide layer 2
security in addition to any higher layer mechanisms”, it isn’t clear how this
is in-scope given the remit of RAW (see above).

-- Section 9.1 is helpful background but what of that applies to layer 3?  The
specifics in the threat analysis of [STR2016] and the advent of SDRs appears to
be largely data link considerations.

-- Section 9.2  How does [MAE20181] inform layer 3 threats as it’s explicitly
focused on data link issues?

-- Section 9.3.  Which of these security objectives apply to the FCI?

-- Section 9.5.3.  Architecturally, it isn’t clear how IPSec, TLS are being
used by the FCI.

==[ COMMENTs on -10
I was unable to review the security claims of this document as several of the
references were not available to me. For example, [ARI2021], [ICAO2015], and
[ICA2018].  I leave it the judgement of the responsible AD to that the WG had
appropriate access and that they are being appropriately used.