L-Band Digital Aeronautical Communications System (LDACS)
draft-ietf-raw-ldacs-14

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

[Ballot comment]

I am changing my position from DISCUSS to ABSTAIN.  After discussion in the IESG, it is clear that I am in the rough.  I am leaving the DISCUSS text below for reference.

=====

I found this document very informative, and there is value in publishing it as
an RFC.  However, I don't believe it can pass the rough consensus bar set by
rfc8789 to become an IETF Stream RFC.

As mentioned by the Shepherd, this document is a "description by matter
specialists of an externally-defined link-layer".  The technology described is
an overview of work done in another standards development organization (SDO)
[1].  There was no discussion of the content on the mailing list, which shows
only two messages from non-authors: one asking for more information; the reply
was a pointer to the LDACS external specification [2] -- the other was the
single WGLC reply from the document shepherd [3].

I want to discuss this question with the IESG:  Can the IETF reach rough
consensus on a document that describes technology developed by a different
SDO? 

My opinion is that documents that describe technology developed by a different
SDO cannot be published as IETF RFCs given the requirement in rfc8789.


[1] https://www.ldacs.com/wp-content/uploads/2013/12/SESAR2020_PJ14_D3_3_030_LDACS_AG_Specification_00_02_02-1_0.pdf
[2] https://mailarchive.ietf.org/arch/msg/raw/iyext4Ub8MgUjNYYPE7XOPpq1Y0
[3] https://mailarchive.ietf.org/arch/msg/raw/L-ByflWTn_3vcGC8NNfMO-blkJU

[Ballot comment]
Thank you, Nils and other authors, for addressing my previous blocking DISCUSS and non-blocking COMMENT points per:
https://mailarchive.ietf.org/arch/msg/raw/WnMNGy4YMhqUHtPW6UC45CJ6KXI/

Thanks again for the work done: I have enjoyed reading this document.

Regards

-éric

PS: thanks also to Carlos Bernardos for his INT directorate review.

[Ballot discuss]
[I'm updating the text of my DISCUSS ballot from Apr/18.  This is a clarification
to avoid misinterpretations when considering the ballot in a general context.]

[Authors:  Thank you for the work!  There's no action required from you.  My
opinion below is to be discussed with the IESG.]


I found this document very informative, and there is value in publishing it as
an RFC.  However, I don't believe it can pass the rough consensus bar set by
rfc8789 to become an IETF Stream RFC.

As mentioned by the Shepherd, this document is a "description by matter
specialists of an externally-defined link-layer".  The technology described is
an overview of work done in another standards development organization (SDO)
[1].  There was no discussion of the content on the mailing list, which shows
only two messages from non-authors: one asking for more information; the reply
was a pointer to the LDACS external specification [2] -- the other was the
single WGLC reply from the document shepherd [3].

I want to discuss this question with the IESG:  Can the IETF reach rough
consensus on a document that describes technology developed by a different
SDO? 

My opinion is that documents that describe technology developed by a different
SDO cannot be published as IETF RFCs given the requirement in rfc8789.


[1] https://www.ldacs.com/wp-content/uploads/2013/12/SESAR2020_PJ14_D3_3_030_LDACS_AG_Specification_00_02_02-1_0.pdf
[2] https://mailarchive.ietf.org/arch/msg/raw/iyext4Ub8MgUjNYYPE7XOPpq1Y0
[3] https://mailarchive.ietf.org/arch/msg/raw/L-ByflWTn_3vcGC8NNfMO-blkJU

[Ballot comment]
Thanks for working on this document. This was interesting read. However, it felt a bit short on the purpose of such a documentation about LDACS and FCI description.

I was trying to see how much of this document is actually leading to usecase / requirements and how much of it just description of something done outside of IETF. I concluded that this merely a description of other related technology which might be using RAW. I see that is what the shepherd also wrote. Hence, I find it as support material and in that category we are supposed to encourage the WG to use other tools to publish something which does not have archiving values. A simple reference to the LDAC spec or something in appendix or use of WG wiki could serve the purpose and save WG's time and energy.More than that I found this is below layer-3 and to me that seems to be out of scope of RAW.

It might be the way the document is written where the scope and intention is not clear from the document itself. yes, this might be good information for RAW work, but may be it should then focus on those part which are relevant and need a IETF consensus to really agree on those relevant parts to work in RAW.

