<del> Requirements for Adaptive DNS Discovery draft-box-add-requirements-01 </del>  Abstract Adaptive DNS Discovery is chartered to define mechanisms that allow clients to discover and select encrypted DNS resolvers.  This <del> document describes one common use case, that of discovering the encrypted DNS resolver that corresponds to the Do53 resolver offered by a network.  It lists requirements that any proposed discovery mechanisms should address. </del>  1. The Adaptive DNS Discovery (ADD) Working Group is chartered to define mechanisms that allow clients to automatically discover and select encrypted DNS resolvers in a wide variety of network environments. <del> This document currently focusses on one common use case, that of discovering the encrypted DNS resolver that corresponds to the Do53 resolver offered by a network.  Additional use cases can be added in future versions.  As well as describing the use case, it lists requirements that any proposed discovery mechanisms should address. They can do this either by providing a solution, or by explicitly stating why it is not in scope. </del>  1.1. Do53: Unencrypted DNS over UDP port 53, or TCP port 53 RFC1035. <del> Equivalent: See equivalence. </del>  3. It is often the case that a client possesses no specific configuration for how to operate DNS, and at some point joins a <del> network that it has no previous knowledge about.  In such a case the usual existing behaviour is to dynamically discover the network's recommended Do53 resolver and use it.  This long-standing practice </del>  works in nearly all networks, but presents a number of privacy and security risks that were the motivation for the development of encrypted DNS. <del> The network's recommended unencrypted resolver may have a number of </del>  properties that differ from a generic resolver.  It may be able to answer names that are not known globally, it may exclude some names (for positive or negative reasons), and it may provide address least some of the time.  However they would like to use an encrypted DNS protocol rather than Do53. <del> Using an encrypted and authenticated resolver that is equivalent to the one provisioned by the network can provide several benefits that are not possible if only unencrypted DNS is used: </del>  Prevent other devices on the network from observing client DNS messages Verify that answers come from the selected DNS resolver To meet this case there should be a means by which the client can <del> learn how to contact an encrypted DNS resolver that provides equivalent responses as the ones served by the network's recommended unencrypted resolver.  It is not a requirement that these two resolvers are the same physical or logical machine.  Often they will be, but they could equally be separated, perhaps by hundreds of miles.  However it is deployed, the key is that they are equivalent. </del>  3.1. <del> Given two resolvers A and B, equivalence is the claim that A and B can provide the same upper-layer DNS function to the client.  This does not include the DNS transport protocol (e.g.  Do53 or DNS-over- HTTPS) which can differ between equivalent resolvers.  To provide equivalence it is frequently likely to be the case that A and B are operated by the same administrative domain, but this document does not require that. </del>  <del> There are two possible ways to claim equivalence. </del>  <del> The local network can claim that one or more encrypted DNS resolvers (B, C, etc) are equivalent to the Do53 resolver (A) it has offered.  This is known as network-identified. </del>  <del> During communication with the (often unencrypted) resolver (A), this resolver can claim that one or more encrypted DNS resolvers (B, C, etc) are equivalent.  This is known as resolver-identified. </del>  <del> Network-identified is preferred since it comes from the same source of information, and removes the need to talk to the Do53 resolver at all.  However it cannot be the sole mechanism, at least for several years, since there is a large installed base of local network equipment that is difficult to upgrade with new features.  Hence the second mechanism must support being able to announce an equivalent resolver using only existing widely-deployed DNS features. </del>  3.2. Many networks offer a Do53 resolver on an address that is not globally meaningful, e.g.  RFC1918, link-local or unique local <del> addresses.  To support the discovery of Encrypted DNS in these </del>  environments, a means is needed for the discovery process to work <del> from a locally-addressed Do53 resolver to an Encrypted DNS resolver </del>  that is accessible either at the same (local) address, or at a different global address.  Both options need to be supported. <del> 4. </del>  DNS servers are often provisioned by a network as part of DHCP options RFC2132, IPv6 Router Advertisement (RA) options RFC8106, resolver IP addresses, to be used for traditional unencrypted DNS. A solution is required that enhances the set of information delivered <del> to include details of one or more equivalent encrypted DNS resolvers, or states that there are none. </del>  <del> 5. </del>  To support cases where the network is unable to identify an encrypted resolver, it should be possible to learn the details of one or more <del> equivalent encrypted DNS resolvers by communicating with the network- recommended unencrypted Do53 resolver.  This should involve an exchange that uses standard DNS messages that can be handled, or forwarded, by existing deployed software. </del>  <del> It is frequently the case that Do53 resolvers announced by home networks are difficult to upgrade to support encrypted operation.  In such cases it is possible that the only option for encrypted operation is to refer to a separate globally-addressed encrypted DNS resolver. </del>  If the local resolver has been upgraded to support encrypted DNS, the client may not initially be aware that its local resolver supports retaining the benefits of a local caching resolver with knowledge of the local topology.  An additional benefit of using a local resolver occurs with IoT devices.  A common usage pattern for such devices is for it to "call home" to a service that resides on the public Internet, where that accessible for inspection, it becomes quite difficult for the infrastructure to suspect anything. <del> 6. </del>  Encrypted (and authenticated) DNS improves the privacy and security of DNS queries and answers in the presence of malicious attackers. administrator. Cause clients to use a discovered resolver which has no <del> authenticated delegation from a client-known entity. Influence automatic discovery mechanisms such that a client uses one or more resolvers that are not otherwise involved with providing service to the client, such as: a network provider, a VPN server, a content provider being accessed, or a server that the client has manually configured. </del>  When discovering DNS resolvers on a local network, clients have no mechanism to distinguish between cases where an active attacker with discovery solutions designed around this threat model may have limited value. <del> 7. </del>  This section lists requirements that flow from the above sections. <del> 8. </del>  See priv-sec. <del> 9. </del>  This document has no IANA actions.

This PR simplifies further by removing any mention of properties of the encrypted resolvers, or properties of the relationship between the Do53 and the encrypted resolver. It now purely focusses on the ability of an untrusted network or resolver to designate other encrypted resolvers. This is an assertion that the encrypted resolver is safe and appropriate to use, but little else. Clients will of course make their own decisions about whether to use designated resolvers or not. Other drafts will look at trusted networks, and communicating information that can be useful to clients as part of the untrusted decision-making.
comments
comments on the draft02
It was pointed out that this should be limited to IETF-standardised encrypted DNS protocols rather than potentially including DNSCrypt and being very open-ended.

