A YANG Data Model for Optical Impairment-aware Topology <del> draft-ietf-ccamp-optical-impairment-topology-yang-10 </del>  Abstract and management plane capabilities.  The YANG data model defined in this draft is providing sufficient information to enable optical impairment aware path computation. Optical data plane interoperability is outside the scope of this draft. 2.10. The YANG model defined in this document supports the following <del> protection architectures: </del>  Individual OTSi protection OMS MCG protection = TE-link protection between adjacent WDM-TE- 2.10.1. Individual OTSi protection is a protection architecture where an <del> individual OTSi signal is protected as defined in Appendix III of </del>  ITU-T Recommendation G.873.1 G.873.1.  This protection architecture <del> requires dedicated photonic protection functions that are typically provided by dedicated protection hardware.  These photonic protection functions are a photonic splitter function splitting the OTSi signal in transmit direction and a photonic selector function selecting the OTSi signal in receive direction from one of the two protection legs between the protection functions terminating the individual OTSi protection.  This individual OTSi protection scheme can be considered as a photonic 1+1 protection scheme (1+1 sub-network connection protection (SNCP) in ITU-T terminology). </del>  In case of individual OTSi protection, there are two network media channel paths associated with the OTSi signal.  In the YANG model, for the two network media channel paths associated with the individually protected otsi. <del> [Editor's note: this section is still work in progress] </del>  2.10.2.

draft-ietf-ccamp-optical-impairment-topology-URL for IETF 115 submission --> draft-ietf-ccamp-optical-impairment-topology-yang-URL Related to pull request URL Addressing and resolving .

A YANG Data Model for Optical Impairment-aware Topology  <ins> draft-ietf-ccamp-optical-impairment-topology-yang-11 </ins> Abstract and management plane capabilities.  The YANG data model defined in this draft is providing sufficient information to enable optical impairment aware path computation. Optical data plane interoperability is outside the scope of this draft. 2.10. The YANG model defined in this document supports the following  <ins> optical protection architectures: </ins> Individual OTSi protection OMS MCG protection = TE-link protection between adjacent WDM-TE- 2.10.1. Individual OTSi protection is a protection architecture where an  <ins> individual OTSi signal is protected as described in Appendix III of </ins> ITU-T Recommendation G.873.1 G.873.1.  This protection architecture  <ins> requires dedicated photonic protection functions in the optical domain that are typically provided by dedicated protection hardware. These photonic protection functions are a photonic splitter function splitting the OTSi signal in transmit direction and a photonic selector function selecting the OTSi signal in receive direction from one of the two protection legs between the two protection functions terminating the individual OTSi protection.  This individual OTSi protection scheme can be considered as a photonic 1+1 protection scheme (1+1 sub-network connection protection (SNCP) in ITU-T terminology). In order to achieve short protection switching times, it is necessary that the OTSi signals of the two legs are identical in terms of wavelength, modulation format, FEC, etc., which means no receiver configuration changes when a protection switch at the selector occurs selecting the other leg.  This is important when 3R regenerators are needed between the two end-points terminating the protected segment, which typically is end-to-end. </ins> In case of individual OTSi protection, there are two network media channel paths associated with the OTSi signal.  In the YANG model, for the two network media channel paths associated with the individually protected otsi.  <ins> Individual OTSi protection use cases: The different use cases are described in following sub-sections and examples are provided how these uses cases can be modeled properly using the optical impairment aware TE-topology YANG data model. 2.10.1.1. This use case is based on the architecture illustrated in Figure-6 and the following entities are all integral parts of the WDM-TE-node: Figure-11 illustrates such a WDM-TE-node configuration in transmit/ forward direction where the protection function is an optical splitter and Figure-12 illustrates the same WDM-TE-node configuration in receive/reverse direction where the protection function is an optical selector selecting one of the two incoming OTSi signals and switching to the other incoming OTSi signal when the optical power of the selected OTSi signal drops below a pre-defined threshold. The TE-topology YANG model has been augmented to describe this protection architecture.  The already existing optional protection- type leaf of the TTP associated with the optical transceiver is used to indicate whether the TTP is protected, i.e., whether it is connected to a protection function or whether it is unprotected, i.e., whether it is directly connected to an add-drop port of the ROADM function in the WDM-TE-node. For unprotected TTPs associated with an optical transceiver, the local-link-connectivity list describes the potential connectivity between the TTP and the LTPs of the WDM-TE-node that are the local end-points of the TE-links (OMS MCGs) interconnecting the WDM-TE-node with its neighbors, also often called degrees of the WDM-TE-node as opposed to its add-drop ports. For protected TTPs, the local-link-connectivity list has been augmented such that is is capable of describing the potential connectivity not only between the TTP and a single LTP a (unprotected case) but is now capable to describe the potential connectivity to additional LTPs including the related optical impairments.  If the optical impairments are the same for all local-link-connectivity list entries for a particular TTP, which is usually the case, the optical impairments shall be omitted for the additional LTPs leading to a more compact topology description.  If the optical impairments are different, however, they can be described for each additional LTP entry separately. A local-link-connectivity list example for a protected TTP in JSON format is provided in JSON Examples. 2.10.1.2. This use case is based on the architecture illustrated in Figure-7 where the optical transponder is not part of the WDM-TE-node containing the ROADM function (WDM-TE-Node-2) but is part of a separate WDM-TE-node (WDM-TE-Node-1) containing one or more optical transponders (remote OTs).  WDM-TE-Node-2 contains: Figure-13 illustrates such a network configuration in transmit/ forward direction showing the two WDM-TE-nodes where the protection function is the optical splitter in WDM-TE-Node-2 and Figure-14 illustrates the same network configuration in receive/reverse direction where the protection function is the optical selector in WDM-TE-Node-2 selecting one of the two incoming OTSi signals and switching to the other incoming OTSi signal when the optical power of the selected OTSi signal drops below a pre-defined threshold. In the network configuration shown in Figure-13 and Figure-14, respectively, the two WDM-TE-nodes are interconnected via a TE-link only carrying a single OTSi signal.  This TE-link interconnects the remote OT with an add-drop port of WDM-TE-Node-2 and in the following the qualifier "add-drop" is used to refer to that LTP as opposed to the line LTPs representing degrees of WDM-TE-Node-2.  Similar to the protected TTP in Protection UC (i), the optional protection-type leaf is used to indicate whether the add-drop LTP is connected to a protection function and then to two line LTPs via the ROADM function inside WDM-TE-Node-2 or whether it is connected to a single line LTP via the ROADM function inside WDM-TE-Node-2 (unprotected add-drop LTP).  While the protection-type attribute was already defined for the TTP, the YANG model has been augmented to also support this optional attribute for the LTP. For protected LTPs, the connectivity-matrix has been augmented such that it is capable of describing the potential connectivity not only from an add-drop LTP to a single line LTP (unprotected case) but is now capable to describe the potential connectivity to additional line LTPs (protected case) including the related optical impairments.  If the optical impairments are the same from the protected ad-drop LTP to all line LTPs, which is usually the case, the optical impairments shall be omitted for the additional LTPs leading to a more compact connectivity matrix description.  If the optical impairments are different, however, they can be described for each additional LTP separately. 2.10.1.3. The use case illustrated in Figure-15 is similar to the use case in Protection UC (i).  The difference compared to use case (i) is that WDM-TE-Node-1 does not contain the ROADM function but contains: WDM-TE-Node-1 can be a data center device or a router router device that supporting 1+1 OTSi protection for its OTs while WDM-TE-Node-2 is a WDM-TE-node providing add-drop ports for remote OTs as depicted in Figure-7.  WDM-TE-Node-1 and WDM-TE-Node-2 are interconnected via two separate TE-links, each carrying a single OTSi signal.  The protection configuration for the protected TTP in WDM-TE-Node-1 can be described in the same way as for use case (i) using the local- link-connectivity list. </ins> 2.10.2.


4.6. <del> Quality of Service (QoS) mechanisms for flow specific traffic </del>  treatment typically includes a guarantee/agreement for the service, and allocation of resources to support the service.  Example QoS mechanisms include discrete resource allocation, admission control, 5. <del> [Editor's note: This section to be updated.] While management plane and control plane are traditionally considered separately, from the Data Plane perspective there is no practical difference based on the origin of flow provisioning information. This document therefore does not distinguish between information provided by a control plane protocol, e.g., RSVP-TE RFC3209 and RFC3473, or by a network management mechanisms, e.g., RestConf RFC8040 and YANG RFC7950. [Editor's note: This section is a work in progress.  discuss here what kind of enhancements are needed for DetNet and specifically for PREOF and DetNet zero congest loss and latency control.  Need to cover both traffic control (queuing) and connection control (control plane).] </del>  5.1. <del> [Editor's note: this is TBD.] </del>  5.2. <del> [Editor's note: this is TBD.] </del>  5.3. <del> [Editor's note: this is TBD.] </del>  5.4. <del> [Editor's note: this is TBD.] </del>  5.5. <del> [Editor's note: This is managed at the management plane or controller level.] Some DetNet applications generate bidirectional traffic.  While the DetNet data plane must support bidirectional DetNet flows, there are no special bidirectional features with respect to the data plane other than need for the two directions take the same paths.  That is to say that bidirectional DetNet flows are solely represented at the management and control plane levels, without specific support or knowledge within the DetNet data plane.  Fate sharing and associated vs co-routed bidirectional flows can be managed at the control level. Note, that there is no stated requirement for bidirectional DetNet flows to be supported using the same 6-tuple in each direction. Control mechanisms will need to support such bidirectional flows but such mechanisms are out of scope of this document.  An example control plane solution for MPLS can be found in RFC7551. </del>  6. 6.4. <del> The use of prefixes, wildcards, bimasks, and port ranges allows a </del>  DetNet node to aggregate DetNet flows.  This aggregation can take place within a single node, when that node maintains state about both the aggregated and component flows.  It can also take place between

New section 5, and capitalized headings.
Lou, Yes, I'll make that change. Cheers, Andy
And done.
Thanks.... Lou PS you might want to turn off line wrap in your editor...
Lou, I just checked the settings and I don't believe it's doing any hard wrapping. What are you seeing? Cheers, Andy
right - it's best to use hard wrapping for maximum editor independence as well as github reviews. Lou
Balázs, This is similar to the text in the MPLS document, but that document references SR-MPLS. In the IP case, I figured that SR-MPLS was off the table, so I changed the reference to SRv6. The earlier part of the sentence already references control plane signaling, centralized management, and hybrid solutions. In addition to those, I wanted to include the fact that SRv6 is also a valid solution here. If there's anything else that you would like to include, we can certainly add that. Cheers, Andy

4.6.  <ins> Quality of Service (QoS) mechanisms for flow-specific traffic </ins> treatment typically includes a guarantee/agreement for the service, and allocation of resources to support the service.  Example QoS mechanisms include discrete resource allocation, admission control, 5.  <ins> While management plane and control planes are traditionally considered separately, from the Data Plane perspective there is no practical difference based on the origin of flow provisioning information, and the DetNet architecture I-D.ietf-detnet-architecture refers to these collectively as the 'Controller Plane'.  This document therefore does not distinguish between information provided by distributed control plane protocols, e.g., IGP routing protocols, or by centralized network management mechanisms, e.g., RestConf RFC8040, YANG RFC7950, and the Path Computation Element Communication Protocol (PCEP) RFC8283 I-D.ietf-teas-pce-native-ip or any combination thereof.  Specific considerations and requirements for the DetNet Controller Plane are discussed in control-management- requirements. </ins> 5.1.  <ins> sec_dt_dp introduces the use of the IP "6-tuple" for flow identification, and QoS goes on to discuss how identified flows use specific QoS mechanisms for flow-specific traffic treatment, including path control and resource allocation. ip-flow-id contains detailed DetNet IP flow identification procedures.  Flow identification will play an important role for the DetNet controller plane. aggregation and agg-con discuss the use of flow aggregation in DetNet.  Flow aggregation can be accomplished using any of the 6-tuple fields defined in ip-flow-id, using a DSCP identified traffic class or other field.  It will be the responsibility of the DetNet controller plane to be able to properly provision the use of these aggregation mechanisms.  These requirements are included in control- management-requirements. </ins> 5.2.  <ins> Explicit routes are used to ensure that packets are routed through the resources that have been reserved for them, and hence provide the DetNet application with the required service.  A requirement for the DetNet Controller Plane will be the ability to assign a particular identified DetNet IP flow to a path through the DetNet domain that has been assigned the required nodal resources to provide the appropriate traffic treatment for the flow, and also to include particular links as a part of the path that are able to support the DetNet flow, for example by using IEEE 802.1 TSN links (as discussed in mapping-tsn).  Further considerations and requirements for the DetNet Controller Plane are discussed in control-management- requirements. Whether configuring, calculating and instantiating these routes is a single-stage or multi-stage process, or in a centralized or distributed manner, is out of scope of this document. There are several of approaches that could be used to provide explicit routes and resource allocation in the DetNet layer.  For example: The path could be explicitly set up by a controller which calculates the path and explicitly configures each node along that path with the appropriate forwarding and resource allocation information. The path could be implemented using IPv6-based segment routing when extended to support resource allocation. See control-management-requirements for further discussion of these alternatives.  In addition, RFC2386 contains useful background information on QoS-based routing, and RFC5575 discusses a specific mechanism used by BGP for traffic flow specification and policy-based routing. </ins> 5.3.  <ins> As discussed in sec_intro, this document does not specify the mechanisms needed to eliminate contention loss or reduce jitter for DetNet flows at the DetNet forwarding sub-layer.  The ability to manage node and link resources to be able to provide these functions will be a necessary part of the DetNet controller plane.  It will also be necessary to be able to control the required queuing mechanisms used to provide these functions along a flow's path through the network.  See ip-svc and control-management-requirements for further discussion of these requirements. </ins> 5.4.  <ins> Some DetNet applications generate bidirectional traffic.  Although this document discusses the DetNet IP data plane, MPLS definitions RFC5654 are useful to illustrate terms such as associated bidirectional flows and co-routed bidirectional flows.  MPLS defines a point-to-point associated bidirectional LSP as consisting of two unidirectional point-to-point LSPs, one from A to B and the other from B to A, which are regarded as providing a single logical bidirectional forwarding path.  This is analogous to standard IP routing.  MPLS defines a point-to-point co-routed bidirectional LSP as an associated bidirectional LSP which satisfies the additional constraint that its two unidirectional component LSPs follow the same path (in terms of both nodes and links) in both directions.  An important property of co-routed bidirectional LSPs is that their unidirectional component LSPs share fate.  In both types of bidirectional LSPs, resource reservations may differ in each direction.  The concepts of associated bidirectional flows and co- routed bidirectional flows can also be applied to DetNet IP flows. While the DetNet IP data plane must support bidirectional DetNet flows, there are no special bidirectional features with respect to the data plane other than the need for the two directions of a co- routed bidirectional flow to take the same path.  That is to say that bidirectional DetNet flows are solely represented at the management and control plane levels, without specific support or knowledge within the DetNet data plane.  Fate sharing and associated vs. co- routed bidirectional flows can be managed at the control level. Control and management mechanisms will need to support bidirectional flows, but the specification of such mechanisms are out of scope of this document.  An example control plane solution for MPLS can be found in RFC7551. This is further discussed in control-management-requirements. </ins> 5.5.  <ins> While the definition of controller plane for DetNet is out of the scope of this document, there are particular considerations and requirements for such that result from the unique characteristics of the DetNet architecture I-D.ietf-detnet-architecture and data plane as defined herein. The primary requirements of the DetNet controller plane are that it must be able to: Instantiate DetNet flows in a DetNet domain (which may include some or all of explicit path determination, link bandwidth reservations, restricting flows to IEEE 802.1 TSN links, node buffer and other resource reservations, specification of required queuing disciplines along the path, ability to manage bidirectional flows, etc.) as needed for a flow. The ability to support DetNet flow aggregation Advertise static and dynamic node and link resources such as capabilities and adjacencies to other network nodes (for dynamic signaling approaches) or to network controllers (for centralized approaches) Scale to handle a large number of DetNet flows in a domain (which may require per-flow signaling or provisioning) Provision flow identification information at each of the nodes along the path, and it may differ depending on the location in the network and the DetNet functionality. These requirements, as stated earlier, could be satisfied using distributed control protocol signaling, centralized network management provisioning mechanisms, or hybrid combinations of the two, and could also make use of IPv6-based segment routing. In the abstract, the results of either distributed signaling or centralized provisioning are equivalent from a DetNet data plane perspective - flows are instantiated, explicit routes are determined, resources are reserved, and packets are forwarded through the domain using the IP data plane. However, from a practical and implementation standpoint, they are not equivalent at all.  Some approaches are more scalable than others in terms of signaling load on the network.  Some can take advantage of global tracking of resources in the DetNet domain for better overall network resource optimization.  Some are more resilient than others if link, node, or management equipment failures occur.  While a detailed analysis of the control plane alternatives is out of the scope of this document, the requirements from this document can be used as the basis of a later analysis of the alternatives. </ins> 6. 6.4.  <ins> The use of prefixes, wildcards, bitmasks, and port ranges allows a </ins> DetNet node to aggregate DetNet flows.  This aggregation can take place within a single node, when that node maintains state about both the aggregated and component flows.  It can also take place between


path with the appropriate forwarding and resource allocation information.  The path could be implemented using IPv6-based segment routing when extended to support resource allocation. signaling approaches) or to network controllers (for centralized approaches) <del> Scale to handle a large number of DetNet flows in a domain (which may require per-flow signaling or provisioning) </del>  Provision flow identification information at each of the nodes along the path, and it may differ depending on the location in the required.  Port ranges can optionally be used. This information MUST be provisioned per DetNet flow via <del> configuration and the controller plane, see m-cp-considerations. </del>  Information identifying a DetNet flow is ordered and implementations use the first match.  This can, for example, be used to provide a 7. <del> This section defines how IP encapsulated DetNet flows are carried over a DetNet MPLS data plane as defined in I-D.ietf-detnet-dp-sol- mpls.  The basic encapsulation approach is to treat a DetNet IP flow as an app-flow from the DetNet MPLS app perspective.  The corresponding example DetNet Sub-Network format is shown in fig_dn_ip_mpls_sn_ex. </del>  In the figure, "IP App-Flow" indicates the payload carried by the DetNet IP data plane.  "IP" and "NProto" indicate the fields procedures: the mapping of flow identifiers; and ensuring proper traffic treatment. <del> 7.1. </del>  A relay node that sends a DetNet IP flows over a DetNet MPLS network MUST map a single DetNet IP flow into a single app-flow and MUST DetNet IP flows sent over an DetNet MPLS network.  Aggregation as defined in ip-agg MAY be used to identify an individual DetNet IP flow.  The provisioning of the mapping of DetNet IP flows to DetNet <del> MPLS app-flow information MUST be supported via configuration and the controller plane, see m-cp-considerations. </del>  A relay node MAY be provisioned to handle packets received via the DetNet MPLS data plane as DetNet IP flows.  A single incoming MPLS DetNet MPLS data plane MAY follow the normal DetNet IP flow identification procedures defined in ip-flow-id.  An implementation MUST support the provisioning of handling of received DetNet MPLS <del> data plane as DetNet IP flows via configuration and the controller plane, see m-cp-considerations.  Note that such configuration MAY include support from PEOF on the incoming DetNet MPLS flow. </del>  <del> 7.2. </del>  The traffic treatment required for a particular DetNet IP flow is provisioned via configuration or the controller plane.  When an

import IP over MPLS scenarios from mpls-dp doc, carify non-DetNet IP

path with the appropriate forwarding and resource allocation information. <ins> The path could be used a distributed control plane such as RFC2205 or RSVP-TE RFC3473 extended to support DetNet IP flows. </ins> The path could be implemented using IPv6-based segment routing when extended to support resource allocation. signaling approaches) or to network controllers (for centralized approaches)  <ins> Scale to handle the number of DetNet flows expected in a domain (which may require per-flow signaling or provisioning) </ins> Provision flow identification information at each of the nodes along the path, and it may differ depending on the location in the required.  Port ranges can optionally be used. This information MUST be provisioned per DetNet flow via  <ins> configuration, e.g., via the controller plane described in m-cp- considerations. </ins> Information identifying a DetNet flow is ordered and implementations use the first match.  This can, for example, be used to provide a 7.  <ins> This section defines how IP encapsulated flows are carried over a DetNet MPLS data plane as defined in I-D.ietf-detnet-dp-sol-mpls.  As Non-DetNet and DetNet IP packets are identical on the wire, this section is applicable to any node that supports IP over DetNet MPLS, and this section refers to both cases as DetNet IP over DetNet MPLS. 7.1. This section provides example uses of IP over DetNet MPLS for illustrative purposes. fig_dn_ip_mpls_detnet illustrates DetNet enabled End Systems (hosts), connected to DetNet (DN) enabled IP networks, operating over a DetNet aware MPLS network.  In this figure, Relay nodes sit at the boundary of the MPLS domain since the non-MPLS domain is DetNet aware.  This figure is very similar to the DetNet MPLS Network figure in I-D.ietf- detnet-dp-sol-mpls.  The primary difference is that the Relay nodes are at the edges of the MPLS domain and therefore function as T-PEs, and that service sub-layer functions are not provided over the DetNet IP network.  The transit node functions show above are identical to those described in I-D.ietf-detnet-dp-sol-mpls. fig_ip_pw_detnet illustrates how relay nodes can provide service protection over an MPLS domain.  In this case, CE1 and CE2 are IP DetNet end systems which are interconnected via a MPLS domain such as described in I-D.ietf-detnet-dp-sol-mpls.  Note that R1 and R3 sit at the edges of an MPLS domain and therefore are similar to T-PEs, while R2 sits in the middle of the domain and is therefore similar to an S-PE. fig_ip_mpls_detnet illustrates non-DetNet enabled End Systems (hosts), connected to DetNet (DN) enabled MPLS network.  It differs from fig_dn_ip_mpls_detnet in that the hosts and edge IP networks are not DetNet aware.  In this case, edge nodes sit at the boundary of the MPLS domain since it is also a DetNet domain boundary.  The edge nodes provide DetNet service proxies for the end applications by initiating and terminating DetNet service for the application's IP flows.  While the node types differ, there is essentially no difference in data plane processing between relay and edges.  There are likely to be differences in controller plane operation, particularly when distributed control plane protocols are used. fig_pw_detnet2 illustrates how it is still possible to provided DetNet service protection for non-DetNet aware end systems.  This figures is basically the same as fig_ip_pw_detnet, with the exception that CE1 and CE2 are non-DetNet aware end systems and E1 and E3 are edge nodes that replace the relay nodes R1 and R3. 7.2. The basic encapsulation approach is to treat a DetNet IP flow as an app-flow from the DetNet MPLS app perspective.  The corresponding example DetNet Sub-Network format is shown in fig_dn_ip_mpls_sn_ex. </ins> In the figure, "IP App-Flow" indicates the payload carried by the DetNet IP data plane.  "IP" and "NProto" indicate the fields procedures: the mapping of flow identifiers; and ensuring proper traffic treatment.  <ins> 7.3. </ins> A relay node that sends a DetNet IP flows over a DetNet MPLS network MUST map a single DetNet IP flow into a single app-flow and MUST DetNet IP flows sent over an DetNet MPLS network.  Aggregation as defined in ip-agg MAY be used to identify an individual DetNet IP flow.  The provisioning of the mapping of DetNet IP flows to DetNet  <ins> MPLS app-flow information MUST be supported via configuration, e.g., via the controller plane described in m-cp-considerations. </ins> A relay node MAY be provisioned to handle packets received via the DetNet MPLS data plane as DetNet IP flows.  A single incoming MPLS DetNet MPLS data plane MAY follow the normal DetNet IP flow identification procedures defined in ip-flow-id.  An implementation MUST support the provisioning of handling of received DetNet MPLS  <ins> data plane as DetNet IP flows via configuration.  Note that such configuration MAY include support from PEOF on the incoming DetNet MPLS flow. </ins>  <ins> 7.4. </ins> The traffic treatment required for a particular DetNet IP flow is provisioned via configuration or the controller plane.  When an