For this I am supporting Roman's and Alvero's discuss.

[Ballot discuss]
** 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.

[Ballot comment]
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.

** Section 1.  Editorial

(2) the introduction of IPv6 based networking protocols in
  aeronautical networks [RFC4291], [RFC7136], [ICAO2015].

I didn’t understand the link between [RFC4291] and [RFC7136] and aeronautical networks.  If these are only intended to be citations to IPv6, then the text would be clearer as:

(2) the introduction of IPv6 based networking protocols [RFC4291], [RFC7136] in aeronautical networks  [ICAO2015].

** Section 5.2.1

The related protocol
  stack is currently under development by ICAO, within SESAR, and the
  IETF [I-D.haindl-lisp-gb-atn] [I-D.ietf-rtgwg-atn-bgp]

Judged entirely on datatracker meta-data, it appears to be a mis-characterization to say that draft-haindl-lisp-gb-atn is under-development in the IETF.  All I can confirm is the existence of an individual submission that has been updated a number of times over 4+ years that has not been adopted by a WG.

** From idnits:
  == Missing Reference: 'KOB1987' is mentioned on line 1211, but not defined

[Ballot comment]
Hi,

Thanks for this document.

I have some sympathy with other ADs opinions that this may be better published via the ISE, although it isn't entirely clear to me that this should be out of scope for an IETF informational document.

I didn't read the document in complete detail, but I did wonder whether it would be helpful to have a short section describing management considerations?  E.g., what management interface/protocols would be used to configure/manage the solution?  Would this be done via YANG + NETCONF, or a different network management stack.

Regards,
Rob

[Ballot comment]
The datatracker state does not indicate whether the consensus boilerplate
should be included in this document.

No reference entries found for: [KOB1987].

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term "master"; alternatives might be "active", "central", "initiator",
  "leader", "main", "orchestrator", "parent", "primary", "server"

Thanks to Dale Worley for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/DhJCJ3dvXjga7paQ8GrXYswpX6E).

-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 7.3.3, paragraph 1, nit:
-    Lastly, the SNP handles the transition from IPv6 packts to LDACS
+    Lastly, the SNP handles the transition from IPv6 packets to LDACS
+                                                        +

Document references draft-haindl-lisp-gb-atn-06, but -07 is the latest
available revision.

Document references draft-ietf-rtgwg-atn-bgp-14, but -17 is the latest
available revision.

Paragraph 2076, nit:
> band's increasing saturation in high- density areas and the limitations posed
>                                ^^^^^^^^^^^^^
This word seems to be formatted incorrectly. Consider fixing the spacing or
removing the hyphen completely.

Paragraph 2256, nit:
> ications System (LDACS). Since central Europe has been identified as the area
>                                ^^^^^^^^^^^^^^
If the term is a proper noun, use initial capitals.

Paragraph 2315, nit:
> ically LDACS enables IPv6 based air- ground communication related to aviation
>                                ^^^^^^^^^^^
This word seems to be formatted incorrectly. Consider fixing the spacing or
removing the hyphen completely.

Paragraph 2604, nit:
> cols, the ATN/OSI, failed in the market place. In the context of safety-relat
>                                  ^^^^^^^^^^^^
This is normally spelled as one word.

Paragraph 5565, nit:
> sponsible to guide the aircraft. Currently this is done by the air crew manu
>                                  ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Currently".

Paragraph 5863, nit:
> eceiver via a separate data link. Currently the VDB data link is used. VDB is
>                                  ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Currently".

Paragraph 5870, nit:
> VDB data link is used. VDB is a narrow-band single-purpose datalink without
>                                ^^^^^^^^^^^
This word is normally spelled as one.

Paragraph 7117, nit:
> .1. LDACS Sub-Network An LDACS sub-network contains an Access Router (AR) an
>                                ^^^^^^^^^^^
This word is normally spelled as one. (Also elsewhere.)

Paragraph 7315, nit:
> imultaneously support multiple bi-directional communications to the ASs unde
>                                ^^^^^^^^^^^^^^
This word is normally spelled as one. (Also elsewhere.)