<ins> Requirements for Discovering Designated Resolvers draft-box-add-requirements-02 </ins> Abstract Adaptive DNS Discovery is chartered to define mechanisms that allow clients to discover and select encrypted DNS resolvers.  This  <ins> document describes one common use case, namely that of clients that connect to a network but where they cannot securely authenticate the identity of that network.  In such cases the client would like to learn which encrypted DNS resolvers are designated by that network or by the Do53 resolver offered by that network.  It lists requirements that any proposed discovery mechanisms should seek to address. </ins> 1. The Adaptive DNS Discovery (ADD) Working Group is chartered to define mechanisms that allow clients to automatically discover and select encrypted DNS resolvers in a wide variety of network environments.  <ins> This document describes one common use case, namely that of clients that connect to a network but where they cannot securely authenticate that network.  Whether the network required credentials before the client was permitted to join is irrelevant; the client still cannot be sure that it has connected to the network it was expecting. In such cases the client would like to learn which encrypted DNS resolvers are designated by that network, or by the Do53 resolver offered by that network.  It lists requirements that any proposed discovery mechanisms should seek to address.  They can do this either by providing a solution, or by explicitly stating why it is not in scope. </ins> 1.1. Do53: Unencrypted DNS over UDP port 53, or TCP port 53 RFC1035.  <ins> Designated: See designation. Designator: The network or resolver that issued the designation. </ins> 3. It is often the case that a client possesses no specific configuration for how to operate DNS, and at some point joins a  <ins> network that it cannot authenticate.  It may have no prior knowledge of the network, or it may have connected previously to a network that looked the same.  In either case the usual behaviour, because of lack of specific configuration, is to dynamically discover the network's designated Do53 resolver and use it.  This long-standing practice </ins> works in nearly all networks, but presents a number of privacy and security risks that were the motivation for the development of encrypted DNS.  <ins> The network's designated Do53 resolver may have a number of </ins> properties that differ from a generic resolver.  It may be able to answer names that are not known globally, it may exclude some names (for positive or negative reasons), and it may provide address least some of the time.  However they would like to use an encrypted DNS protocol rather than Do53.  <ins> Using an encrypted and authenticated resolver can provide several benefits that are not possible if only unencrypted DNS is used: </ins> Prevent other devices on the network from observing client DNS messages Verify that answers come from the selected DNS resolver To meet this case there should be a means by which the client can  <ins> learn how to contact a set of encrypted DNS resolvers that are designated by the network it has joined. </ins> 3.1.  <ins> Designation is the process by which a local network or a resolver can point clients towards a particular set of resolvers.  This is not a new concept, as networks have been able to dynamically designate Do53 resolvers for decades (see network).  However here we extend the concept in two ways: </ins>  <ins> To allow resolvers to designate other resolvers </ins>  <ins> The inclusion of support for encrypted DNS </ins>  <ins> The designated set could be empty, or it could list the contact details (such as DoH URI Template) of DNS resolvers that it recommends.  It is not required that there be any relationship between the resolvers in the set, simply that all of them are options that the designator asserts are safe and appropriate for the client to use without user intervention. There are two possible sources of designation. The local network can designate one or more encrypted DNS resolvers (B, C, etc) in addition to any Do53 resolver (A) it may offer.  This is known as network-identified. </ins>  <ins> During communication with the (often unencrypted) resolver (A), this resolver can designate one or more encrypted DNS resolvers (B, C, etc).  This is known as resolver-identified. Network-identified has the advantages that it derives from the same source of information as the network's Do53 announcement, and removes the need to talk to the Do53 resolver at all.  However it cannot be the sole mechanism, at least for several years, since there is a large installed base of local network equipment that is difficult to upgrade with new features.  Hence the second mechanism should support being able to designate resolvers using only existing widely-deployed DNS features. </ins> 3.2. Many networks offer a Do53 resolver on an address that is not globally meaningful, e.g.  RFC1918, link-local or unique local  <ins> addresses.  To support the discovery of encrypted DNS in these </ins> environments, a means is needed for the discovery process to work  <ins> from a locally-addressed Do53 resolver to an encrypted DNS resolver </ins> that is accessible either at the same (local) address, or at a different global address.  Both options need to be supported.  <ins> 3.3. After the client receives designation information, it must come to a decision on whether and when to use any of the designated resolvers. In the case of resolver-identified designation, it would be advantageous for a solution to enable the client to validate the source of the assertion in some way.  For example it may be possible to verify that the designation comes from an entity who already has full control of the client's Do53 queries.  Network-identified designation should not require this, unless the network-identified resolver in turn initiated a new resolver-identified designation.  It would be beneficial to extend such a verification process to defend against attackers that have only transient control of such queries. Clients may also seek to validate the identity of the designated resolver, beyond what is required by the relevant protocol.  Authors of solution specifications should be aware that clients may impose arbitrary additional requirements and heuristics as they see fit. 3.4. </ins> DNS servers are often provisioned by a network as part of DHCP options RFC2132, IPv6 Router Advertisement (RA) options RFC8106, resolver IP addresses, to be used for traditional unencrypted DNS. A solution is required that enhances the set of information delivered  <ins> to include details of one or more designated encrypted DNS resolvers, or states that there are none.  Such resolvers could be on the local network, somewhere upstream, or on the public Internet. </ins>  <ins> 3.5. </ins> To support cases where the network is unable to identify an encrypted resolver, it should be possible to learn the details of one or more  <ins> designated encrypted DNS resolvers by communicating with the network's designated Do53 resolver.  This should involve an exchange that uses standard DNS messages that can be handled, or forwarded, by existing deployed software. </ins>  <ins> Each resolver in the set may be at a different network location, which leads to several subcases for the mapping from Do53 to a particular designated resolver. 3.5.1. </ins> If the local resolver has been upgraded to support encrypted DNS, the client may not initially be aware that its local resolver supports retaining the benefits of a local caching resolver with knowledge of the local topology. <ins> Clients will be aware when the designated resolver has the same IP address as the Do53 (after looking up its name if required).  They can use this information in their decision-making as to the level of trust to place in the designated resolver.  In some networks it will not be possible to deploy encrypted DNS on the same IP address, e.g. because of the increased resource requirements of encrypted DNS. Discovery solutions should work in the presence of a change to a different local IP address. </ins> An additional benefit of using a local resolver occurs with IoT devices.  A common usage pattern for such devices is for it to "call home" to a service that resides on the public Internet, where that accessible for inspection, it becomes quite difficult for the infrastructure to suspect anything.  <ins> 3.5.2. It is frequently the case that Do53 resolvers announced by home networks are difficult to upgrade to support encrypted operation.  In such cases it is possible that the only option for encrypted operation is to refer to a separate globally-addressed encrypted DNS resolver, somewhere upstream.  Other networks may choose deploy their encrypted DNS resolver away from the local network, for other reasons. The use of an upstream resolver can mean the loss of local knowledge, such as the ability to respond to queries for locally-relevant names. Solutions should consider how to guide clients when to direct their queries to the local Do53.  For example this could be through pre- emptive communication ("if you ever need to query *.example.com, use your local Do53"), or reactively ("I don't know the answer to that, but your local Do53 should know"). 3.5.3. In cases where the local network has designated a Do53 resolver on the public Internet, this resolver may designate its own or another public encrypted DNS service.  Since public IP addresses may appear in TLS certificates, solutions may use this as one way to validate that the designated encrypted resolver is legitimately associated with the original Do53. 3.6. In cases where the designation is delivered over an authenticated and encrypted channel, such as when one encrypted DNS resolver designates another, one form of attack is removed.  Specifically, clients may be more confident that the received designation was actually sent by the designator.  Clients may take this into account when deciding whether to follow the designation. 4. </ins> Encrypted (and authenticated) DNS improves the privacy and security of DNS queries and answers in the presence of malicious attackers. administrator. Cause clients to use a discovered resolver which has no  <ins> designation from a client-known entity. </ins> When discovering DNS resolvers on a local network, clients have no mechanism to distinguish between cases where an active attacker with discovery solutions designed around this threat model may have limited value.  <ins> 5. </ins> This section lists requirements that flow from the above sections.  <ins> 6. </ins> See priv-sec.  <ins> 7. </ins> This document has no IANA actions.


14 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> This document makes use of the terms defined in RFC8499.  The term "Global DNS" is defined in RFC8499. 'Encrypted DNS' refers to a DNS protocol that provides an encrypted channel between a DNS client and server (e.g., DoT, DoH, or DoQ). The term 'Validated Split-Horizon' is also defined. 2.1. A split horizon configuration for some name is considered "validated" if the network client has confirmed that a parent of that name has authorized the local network to serve its own responses for that name.  Such authorization generally extends to the entire subtree of names below the authorization point. </del>  3. 6.1. <del> The client sends the NS query to a pre-configured resolver that is external to the network, over a secure transport.  Clients SHOULD apply whatever acceptance rules they would otherwise apply when using this resolver (e.g. checking the AD bit, validating RRSIGs). </del>  6.2.

From Paul Wouters: From Michael Richardson:
Do you think this is a client configuration that we should reasonably expect? It seems to me that that behavior would be quite strange, although it is permissible. I think it's probably clearer for our examples to represent common configurations.
NAME Can we discuss it separately? This PR is for changes in response to feedback in the ADD adoption thread. Do you approve of this PR for that purpose? Perhaps you can open a new PR if you would like to add more example text.
Yes, changes look good to me. Works for me. I proposed this text to address the comment from the WG on whether client implementations will enable DNSSEC to support the proposed mechanism.

14 RFC8174 when, and only when, they appear in all capitals, as shown here.  <ins> This document makes use of the terms defined in RFC8499, e.g. "Global DNS".  The following additional terms are used throughout the document: </ins> 3. 6.1.  <ins> This method applies only if the client is already configured with a default resolution strategy that sends queries to a resolver outside of the network over a secure transport.  That resolution strategy is considered "tamperproof" because any actor who could modify the NS response could already modify all of the user's other DNS responses. To ensure that this assumption holds, clients MUST NOT relax the acceptance rules they would otherwise apply when using this resolver. For example, if the client would check the AD bit or validate RRSIGs locally when using this resolver, it must also do so when resolving NS records for this purpose. </ins> 6.2.


Names are formed using Port-Prefix Naming (SVCB Section 2.3).  For example, a DNS service identified by the name "dns1.example.com" and (unusually) the non-default port number 5353 would be represented as <del> "_5353._dns.dns1.example.com.". </del>  4.

Hey Ben, I know the SVCB spec defines this clearly, but I hope you'll feel that this additional sentence strikes a nice balance that can help future readers that, like me, had to dig a bit to un-confuse themselves. Regards, Peter van Dijk
Thanks for the clarification!

Names are formed using Port-Prefix Naming (SVCB Section 2.3).  For example, a DNS service identified by the name "dns1.example.com" and (unusually) the non-default port number 5353 would be represented as  <ins> "_5353._dns.dns1.example.com.".  A DNS service using the default port number of 53 would be represented as "_dns.dns1.example.com.". </ins> 4.


This behavior creates a number of possible attacks for certain server configurations.  For example, if "https://$HOSTNAME/upload" accepts any POST request as a public file upload, the adversary could forge a <del> SVCB record containing "dohpath=/upload".  This would cause the </del>  client to upload and publish every query, resulting in unexpected storage costs for the server and privacy loss for the client. Similarly, if two DoH endpoints are available on the same origin, and endpoint instead. To mitigate redirection attacks, a client of this SVCB mapping MUST <del> NOT provide client authentication for DNS queries, except to servers that it specifically knows are not vulnerable to such attacks.  If an endpoint sends an invalid response to a DNS query, the client SHOULD NOT send more queries to that endpoint.  DNS services that are identified by a hostname (identity) MUST ensure that all unauthenticated DNS requests to that name receive any promised privacy and security guarantees, regardless of transport, port number, or HTTP path. </del>  8.2.

NAME Please review.
currently says: This MUST seems strange. Is this just saying "don't do silly or otherwise bad things with client queries"? I'm not sure that's something we need normative language for here, so unless there's a particular behavior that this is meant to require (or prohibit), I'd recommend removing it.
Suppose is your consumer-facing endpoint with limited logging, and is a debug endpoint that drops all queries into a log that's accessible to your whole engineering staff. The point of this sentence is that, if this is your configuration, you can't promise users the limited logging on the consumer-facing endpoint, because any intermediary could flip users onto the debug endpoint, causing you to violate your own promise. You need to move these endpoints onto separate hostnames. Separate paths, port numbers, or even separate ALPNs, is not sufficient, because an attacker can steer the user between them.
I agree the original text was unclear unless you're already familiar with the problem. I wasn't. However Ben's response above DID make sense to me, so it would be good to use some of it.
recommends that clients mitigate redirection attacks by not using client authentication to DNS resolvers. Perhaps a better approach would be to not use a TLS context or association that is used for other purposes, regardless of whether that context uses client authentication.
I don't think that is sufficient. The attack does not depend on the client authentication being shared with another context. For example, if I rewrite the to be , and this triggers an HTTP Basic Authentication response that causes the client software to pop up a username+password prompt, the user might log in and enable the attack.
There are lots of ways connection state could be misused here. For example, what if the new DNS query is sent over a connection that uses cookies? What if the DNS query resumes a previously established TLS connection that used some application layer authentication? Basically, this text seems not quite right, since it seems to focus on TLS-layer things. I recommend further refining to make it clear what is expected of this new connection. I'm happy to propose a PR to clarify my thinking, if that would be useful.
"Client authentication" in this text is not intended to to be limited to TLS. It applies to any form of client authentication in any protocol, including HTTP.
Great -- I'll propose text!
I've added a small change to that tries to clarify this requirement.