4.9. <del> [JiK] Should be documented somewhere else.. possible in it own document.  Time sync not part of the data plane.  [JiK] 802.1AS over routers?  Who is doing that.  In 802.1 is doing ".1AS over time aware systems?"  Provide a reference.  [JiK] Check TICTOC, [Editor's NOTE: delete this section (scope time synchronization solution outside data plane).] SB> This section should point the reader to RFC8169 (residence time in MPLS n/w.  We need to consider if we need to introduce the same concept in IP. Agree.  For IP we could reference to PTPv2 or v3 over UDP/IP, since it measures residence time among other things. [Editor's note: describe a bit of issues and deployment considerations related to time-synchronization within DetNet.  Refer to DT discussion and the slides that summarize different approaches and rough synchronization performance numbers.  Finally, scope time- synchronization solution outside data plane.] When DetNet is used, there is an underlying assumption that the applicaton(s) require clock synchronization such as the Precision Time Protocol (PTP) IEEE1588.  The relay nodes may or may not utilize clock synchronization in order to provide zero congestion loss and controlled latency delivery.  In either case, there are a few possible approaches of how synchronization protocol packets are forwarded and handled by the network: PTP packets can be sent either as DetNet flows or as high-priority best effort packets.  Using DetNet for PTP packets requires careful consideration to prevent unwanted interactions between clock-synchronized network nodes and the packets that synchronize the clocks. PTP packets are sent as a normal DetNet flow through network nodes that are not time-synchronized: in this approach PTP traffic is forwarded as a DetNet flow, and as such it is forwarded in a way that allows a low delay variation.  However, since intermediate nodes do not take part in the synchronization protocol, this approach provides a relatively low degree of accuracy. PTP with on-path support: in this approach PTP packets are sent as ordinary or as DetNet flows, and intermediate nodes take part in the protocol as Transparent Clocks or Boundary Clocks IEEE1588. The on-path PTP support by intermediate nodes provides a higher degree of accuracy than the previous approach.  The actual accuracy depends on whether all intermediate nodes are PTP- capable, or only a subset of them. Time-as-a-service: in this approach accurate time is provided as- a-service to the DetNet source and destination, as well as the intermediate nodes.  Since traffic between the source and destination is sent over a provider network, if the provider supports time-as-a-service, then accurate time can be provided to both the source and the destination of DetNet traffic.  This approach can potentially provide the highest degree of accuracy. It is expected that the latter approach will be the most common one, as it provides the highest degree of accuracy, and creates a layer separation between the DetNet data and the synchronization service. It should be noted that in all four approaches it is not recommended to use replication and elimination for synchronization packets; the replication/elimination approach may in some cases reduce the synchronization accuracy, since the observed path delay will be bivalent. SB> I am not sure why we sould not use PREP.  We should explain to the reader. Agree that a this can be opened a bit more in detail.  The issue is explained briefly in the last sentence but it could be more clear. </del>  5.