Paragraph 9499, nit:
> data links are handled by the FCI multi- link concept. 8. Reliability and Ava
>                                  ^^^^^^^^^^^
This word seems to be formatted incorrectly. Consider fixing the spacing or
removing the hyphen completely.

Paragraph 10374, nit:
> DiffServ) based solution with a small number of priorities is to be expected
>                              ^^^^^^^^^^^^^^^^^
Specify a number, remove phrase, use "a few", or use "some".

Paragraph 15162, nit:
> tps://sike.org/>. [ROY2020] Roy, S.S.. and A. Basso, "High-Speed Instruction
>                                    ^^
Two consecutive dots.

Paragraph 15855, nit:
> f Flight Measurement Results", IEEE 32th Digital Avionics Systems Conference
>                                    ^^^^
The suffix does not match the ordinal number.

Paragraph 16248, nit:
> nich, N., Micallef, J., Klauspeter, H.., MacBride, J., Sacre, P., v.d. Eiden
>                                      ^^
Two consecutive dots.

[Ballot discuss]
Firstly thank you to the authors of the document for the good work.

I however must agree with Alvaro's ballot and further expand on it.  I have a concern that publishing a document that merely describes an outside standard, that is not developed within the IETF, could open a significantly problematic door to people developing standards outside of the IETF, and then using a mechanism like this, to effectively get a rubber stamp on something that the IETF has no control over.  To me, this document would seem better suited to the ISE rather than the IETF track.

[Ballot discuss]
Thank you for the work put into this document. It is also important for the IETF to welcome new work. The content is really interesting to read (especially for a private pilot!); albeit, it appears more like a roadmap / plan to use IETF protocols for aviation rather than being focused only on LDACS.

Please find below some blocking DISCUSS points, some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

I also support Alvaro Retana's DISCUSS on using the right publication stream, which should have been ISE in this case as often done for documents describing specifications done outside the IETF. I notice that this document as an "unknown" status for the consensus boilerplate and setting it to "No" (if possible) would probably address Alvaro's concern.

Special thanks to:

- Pascal Thubert for the shepherd's write-up including the WG consensus and the intended status.

- Carlos Bernardos for his INT directorate review at https://mailarchive.ietf.org/arch/msg/int-dir/oRK9fXWx48Xj6VhdJMMarEPFB3c/ which also raises the same issue as Alvaro but also has other points deserving a reply

I hope that this helps to improve the document,

Regards,

-éric

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

## Section 4

Raising a DISCUSS just to get a discussion with authors, RAW WG, ICAO representatives, and the community:
  "There is currently no "IPv6 over LDACS" specification
  publicly available; however, SESAR2020 has started the testing of
  IPv6-based LDACS testbeds."
Is the plan to have this "IPv6 over LDACS" be specified in an IETF WG (e.g., intarea) ? Or will ICAO work alone on this specification (and perhaps not using the experience of the IETF community)?

## Section 5.2.1

Let me share Carlos' point, which I second (it would be enough to state the intention about MIPv6 to address it):

- "Technically the FCI multilink concept will be realized by multi-homed mobile
IPv6 networks in the aircraft." --> how is Mobile IPv6 going to be used and
which specific protocol of the Mobile IPv6 family? just MIPv6 and/or PMIPv6?
implications on mobility and RAW are unclear at this point (probably this is
for the RAW WG to evaluate, but just wanted to point it out).

[Ballot comment]
# COMMENTS

## Section 1

As Erik Kline, please use RFC 8200 as a reference to IPv6.

The last two paragraphs are more a liaison statement of the ICAO than an integral part of an IETF stream document.

## Section 2

It is not really a terminology section but rather an acronym list. I.e., suggest renaming this section ?

## Section 5.2.5

Some explanations on how positioning can be done in the absence of GNSS would be welcome.

## Section 8.2

Suggest to also add the well-known SNMP & NETCONF as the acronyms are more often known than their expansions.

## Section 9.2

Should the section title include the word "security" ?

## Section 9.3

"Currently" won't age well ;-) Suggest to write "Work in 2022 includes..."

## Section 9.5.2

What is "ICAO unique address of an aircraft" ? Is it a layer-2 address ?


# NITS 

## Section 1
s/area of the world, that suffers/area of the world that suffers/ ?
s/east- and west- cost of the US/East and West Coast of the USA/ ?