This behavior creates a number of possible attacks for certain server configurations.  For example, if "https://$HOSTNAME/upload" accepts any POST request as a public file upload, the adversary could forge a  <ins> SVCB record containing "dohpath=/upload{?dns}".  This would cause the </ins> client to upload and publish every query, resulting in unexpected storage costs for the server and privacy loss for the client. Similarly, if two DoH endpoints are available on the same origin, and endpoint instead. To mitigate redirection attacks, a client of this SVCB mapping MUST  <ins> NOT identify or authenticate itself when performing DNS queries, except to servers that it specifically knows are not vulnerable to such attacks.  If an endpoint sends an invalid response to a DNS query, the client SHOULD NOT send more queries to that endpoint. Multiple DNS services MUST NOT share a hostname identifier (identity) unless they are so similar that it is safe to allow an attacker to choose which one is used. </ins> 8.2.


the contents of the SVCB SvcParams.  This document provides the mapping for the "dns" service type, allowing DNS servers to offer alternative endpoints and transports, including encrypted transports <del> like DNS over TLS and DNS over HTTPS. </del>  2. "dohpath" is a single-valued SvcParamKey whose value (both in presentation and wire format) MUST be a URI Template RFC6570 encoded <del> in UTF-8 RFC3629.  If the "alpn" SvcParamKey indicates support for HTTP, "dohpath" MUST be present, and clients MAY construct a DNS over HTTPS URI Template as follows: Let "$HOST" be the authentication name encoded as a ""host"" value (Section 3.2.2 of RFC3986). Let "$PORT" be the port from the "port" key if present, otherwise 443.  (The binding authority's port number MUST NOT be used.) Let "$DOHPATH" be the "dohpath" value, decoded from UTF-8. The DNS over HTTPS URI Template is ""https://$HOST:$PORT$DOHPATH"". The "dohpath" value MUST be chosen such that the resulting URI Template is valid for use with DNS over HTTPS.  For example, DNS over HTTPS servers are required to support requests using GET and POST methods.  The GET method relies on the "dns" URI Template parameter, and the POST method does not use it.  Therefore, the URI Template is required to make use of a "dns" variable, and result in a valid URI whether or not "dns" is defined. Clients SHOULD NOT query for any "HTTPS" RRs when using the constructed URI Template.  Instead, the SvcParams and address records associated with this SVCB record SHOULD be used for the HTTPS connection, with the same semantics as an HTTPS RR.  However, for consistency, service operators SHOULD publish an equivalent HTTPS RR, especially if clients might learn this URI Template through a different channel. </del>  6. <del> A resolver at ""doh.example"" that supports only DNS over HTTPS (DNS over TLS is not supported): </del>  A resolver at ""resolver.example"" that supports: <del> DNS over TLS on ""resolver.example"" ports 853 (implicit in record 1) and 8530 (explicit in record 2), with ""resolver.example"" as the Authentication Domain Name, </del>  <del> DNS over HTTPS at "https://resolver.example/dns-query{?dns}" (record 1), and </del>  an experimental protocol on "fooexp.resolver.example:5353" (record 3):

This wording avoids the complexity of a URI construction algorithm and is more direct and compact.
The DoH URI Template algorithm currently works like so: where $DOHPATH is "a URI Template ] encoded in UTF-8 ]." This seems not restrictive enough. For example, a valid $DOHPATH template could be "URL{?dns}," and following the algorithm above would yield "URL{?dns}," which obviously seems like not the intended result. There's text that says "The "dohpath" value MUST be chosen such that the resulting URI Template is valid for use with DNS over HTTPS," but note that the algorithm above is presented with the word MAY which, to me, implies that clients could construct the URI Template some other way. Unless there's a good reason to do so, we should be more restrictive with what $DOHPATH contains (it might be just a path component of a URI Template, or something), and how clients construct the Template.
Yes. Surely this normatively constrains the value in the way you're asking? Yes. People don't like it when you normatively require implementation of a specific algorithm, because it artificially constrains implementation. In this case, for example, a client could choose to omit the port number when it is unspecified, instead of setting it explicitly to 443. This would undeniably result in a different DoH URI Template, although the resulting calculated URIs for each request would be equivalent in some sense. A client could even skip computation of the full URI template, and instead perform substitution for each request directly on the string, plugging and and the path into their HTTP client library without ever constructing a URI.
Maybe it would be better to say that is a URI template that expands to the for each HTTP request, and remove the discussion about forming a full URL?

the contents of the SVCB SvcParams.  This document provides the mapping for the "dns" service type, allowing DNS servers to offer alternative endpoints and transports, including encrypted transports  <ins> like DNS over TLS (DoT) and DNS over HTTPS (DoH). </ins> 2. "dohpath" is a single-valued SvcParamKey whose value (both in presentation and wire format) MUST be a URI Template RFC6570 encoded  <ins> in UTF-8 RFC3629.  If the "alpn" SvcParam indicates support for HTTP, "dohpath" MUST be present.  The URI Template MUST contain a "dns" variable, and MUST be chosen such that the result after DoH template expansion (Section 6 of RFC8484) is always a valid and functional ":path" value (RFC7540, Section 8.1.2.3). When using this SVCB record, the client MUST send any DoH requests to the HTTP origin identified by the "https" scheme, the authentication name, and the port from the "port" SvcParam (if present).  HTTP requests MUST be directed to the resource resulting from DoH template expansion of the "dohpath" value. Clients SHOULD NOT query for any "HTTPS" RRs when using "dohpath". Instead, the SvcParams and address records associated with this SVCB record SHOULD be used for the HTTPS connection, with the same semantics as an HTTPS RR.  However, for consistency, service operators SHOULD publish an equivalent HTTPS RR, especially if clients might learn about this DoH service through a different channel. </ins> 6.  <ins> A DoH-only resolver at "https://doh.example/dns-query{?dns}". (DNS over TLS is not supported.): </ins> A resolver at ""resolver.example"" that supports:  <ins> DoT on ""resolver.example"" ports 853 (implicit in record 1) and 8530 (explicit in record 2), with ""resolver.example"" as the Authentication Domain Name, </ins>  <ins> DoH at "https://resolver.example/dns-query{?dns}" (record 1), and </ins> an experimental protocol on "fooexp.resolver.example:5353" (record 3):


4.1. <del> These keys indicate the set of supported protocols (SVCB Section 6.1).  The default protocol is "dot", indicating support for DNS over TLS DOT. </del>  If the protocol set contains any HTTP versions (e.g. "h2", "h3"), then the record indicates support for DNS over HTTPS DOH, and the on their default ports.  Note that in this configuration, ALPN negotiation does not defend against cross-protocol downgrade attacks. <del> These keys are automatically mandatory if present.  (See Section 7 of SVCB for the definition of "automatically mandatory".) </del> 4.2. This key is used to indicate the target port for connection ((SVCB Section 6.2)).  If omitted, the client SHALL use the default port for <del> each transport protocol (853 for DNS over TLS, 443 for DNS over </del>  HTTPS). <del> This key is automatically mandatory if present. </del>  4.3. 8. A resolver at "simple.example" that supports DNS over TLS on port <del> 853 (implicitly, as this is the default protocol and its default port): </del>  A resolver at "doh.example" that supports only DNS over HTTPS (DNS over TLS is disabled): _dns.doh.example. 7200 IN SVCB 1 <del> doh.example. ( no-default-alpn alpn=h2 dohpath=/dns-query{?dns} ) </del>  A resolver at "resolver.example" that supports

This change removes the default protocol, which is currently DNS over TLS ("dot"). Several readers have expressed concern that this default is confusing.
Blocked by URL
Section 5.1 says this: The examples are all like this: RFC 6570 says this: I assume that we don't want passed in the SVCB record. Should we clarify that MUST be in relative form, i.e., just the path portion of the URI?
As a normative matter, I think this is already settled in the text, but I'm happy to improve clarity of the description.
Yeah, I think this technically covers it (), but it would be nice to say something at the start of the paragraph to specify that this is just a path segment of the URL.
approved with 1 question

4.1.  <ins> This key indicates the set of supported protocols (SVCB Section 6.1). There is no default protocol, so the "no-default-alpn" key does not apply, and the "alpn" key MUST be present. </ins> If the protocol set contains any HTTP versions (e.g. "h2", "h3"), then the record indicates support for DNS over HTTPS DOH, and the on their default ports.  Note that in this configuration, ALPN negotiation does not defend against cross-protocol downgrade attacks.  4.2. This key is used to indicate the target port for connection ((SVCB Section 6.2)).  If omitted, the client SHALL use the default port for  <ins> each transport protocol (853 for DNS over TLS DOT, 443 for DNS over </ins> HTTPS).  <ins> This key is automatically mandatory if present.  (See Section 7 of SVCB for the definition of "automatically mandatory".) </ins> 4.3. 8. A resolver at "simple.example" that supports DNS over TLS on port  <ins> 853 (implicitly, as this is its default port): </ins> A resolver at "doh.example" that supports only DNS over HTTPS (DNS over TLS is disabled): _dns.doh.example. 7200 IN SVCB 1  <ins> doh.example. ( alpn=h2 dohpath=/dns-query{?dns} ) </ins> A resolver at "resolver.example" that supports


5.1. "dohpath" is a single-valued SvcParamKey whose value (both in <del> presentation and wire format) MUST be a URI Template RFC6570 encoded in UTF-8 RFC3629.  If the "alpn" SvcParam indicates support for HTTP, "dohpath" MUST be present.  The URI Template MUST contain a "dns" variable, and MUST be chosen such that the result after DoH template expansion (Section 6 of RFC8484) is always a valid and functional ":path" value (RFC9113, Section 8.3.1). </del>  When using this SVCB record, the client MUST send any DoH requests to the HTTP origin identified by the "https" scheme, the authentication

Section 5.1 says this: The examples are all like this: RFC 6570 says this: I assume that we don't want passed in the SVCB record. Should we clarify that MUST be in relative form, i.e., just the path portion of the URI?
As a normative matter, I think this is already settled in the text, but I'm happy to improve clarity of the description.
Yeah, I think this technically covers it (), but it would be nice to say something at the start of the paragraph to specify that this is just a path segment of the URL.

5.1. "dohpath" is a single-valued SvcParamKey whose value (both in  <ins> presentation and wire format) MUST be a URI Template in relative form (RFC6570, Section 1.1) encoded in UTF-8 RFC3629.  If the "alpn" SvcParam indicates support for HTTP, "dohpath" MUST be present.  The URI Template MUST contain a "dns" variable, and MUST be chosen such that the result after DoH template expansion (Section 6 of RFC8484) is always a valid and functional ":path" value (RFC9113, Section 8.3.1). </ins> When using this SVCB record, the client MUST send any DoH requests to the HTTP origin identified by the "https" scheme, the authentication


server.  Clients need to know the intended use of services based on their context.  7. A resolver known as "simple.example" that supports DNS over TLS on

See URL
LGTM I have read the draft. It aims to be agnostic as to whether the DNS server that is the subject of the SVCB record is a recursive resolver or an authoritative nameserver for some zone (typically delegated by its parent). It also aims to facilitate the establishment of an authenticated transport. It should be noted that with authoritative delegations from a parent zone, the "service name" for each delegated to nameserver is always obtained from the unsigned parent-side NS RRset. Consequently unless the transport to the parent zone nameserver is authenticated, there is an unavoidable MiTM exposure even when the zone with the SVCB qname is DNSSEC-signed, because an on-path attacker can tamper with the returned NS records. And of course if the transport to the parent nameserver is not encrypted, the name of the desired child zone is leaked in the clear, defeating some or most of the privacy gains from subsequent use of an encrypted transport with the child zone nameservers. So perhaps the document should note using SVCB to signal transport security for nameservers derived from NS records is predicated on a suitably secure connection to the parent zone. The use of SVCB RRs for authoritative nameservers introduces the possibility that the SVCB target name is different from the "service name" in the NS record. Such additional indirection is perhaps surprising or even undesirable. Also, likely DoH would not be a supported transport for authoritative servers, with DoT or DoQ being the available options. If this draft is to be adopted for use with authoritative nameservers these topics would warrant some further discussion, and perhaps some minimal text is warranted to say as much. Viktor.

server.  Clients need to know the intended use of services based on their context. <ins> Not all features of this specification will be applicable or effective in all contexts: If the authentication name is received over an insecure channel (e.g., a glue NS record), this specification cannot prevent the client from connecting to an attacker. Different transports might prove to be popular for different purposes (e.g., stub resolution vs. iterative resolution). Implementors are not obligated to implement all the defined transports, although doing so is beneficial for compatibility. Where resolution speed is a high priority, the SVCB TargetName SHOULD follow the convention described in Section 11.2 of SVCB, and the use of AliasMode records (Section 2.4.2 of SVCB) is NOT RECOMMENDED. </ins> 7. A resolver known as "simple.example" that supports DNS over TLS on


3. <del> Names are formed using Port-Prefix Naming (SVCB Section 2.3), with a scheme of "dns".  For example, SVCB records for a DNS service identified as "dns1.example.com" would be located at "_dns.dns1.example.com". </del>  3.1. When a non-default port number is part of a service identifier, Port- Prefix Naming places the port number in an additional a prefix on the name.  For example, SVCB records for a DNS service identified as <del> "dns1.example.com:9953" would be located at "_9953._dns.dns1.example.com".  If two DNS services operating on </del>  different port numbers provide different behaviors, this arrangement allows them to preserve the distinction when specifying alternative endpoints. 4.1. <del> This key indicates the set of supported protocols (SVCB Section 6.1). There is no default protocol, so the "no-default-alpn" key does not apply, and the "alpn" key MUST be present. </del>  If the protocol set contains any HTTP versions (e.g. "h2", "h3"), then the record indicates support for DNS over HTTPS DOH, and the 4.2. <del> This key is used to indicate the target port for connection ((SVCB Section 6.2)).  If omitted, the client SHALL use the default port for each transport protocol (853 for DNS over TLS DOT, 443 for DNS over HTTPS). </del>  This key is automatically mandatory if present.  (See Section 7 of SVCB for the definition of "automatically mandatory".)

The lack of quoting in some of the examples might make it harder to see what constitutes example and what is punctuation. Highlighting and fonts in the HTML rendering are subtle and not present in text renderings (any more). I've also changed some section references. I'm happy to split that off into a different change or use the form if you prefer that.

3.  <ins> Names are formed using Port-Prefix Naming (Section 2.3 of SVCB), with a scheme of "dns".  For example, SVCB records for a DNS service identified as ""dns1.example.com"" would be located at ""_dns.dns1.example.com"". </ins> 3.1. When a non-default port number is part of a service identifier, Port- Prefix Naming places the port number in an additional a prefix on the name.  For example, SVCB records for a DNS service identified as  <ins> ""dns1.example.com:9953"" would be located at ""_9953._dns.dns1.example.com"".  If two DNS services operating on </ins> different port numbers provide different behaviors, this arrangement allows them to preserve the distinction when specifying alternative endpoints. 4.1.  <ins> This key indicates the set of supported protocols (Section 6.1 of SVCB).  There is no default protocol, so the "no-default-alpn" key does not apply, and the "alpn" key MUST be present. </ins> If the protocol set contains any HTTP versions (e.g. "h2", "h3"), then the record indicates support for DNS over HTTPS DOH, and the 4.2.  <ins> This key is used to indicate the target port for connection ((Section 6.2 of SVCB)).  If omitted, the client SHALL use the default port for each transport protocol (853 for DNS over TLS DOT, 443 for DNS over HTTPS). </ins> This key is automatically mandatory if present.  (See Section 7 of SVCB for the definition of "automatically mandatory".)


7. <del> A resolver at "simple.example" that supports DNS over TLS on port 853 (implicitly, as this is its default port): </del>  <del> A resolver at "doh.example" that supports only DNS over HTTPS (DNS over TLS is not supported): </del>  <del> A resolver at "resolver.example" that supports </del>  <del> DNS over TLS on "resolver.example" ports 853 (implicit in </del>  record 1) and 8530 (explicit in record 2), with <del> "resolver.example" as the Authentication Domain Name, </del>  DNS over HTTPS at "https://resolver.example/dns-query{?dns}" (record 1), and <del> A nameserver at "ns.example" whose service configuration is </del>  published on a different domain:

These are really minor, was making all your dns names use the same syntax you started with ("") But I think the examples should look similar in nature. (i'm also thinking of some horrible bad examples to include)
agreed - totally missed that. I pushed up the edit if that is easier.

7.  <ins> A resolver at ""simple.example"" that supports DNS over TLS on port 853 (implicitly, as this is its default port): </ins>  <ins> A resolver at ""doh.example"" that supports only DNS over HTTPS (DNS over TLS is not supported): </ins>  <ins> A resolver at ""resolver.example"" that supports: </ins>  <ins> DNS over TLS on ""resolver.example"" ports 853 (implicit in </ins> record 1) and 8530 (explicit in record 2), with  <ins> ""resolver.example"" as the Authentication Domain Name, </ins> DNS over HTTPS at "https://resolver.example/dns-query{?dns}" (record 1), and  <ins> A nameserver at ""ns.example"" whose service configuration is </ins> published on a different domain:


A YANG Data Model for Optical Impairment-aware Topology <del> draft-ietf-ccamp-optical-impairment-topology-yang-08 </del>  Abstract Optical data plane interoperability is outside the scope of this draft. <del> This document augments the generic TE topology draft RFC8795 where possible. </del>  This document defines one YANG module: ietf-optical-impairment- topology (sect-3) according to the new Network Management Datastore The terminology for describing YANG data models is found in RFC7950.  1.2. A simplified graphical representation of the data model is used in Figure-1 shows the control plane architecture. <del> The models developed in this document is an abstracted YANG model that may be used in the interfaces between the MDSC and the Optical Domain Controller (aka MPI) and between the Optical Domain Controller and the Optical Device (aka SBI) in Figure-1.  It is not intended to support a detailed low-level DWDM interface model.  DWDM interface model is supported by the models presented in I-D.ietf-ccamp-dwdm-if- param-yang. </del>  2.2. <del> This section provides the description of the reference optical network architecture and its relevant components to support optical impairment-aware path computation. </del>  Figure-2 shows the reference architecture. <del> BA (on the left side ROADM) is the ingress Amplifier and PA (on the right side ROADM is the egress amplifier for the OMS link shown in Figure-2. </del>  2.3. <del> According to G.872, OMS Media Link represents a media link between two ROADMs.  Specifically, it originates at the ROADM's Filter in the source ROADM and terminates at the ROADM's Filter in the destination ROADM. OMS Media link can be decomposed in a sequence of OTS links type (i), (ii), and (iii) as discussed above.  OMS Media link would give an abstracted view of impairment data (e.g., power, OSNR, etc.) to the network controller. For the sake of optical impairment evaluation OMS Media link can be also decomposed in a sequence of elements such as BA, fiber section, ILA, concentrated loss and PA. An OMS Media link is terminated on both ends by a link termination point (LTP) as defined in RFC8345.  Links in optical transport networks are typically bidirectional but have to be modeled as a pair of two unidirectional links following the RFC8345 modeling approach. Unlike TE links, which are unidirectional, the LTPs on either end of the TE link pair forming the bidirectional link, are bidirectional as </del>  described in I-D.ietf-teas-te-topo-and-tunnel-modeling and the pair of unidirectional links are connected to the same bidirectional LTP on either end of the link pair. <del> [Editor's note: text below related to G.807 needs to be revised! G.807 is now in publication process.] </del>  2.3.1. carrier frequency, baud rate, and signal power for all existing OTSi signals on each OMS link. <del> Additionally, it is necessary for each ROADM node in the network to know the OTSi signals that are added to or dropped from an OMS link as well as the optical power of these OTSi signals to check whether the ROADM's optical power constraints are met. </del>  The optical impairment-aware topology YANG model below defines the OTSi properties needed for optical impairment-aware path computation 2.3.3. <del> The definition of the MC is currently being moved from ITU-T Recommendation G.872 G.872 to the new draft Recommendation G.807 (still work in progress) [G.807].  Section 3.2.2 defines the term MC and section 7.1.2 provides a more detailed description with some examples.  The definition of the MC is very generic (see ITU-T draft Recommendation G.807, Figure 7-1).  In the YANG model below, the MC is used with the following semantics: </del>  The MC is an end-to-end topological network construct and can be considered as an "optical pipe" with a well-defined frequency slot 2.4. <del> Optical amplifiers are in charge of amplifying the optical signal in the optical itself without any electrical conversion.  There are three main technologies to build amplifiers: Erbium Doped Fiber Amplifier (EDFA), Raman Fiber Amplifier (RFA), and Semiconductor Optical Amplifier (SOA).  Nowadays, most of optical networks uses EDFAs.  However, RFA has an attractive feature that it works in any wavelength band with a similar or lower noise figures compared to EDFA.  On the other hand, RFAs consumes more power and are more expensive than EDFAs. Amplifiers can be classified according to their location in the communication link.  There are three basic types of amplifiers: ILA, Pre-Amplifier and Booster.  ILA is In-Line Amplifier which is a separate node type while Pre-Amplifier and Booster Amplifier are integral elements of ROADM node.  From a data modeling perspective, Pre-Amplifier and Booster Amplifier are internal functions of a ROADM node and as such these elements are hidden within ROADM node.  In this document, we would avoid internal node details, but attempt to abstract as much as possible. </del>  ILAs are placed at locations where the optical amplification of the <del> WDM signal is required on the OMS link between two ROADM nodes. Geolocation information is already defined for TE nodes in RFC8795 and is also beneficial for ILAs.  Therefore, the same geolocation container has been added to the amplifier element on an OMS link containing altitude, latitude, and longitude as optional attributes. </del>  One modeling consideration of the ROADM internal is to model power parameter through the ROADM, factoring the output power from the Pre- 2.9. <del> The ROADM node architectures in today's dense wavelength division </del>  multiplexing (DWDM) networks can be categorized as follows: <del> Integrated ROADM architecture with integrated optical transponders </del>  <del> Integrated ROADM architecture with integrated optical transponders </del>  and single channel add/drop ports for remote optical transponders <del> Disaggregated ROADM architecture where the ROADM is subdivided into degree, add/drop, and optical transponder subsystems handled as separate network elements </del>  The TE topology YANG model augmentations including optical impairments for DWDM networks defined below intend to cover all the 3 <del> categories of ROADM architectures listed above.  In the case of a disaggregated ROADM architecture, it is assumed that optical domain controller already performs some form of abstraction and presents the TE-node representing the disaggregated ROADM in the same way as an integrated ROADM with integrated optical transponders if the optical transponder subsystems and the add/drop subsystems are collocated (short fiber links not imposing significant optical impairments). The different ROADM architectures are briefly described and </del>  illustrated in the following subsections. [Editor's note: The modeling of remote optical transponders located for example in the client device with a single channel link between <del> the OT and the add/drop port of the ROADM requires further </del>  investigations and will be addressed in a future revision of this document.] 2.9.1. Figure-2 and Figure-6 below show the typical architecture of an <del> integrated ROADM node, which contains the optical transponders as an integral part of the ROADM node.  Such an integrated ROADM node provides DWDM interfaces as external interfaces for interconnecting the device with its neighboring ROADMs (see OTS link above).  The number of these interfaces denote also the degree of the ROADM.  A degree 3 ROADM for example has 3 DWDM links that interconnect the ROADM node with 3 neighboring ROADMs.  Additionally, the ROADM provides client interfaces for interconnecting the ROADM with client </del>  devices such as IP routers or Ethernet switches.  These client interfaces are the client interfaces of the integrated optical transponders. 2.9.2. Figure-7 below shows the extreme case where all optical transponders <del> are not integral parts of the ROADM but are separate devices that are interconnected with add/drop ports of the ROADM.  If the optical transponders and the ROADM are collocated and if short single channel fiber links are used to interconnect the optical transponders with an add/drop port of the ROADM, the optical domain controller may present these optical transponders in the same way as integrated optical transponders.  If, however, the optical impairments of the single channel fiber link between the optical transponder and the add/drop port of the ROADM cannot be neglected, it is necessary to represent the fiber link with its optical impairments in the topology model This also implies that the optical transponders belong to a separate TE node </del>  [Editor's note: this requires further study]. 2.9.3. <del> Recently, some DWDM network operators started demanding ROADM </del>  subsystems from their vendors.  An example is the OpenROADM project where multiple operators and vendors are developing related YANG <del> models.  The subsystems of a disaggregated ROADM are: single degree subsystems, add/drop subsystems and optical transponder subsystems. These subsystems separate network elements and each network element provides a separate management and control interface.  The subsystems are typically interconnected using short fiber patch cables and form together a disaggregated ROADM node.  This disaggregated ROADM architecture is depicted in Figure-8 below. </del>  As this document defines TE topology YANG model augmentations RFC8795 for the TE topology YANG model provided at the north-bound interface of the optical domain controller, it is a valid assumption that the optical domain controller abstracts the subsystems of a disaggregated <del> ROADM and presents the disaggregated ROADM in the same way as an integrated ROADM hiding all the interconnects that are not relevant from an external TE topology view. </del>  2.9.4.  When an optical OTSi signal traverses a ROADM node, optical impairments are imposed on the signal by various passive or active optical components inside the ROADM node.  Examples of optical

draft-ietf-ccamp-optical-impairment-topology-URL for IETF 113 submission --> draft-ietf-ccamp-optical-impairment-topology-yang-URL Related to pull request . Addressing and resolving several open issues.
+1 the TE-node doesn’t include BA/PA, a physical node however could.
In TIP, carrier use cases exist for copropagating Raman. It has been verified that gnpy can model those by indicating the direction (see snippet below). So the provisional limit to consider only counterpropagating raman in can be lifted. example: "ramanpumps": [ { "power": 224.403e-3, "frequency": 205e12, "propagationdirection": "coprop" }, { "power": 231.135e-3, "frequency": 201e12, "propagation_direction": "coprop" }
There is agreement to introduce also co-propagating option. The model as it is can support the feature using type-variety. Only one point has to be verified: if in the case of co-propagation we can report the gain. he pump power is in the type-variety. The text in the draft has to updated without the limitation of counter-propagating.
During the meeting on February 15th , we agree to add two attributes pump-power and frequency. Also direction has to be added in alignment with the GNPy . Need to clearly say in the text that these attributes are needed for RAMN only.
Meeting 02/15/22: The agreement was to add "pump-power", "frequency" and "direction" attributes as described in Gert's comment URL Meeting 02/22/22: Esther sent a proposed description of attributes to TIP experts for revision .
From Esther: Compared to GNPy data model, the pumps are listed in an ‘amplifier element’, not in a fiber. I have assumed that a given amplifier element can not hold the two co and contra propagation roles. Final result: “Raman-direction”: "counter-propagating" "Raman-pumps": [ { "power": 224.403e-3, "frequency": 205e12, }, { "power": 231.135e-3, "frequency": 201e12, } ] Descriptions: Raman-pumps container: list of pumps for the Raman amplifier Power: Total pump power in W considering a depolarized pump at frequency “frequency” Frequency: Pump central frequency in THz Raman-direction: direction of injection of the pump in the OMS. Contra-propagating means that optical pumps are injected in opposite direction to the optical signal that is amplified (backward pump). Co-propagating means that the optical pumps are injected in the same direction to the optical signal that is amplified (forward pump). enumerate type “co-propagating” or “contra-propagating” This porposal has been sent also to TIP experts for comments .
ITU-T G.872 (12/2019) The draft text needs to be aligned with the latest revisions of the referenced ITU-T Recommendations G.807 and G.872.
I have a mixed feeling about this ... On one side, I can understand that using the terms OTS/OMS MCG would align the terminology used in the draft with the ITU-T G.807 terminology On the other side, the OTS/OMS MCG from a topological perspective are modelled as links (at least the OMS MCG) so I am not sure whether the term MCG to represent a link would cause some confusion
Here is the text update I prepared with the objective to align with ITU-T G.807 and describe how the new terms map to the IETF TE-topology terminology: OMS Media Channel Group According to [G.807] and [G.872], an OMS Media Channel Group (MCG) represents a topological construct between two WDM-TE-nodes. In TE- topolgy terms, an OMS MCG corresponds to a WDM TE-link interconnecting two WDM-TE-nodes. Specifically, it originates at the ROADM in the source WDM-TE-node and terminates at the ROADM in the destination ROADM including the Booster Amplifier (BA) and the Pre- Amplifier in the WDM-TE-nodes as well as In-Line Amplifiers (ILAs). OTS Media Channel Group represents a link: (i) between a WDM-TE-node's BA and the adjacent ILA, (ii) between a pair of ILAs, (iii) between an ILA and the adjacent WDM-TE-node's PA. An OMS MCG can be decomposed into a sequence of OTS MCGs of type (i), (ii), and (iii) as listed above. An OMS MCG (TE-link) provides the optical impairment data for its elements defined in the layer-0 topology YANG model and can be retrieved by a network controller. For the sake of optical impairment modeling, an OMS MCG can also be decomposed into a sequence of elements such as BA, fiber section, ILA, concentrated loss, and PA. An OMS MCG is terminated on both ends by a link termination point (LTP) as defined in [RFC8345]. Links in optical transport networks are typically bidirectional but have to be modeled as a pair of two unidirectional links following the [RFC8345] modeling approach. Unlike TE-links, which are unidirectional, the LTPs on either end of the TE-link pair forming the bidirectional link, are bidirectional as described in [I-D.ietf-teas-te-topo-and-tunnel-modeling] and the pair of unidirectional links are connected to the same bidirectional LTP on either end of the link pair.
few nits: The OMS-MCG starts from the ROADM element in the WDM-TE-node, but the description of OTS-MCG doesn't cover the link between ROADM element and Booster/PA. To cover this, a case iv should be added. (see G.807 Fig 11-1) last paragraph: [RFC8345] does not specifically define LTPs. It defines Termination Points (TPs) in a generic manner. So "LTP" would better be replaced by "TP"
NAME NAME : thanks Gert to pointed out, we need to substitute RFC8345 with RFC8795, since LTP it is a a te-topology defined entity.
Fixed by PR
Elements as they are defined may be enough to handle Raman amplification, but I would like to have the feedback from the group about the possible missing attributes or change to the model. For example, it is not said in the model if the loss of the fiber should be its loss with or without Raman gain if any.
As per action point, here is a proposal for the text: "Hybrid backward Raman + EDFA amplification can be modelled for example by using an amplifier element in front of the EDFA amplifier element to represent the amplifier pump place and the resulting gain. In this case tilt target is not mandatory" (Ithink that nominal power should not be mandatory either, this is not something configurable) "In case of Raman amplification on a fiber section, the total-loss of the corresponding fiber element should contain only the fiber loss and not the resulting loss including Raman gain".
Here is a revised text proposal for section "2.4. Amplifiers": some editorial as well as format changes have been made to the a new paragraph on Raman amplifiers has been added (paragraph at the bottom below) addressing the modeling approach for Raman amplifiers the remaining text in this section is unchanged
Thanks, that's clear for me ! shall we also amend the model and put nominal-power as optional ?
NAME : sorry ,which nominal-power are you referring to?
I was refering to nominal-carrier-power and nominal-power-spectral-density, but I just realized that they are already optional !
I would propose some text update to the last part of Dieter's text proposal: The remaining text proposal from Dieter is fine for me
NAME
I like NAME proposal including NAME amendments: however I'm wondering if it's worth mentioning the amplifier element shall model Ramam gain tilt and bandwidth as well. something like an amplifier element at the pump location which reports all the optical properties (gain, tilt, etc) of the Raman amplification.
NAME NAME NAME What about: "an amplifier element whose location (provided by both the position in the OMS-link list of elements and geolocation) reports the pump place and whose parameters reports all the optical properties (gain, tilt, etc) of the Raman amplification.
I’m OK with the text with only one comment: there are co-propagating and counter-propagating raman pumps, do We want to limit the solution to counter-propagating pumps ?
Here the text we agree during the December 14th meeting: Amplifiers Optical amplifiers are used in WDM networks for amplifying the optical signal in the optical domain without any optical to electrical and electrical to optical conversion. There are three main optical amplifier technologies: o Erbium Doped Fiber Amplifiers (EDFAs) o Raman Amplifiers o Semiconductor Optical Amplifiers (SOAs) In today's WDM networks EDFAs and Raman amplifiers are widely used. Raman amplifiers have become attractive due to their large spectral gain bandwidth, which can be quite flat, with similar or even lower noise figures compared to EDFAs. On the other hand, Raman amplifiers consume more power and are usually more expensive than EDFAs. Raman amplifiers are distributed amplifiers where an optical pump signal is injected in opposite direction to the optical signal that is amplified (backward pump). Due to the distributed nature of the Raman amplifier it is difficult to clearly separate the amplifier from the fiber span into which the pump signal is injected. From a topology modeling perspective, the Raman amplifier is modeled as two OMS link elements: a passive fiber element whose loss accounts only the fiber loss and not the resulting loss including Raman gain an amplifier element whose location (provided by both the position in the OMS-link list of elements and geolocation) reports the pump place and whose parameters reports all the optical properties (gain, tilt, etc) of the Raman amplification
During December 14th meeting it was decided that is acceptable, for the moment, to limit the solution to counter-propagating pumps only. An explicit sentence regarding this point will be added , together with the text suggested by Dieter.
Updated section 2.4 text addressing the previous comment, text proposal from Dec 14, 2021, slightly modified - pure editorial changes only - see numbered list items at the bottom: Amplifiers Optical amplifiers are used in WDM networks for amplifying the optical signal in the optical domain without any optical to electrical and electrical to optical conversion. There are three main optical amplifier technologies: o Erbium Doped Fiber Amplifiers (EDFAs) o Raman Amplifiers o Semiconductor Optical Amplifiers (SOAs) In today's WDM networks EDFAs and Raman amplifiers are widely used. Raman amplifiers have become attractive due to their large spectral gain bandwidth, which can be quite flat, with similar or even lower noise figures compared to EDFAs. On the other hand, Raman amplifiers consume more power and are usually more expensive than EDFAs. Raman amplifiers are distributed amplifiers where an optical pump signal is injected in opposite direction to the optical signal that is amplified (backward pump). Injecting the pump signal in the same directions as the optical signal that is amplified (forward pump) is currently not considered. Due to the distributed nature of the Raman amplifier it is difficult to clearly separate the amplifier from the fiber span into which the pump signal is injected. From a topology modeling perspective, the Raman amplifier is modeled as two OMS line elements: a passive fiber element accounting for the fiber loss only and not the resulting loss including the Raman gain an amplifier element providing all optical amplifier properties (gain, tilt, etc.). On the OMS-link, the amplifier element is placed where the pump is located and the geolocation information also indicates the location of the pump.
NAME I like the editorial modifications and new structure of the text, with the numbered list bullets at the bottom.
Thanks, Ok for me!
NAME The new formulation is fine for me (and it will address NAME comment too).
Fixed by PR
We would like to use the model to describe a topology where the ROADMs have one/multiple external shelves with OTs. For management reason we want to represent the external shelf as a te-node (in the ietf model), to represent all names and adresses (we do not want to represent the shelf+ROADM as a single abstract ROADM). The links between the OTs hosted in this shelf can be described using te-link with optical impairment augmentation to describe possible loss or noise (the tooling provided by the model is enough to handle this case). However the external shelf does not contain any mux, so that the link between the remote transceiver and the ROADM is not an OMS. However all the impairments we have defined in our model have this 'OMS' attribute. This mismatch between the name of the attributes (containing OMS) and its usage for non OMS links might be confusing for implementers. We thus would like to say explicitely in the draft that the links between ROADMs and external shelves can also be described with our model. Currently, this sentence is in the draft: for example in the client device with a single channel link between the OT and the add/drop port of the ROADM requires further investigations and will be addressed in a future revision of this document.] Would it be possible instead to say: The impairments related to the link between remote optical transponders located in a different shelf from the ROADM itself, can also be modelled using the same optical impairments as those defined for a link between ROADMs (OMS).
in the scenario the external shelf can be considered as TE-node with termination capability only (not switching) the external shelf is under the control of the same controller as the ROADM
the external shelf is under the control of the same controller as the ROADM : the text is no more used . -AP: NAME to add specific issue to clarify how the link between external shelf and ROADM is discovered . No impact on this issue that we can consider as closed .
This is the "agreed" text , to be added in the draft in the next version upload (by IETF-113): "The impairments related to the link between remote optical transponders located in a different shelf from the ROADM itself, can also be modelled using the same optical impairments as those defined for a link between ROADMs (OMS). In the scenario the external shelf can be considered as TE-node with termination capability only (not switching)"
Let me suggest a couple of tweaks: "The impairments related to the link between remote optical transponders, located in a different node from the ROADM itself, can also be modeled using the same optical impairments as those defined for a link between ROADMs (OMS). In this scenario, the transponder-carrying node can be considered as TE-node with termination capability only (i.e. no switching)."
NAME : Thanks Julien for the suggested modifications, why at this point do not use the terminology proposed in issue ? "The impairments related to the link between remote optical transponders, located in a different WDM-TE-node from the ROADM itself, can also be modeled using the same optical impairments as those defined for a link between ROADMs (OMS). In this scenario, the transponder-carrying node can be considered as WDM-TE-node with termination capability only (i.e. no switching)."
NAME If we agree on the terms in , I concur: we MUST use them here.
Fixed by PR

A YANG Data Model for Optical Impairment-aware Topology  <ins> draft-ietf-ccamp-optical-impairment-topology-yang-09 </ins> Abstract Optical data plane interoperability is outside the scope of this draft.  <ins> This document augments the generic TE topology YANG model defined in RFC8795 where possible. </ins> This document defines one YANG module: ietf-optical-impairment- topology (sect-3) according to the new Network Management Datastore The terminology for describing YANG data models is found in RFC7950. <ins> The term ROADM in this document refers to the term "multi-degree reconfigurable optical add/drop multiplexer (MD-ROADM)" as defined in G.672.  It does not include local optical transponders, which can be co-located in the same physical device (managed entity). The term WDM-node refers to a physical device, which is managed as a single network element. The term WDM-TE-node refers to those parts of a WDM-node (physical device) that are modeled as a TE-node as defined in RFC8795, which may include a ROADM and/or multiple local optical transponders(OTs). Hence, a WDM-TE-node may only contain OTs. The term "WDM-TE-network" refers to a set of WDM-TE-nodes as defined above that are interconnected via TE-links carrying WDM signals. These TE-links may include optical amplifiers. </ins> 1.2. A simplified graphical representation of the data model is used in Figure-1 shows the control plane architecture.  <ins> The topology model developed in this document is an abstracted topology YANG model that can be used at the interfaces between the MDSC and the Optical Domain Controller (aka MPI) and between the Optical Domain Controller and the Optical Device (aka SBI) in Figure- 1.  It is not intended to support a detailed low-level DWDM interface model.  DWDM interface model is supported by the models presented in I-D.ietf-ccamp-dwdm-if-param-yang. </ins> 2.2.  <ins> This section provides the description of the optical transport network reference architecture and its relevant components to support optical impairment-aware path computation. </ins> Figure-2 shows the reference architecture.  <ins> BA (on the left side WDM-TE-node) is the engress Amplifier and PA (on the right side WDM-TE-node is the ingress amplifier for the OMS Media Channel Group (MCG) Figure-2. </ins> 2.3.  <ins> According to G.807 and G.872, an OTS Media Channel Group (MCG) represents a topological construct between two adjacent amplifiers, such as: According to G.807 and G.872, an OMS Media Channel Group (MCG) represents a topological construct between two WDM-TE-nodes. Specifically, it originates at the ROADM in the source WDM-TE-node and terminates at the ROADM in the destination WDM-TE-node including the Booster Amplifier (BA) and the Pre-Amplifier (PA) in the WDM-TE- nodes as well as the In-Line Amplifiers (ILAs) between the two WDM- TE-nodes. An OMS MCG can be decomposed into a sequence of OTS MCGs and amplifiers. An OMS MCG can be described as a sequence of elements such as BA, fiber section, ILA, PA, and concentrated loss wherever there is an insertion loss caused for example by a fiber connector. In TE-topology terms, the OMS MCG is modeled as a WDM TE-link interconnecting two WDM-TE-nodes.  A network controller can retrieve the optical impairment data for all the WDM TE-link elements defined in the layer-0 topology YANG model. The optical impairments related to the link between remote optical transponders, located in a different WDM-TE-node (an IP router with integrated optical transponders for example), can also be modeled as a WDM TE-link using the same optical impairments as those defined for a WDM TE-link between WDM-TE-nodes (OMS MCG).  In this scenario, the node containing the remote optical transponders can be considered as WDM-TE-node with termination capability only and no no switching capabilities. An OMS MCG is terminated on both ends by a link termination point (LTP) as defined in RFC8345.  Links in optical transport networks are typically bidirectional but have to be modeled as a pair of two unidirectional links following the RFC8345 modeling approach.  Unlike TE-links, which are unidirectional, the LTPs on either end of the TE- link pair forming the bidirectional link, are bidirectional as </ins> described in I-D.ietf-teas-te-topo-and-tunnel-modeling and the pair of unidirectional links are connected to the same bidirectional LTP on either end of the link pair.  <ins> [Editor's note: text below related to G.807 needs to be revised based on the published G.807 revision!] </ins> 2.3.1. carrier frequency, baud rate, and signal power for all existing OTSi signals on each OMS link.  <ins> Additionally, it is necessary for each WDM-TE-node in the network to know the OTSi signals that are added to or dropped from an WDM TE- link (OMS MCG)link as well as the optical power of these OTSi signals to check whether the WDM-TE-node's optical power constraints are met. </ins> The optical impairment-aware topology YANG model below defines the OTSi properties needed for optical impairment-aware path computation 2.3.3.  <ins> G.807 defines a "media channel" as "A media association that represents both the topology (i.e., the path through the media) and the resource (i.e., frequency slot or effective frequency slot) that it occupies."  In this document, the term "channel" is occasionally used to indicate the resource of an MC (i.e., frequency slot or effective frequency slot), without representing topology. </ins> The MC is an end-to-end topological network construct and can be considered as an "optical pipe" with a well-defined frequency slot 2.4.  <ins> Optical amplifiers are used in WDM networks for amplifying the optical signal in the optical domain without any optical to electrical and electrical to optical conversion.  There are three main optical amplifier technologies: Erbium Doped Fiber Amplifiers (EDFAs) Raman Amplifiers Semiconductor Optical Amplifiers (SOAs) In today's WDM networks EDFAs and Raman amplifiers are widely used. Raman amplifiers have become attractive due to their large spectral gain bandwidth, which can be quite flat, with similar or even lower noise figures compared to EDFAs.  On the other hand, Raman amplifiers consume more power and are usually more expensive than EDFAs. Raman amplifiers are distributed amplifiers where an optical pump signal is injected typically in opposite direction to the optical signal that is amplified (backward pump, counter-propagating pump light).  Injecting the optical pump signal in the same direction is also possible (forward pump, co-propagating pump light).  For optical amplifiers, the YANG model defines Raman pump light attributes describing the direction (raman-direction) with respect to the signal that is amplified and optical frequency and power for the pump light source(s) contained in the raman-pump list.  These Raman amplifier- specific attributes are optional as they are only applicable to Raman amplifiers.  For determining the optical amplifier type, i.e., to figure out whether an optical amplifier is a Raman amplifier, the type-variety attribute is used.  Due to the distributed nature of the Raman amplifier it is difficult to clearly separate the amplifier from the fiber span into which the pump signal is injected.  From a topology modeling perspective, the Raman amplifier is modeled as two OMS line elements: a passive fiber element accounting for the fiber loss only and not the resulting loss including the Raman gain an amplifier element providing all optical amplifier properties (gain, tilt, etc.).  On the OMS-link, the amplifier element is placed where the pump is located and the geolocation information also indicates the location of the pump. Amplifiers can be classified according to their location along the TE-link (OMS MCG).  There are three basic amplifier types: In-Line Amplifiers, Pre-Amplifiers and Booster Amplifiers.  ILAs are separate physical devices while Pre-Amplifiers and Booster Amplifiers are integral elements of a WDM-node.  From a data modeling perspective, node-internal details should not be modeled and should be abstracted as much as possible.  For Pre-Amplifiers and Booster Amplifiers, however, a different approach has been taken and they are modeled as TE-link elements as they have the same optical impairments as ILAs. </ins> ILAs are placed at locations where the optical amplification of the  <ins> WDM signal is required on the TE-link (OMS MCG) between two WDM-TE- nodes nodes.  Geolocation information is already defined for TE nodes in RFC8795 and is also beneficial for ILAs.  Therefore, the same geolocation container has been added to the amplifier element on an OMS link containing altitude, latitude, and longitude as optional attributes. </ins> One modeling consideration of the ROADM internal is to model power parameter through the ROADM, factoring the output power from the Pre- 2.9.  <ins> The WDM-node architectures in today's dense wavelength division </ins> multiplexing (DWDM) networks can be categorized as follows:  <ins> Integrated WDM-node architecture with local optical transponders </ins>  <ins> Integrated WDM-node architecture with local optical transponders </ins> and single channel add/drop ports for remote optical transponders  <ins> Disaggregated WDM-node architecture where the WDM-TE-node is composed of degree, add/drop, and optical transponder subsystems handled as separate WDM-nodes </ins> The TE topology YANG model augmentations including optical impairments for DWDM networks defined below intend to cover all the 3  <ins> categories of WDM-node architectures listed above.  In the case of a disaggregated WDM-node architecture, it is assumed that the optical domain controller already performs some form of abstraction and presents the WDM-TE-node representing the disaggregated WDM-node in the same way as an integrated WDM-TE-node with local optical transponders if the optical transponder subsystems and the add/drop subsystems are collocated (short fiber links not imposing any significant optical impairments). The different WDM-node architectures are briefly described and </ins> illustrated in the following subsections. [Editor's note: The modeling of remote optical transponders located for example in the client device with a single channel link between  <ins> the OT and the add/drop port of the WDM-TE-node requires further </ins> investigations and will be addressed in a future revision of this document.] 2.9.1. Figure-2 and Figure-6 below show the typical architecture of an  <ins> integrated WDM-node, which contains the optical transponders as an integral part of the WDM-node.  Such an integrated WDM-node provides DWDM interfaces as external interfaces for interconnecting the device with its neighboring WDM-node (see OMS MCG above).  The number of these interfaces denote also the degree of the WDM-node.  A degree 3 WDM-node for example has 3 DWDM links that interconnect the WDM-node with 3 neighboring WDM-nodes.  Additionally, the WDM-node provides client interfaces for interconnecting the WDM-node with client </ins> devices such as IP routers or Ethernet switches.  These client interfaces are the client interfaces of the integrated optical transponders. 2.9.2. Figure-7 below shows the extreme case where all optical transponders  <ins> are not integral parts of the WDM-node but are separate devices that are connected to the add/drop ports of the WDM-node.  If the optical transponders and the WDM-node are collocated and if short single channel fiber links are used to interconnect the optical transponders with an add/drop port of the WDM-node, the optical domain controller may present these optical transponders in the same way as local optical transponders.  If, however, the optical impairments of the single channel fiber link between the optical transponder and the add/drop port of the WDM-node cannot be neglected, it is necessary to represent the fiber link with its optical impairments in the topology model This also implies that the optical transponders belong to a separate TE-node </ins> [Editor's note: this requires further study]. 2.9.3.  <ins> Recently, some DWDM network operators started demanding WDM </ins> subsystems from their vendors.  An example is the OpenROADM project where multiple operators and vendors are developing related YANG  <ins> models.  The subsystems of a disaggregated WDM-TE-node are: Single degree subsystems Add/drop subsystems Optical transponder subsystems These subsystems are separate network elements and each network element provides a separate management and control interface.  The subsystems are typically interconnected using short fiber patch cables and form together a disaggregated WDM-TE-node.  This disaggregated WDM-TE-node architecture is depicted in Figure-8 below. </ins> As this document defines TE topology YANG model augmentations RFC8795 for the TE topology YANG model provided at the north-bound interface of the optical domain controller, it is a valid assumption that the optical domain controller abstracts the subsystems of a disaggregated  <ins> WDM-TE-node and presents the disaggregated WDM-TE-node in the same way as an integrated WDM-node hiding all the interconnects that are not relevant from an external TE topology view. </ins> 2.9.4. <ins> [Editor's note: the following text still needs to be updated based on the agreed terminology] </ins> When an optical OTSi signal traverses a ROADM node, optical impairments are imposed on the signal by various passive or active optical components inside the ROADM node.  Examples of optical


A YANG Data Model for Optical Impairment-aware Topology <del> draft-ietf-ccamp-optical-impairment-topology-yang-09 </del>  Abstract of unidirectional links are connected to the same bidirectional LTP on either end of the link pair. <del> [Editor's note: text below related to G.807 needs to be revised based on the published G.807 revision!] </del> 2.3.1. The OTSi is defined in ITU-T Recommendation G.959.1, section 3.2.4 defines a pointer (leafref) from the OTSi to the transceiver module terminating the OTSi signal.  2.3.2. <del> The definition of the OTSiG is currently being moved from ITU-T Recommendation G.709 G.709 to the new draft Recommendation G.807 (still work in progress) [G.807].  The OTSiG is an electrical signal that is carried by one or more OTSi's.  The relationship between the OTSiG and the the OTSi's is described in ITU-T draft Recommendation G.807, section 10.2 [G.807].  The YANG model below supports both cases: the single OTSi case where the OTSiG contains a single OTSi (see ITU-T draft Recommendation G.807, Figure 10-2) and the multiple OTSi case where the OTSiG consists of more than one OTSi (see ITU-T draft Recommendation G.807, Figure 10-3).  From a layer 0 topology YANG model perspective, the OTSiG is a logical construct that associates the OTSi's, which belong to the same OTSiG.  The typical application of an OTSiG consisting of more than one OTSi is inverse multiplexing.  Constraints exist for the OTSi's belonging to the same OTSiG such as: (i) all OTSi's must be co-routed over the same optical fibers and nodes and (ii) the differential delay between the different OTSi's may not exceed a certain limit.  Example: a 400Gbps client signal may be carried by 4 OTSi's where each OTSi carries 100Gbps of client traffic. </del>  2.3.3. The frequency slot of the MC is defined by the n value defining the central frequency of the MC and the m value that defines the width of <del> the MC following the flexible grid definition in ITU-T Recommendation G.694.1 G.694.1.  In this model, the effective frequency slot as defined in ITU-T draft Recommendation G.807 is equal to the frequency slot of this end-to-end MC.  It is also assumed that ROADM devices can switch MCs.  For various reasons (e.g.  differential delay), it is preferred to use a single MC for all OTSi's of the same OTSiG.  It may however not always be possible to find a single MC for carrying all OTSi's of an OTSiG due to spectrum occupation along the OTSiG path. </del>  2.3.4. entity like the LTP described above.  Moreover, a TTP can terminate one or several OTSiG signals (tunnels) as described in I-D.ietf-teas- te-topo-and-tunnel-modeling and each OTSiG consists of one or <del> multiple OTSi signals as described in sect-2.3.2.  Therefore, a TTP may be associated with multiple transceiver modules. </del>  A transponder is typically characterized by its data/symbol rate and the maximum distance the signal can travel.  Other transponder Supported transmitter tuning range with min/max nominal carrier frequency [f_tx_min, f_tx_max] <del> Supported transmitter tunability grid, the distance between two adjacent carrier frequencies (in GHz) </del>  Supported transmitter power range [p_tx-min, p_tx_max] Supported receiver channel power range [p_rx-min, p_rx_max] Supported maximum total power, rx power for all channels fed into regeneration and each transceiver is operated in an uni- directional mode.  Due to the fact that 3R regenerators are composed of an optical transponder pair, the capabilitiy whether an optical transponder can be used as a 3R regenerator is is added to the transponder [Editor's note: this section is still work in progress]  3. [Editor's note: tree view below always has to be updated before

draft-ietf-ccamp-optical-impairment-topology-URL for IETF 114 submission --> draft-ietf-ccamp-optical-impairment-topology-yang-URL Related to pull request . Addressing and resolving several open issues.
May need to rebase this branch with the master branch to make sure all the validation checks pass

A YANG Data Model for Optical Impairment-aware Topology  <ins> draft-ietf-ccamp-optical-impairment-topology-yang-10 </ins> Abstract of unidirectional links are connected to the same bidirectional LTP on either end of the link pair.  2.3.1. The OTSi is defined in ITU-T Recommendation G.959.1, section 3.2.4 defines a pointer (leafref) from the OTSi to the transceiver module terminating the OTSi signal. <ins> The OTSi signals in the YANG model are described by augmenting the network and each OTSi signal is uniquely identified by its otsi- carrier-id, which is unique within the scope the OTSiG [see OTSiG below] the OTSi belongs to. </ins> 2.3.2.  <ins> The OTSiG is defined in ITU-T Recommendation G.807 G.807 as a "set of optical tributary signals (OTSi) that supports a single digital client".  Hence, the OTSiG is an electrical signal that is carried by one or more OTSi's.  The relationship between the OTSiG and the the OTSi's is described in G.807, section 10.2.  The YANG model below supports both cases: the single OTSi case where the OTSiG contains a single OTSi (see G.807, Figure 10-2) and the multiple OTSi case where the OTSiG consists of more than one OTSi (see G.807, Figure 10-3). From a layer 0 topology YANG model perspective, the OTSiG is a logical construct that associates the OTSi's, which belong to the same OTSiG.  The typical application of an OTSiG consisting of more than one OTSi is inverse multiplexing.  Constraints exist for the OTSi's belonging to the same OTSiG such as: (i) all OTSi's must be co-routed over the same optical fibers and nodes and (ii) the differential delay between the different OTSi's may not exceed a certain limit.  Example: a 400Gbps client signal may be carried by 4 OTSi's where each OTSi carries 100Gbps of client traffic. All OTSiGs are described in the YANG model by augmenting the network and each OTSiG is uniquely identified by its otsi-group-id, which is unique within the network.  Each OTSiG also contains a list of the OTSi signals belonging to the OTSiG. </ins> 2.3.3. The frequency slot of the MC is defined by the n value defining the central frequency of the MC and the m value that defines the width of  <ins> the MC following the flexible grid definition in G.694.1.  In this model, the effective frequency slot as defined in G.807 is equal to the frequency slot of this end-to-end MC.  It is also assumed that ROADM devices can switch MCs.  For various reasons (e.g. differential delay), it is preferred to use a single MC for all OTSi's of the same OTSiG.  It may however not always be possible to find a single MC for carrying all OTSi's of an OTSiG due to spectrum occupation along the OTSiG path. </ins> 2.3.4. entity like the LTP described above.  Moreover, a TTP can terminate one or several OTSiG signals (tunnels) as described in I-D.ietf-teas- te-topo-and-tunnel-modeling and each OTSiG consists of one or  <ins> multiple OTSi signals as described in OTSiG.  Therefore, a TTP may be associated with multiple transceiver modules. </ins> A transponder is typically characterized by its data/symbol rate and the maximum distance the signal can travel.  Other transponder Supported transmitter tuning range with min/max nominal carrier frequency [f_tx_min, f_tx_max]  <ins> Supported transmitter tunability describing the transmitter's frequency fine tuning steps (the minimum distance between two adjacent carrier frequencies in GHz) </ins> Supported transmitter power range [p_tx-min, p_tx_max] Supported receiver channel power range [p_rx-min, p_rx_max] Supported maximum total power, rx power for all channels fed into regeneration and each transceiver is operated in an uni- directional mode. <ins> Implemantations may support the change of the carrier frequency where the receiver may operate at a different optical frequency as the transmitter.  The transceiver mode is a property of the transceiver and is applied to the transmitter and the receiver. Therefore, the transceiver mode is the same for the two segments on the two sides of the 3R regenaretor realised by two transceivers operated in the uni-directional mode. </ins> Due to the fact that 3R regenerators are composed of an optical transponder pair, the capabilitiy whether an optical transponder can be used as a 3R regenerator is is added to the transponder [Editor's note: this section is still work in progress] <ins> 2.10. The YANG model defined in this document supports the following protection architectures: Individual OTSi protection OMS MCG protection = TE-link protection between adjacent WDM-TE- nodes [Editor's note: this section is still work in progress] 2.10.1. Individual OTSi protection is a protection architecture where an individual OTSi signal is protected as defined in Appendix III of ITU-T Recommendation G.873.1 G.873.1.  This protection architecture 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). In case of individual OTSi protection, there are two network media channel paths associated with the OTSi signal.  In the YANG model, this is modeled as a leaf list of the otsi providing the nmc-path-id for the two network media channel paths associated with the individually protected otsi. [Editor's note: this section is still work in progress] 2.10.2. OMS MCG protection is a protection architecture where a TE-link between two adjacent WDM-TE-nodes is protected.  This is a local protection scheme, which can be modeled as a TE-link property. [Editor's note: this section is still work in progress] </ins> 3. [Editor's note: tree view below always has to be updated before