Aligned the Time Synchronization text with the MPLS equivalent text. Added an informative ref to RFC8169 Deleted ref to IEEE1588 as not needed Slightly reduced the width of Fig 3 by deleting one column of spaces and "-" in the middle to stop the compile warning.

4.9.  <ins> Editor's Note: A detailed discussion of time synchronization is outside the scope of this document, and the production of a specialist text discussing this topic is encouraged.  This section will be updated if such a documents is available before publication of this text. Time synchronization is important both from the perspective of operating the DetNet network itself and from the perspective of transferring time across the network between client applications. Some clients may be able to use the DetNet as their provider of time and frequency, others may require the DetNet to transfer time between a client clock source and a client clock user. The reader's attention is drawn to RFC8169 which describes a method of recording the packet queuing time in an MPLS LSR on a packet by per packet basis and forwarding this information to the egress edge system.  This allows compensation for any variable packet queuing delay to be applied at the packet receiver.  Whether a similar mechanism needs to be defined for IP is for further study.  Such a mechanism may have wider application than basic time transfer in a DetNet. A more detailed discussion of time synchronization is outside the scope of this document. </ins> 5.


1. Deterministic Networking (DetNet) is a service that can be offered by <del> a network to DetNet flows.  DetNet provides these flows extremely low packet loss rates and assured maximum end-to-end delivery latency. General background and concepts of DetNet can be found in I-D.ietf- detnet-architecture. </del>  This document specifies the DetNet data plane and the on-wire encapsulation of DetNet flows over an MPLS-based Packet Switched implment also the DetNet service layer functions.  An S-Label is also used to identify a DetNet flow at DetNet service layer.  A DetNet Edge and Relay node internal construct that uniquely identifies a DetNet flow within a node and never appear on-wire. It may be used to select proper forwarding and/or DetNet specific operate over multiple (separate) DetNet member flows of a DetNet compound flow. <del> A control word used for sequencing and identifying duplaicate </del>  packets at the DetNet service layer. 2.2. ensuring congestion protection and latency control for the above listed DetNet functions.  The DetNet data plane allows for the aggregation of DetNet flows, e.g., via MPLS hierarchical LSPs, to improved scaling.  When DetNet flows are aggregated, transit nodes may have limited ability to Therefore, local-IDs has to be unique on each edge and relay nodes. Local-ID is unambiguously bound to the DetNet flow.  4.2. DetNet service layer introduces packet replication and elimination the packet elimination on the packet processing pipeline is implementation specific.  4.3. DetNet service layer introduces also packet reordering functionality DetNet service Label (S-label) that identifies a DetNet flow to the peer node that is to process it.  The S-Label is allocated <del> from the platform label space. </del>  Zero or more MPLS transport LSP label(s) (T-label) used to direct the packet along the label switched path (LSP) to the next peer 6.4. DetNet flow identification at a DetNet service layer is realized by <del> an S-label.  It maps a Detnet flow to a specific d-CW in a DetNet node.  For a data flow the S-label used for flow identification MUST be bottom label of the label stack for a DetNet-s- or DetNet-st-flow and MUST precede the d-CW. An S-label for a single DetNet flow does not need to be unique DetNet domain wide.  As long as two or more different DetNet flows do not errorneously map to a same d-CW in a DetNet node the labels may vary. </del>  [Editor's note: We have specified the above for _data_ to leave the door open for the GAL based OAM method as an alternative to

I have started to address the comments as agreed on the call 2nd May. Before I do a more significant edit next week I want to test out the pull mechanism,
Merged Stewart's first three commits to the master.
I wonder why we need to have/propose two approaches for the aggregation?

1. Deterministic Networking (DetNet) is a service that can be offered by  <ins> a network to DetNet flows.  DetNet provides these flows extremely an low packet loss rates and assured maximum end-to-end delivery latency.  General background and concepts of DetNet can be found in I-D.ietf-detnet-architecture. </ins> This document specifies the DetNet data plane and the on-wire encapsulation of DetNet flows over an MPLS-based Packet Switched implment also the DetNet service layer functions.  An S-Label is also used to identify a DetNet flow at DetNet service layer. <ins> [Note to the editors this section is not needed.  This is internal to the node.  With pseudowires we needed global identifier for the control plane to identfy the PW to the node, and we used platform label space to ensure the PW was identiable when it was received. I think this can be deleted - SB] </ins> A DetNet Edge and Relay node internal construct that uniquely identifies a DetNet flow within a node and never appear on-wire. It may be used to select proper forwarding and/or DetNet specific operate over multiple (separate) DetNet member flows of a DetNet compound flow.  <ins> A control word used for sequencing and identifying duplicate </ins> packets at the DetNet service layer. 2.2. ensuring congestion protection and latency control for the above listed DetNet functions. <ins> [Note to Editors.  I am not convinced that the previous para adds value.  It certainly has the opportunity to add confusion.  I think it needs to be deleted - SB] </ins> The DetNet data plane allows for the aggregation of DetNet flows, e.g., via MPLS hierarchical LSPs, to improved scaling.  When DetNet flows are aggregated, transit nodes may have limited ability to Therefore, local-IDs has to be unique on each edge and relay nodes. Local-ID is unambiguously bound to the DetNet flow. <ins> [Note to Editor - again I think previous para needs to be removed] </ins> 4.2. DetNet service layer introduces packet replication and elimination the packet elimination on the packet processing pipeline is implementation specific. <ins> [Note to editor - Clean up local-id when dealing with PREF text] </ins> 4.3. DetNet service layer introduces also packet reordering functionality DetNet service Label (S-label) that identifies a DetNet flow to the peer node that is to process it.  The S-Label is allocated  <ins> from the platform label space RFC3031. </ins> Zero or more MPLS transport LSP label(s) (T-label) used to direct the packet along the label switched path (LSP) to the next peer 6.4. DetNet flow identification at a DetNet service layer is realized by  <ins> an S-label.  The S-lable is allocated from the platform label label space RFC3031 Thich means that the DetNet flow is correctly identified and matched to the flow parameters, including the flow history, regardless of which input interface the packet arrives on. The S-label MUST be at the bottom label of the label stack for a DetNet-s- or DetNet-st-flow and MUST precede the d-CW. The S-label for a specific DetNet flow is unique to that DetNet flow on a specific node, but is not required to be identical with the S-lable for that DetNet flow in any other node within the DetNet domain.  Thus the S-label can only be used to identify the DetNet flow at the intended receiving node. </ins> [Editor's note: We have specified the above for _data_ to leave the door open for the GAL based OAM method as an alternative to


The only nodes that needs to know the payload type of a flow are the DetNet ingress node and the DetNet egress nodes.  The ingress node has to know how to process the packet it receives from the ingress <del> AC, and egress edge node has to know how to.. </del>  [Editor's note: We have specified the above for _data_ to leave the door open for the GAL based OAM method as an alternative to When DetNet is used, there is an underlying assumption that the applicaton(s) require clock synchronization such as the Precision <del> Time Protocol (PTP) [IEEE1588].  The relay nodes may or may not utilize clock synchronization in order to provide zero congestion loss and controlled latency delivery.  In either case, there are a few possible approaches of how synchronization protocol packets are </del>  forwarded and handled by the network: PTP packets can be sent either as DetNet flows or as high-priority

Put the text that was taken out of the payload ident section back in. Fixed some compile warnings Two were figs too large One was use of [IEEE1588] instead of Rest were apparently unused references Requesting pull so we are in sync on this.
Looks OK to me. Merging all these chnanes.

The only nodes that needs to know the payload type of a flow are the DetNet ingress node and the DetNet egress nodes.  The ingress node has to know how to process the packet it receives from the ingress  <ins> AC, and egress edge node has to know how to prepare the packet for transmission on the egress AC. On ingress a DetNet edge node has to classify the packets into those that are for transmission as Detnet packets and those that are for transmission as "normal" packets at one of more lower priorities. The packet type is indicated to the egress edge node through the value of the S-label.  Thus, when the egress edge node looks up the S-label one of the parameters returned is the packet type which in turn tells the egress edge node how to prepare the packet for transmission over the egress AC. The consequence of this approach is that if multiple packet encapsulations are processed on a node, each will need its own S-Label.  That is not generally a problems, since it is anticipated that only one encapsulation type intented for carriage as a DetNet flow will be present on any egress.  However, IPv4 and IPv6 have different forwarding equivalence classes (FEC) in MPLS and are therefore allocated different labels rather than being distinguished through the IP version field in the IP header.  Futhermore IPv4 and IPv6 when running directly over Ethernet are identified via the Ethertype rather than via the IP version number.  Whilst it ought to be safe to identify the IP type though the IP version number the absence this approach in practical applications suggests that it is more conservative to distinguish between IP types through the S-Label.  Thus when the payload is IP, two S-Labels are used, one to identify an IPv4 payload and one to identify an IPv6 payload. </ins> [Editor's note: We have specified the above for _data_ to leave the door open for the GAL based OAM method as an alternative to When DetNet is used, there is an underlying assumption that the applicaton(s) require clock synchronization such as the Precision  <ins> Time Protocol (PTP) IEEE1588.  The relay nodes may or may not utilize clock synchronization in order to provide zero congestion loss and controlled latency delivery.  In either case, there are a few possible approaches of how synchronization protocol packets are </ins> forwarded and handled by the network: PTP packets can be sent either as DetNet flows or as high-priority


A Packet Reorder Function (PROF) re-orders packets within a DetNet flow that are received out of order.  This function may be <del> implemented at an edge node or end system. </del>  A control word used for sequencing and identifying duplicate packets at the DetNet service layer.

Also pick up simplified makefile from ip draft
EMAIL NAME NAME can you take a look...
I got one specific comment on reordering and relay functions... comment embedded.

A Packet Reorder Function (PROF) re-orders packets within a DetNet flow that are received out of order.  This function may be  <ins> implemented at an edge or relay node. </ins> A control word used for sequencing and identifying duplicate packets at the DetNet service layer.


supported. The place such URIs are specified (see general-record-format) allows <del> a list of these to be provided.  A report is normally sent to each listed URI in the order provided by the Domain Owner.  Receivers MAY impose a limit on the number of URIs to which they will send reports but MUST support the ability to send to at least two.  The list of URIs is separated by commas (ASCII 0x2C). </del>  Each URI can have associated with it a maximum report size that may be sent to it.  This is accomplished by appending an exclamation

should serve to regulate the size of reports, by sending them more often. See .
The work of the design team is to propose text at this stage. Discussion of the proposed text can take place on-list starting after April 23.

supported. The place such URIs are specified (see general-record-format) allows  <ins> a list of these to be provided.  The list of URIs is separated by commas (ASCII 0x2c).  A report is normally sent to each listed URI in the order provided by the Domain Owner. </ins> Each URI can have associated with it a maximum report size that may be sent to it.  This is accomplished by appending an exclamation


In essence, the steps are as follows:  5. One of the most obvious points of security scrutiny for DMARC is the

How come ARC compliance becomes an integral part of DMARC? They are different protocols.
The work of the design team is to propose text at this stage. Discussion of the proposed text can take place on-list starting after April 23.

In essence, the steps are as follows: <ins> 4.4. Domain owners, intermediaries, and mail receivers can all claim to implement DMARC, but what that means will depend on their role in the transmission of mail.  To remove any ambiguity from the claims, this document specifies the following minimum criteria that must be met for each agent to rightly claim to be "implementing DMARC". Domain Owner: To implement DMARC, a domain owner MUST configure its domain to request that unauthenticated mail be rejected or at least treated with suspicion.  This means that it MUST publish a policy record that: While 'none' is a syntactically valid value for both the p and sp tags, the practical value of either the p tag or sp tag being 'none' means that the domain owner is still gathering information about mail flows for the domain or sub-domains, and is not yet ready to commit to requesting that unauthenticated mail receive different handling than authenticated mail. Intermediary: To implement DMARC, an intermediary MUST do the following before passing the message to the next hop or rejecting it as appropriate: Mail Receiver: To implement DMARC, a mail receiver MUST do the following: </ins> 5. One of the most obvious points of security scrutiny for DMARC is the


4.3.  The above diagram shows a simple flow of messages through a DMARC- aware system.  Solid lines denote the actual message flow, dotted lines involve DNS queries used to retrieve message policy related to authentication modules.  "sMTA" is the sending MTA, and "rMTA" is the receiving MTA. <del> In essence, the steps are as follows: </del>  5. 6.5. <del> To implement the DMARC mechanism, the only action required of a Domain Owner is the creation of the DMARC policy record in the DNS. However, in order to make meaningful use of DMARC, a Domain Owner must at minimum either establish an address to receive reports, or deploy authentication technologies and ensure Identifier Alignment. Most Domain Owners will want to do both. DMARC reports will be of significant size, and the addresses that receive them are publicly visible, so we encourage Domain Owners to set up dedicated email addresses to receive and process reports, and to deploy abuse countermeasures on those email addresses as appropriate. Authentication technologies are discussed in RFC6376 (see also RFC5585 and RFC5863) and RFC7208. </del>  6.6.

Proposed updated ASCII art for mail flow. Proposed stripped down description of ASCII art. Proposed new text for Domain Owner actions.

4.3. <ins> Issue 2, Original text: Issue 2, Proposed replacement text: </ins> The above diagram shows a simple flow of messages through a DMARC- aware system.  Solid lines denote the actual message flow, dotted lines involve DNS queries used to retrieve message policy related to authentication modules.  "sMTA" is the sending MTA, and "rMTA" is the receiving MTA.  <ins> Issue 2, Original text to be deleted and/or repurposed: Issue 2, Proposed replacement text: </ins> 5. 6.5.  <ins> Issue 2, Original text: Issue 2, Proposed replacement text: </ins> 6.6.


The DNS uses glue records to allow iterative clients to find the addresses of nameservers that are contained within a delegated zone. <del> Servers are expected to return available glue records in referrals. If message size constraints prevent the inclusion of all glue records in a UDP response, the server MUST set the TC flag to inform the client that the response is incomplete, and that the client SHOULD use TCP to retrieve the full response. </del>  1. The Domain Name System (DNS) RFC1034, RFC1035 uses glue records to allow iterative clients to find the addresses of nameservers that are contained within a delegated zone.  Glue records are added to the <del> parent zone as part of the delegation process.  Servers are expected to return all available glue records in referrals.  If message size constraints prevent the inclusion of all glue records in a UDP response, the server MUST set the TC flag to inform the client that the response is incomplete, and that the client SHOULD use TCP to retrieve the full response.  This document clarifies that expectation. </del>  1.1. 2. <del> Replace </del>  <del> "Copy the NS RRs for the subzone into the authority section of the reply.  Put whatever addresses are available into the additional section, using glue RRs if the addresses are not available from authoritative data or the cache.  Go to step 4." </del>  <del> with "Copy the NS RRs for the subzone into the authority section of the reply.  Put whatever addresses are available into the additional section, using glue RRs if the addresses are not available from authoritative data or the cache.  If all glue RRs do not fit, set TC=1 in the header.  Go to step 4." 3. </del>  While not common, real life examples of servers that fail to set TC=1 <del> when glue records are available exist and they do cause resolution </del>  failures. <del> 3.1. </del> The example below from June 2020 shows a case where none of the glue records, present in the zone, fitted into the available space and TC=1 was not set in the response.  While this example shows an DNSSEC writing, this configuration has been corrected and the response correctly sets the TC=1 flag. <del> DNS responses sometimes contain optional data in the additional section.  Glue records however are not optional.  Several other protocol extensions, when used, are also not optional.  This includes TSIG RFC2845, OPT RFC6891, and SIG(0) RFC2931. </del>  <del> 3.2. </del>  <del> Sibling glue are glue records that are not contained in the delegating zone itself, but in another delegated zone.  In many cases, these are not strictly required for resolution, since the </del>  resolver can make follow-on queries to the same zone to resolve the nameserver addresses after following the referral to the sibling <del> zone.  However, most nameserver implementations provide them as an optimization to obviate the need for extra traffic. </del>  <del> Question: if sibling glue from the same delegating zone does not fit into the response, should we also recommend or require that TC=1 be set? </del>  <del> 3.3. </del>  <del> Here is a more complex example of sibling glue that lives in another zone, but is required to resolve a circular dependency in the zone configuration. </del>  <del> 3.4. </del>  When a zone is deleted but the parent notices that its NS glue records are required for other zones, it MAY opt to take these (now orphaned) glue records into its own zone to ensure that other zones <del> depending on this glue are not broken.  Technically, these NS records are no longer glue records, but authoritative data of the parent zone, and should be added to the DNS response similarly to regular glue records. </del>  <del> 4. </del>  This document clarifies correct DNS server behaviour and does not introduce any changes or new security considerations. <del> 5. </del>  There are no actions for IANA.

Misc updates .. Rework Sibling Glue section, and clarify that they MUST be included, and also subject to TC=1 if they don't fit. Remove the cross parent zone cyclic dependency example, which doesn't work (I think we agreed to that, but I can be persuaded to add it back, if we want to point out a misconfiguration as a warning). Move the paragraph about non-optionality of types of additional section data into the tail end of the Intro. It deserves to be more prominently mentioned than buried at the end of the example of missing glue. Addressed Duane's comment that the "Why is Glue Required?" section did not actually say why, but instead just gave examples. Instead, I added a one phrase explaining why to the Intro section that defines glue records. I don't think it requires a separate section. Removed Duane's comment about "I think the document should say that some servers might experience an increase in TCP if implementations require all glue or set TC=1. If not in this section then somewhere else._". I agree we should address this, so I've made an "issue" for it. And we can add the relevant text in the next update, once we figure out where it goes (an "Operational Considerations" section perhaps?).
NAME - added your tweaks. Please review/approve!

The DNS uses glue records to allow iterative clients to find the addresses of nameservers that are contained within a delegated zone.  <ins> Authoritative Servers are expected to return all available glue records in referrals.  If message size constraints prevent the inclusion of all glue records in a UDP response, the server MUST set the TC flag to inform the client that the response is incomplete, and that the client SHOULD use TCP to retrieve the full response. </ins> 1. The Domain Name System (DNS) RFC1034, RFC1035 uses glue records to allow iterative clients to find the addresses of nameservers that are contained within a delegated zone.  Glue records are added to the  <ins> parent zone as part of the delegation process and returned in referral responses, otherwise a resolver following the referral has no way of finding these addresses.  Authoritative servers are expected to return all available glue records in referrals.  If message size constraints prevent the inclusion of all glue records in a UDP response, the server MUST set the TC (Truncated) flag to inform the client that the response is incomplete, and that the client SHOULD use TCP to retrieve the full response.  This document clarifies that expectation. DNS responses sometimes contain optional data in the additional section.  Glue records however are not optional.  Several other protocol extensions, when used, are also not optional.  This includes TSIG RFC2845, OPT RFC6891, and SIG(0) RFC2931. </ins> 1.1. 2.  <ins> The following is a simple example of glue records present in the delegating zone "test" for the child zone "foo.test".  The nameservers for foo.test (ns1.foo.test and ns2.foo.test) are both below the delegation point.  They are configured as glue records in the "test" zone: </ins>  <ins> Referral responses from "test" for "foo.test" must include the glue records in the additional section (and set TC=1 if they do not fit): </ins>  <ins> 2.1. </ins> While not common, real life examples of servers that fail to set TC=1  <ins> when glue records are available, exist and they do cause resolution </ins> failures.  The example below from June 2020 shows a case where none of the glue records, present in the zone, fitted into the available space and TC=1 was not set in the response.  While this example shows an DNSSEC writing, this configuration has been corrected and the response correctly sets the TC=1 flag.  <ins> 3. Replace "Copy the NS RRs for the subzone into the authority section of the reply.  Put whatever addresses are available into the additional section, using glue RRs if the addresses are not available from authoritative data or the cache.  Go to step 4." with </ins>  <ins> "Copy the NS RRs for the subzone into the authority section of the reply.  Put whatever addresses are available into the additional section, using glue RRs if the addresses are not available from authoritative data or the cache.  If all glue RRs do not fit, set TC=1 in the header.  Go to step 4." </ins>  <ins> 4. Sibling glue are glue records that are not contained in the delegated zone itself, but in another delegated zone from the same parent.  In many cases, these are not strictly required for resolution, since the </ins> resolver can make follow-on queries to the same zone to resolve the nameserver addresses after following the referral to the sibling  <ins> zone.  However, most nameserver implementations today provide them as an optimization to obviate the need for extra traffic from iterative resolvers. This document clarifies that sibling glue (being part of all available glue records) MUST be returned in referral responses, and that the requirement to set TC=1 applies to sibling glue that cannot fit in the response too. </ins>  <ins> 4.1. </ins>  <ins> Here the delegating zone "test" contains 2 sub-delegations for the subzones "bar.test" and "foo.test". </ins>  <ins> Referral responses from "test" for "foo.test" must include the sibling glue (and set TC=1 if they do not fit): </ins>  <ins> 5. </ins> When a zone is deleted but the parent notices that its NS glue records are required for other zones, it MAY opt to take these (now orphaned) glue records into its own zone to ensure that other zones  <ins> depending on this glue are not broken.  Technically, these address records are no longer glue records, but authoritative data of the parent zone, and should be added to the DNS response similarly to regular glue records. </ins>  <ins> 6. </ins> This document clarifies correct DNS server behaviour and does not introduce any changes or new security considerations.  <ins> 7. </ins> There are no actions for IANA.


records in referrals.  If message size constraints prevent the inclusion of all glue records in a UDP response, the server MUST set the TC flag to inform the client that the response is incomplete, and <del> that the client SHOULD use TCP to retrieve the full response. </del>  1. protocol extensions, when used, are also not optional.  This includes TSIG RFC2845, OPT RFC6891, and SIG(0) RFC2931.  1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

For issue .
A colleague asked me to clarify that the document applies only to name server behavior, and does not place any requirements on how zones or registries are populated. i.e., we are not saying that "glue is not optional" for delegations in a zone.
This was done with commit 45cb8efcbf03c193791a14894aeb8d9d2a15096e

records in referrals.  If message size constraints prevent the inclusion of all glue records in a UDP response, the server MUST set the TC flag to inform the client that the response is incomplete, and  <ins> that the client SHOULD use TCP to retrieve the full response.  This document updates RFC 1034 to clarify correct server behavior. </ins> 1. protocol extensions, when used, are also not optional.  This includes TSIG RFC2845, OPT RFC6891, and SIG(0) RFC2931. <ins> Note that this document only clarifies requirements of name server software implementations.  It does not place any requirements on data placed in DNS zones or registries. </ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",


2.  The following is a simple example of glue records present in the delegating zone "test" for the child zone "foo.test".  The nameservers for foo.test (ns1.foo.test and ns2.foo.test) are both below the delegation point.  They are configured as glue records in the "test" zone: <del> Referral responses from "test" for "foo.test" must include the glue records in the additional section (and set TC=1 if they do not fit): </del>  <del> 2.1. </del>  While not common, real life examples of servers that fail to set TC=1 when glue records are available, exist and they do cause resolution 3.  Replace "Copy the NS RRs for the subzone into the authority section of the Referral responses from "test" for "foo.test" must include the sibling glue (and set TC=1 if they do not fit):  This document clarifies correct DNS server behaviour and does not introduce any changes or new security considerations. <del> 5. </del>  There are no actions for IANA. <del> 6. </del>  The authors wish to thank Joe Abley, Brian Dickson, Geoff Huston, Jared Mauch, George Michaelson, Benno Overeinder, John R Levine,

work in progress. please do not merge without review & discussion.
Should we use the naming for Glue from 8499?
"Sibling domain glue" "in-domain glue" and maybe we should define "orphan glue/promoted glue". while we have 8499bis open?
IMO 8499 doesn't have glue definitions that are useful for this draft, so yeah, maybe they should be added to 8499.

2. <ins> This section describes different types of glue that may be found in DNS referral responses.  Note that the type of glue depends on the QNAME.  A particular record can be in-domain glue for one response and sibling glue for another. 2.1. </ins> The following is a simple example of glue records present in the delegating zone "test" for the child zone "foo.test".  The nameservers for foo.test (ns1.foo.test and ns2.foo.test) are both below the delegation point.  They are configured as glue records in the "test" zone:  <ins> A referral response from "test" for "foo.test" with in-domain glue looks like this: </ins>  <ins> 2.2. Sibling glue are glue records that are not contained in the delegated zone itself, but in another delegated zone from the same parent.  In many cases, these are not strictly required for resolution, since the resolver can make follow-on queries to the same zone to resolve the nameserver addresses after following the referral to the sibling zone.  However, most nameserver implementations today provide them as an optimization to obviate the need for extra traffic from iterative resolvers. Here the delegating zone "test" contains 2 sub-delegations for the subzones "bar.test" and "foo.test": A referral response from "test" for "foo.test" with sibling glue looks like this: 2.3. [missing glue isn't really a type of glue, so we'll need to think about this] </ins> While not common, real life examples of servers that fail to set TC=1 when glue records are available, exist and they do cause resolution 3. <ins> 3.1. This document clarifies that when a name server generates a referral response, it MUST either include all in-domain glue records in the additional section, or MUST set TC=1. 3.2. This document clarifies that when a name server generates a referral response, it SHOULD include available sibling glue records in the additional section.  If sibling glue records do not fit in the response, the name server is NOT REQUIRED to set TC=1. 3.3. Promoted glue is a special case of sibling glue and should be treated as such. 3.4. [this doesn't really account for SHOULD on sibling glue...] </ins> Replace "Copy the NS RRs for the subzone into the authority section of the Referral responses from "test" for "foo.test" must include the sibling glue (and set TC=1 if they do not fit): <ins> 5. </ins> This document clarifies correct DNS server behaviour and does not introduce any changes or new security considerations.  <ins> 6. </ins> There are no actions for IANA.  <ins> 7. </ins> The authors wish to thank Joe Abley, Brian Dickson, Geoff Huston, Jared Mauch, George Michaelson, Benno Overeinder, John R Levine,


zone.  Authoritative Servers are expected to return all available referral glue records in a referral response.  If message size constraints prevent the inclusion of all in-domain referral glue <del> records over UDP transport, the server MUST set the TC flag to inform the client that the response is incomplete, and that the client SHOULD use TCP to retrieve the full response.  This document updates RFC 1034 to clarify correct server behavior. </del>  1. Authoritative servers are expected to return all available in-domain referral glue records in a referral response.  If message size constraints prevent the inclusion of all in-domain glue records over <del> UDP transport, the server MUST set the TC (Truncated) flag to inform the client that the response is incomplete, and that the client SHOULD use TCP to retrieve the full response.  This document clarifies that expectation. </del>  DNS responses sometimes contain optional data in the additional section.  In-domain referral glue records, however, are not optional. 2.4. <del> An example of missing glue is included here, even though it is not really a type of glue.  While not common, real examples of responses that lack required glue, and with TC=0, have been shown to occur and cause resolution failures. </del>  The example below is based on a response observed in June 2020.  The names have been altered to fall under documentation domains.  It 3.1. This document clarifies that when a name server generates a referral <del> response over UDP transport, it MUST include all available in-domain glue records in the additional section, or MUST set TC=1.  When a name server generates a referral response over TCP transport, it MUST include all available in-domain glue records. </del>  3.2. This document clarifies that when a name server generates a referral response, it SHOULD include all available glue records in the additional section.  If after adding all in-domain glue records, not <del> all sibling glue records fit in a response over UDP transport, the </del>  name server is NOT REQUIRED to set TC=1. Note that users may experience resolution failures for domains with

and talk more generically about message size constraints regardless of transport. For
As currently written the document only talks about setting TC=1 over UDP. This sort of implies that UDP is the only possible transport where TC flag has meaning. We don't talk about setting TC over TCP because the assumption is that TCP always has enough room for all glue or whatever. But this doesn't account for two possibilities 1) a future transport that is limited in space 2) some kind of ridiculous zone configuration with so many NS and glue records that they won't even fit in a single DNS-over-TCP message. Would it be better to just say "set TC=1 if glue doesn't fit" and not bring UDP or TCP into the requirements language?
I like the idea of that, but I think simultaneous possession and ingestion of cake is also possible -- make the general, transport-agnostic point but also give the UDP/TCP fallback as an example that is known to be common at the time of writing. Joe
I prefer mentioning UDP and TCP and to say clearly never set it for TCP. I wouldn't consider "insanely weird" TCP that requires TC=1
would or wouldn't?
was merged so closing this for now

zone.  Authoritative Servers are expected to return all available referral glue records in a referral response.  If message size constraints prevent the inclusion of all in-domain referral glue  <ins> records, the server MUST set the TC flag to inform the client that the response is incomplete, and that the client SHOULD use another transport to retrieve the full response.  This document updates RFC 1034 to clarify correct server behavior. </ins> 1. Authoritative servers are expected to return all available in-domain referral glue records in a referral response.  If message size constraints prevent the inclusion of all in-domain glue records over  <ins> the chosen transport, the server MUST set the TC (Truncated) flag to inform the client that the response is incomplete, and that the client SHOULD use another transport retrieve the full response.  This document clarifies that expectation. </ins> DNS responses sometimes contain optional data in the additional section.  In-domain referral glue records, however, are not optional. 2.4.  <ins> An example of missing glue is included here, even though it can not be considered as a type of glue.  While not common, real examples of responses that lack required glue, and with TC=0, have been shown to occur and cause resolution failures. </ins> The example below is based on a response observed in June 2020.  The names have been altered to fall under documentation domains.  It 3.1. This document clarifies that when a name server generates a referral  <ins> response, it MUST include all available in-domain glue records in the additional section, or MUST set TC=1 if constrained by message size. At the time of writing, most iterative clients send initial queries over UDP and retry over TCP upon receiving a response with the TC flag set.  UDP responses are generally limited to between 1232 and 4096 bytes, due to values commonly used for the EDNS0 UDP Message Size field RFC6891, FLAGDAY2020.  TCP responses are limited to 65,536 bytes. </ins> 3.2. This document clarifies that when a name server generates a referral response, it SHOULD include all available glue records in the additional section.  If after adding all in-domain glue records, not  <ins> all sibling glue records fit due to message size constraints, the </ins> name server is NOT REQUIRED to set TC=1. Note that users may experience resolution failures for domains with


DNS responses sometimes contain optional data in the additional section.  In-domain glue records, however, are not optional.  Several other protocol extensions, when used, are also not optional.  This <del> includes TSIG RFC2845, OPT RFC6891, and SIG(0) RFC2931. </del>  At the time of this writing, addresses (A or AAAA records) for a delegation's authoritative name servers are the only type of glue

idnits mentions this: -- Obsolete informational reference (is this intentional?): RFC 2845 (Obsoleted by RFC 8945)

DNS responses sometimes contain optional data in the additional section.  In-domain glue records, however, are not optional.  Several other protocol extensions, when used, are also not optional.  This  <ins> includes TSIG RFC8945, OPT RFC6891, and SIG(0) RFC2931. </ins> At the time of this writing, addresses (A or AAAA records) for a delegation's authoritative name servers are the only type of glue


retrieve the full response.  This document clarifies that expectation. <del> While not common, real life examples of servers that fail to set TC=1 when glue records are available exist and they do cause resolution failures.  The example below from June 2020 shows a case where none of the glue records, present in the zone, fitted into the available space and TC=1 was not set in the response.  While this example shows an DNSSEC RFC4033, RFC4034, RFC4035 referral response, this behaviour has also been seen with plain DNS responses as well.  The records have been truncated for display purposes.  Note that at the time of this writing, this configuration has been corrected and the response correctly sets the TC=1 flag. DNS responses sometimes contain optional data in the additional section.  Glue records however are not optional.  Several other protocol extensions, when used, are also not optional.  This includes TSIG RFC2845, OPT RFC6891, and SIG(0) RFC2931. </del> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 3. <del> This document clarifies correct DNS server behaviour expectations and does not introduce new security considerations. </del>  4.  There are no actions for IANA.

Clarify glue, slightly reorder.
Merging - as mentioned in email, I will also add a more typical case of sibling glue (that doesn't involve cross zone and circular dependency). PR forthcoming ...

retrieve the full response.  This document clarifies that expectation.  1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 3.  <ins> While not common, real life examples of servers that fail to set TC=1 when glue records are available exist and they do cause resolution failures. 3.1. The example below from June 2020 shows a case where none of the glue records, present in the zone, fitted into the available space and TC=1 was not set in the response.  While this example shows an DNSSEC RFC4033, RFC4034, RFC4035 referral response, this behaviour has also been seen with plain DNS responses as well.  The records have been truncated for display purposes.  Note that at the time of this writing, this configuration has been corrected and the response correctly sets the TC=1 flag. DNS responses sometimes contain optional data in the additional section.  Glue records however are not optional.  Several other protocol extensions, when used, are also not optional.  This includes TSIG RFC2845, OPT RFC6891, and SIG(0) RFC2931. 3.2. A zone's sibling glue is glue in another zone that is required for proper resolving.  While the example below is obvious, real life examples can be more complex and not obvious. This situation is harder to detect if the sibling zones are nog hosted on the same nameservers. 3.3. When a zone is deleted but the parent notices that its NS glue records are required for other zones, it MAY opt to take these (now orphaned) glue records into its own zone to ensure that other zones depending on this glue are not broken.  Technically, these NS records are no longer glue records, but authorative data of the parent zone, and should be added to the DNS response similarly to regular glue records. </ins> 4. <ins> This document clarifies correct DNS server behaviour and does not introduce any changes or new security considerations. 5. </ins> There are no actions for IANA.


because it helps describe the DNS and naming systems similar to the DNS. <del> An ordered list of zero or more labels. </del>  Note that this is a definition independent of the DNS RFCs, and the definition here also applies to systems other than the DNS.

Shouldn't that be "An ordered list of one or more labels"? If not, I'd like to see some text specifically addressing the zero-length case.

because it helps describe the DNS and naming systems similar to the DNS.  <ins> An ordered list of one or more labels. </ins> Note that this is a definition independent of the DNS RFCs, and the definition here also applies to systems other than the DNS.


<del> (a) An adjective to describe a name server whose name is either </del>  subordinate to or (rarely) the same as the zone origin.  In- <del> bailiwick name servers require glue records in their parent zone </del>  (using the first of the definitions of "glue records" in the <del> definition above). (b) Data for which the server is either authoritative, or else authoritative for an ancestor of the owner name.  This sense of the term normally is used when discussing the relevancy of glue records in a response.  For example, the server for the parent zone "example.com" might reply with glue records for "ns.child.example.com".  Because the "child.example.com" zone is a descendant of the "example.com" zone, the glue records are in- bailiwick. The antonym of in-bailiwick. </del>  "All of the RRs attached to all of the nodes from the top node of the zone down to leaf nodes or nodes above cuts around the bottom

Two definitions of In-bailiwick are unclear and seems the same. In-bailiwick name server names have two meanings. One is narrow and requires glue records. The other is wide and may have glue records. There are needs to distinguish two types of in-bailiwick name server names. Ondrej Sury used NS Types as in OARC 26. URL Peter Koch proposed "in domain", "sibing domain", and "unrelated". "unrelated" is out-of-bailiwick. URL I propose to add "in domain" and "sibling domain", update "in-bailiwick" and add a description for "out-of-bailiwick". If this proposal is reasonable, please improve the text and merge.
lgtm (apart from the typo)
I like the idea but still, this is sufficiently muddy area to warrant short example for each type. It will be great with examples and I will definitely support the new wording over the old one.

<ins> An adjective to describe a name server whose name is either </ins> subordinate to or (rarely) the same as the zone origin.  In-  <ins> bailiwick name servers may have glue records in their parent zone </ins> (using the first of the definitions of "glue records" in the  <ins> definition above).  'In-bailiwick' names are divided into two type of name server names: 'in-domain' names and 'Sibling domain' names. An adjective to describe a name server whose name is either subordinate to or (rarely) the same as the ownwer name of the NS resource records.  In-domain name server name MUST have glue records or name resolution fails.  For example, a delegation for "child.example.com" may have "in-domain" name server name "ns.child.example.com". A name server's name that is either subordinate to or (rarely) the same as the zone origin and not subordinate to or the same as the owner name of the NS resource records.  Glue records for sibling domains are allowed, but not necessary.  For example, a delegation for "child.example.com" in "example.com" zone may have "Sibling" name server name "ns.another.example.com". The antonym of in-bailiwick.  An adjective to describe a name server whose name is not subordinate to or the same as the zone origin.  Glue records for out-of-bailiwick name servers are useless. </ins> "All of the RRs attached to all of the nodes from the top node of the zone down to leaf nodes or nodes above cuts around the bottom


Composition of names -- A name in the global DNS has one or more labels.  The length of each label is between 0 and 63 octets <del> inclusive.  In a fully-qualified domain name, the first label is 0 octets long; it is the only label whose length may be 0 octets, and it is called the "root" or "root label".  A domain name in the global DNS has a maximum total length of 255 octets in the wire format; the root represents one octet for this calculation. </del>  Format of names -- Names in the global DNS are domain names. There are three formats: wire format, presentation format, and cookies (RFC6265) should not be set.  There is no indication in a domain name whether it is a public suffix; that can only be determined by outside means.  In fact, both a domain and a <del> subdomain of that domain can be public suffixes.  At the time this document is published, the IETF DBOUND Working Group DBOUND is dealing with issues concerning public suffixes. </del>  There is nothing inherent in a domain name to indicate whether it is a public suffix.  One resource for identifying public suffixes community for many reasons, and may be significantly changed in the future.  One example of the difficulty of calling a domain a public suffix is that designation can change over time as the <del> registration policy for the zone changes, such as the case of the "uk" TLD around the time this document is published. </del>  3. This section defines the terms used for the systems that act as DNS clients, DNS servers, or both. <del> For teminology specific to the public DNS root server system, see </del>  RSSAC026.  That document defines terms such as "root server", "root server operator", and terms that are specific to the way that the root zone of the public DNS is served. server", "security-aware resolver", "security-aware stub resolver", and "security-oblivious 'anything'".  (Note that the term "validating resolver", which is used in some places in <del> DNSSEC-related documents, is also not defined.) </del>  "A zone whose RRsets are signed and that contains properly constructed DNSKEY, Resource Record Signature (RRSIG), Next Secure The term "verification", when used, is usually synonym for "validation".  DNSSEC keys that "only sign the apex DNSKEY RRset in a zone."(Quoted from RFC6781, Section 3.1)

…st label', and remove dbound. Fix affiliation. I suggest these before publication. This addresses issue 18.
Yep, these all seem great.

Composition of names -- A name in the global DNS has one or more labels.  The length of each label is between 0 and 63 octets  <ins> inclusive.  In a fully-qualified domain name, the first label (logically speaking) is 0 octets long; it is the only label whose length may be 0 octets, and it is called the "root" or "root label".  A domain name in the global DNS has a maximum total length of 255 octets in the wire format; the root represents one octet for this calculation. </ins> Format of names -- Names in the global DNS are domain names. There are three formats: wire format, presentation format, and cookies (RFC6265) should not be set.  There is no indication in a domain name whether it is a public suffix; that can only be determined by outside means.  In fact, both a domain and a  <ins> subdomain of that domain can be public suffixes. </ins> There is nothing inherent in a domain name to indicate whether it is a public suffix.  One resource for identifying public suffixes community for many reasons, and may be significantly changed in the future.  One example of the difficulty of calling a domain a public suffix is that designation can change over time as the  <ins> registration policy for the zone changes, such as was the case with the "uk" TLD in 2014. </ins> 3. This section defines the terms used for the systems that act as DNS clients, DNS servers, or both.  <ins> For terminology specific to the public DNS root server system, see </ins> RSSAC026.  That document defines terms such as "root server", "root server operator", and terms that are specific to the way that the root zone of the public DNS is served. server", "security-aware resolver", "security-aware stub resolver", and "security-oblivious 'anything'".  (Note that the term "validating resolver", which is used in some places in  <ins> DNSSEC-related documents, is also not defined in those RFCs, but is defined below.) </ins> "A zone whose RRsets are signed and that contains properly constructed DNSKEY, Resource Record Signature (RRSIG), Next Secure The term "verification", when used, is usually synonym for "validation". <ins> A security-aware recursive name server, security-aware resolver, or security-aware stub resolver that is applying at least one of the definitions of validation (above), as appropriate to the resolution context.  For the same reason that the generic term "resolver" is sometimes ambiguous and needs to be evaluated in context (see dns-servers-and-clients), "validating resolver" is a context-sensitive term. </ins> DNSSEC keys that "only sign the apex DNSKEY RRset in a zone."(Quoted from RFC6781, Section 3.1)


agree on a good set of facets that can be used to compare naming systems.  For example, other facets might include "protocol to update data in a name", "privacy of names", and "privacy of data <del> associated with names", but those do not not have a clear definitions as the ones listed above.  The list here is chosen because it helps describe the DNS and naming systems similar to the DNS. </del>  An ordered list of one or more labels. and their nodes in graph theory, and the definition in RFC1034 has the same practical result as the definition here.  Using graph theory, a domain name is a list of labels identifying a portion <del> along one edge of an acyclic directed graph.  A domain name can be </del>  relative to other parts of the tree, or it can be fully qualified <del> (in which case, it ends at the common root of the graph). </del>  Also note that different IETF and non-IETF documents have used the term "domain name" in many different ways.  It is common for Composition of names -- A name in the global DNS has one or more labels.  The length of each label is between 0 and 63 octets <del> inclusive.  In a fully-qualified domain name, the first label (logically speaking) is 0 octets long; it is the only label whose </del>  length may be 0 octets, and it is called the "root" or "root label".  A domain name in the global DNS has a maximum total length of 255 octets in the wire format; the root represents one common display. The basic wire format for names in the global DNS is a list of <del> labels with the root label last.  Each label is preceded by a length octet.  RFC1035 also defines a compression scheme that modifies this format. </del>  The presentation format for names in the global DNS is a list of <del> labels, encoded as ASCII, with the root label last, and a "." character between each label.  In presentation format, a fully- qualified domain name includes the root label and the associated separator dot.  In presentation format, a fully-qualified domain name with two additional labels is always shown as "example.tld." instead of "example.tld".  RFC1035 defines a method for showing octets that do not display in ASCII. </del>  The common display format is used in applications and free text. It is the same as the presentation format, but showing the root <del> label and the "." before it is optional and is rarely done.  In common display format, a fully-qualified domain name with two additional labels is usually shown as "example.tld" instead of "example.tld.".  Names in the common display format are normally written such that the first label in the ordered list is in the last position from the point of view of the directionality of the writing system (so, in both English and C the first label is the right-most label; but in Arabic it may be the left-most label, depending on local conventions). </del>  Administration of names -- Administration is specified by delegation (see the definition of to "delegation" in zones). This is often just a clear way of saying the same thing as "domain name of a node", as outlined above.  However, the term is ambiguous.  Strictly speaking, a fully qualified domain name would <del> include every label, including the final, zero-length label of the root: such a name would be written "www.example.net." (note the </del>  terminating dot).  But because every name eventually shares the common root, names are often written relative to the root (such as "www.example.net") and are still called "fully qualified".  This The need for the term "fully qualified domain name" comes from the existence of partially qualified domain names, which are names <del> where some of the right-most names are left off and are understood </del>  only by context. This term and its equivalent, "hostname", have been widely used This is "like a slave server except not listed in an NS RR for the zone."  (Quoted from RFC1996, Section 2.1) <del> A stealth server that is a master for zone transfers.  "In this arrangement, the master name server that processes the updates is unavailable to general hosts on the Internet; it is not listed in the NS RRset."  (Quoted from RFC6781, Section 3.4.3.)  An earlier RFC, RFC4641, said that the hidden master's name appears in the SOA RRs MNAME field, although in some setups, the name does not appear at all in the public DNS.  A hidden master can be either a secondary or a primary master. </del>  The process of one server sending a DNS query with the RD bit set to 1 to another server to resolve that query.  Forwarding is a

Split into two pairs of commits (each first changing content and then line lengths) for easy partial acceptance, should that be desired: Improve grammar and diction Be consistent about ordering domain name labels from the root The second pair attempts to provide a consistent treatment of "domain name" as an abstract sequence of labels in directed graph order starting at the root, while maintaining clarity about wire, presentation, and common display formats rendering domain names in reverse.

agree on a good set of facets that can be used to compare naming systems.  For example, other facets might include "protocol to update data in a name", "privacy of names", and "privacy of data  <ins> associated with names", but those are not as well-defined as the ones listed above.  The list here is chosen because it helps describe the DNS and naming systems similar to the DNS. </ins> An ordered list of one or more labels. and their nodes in graph theory, and the definition in RFC1034 has the same practical result as the definition here.  Using graph theory, a domain name is a list of labels identifying a portion  <ins> along one edge of a directed acyclic graph.  A domain name can be </ins> relative to other parts of the tree, or it can be fully qualified  <ins> (in which case, it begins at the common root of the graph). </ins> Also note that different IETF and non-IETF documents have used the term "domain name" in many different ways.  It is common for Composition of names -- A name in the global DNS has one or more labels.  The length of each label is between 0 and 63 octets  <ins> inclusive.  In a fully-qualified domain name, the first label in the ordered list is 0 octets long; it is the only label whose </ins> length may be 0 octets, and it is called the "root" or "root label".  A domain name in the global DNS has a maximum total length of 255 octets in the wire format; the root represents one common display. The basic wire format for names in the global DNS is a list of  <ins> labels ordered by decreasing distance from the root, with the root label last.  Each label is preceded by a length octet.  RFC1035 also defines a compression scheme that modifies this format. </ins> The presentation format for names in the global DNS is a list of  <ins> labels ordered by decreasing distance from the root, encoded as ASCII, with a "." character between each label.  In presentation format, a fully-qualified domain name includes the root label and the associated separator dot (for example, in presentation format, a fully-qualified domain name with two non-root labels is always shown as "example.tld." instead of "example.tld").  RFC1035 defines a method for showing octets that do not display in ASCII. </ins> The common display format is used in applications and free text. It is the same as the presentation format, but showing the root  <ins> label and the "." before it is optional and is rarely done (for example, in common display format, a fully-qualified domain name with two non-root labels is usually shown as "example.tld" instead of "example.tld.").  Names in the common display format are normally written such that the directionality of the writing system presents labels by decreasing distance from the root (so, in both English and C the first label in the ordered list is right-most; but in Arabic it may be left-most, depending on local conventions). </ins> Administration of names -- Administration is specified by delegation (see the definition of to "delegation" in zones). This is often just a clear way of saying the same thing as "domain name of a node", as outlined above.  However, the term is ambiguous.  Strictly speaking, a fully qualified domain name would  <ins> include every label, including the zero-length label of the root: such a name would be written "www.example.net." (note the </ins> terminating dot).  But because every name eventually shares the common root, names are often written relative to the root (such as "www.example.net") and are still called "fully qualified".  This The need for the term "fully qualified domain name" comes from the existence of partially qualified domain names, which are names  <ins> where one or more of the earliest labels in the ordered list are omitted (for example, "www").  Such relative names are understood </ins> only by context. This term and its equivalent, "hostname", have been widely used This is "like a slave server except not listed in an NS RR for the zone."  (Quoted from RFC1996, Section 2.1)  <ins> A stealth server that is a primary server for zone transfers.  "In this arrangement, the master name server that processes the updates is unavailable to general hosts on the Internet; it is not listed in the NS RRset."  (Quoted from RFC6781, Section 3.4.3). An earlier RFC, RFC4641, said that the hidden master's name "appears in the SOA RRs MNAME field", although in some setups, the name does not appear at all in the public DNS.  A hidden master can also be a secondary server itself. </ins> The process of one server sending a DNS query with the RD bit set to 1 to another server to resolve that query.  Forwarding is a


Should terms in some sections be alphabetized? Or should some sections be split up more? I realize the current sorting is to start with the most relevant terms and then define ones that are connected to those terms, and on from there. However, as I was reading through some of the longer sections (5 and 6), I found the current order a bit confusing. For instance, at the beginning of section 5, it starts off with: Resolver Stub resolver Iterative mode Recursive mode ... and I was saying "hey, what about a recursive resolver?" and then I found that farther down the page. But then after that it goes: Recursive resolver Priming Root hints Negative caching Authoritative servers ... And then later: Zone transfer Secondary server Slave server Primary server Primary master Which I just found confusing. (For instance, why does Primary appear after Secondary?) I realize that alphabetizing is probably not the right solutions (unless we are making a "dictionary"), but I wonder about at least splitting up section 5 into separate sections for "DNS Servers" and "DNS Clients". As it is right now I found it a bit confusing to move through all the terminology. Just a suggestion - feel free to ignore, of course.
Alphabetizing is indeed the wrong solution. We want a kind of a flow, but that could mean different things to different people. If you can suggest specific reorderings, that would be useful.
Would the right answer be an alphabetic index?
Alphabetic indexes in current RFCs have been a massive failure. They might be better when we have HTML RFCs, but we hope to be done with this before they exist.
Well, arguably they alerady exist on the tools site. So there's that. Also, while alphabetic indexes have often failed, the class of RFCs that contain only definitions, such as this one is, is pretty small. I note that RFC 6365 has an index. It's a little unfortunate that it refers to page numbers instead of sections, but it's still helpful to find a term. A
Added an index in URL

Index <ins> A Alias Anycast Apex Asterisk label Authoritative data Authoritative server Authoritative-only server arpa: Address and Routing Parameter Area Domain C CNAME Canonical name Child Class independent Closest encloser Closest provable encloser Combined signing key (CSK) D DNS operator DNSSEC Policy (DP) DNSSEC Practice Statement (DPS) DNSSEC-aware and DNSSEC-unaware Delegation Delegation-centric zone Domain name E EDNS EPP Empty non-terminals (ENT) F Fast flux DNS Forward lookup Forwarder Forwarding Full resolver Full-service resolver Fully qualified domain name (FQDN) G Global DNS Glue records H Hardware security module (HSM) Hidden master Host name </ins> I <ins> IDN In-bailiwick Infrastructure domain </ins> Insecure delegation <ins> Instance Iterative mode K Key signing key (KSK) L Label Locally served DNS zone M Master file Master server N NODATA NSEC NSEC3 Naming system Negative caching Negative response Next closer name O OPT Occluded name Open resolver Opt-out Origin Out-of-bailiwick Owner P Parent Passive DNS Policy-implementing resolver Presentation format Primary master Primary server Priming Private DNS Public suffix R RDAP RR RRset Recursive mode Recursive resolver Referrals Registrant Registrar Registry Resolver Reverse DNS, reverse lookup Root hints Root zone S SOA field names Secondary server Secure Entry Point (SEP) Service name Signed zone Signing software Slave server Source of Synthesis Split DNS Stealth server Stub resolver Subdomain T TLD TTL Trust anchor U Unsigned zone V Validating resolver Validation View W WHOIS Wildcard Wildcard domain name Z Zone Zone cut Zone enumeration Zone signing key (ZSK) Zone transfer </ins>


to prove or deny the existence of the insecure delegations. (Adapted from RFC7129, Section 5.1)  "The practice of discovering the full content of a zone via successive queries."  (Quoted from RFC5155, Section 1.3.)  This is also sometimes called "zone walking".  Zone enumeration is

I have been unable to find a definition of "insecure delegation", but it is a term in common use. The closest I found was some handwaving in the NSEC3 doc. Perhaps worth adding? [ Feel free to close issue if inappropriate, etc. ]
We should define it. It appears starting in RFC 4956. The definition there is: That seems fine to me
Fixed in URL

to prove or deny the existence of the insecure delegations. (Adapted from RFC7129, Section 5.1) <ins> "A signed name containing a delegation (NS RRset), but lacking a DS RRset, signifying a delegation to an unsigned subzone." (Quoted from RFC4956, Section 2.) </ins> "The practice of discovering the full content of a zone via successive queries."  (Quoted from RFC5155, Section 1.3.)  This is also sometimes called "zone walking".  Zone enumeration is