and many other typos... Strongly suggest using a tool to improve the grammar / spelling

[Ballot comment]
# Internet AD comments for draft-ietf-raw-ldacs-10
CC @ekline

## Comments

### S1

* The use of RFCs 4291 and 7136 for "IPv6 based networking protocols" seems
  a bit odd to me.  These are addressing architecture and interface
  identifier documents; why not just RFC 8200 itself?

### S4, S7.3.3

* I'm sure 6MAN wg might be interested in hearing if anything special is
  required of IPv6 w.r.t. operating over the sub-IP layer here.

### S7.3.2

* Just an FYI: consider having a look at RFC 3366 ("Advice to link designers
  on link Automatic Repeat reQuest (ARQ)"), just in case there's anything
  helpful in there.  (To be clear: no action requested vis. this draft.)

### S9, S9.5.4

* I'm very glad to see that L2 integrity is a requirement.  Without it, many
  IPv6 on-link attacks become possible.

  However, even with L2 integrity, some consideration should be given to
  IPv6 operational security.  Please consider RFC 9099, along with several
  of the documents it references (RFC 4942, etc).

## Nits

### S3.2

* s/While the aircraft is on ground/While the aircraft is on the ground/?

[Ballot discuss]

[Authors:  Thank you for the work!  There's no action required from you.  My
opinion below is to be discussed with the IESG.]


I found this document very informative, and there is value in publishing it as
an RFC.  However, I don't believe it can pass the rough consensus bar set by
rfc8789 to become an IETF Stream RFC.

As mentioned by the Shepherd, this document is a "description by matter
specialists of an externally-defined link-layer".  The technology described is
an overview of work done elsewhere.  There was no discussion of the content on
the mailing list, which shows only two messages from non-authors: one asking
for more information; the reply was a pointer to the LDACS external
specification [1] -- the other was the single WGLC reply from the document
shepherd [2].

I want to discuss this question with the IESG:  Can the IETF reach rough
consensus on a document that describes someone else's technology?  This
document is akin to many others that have been published through the ISE as,
for example, a vendor's implementation of a specific protocol. 

My opinion is that documents that describe someone else's technology cannot be
published as IETF RFCs given the requirement in rfc8789.


[1] https://mailarchive.ietf.org/arch/msg/raw/iyext4Ub8MgUjNYYPE7XOPpq1Y0
[2] https://mailarchive.ietf.org/arch/msg/raw/L-ByflWTn_3vcGC8NNfMO-blkJU

[Ballot discuss]

[Authors:  Thank you for the work!  There's no action required from you.  My
opinion below is to be discussed with the IESG.]


I found this document very informative, and there is value in publishing it as
an RFC.  However, I don't believe it can pass the rough consensus bar set by
rfc8789 to become an IETF Stream RFC.

As mentioned by the Shepherd, this document is a "description by matter
specialists of an externally-defined link-layer".  The technology described is
an overview of work done elsewhere.  There was no discussion of the content on
the mailing list, which shows only two messages from non-authors: one asking
for more information; the reply was a pointer to the LDACS external
specification [1] -- the other was the single WGLC reply from the document shepherd [2].

I want to discuss this question with the IESG:  Can the IETF reach rough
consensus on a document that describes someone else's technology?  This
document is akin to many others that have been published through the ISE as,
for example, a vendor's implementation of a specific protocol. 

My opinion is that documents that describe someone else's technology cannot be
published as IETF RFCs given the requirement in rfc8789.


[1] https://mailarchive.ietf.org/arch/msg/raw/iyext4Ub8MgUjNYYPE7XOPpq1Y0
[2] https://mailarchive.ietf.org/arch/msg/raw/L-ByflWTn_3vcGC8NNfMO-blkJU

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-raw-ldacs-10, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Michelle Thangtamsatid
IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-04-04):

From: The IESG
To: IETF-Announce
CC: draft-ietf-raw-ldacs@ietf.org, jgs@juniper.net, pthubert@cisco.com, raw-chairs@ietf.org, raw@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (L-band Digital Aeronautical Communications System (LDACS)) to Informational RFC


The IESG has received a request from the Reliable and Available Wireless WG
(raw) to consider the following document: - 'L-band Digital Aeronautical
Communications System (LDACS)'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-04-04. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document gives an overview of the architecture of the L-band
  Digital Aeronautical Communications System (LDACS), which provides a
  secure, scalable and spectrum efficient terrestrial data link for
  civil aviation.  LDACS is a scheduled, reliable multi-application
  cellular broadband system with support for IPv6.  LDACS provides a
  data link for IPv6 network-based aircraft guidance.  High reliability
  and availability for IP connectivity over LDACS, as well as security,
  are therefore essential.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-raw-ldacs/



No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

-> Informational. The document illustrates that LDACS has the properties that are needed to support RAW but RAW doesn’t place any special  requirement that would require normative text. In fact, RAW is not even chartered to specify anything so far and produces only informational documents. See also my WG summary below.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
  This document provides an overview of the architecture of the L-band Digital Aeronautical Communications System (LDACS), which is a wireless communication standard defined outside of the IETF and relevant to the work at the RAW WG.
LDACS provides a secure, scalable and spectrum efficient terrestrial data link for civil aviation, based on a scheduled, reliable multi-application cellular broadband system with support for IPv6.
It is expected to become a data link of choice for IP network-based aircraft guidance for which the RAW properties of high reliability and availability are essential.


Working Group Summary:

The process was as smooth as possible, with no contradiction over the ML or during meetings. The document is really the description by matter specialists of an externally-defined link-layer. It is a useful base for the RAW work and good information for the rest of us.

Document Quality:

LDACS is an emerging technology; prototypes were presented, see https://ieeexplore.ieee.org/document/9397802. The draft was written by the technology specialists. It is very readable and quite thorough.

Personnel:

Document Shepherd: Pascal Thubert
Responsible Area Director: John Scudder

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The shepherd performed a full review of the documents and the comments were addressed. No major issue reported. The document appears ready for publication request.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

Not at all!

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

It would be cool that the security model in their Tesla mechanism be validated; but then again this is not an IETF-defined standard.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No such thing

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes, they all confirmed; there is no IPR to report on that document; there might be IPR on the presented technology.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No disclosure

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The former; it’s a good read but not a standard being developed in-house.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No such thing

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Nothing worth mentioning; an unused reference to RFC 2119 will be removed

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No such need

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Only RFCs

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

None

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

No IANA request

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

None

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No such need

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No such need

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

-> Info

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
  This document provides an overview of the architecture of the L-band Digital Aeronautical Communications System (LDACS), which is a wireless communication standard defined outside of the IETF and relevant to the work at the RAW WG.
LDACS provides a secure, scalable and spectrum efficient terrestrial data link for civil aviation, based on a scheduled, reliable multi-application cellular broadband system with support for IPv6.
It is expected to become a data link of choice for IP network-based aircraft guidance for which the RAW properties of high reliability and availability are essential.


Working Group Summary:

The process was as smooth as possible, with no contradiction over the ML or during meetings. The document is really the description by matter specialists of an externally-defined link-layer. It is a useful base for the RAW work and good information for the rest of us.

Document Quality:

LDACS is an emerging technology; prototypes were presented, see https://ieeexplore.ieee.org/document/9397802. The draft was written by the technology specialists. It is very readable and quite thorough.

Personnel:

Document Shepherd: Pascal Thubert
Responsible Area Director: John Scudder

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The shepherd performed a full review of the documents and the comments were addressed. No major issue reported. The document appears ready for publication request.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

Not at all!

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

It would be cool that the security model in their Tesla mechanism be validated; but then again this is not an IETF-defined standard.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No such thing

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes, they all confirmed; there is no IPR to report on that document; there might be IPR on the presented technology.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No disclosure

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The former; it’s a good read but not a standard being developed in-house.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No such thing

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Nothing worth mentioning; an unused reference to RFC 2119 will be removed

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No such need

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Only RFCs

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

None

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

No IANA request

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

None

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No such need

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No such need

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

-> Info

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
  This document provides an overview of the architecture of the L-band Digital Aeronautical Communications System (LDACS), which is a wireless communication standard defined outside of the IETF and relevant to the work at the RAW WG.
LDACS provides a secure, scalable and spectrum efficient terrestrial data link for civil aviation, based on a scheduled, reliable multi-application cellular broadband system with support for IPv6.
It is expected to become a data link of choice for IP network-based aircraft guidance for which the RAW properties of high reliability and availability are essential.


Working Group Summary:

The process was as smooth as possible, with no contradiction over the ML or during meetings. The document is really the description by matter specialists of an externally-defined link-layer. It is a useful base for the RAW work and good information for the rest of us.

Document Quality:

LDACS is an emerging technology; prototypes were presented, see https://ieeexplore.ieee.org/document/9397802. The draft was written by the technology specialists. It is very readable and quite thorough.

Personnel:

Document Shepherd: Pascal Thubert
Responsible Area Director: John Scudder

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The shepherd performed a full review of the documents and the comments were addressed. No major issue reported. The document appears ready for publication request.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

Not at all!

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

It would be cool that the security model in their Tesla mechanism be validated; but then again this is not an IETF-defined standard.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No such thing

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes, they all confirmed; there is no IPR to report on that document; there might be IPR on the presented technology.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No disclosure

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The former; it’s a good read but not a standard being developed in-house.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No such thing

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Nothing worth mentioning; an unused reference to RFC 2119 will be removed

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No such need

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Only RFCs

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

None

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

No IANA request

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

None

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No such need

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No such need

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

-> Info

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
  This document provides an overview of the architecture of the L-band Digital Aeronautical Communications System (LDACS), which is a wireless communication standard defined outside of the IETF and relevant to the work at the RAW WG. LDACS provides a secure, scalable and spectrum efficient terrestrial data link for civil aviation, based on a scheduled, reliable multi-application cellular broadband system with support for IPv6, providing a data link for IP network-based aircraft guidance for which the RAW properties of high reliability and availability are essential.


Working Group Summary:

The process was as smooth as possible, with no contradiction over the ML or during meetings. The document is really the description by matter specialists of an externally-defined link-layer. It is a useful base for the RAW work and good information for the rest of us.

Document Quality:

LDACS is an emerging technology; prototypes were presented, see https://ieeexplore.ieee.org/document/9397802. The draft was written by the technology specialists. It is very readable and quite thorough.

Personnel:

Document Shepherd: Pascal Thubert
Responsible Area Director: John Scudder

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The shepherd performed a full review of the documents and the comments were addressed. No major issue reported. The document appears ready for publication request.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

Not at all!

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

It would be cool that the security model in their Tesla mechanism be validated; but then again this is not an IETF-defined standard.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No such thing

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes, they all confirmed; there is no IPR to report on that document; there might be IPR on the presented technology.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No disclosure

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The former; it’s a good read but not a standard being developed in-house.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No such thing

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Nothing worth mentioning; an unused reference to RFC 2119 will be removed

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No such need

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Only RFCs

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

None

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

No IANA request

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

None

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No such need

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No such need

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

-> Info

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
  This document provides an overview of the architecture of the L-band Digital Aeronautical Communications System (LDACS), which is a wireless communication standard defined outside of the IETF and relevant to the work at the RAW WG. LDACS provides a secure, scalable and spectrum efficient terrestrial data link for civil aviation.  LDACS is a scheduled, reliable multi-application cellular broadband system with support for IPv6, providing a data link for IP network-based aircraft guidance for which the RAW properties of High reliability and availability are essential.


Working Group Summary:

The process was as smooth as possible, with no contradiction over the ML or during meetings. The document is really the description by matter specialists of an externally-defined link-layer. It is a useful base for the RAW work and good information for the rest of us.

Document Quality:

LDACS is an emerging technology; prototypes were presented, see https://ieeexplore.ieee.org/document/9397802. The draft was written by the technology specialists. It is very readable and quite thorough.

Personnel:

Document Shepherd: Pascal Thubert
Responsible Area Director: John Scudder

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The shepherd performed a full review of the documents and the comments were addressed. No major issue reported. The document appears ready for publication request.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

Not at all!

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

It would be cool that the security model in their Tesla mechanism be validated; but then again this is not an IETF-defined standard.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No such thing

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes, they all confirmed; there is no IPR to report on that document; there might be IPR on the presented technology.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No disclosure

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The former; it’s a good read but not a standard being developed in-house.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No such thing

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Nothing worth mentioning; an unused reference to RFC 2119 will be removed

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No such need

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Only RFCs

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

None

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

No IANA request

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

None

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No such need

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No such need