The configuration agent selects a length for the server ID encoding. This length MUST have enough entropy to have a different code point <del> for each server. </del>  It also assigns a server ID to each server. The configuration agent also selects a nonce length and an 16-octet AES-ECB key to use for connection ID decryption.  The nonce length MUST be at least 8 octets and no more than 16 octets.  The nonce <del> length and server ID length MUST sum to 19 or fewer octets. </del>  4.3.2. The server ID will start in the second octet of the decrypted connection ID and occupy continuous octets beyond that. <del> They server ID length MUST be no more than 16 octets and SHOULD be no more than 12 octets, to provide servers adequate space to encode their own opaque data. </del>  The configuration agent also selects an 16-octet AES-ECB key to use for connection ID decryption. connection ID length between 17 and 20 octets.  The server writes its provided server ID into the server ID octets and arbitrary bits into the remaining bits.  These arbitrary bits MAY encode additional <del> information, and MUST differ between connection IDs.  Bits in the eighteenth, nineteenth, and twentieth octets SHOULD appear essentially random to observers.  The first octet is reserved as described in first-octet. </del>  The server then encrypts the second through seventeenth octets using the 128-bit AES-ECB cipher. 10.6.  The Shared-State Retry Service defined in shared-state-retry describes the format of retry tokens or new tokens protected and encrypted using AES128-GCM.  Each token includes a 96 bit randomly In order to protect against collisions, the 96 bit unique token numbers should be generated using a cryptographically secure pseudorandom number generator (CSPRNG), as specified in Appendix C.1 <del> of the TLS 1.3 specificationRFC8446.  With proper random numbers, if </del>  fewer than 2^40 tokens are generated with a single key, the risk of collisions is lower than 0.001%.

Make sure each algorithm always provides 2-3 octets for server use. The current SID limits don't do that.

The configuration agent selects a length for the server ID encoding. This length MUST have enough entropy to have a different code point  <ins> for each server.  The length MUST be no more than 15 octets to provide sufficient entropy for server use. </ins> It also assigns a server ID to each server. The configuration agent also selects a nonce length and an 16-octet AES-ECB key to use for connection ID decryption.  The nonce length MUST be at least 8 octets and no more than 16 octets.  The nonce  <ins> length and server ID length MUST sum to 19 or fewer octets, but SHOULD sum to 15 or fewer to allow space for server use. </ins> 4.3.2. The server ID will start in the second octet of the decrypted connection ID and occupy continuous octets beyond that.  <ins> The server ID length MUST be no more than 12 octets, to provide adequate entropy in the encrypted block. </ins> The configuration agent also selects an 16-octet AES-ECB key to use for connection ID decryption. connection ID length between 17 and 20 octets.  The server writes its provided server ID into the server ID octets and arbitrary bits into the remaining bits.  These arbitrary bits MAY encode additional  <ins> information, and MUST differ between connection IDs.  The encrypted arbitrary bits MUST be unique for each CID the server generates; the easiest way to do so is to start the nonce at zero and simply increment by one for each CID. Bits in the eighteenth, nineteenth, and twentieth octets SHOULD appear essentially random to observers.  The first octet is reserved as described in first-octet. </ins> The server then encrypts the second through seventeenth octets using the 128-bit AES-ECB cipher. 10.6. <ins> The Stream Cipher and Block Cipher algorithms need to generate different cipher text for each generated Connection ID instance to protect the Server ID.  To do so, at least four octets of the Block Cipher CID and at least eight octets of the Stream Cipher CID are reserved for a nonce that, if used only once, will result in unique cipher text for each Connection ID. If servers simply increment the nonce by one with each generated connection ID, then it is safe to use the existing keys until any server's nonce counter exhausts the allocated space and rolls over to zero.  Whether or not it implements this method, the server MUST NOT reuse a nonce until it switches to a configuration with new keys. Configuration agents SHOULD implement an out-of-band method to discover when servers are in danger of exhausting their nonce space, and SHOULD respond by issuing a new configuration.  A server that has exhausted its nonces MUST either switch to a different configuration, or if none exists, use the 4-tuple routing config rotation codepoint. 10.7. </ins> The Shared-State Retry Service defined in shared-state-retry describes the format of retry tokens or new tokens protected and encrypted using AES128-GCM.  Each token includes a 96 bit randomly In order to protect against collisions, the 96 bit unique token numbers should be generated using a cryptographically secure pseudorandom number generator (CSPRNG), as specified in Appendix C.1  <ins> of the TLS 1.3 specification RFC8446.  With proper random numbers, if </ins> fewer than 2^40 tokens are generated with a single key, the risk of collisions is lower than 0.001%.


These client-generated CIDs might not conform to the expectations of the routing algorithm and therefore not be routable by the load <del> balancer.  These are called "non-compliant DCIDs": </del>  The config rotation bits (config-rotation) may not correspond to an active configuration.  Note: a packet with a DCID that Load balancers MUST forward packets with compliant DCIDs to a server in accordance with the chosen routing algorithm. <del> Load balancers SHOULD drop packets with non-compliant DCIDs in a short header. </del>  The routing of long headers with non-compliant DCIDs depends on the server ID allocation strategy, described in sid-allocation.  However, version-invariant properties of QUIC described in QUIC-INVARIANTS to maximize its robustness to future versions of QUIC. <del> An arbitrary algorithmr MUST NOT make the routing behavior dependent </del>  on any bits in the first octet of the QUIC packet header, except the first bit, which indicates a long header.  All other bits are QUIC <del> version-dependent and intermediaries should not base their design on </del>  version-specific templates. For example, one arbitrary algorithm might convert a non-compliant The corresponding server configurations contain one or more unique server IDs. <del> A dynamically allocated configuration does not include any bespoke </del>  assignment, reducing configuration complexity.  However, it places limits on the maximum server ID length and requires more state at the load balancer.  In certain edge cases, it can force parts of the 4.3.1. <del> In the manual allocation method, the configuration agent assigns at </del>  least one server ID to each server. When forwarding a packet with a long header and non-compliant DCID, 4.3.2. In the dynamic allocation method, the load balancer assigns server <del> IDs dynamically so that configuration does not require bespoke server ID assignment.  This also reduces linkability.  However, it requires state at the load balancer that roughly scales with the number of </del>  connections, until the server ID codespace is exhausted. 4.3.2.1.

Here are some suggestions from my first pass, but overall I think the static vs dynamic server ID allocation idea works nicely. 2 Q's: Is the definition of non-compliant different at LB and server in some cases? Might non-routable be a better term than non-compliant?
Yes, they can be different because the perception of the configuration is different. In general, during configuration updates the LB will have a configs that some servers don't. Therefore, a DCID with those CR bits will be compliant at the LB and non-compliant at the server. With static allocation, servers don't do anything with non-compliant DCIDs, so this is irrelevant. With dynamic allocation, it means that the LB will allocate an SID that the server doesn't know anything about, until: 1) the allocation times out 2) the LB has the occasion to forward another packet with that SID to the server when the server has the configuration. I don't feel strongly about this, but it works for me. If you want to file a PR with this change I'd approve it.
In PR I suggested non-routable, though I realize non-conformant may also be an option. The sentence which caused me to suggest non-routable is: URL I'm happy to write a PR if others find non-compliant potentially confusing as well.
I like it. Let's go with it.

These client-generated CIDs might not conform to the expectations of the routing algorithm and therefore not be routable by the load  <ins> balancer.  Those that are not routable are "non-compliant DCIDs" and receive similar treatment regardless of why they're non-compliant: </ins> The config rotation bits (config-rotation) may not correspond to an active configuration.  Note: a packet with a DCID that Load balancers MUST forward packets with compliant DCIDs to a server in accordance with the chosen routing algorithm.  <ins> Load balancers SHOULD drop short header packets with non-compliant DCIDs. </ins> The routing of long headers with non-compliant DCIDs depends on the server ID allocation strategy, described in sid-allocation.  However, version-invariant properties of QUIC described in QUIC-INVARIANTS to maximize its robustness to future versions of QUIC.  <ins> An arbitrary algorithm MUST NOT make the routing behavior dependent </ins> on any bits in the first octet of the QUIC packet header, except the first bit, which indicates a long header.  All other bits are QUIC  <ins> version-dependent and intermediaries SHOULD NOT base their design on </ins> version-specific templates. For example, one arbitrary algorithm might convert a non-compliant The corresponding server configurations contain one or more unique server IDs.  <ins> A dynamically allocated configuration does not have a pre-defined </ins> assignment, reducing configuration complexity.  However, it places limits on the maximum server ID length and requires more state at the load balancer.  In certain edge cases, it can force parts of the 4.3.1.  <ins> In the static allocation method, the configuration agent assigns at </ins> least one server ID to each server. When forwarding a packet with a long header and non-compliant DCID, 4.3.2. In the dynamic allocation method, the load balancer assigns server  <ins> IDs dynamically so that configuration does not require fixed server ID assignment.  This reduces linkability.  However, it requires state at the load balancer that roughly scales with the number of </ins> connections, until the server ID codespace is exhausted. 4.3.2.1.


imposes other operational constraints.  The other requires a shared key, but has no such constraints. <del> Retry services MUST forward all QUIC packets that are not of type Initial or 0-RTT.  Other packet types might involve changed IP addresses or connection IDs, so it is not practical for Retry Services to identify such packets as valid or invalid. </del> 7.1. Regardless of mechanism, a retry service has an active mode, where it require different information in Retry, or use different packet type indicators.  7.2. The no-shared-state retry service requires no coordination, except

In Section 7: "Retry services MUST forward all QUIC packets that are not of type Initial or 0-RTT. Other packet types might involve changed IP addresses or connection IDs, so it is not practical for Retry Services to identify such packets as valid or invalid." MUST is too strong. If it keeps any state (i.e. tracking 4-tuples) it can drop non-initial packets. (However, this would make migration not work). If the Retry Service is in front of a QUIC-LB load balancer, the LB will drop random 1-RTT packets but not Handshake and 0-RTT unless it is version-aware, so passing 1-RTT is "safe." If the Retry Service is behind the load balancer, which is probably better because LBs are often NATs, then random 1-RTT is already dropped and it is safe to forward 1-RTT to preserve migration. If there's a non QUIC-LB load balancers, migration doesn't work anyway; might as well drop it. If it's a single server and the CIDs are random, admitting 1-RTT is weakening the DoS defense. And then there is the issue with QUIC versions and admitting/dropping them, which is hard to adjudicate with short headers.
I don't know. Do you have a case where Retry services should not forward those packets? I don't want this to be a source of ossification because of a possibly incorrect assumption about placement of the retry service in the pipeline.
Well, the reason to not forward them is to block DDoS vectors. A garbage Handshake or 1-RTT packets is at least easily discarded by the server without much in the way of processing. I would actually appreciate some input from your Azure contacts about this; is filtering non-SYN packets important today?
Here's the data I can provide: As I understand it, the DDoS would be in front of the LB. It's all in hardware so it's update cycle could be very long, so any logic added there could effectively be written in stone for many years. So, I really want to be careful about any assumptions here. If we get it wrong for a future version, either all of Azure might end up breaking/preventing future versions/features or we'd have to completely disable and lose the protection. On the topic of dropping garbage/invalid packets, I'd be Ok with that. Perhaps we could change the text to the following? This adds some wiggle room for what is considered "valid" or not. Obviously if the header is garbage it can be tossed. If a device knows a particular CID is invalid, then it could drop it. I'd just strongly caution any "smarts" here because of the possibility of changes in the future.
If "in front of the LB" is cancnical use case, I can shade the language towards that. However, this makes me wonder about the shared-state case. My perception is that combining a NAT with an LB is quite common; will shared token verification work if the server and retry service are seeing different client IP addresses? This calls into question the entire shared-state concept.

imposes other operational constraints.  The other requires a shared key, but has no such constraints.  7.1. Regardless of mechanism, a retry service has an active mode, where it require different information in Retry, or use different packet type indicators. <ins> 7.1.1. Initial Packets are especially effective at consuming server resources because they cause the server to create connection state. Even when mitigating this load with Retry Packets, the act of validating an Initial Token and sending a Retry Packet is more expensive than the response to a non-Initial packet with an unknown Connection ID: simply dropping it and/or sending a Stateless Reset. Nevertheless, a Retry Service in Active Mode might desire to shield servers from non-Initial packets that do not correspond to a previously admitted Initial Packet.  This has a number of considerations. If a Retry Service maintains no per-flow state whatsoever, it cannot distinguish between valid and invalid non_Initial packets and MUST forward all non-Initial Packets to the server. For QUIC versions the Retry Service does not support and are present on the Allow-List (or absent from the Deny-List), the Retry Service cannot distinguish Initial Packets from other long headers and therefore MUST admit all long headers. If a Retry Service keeps per-flow state, it can identify 4-tuples that have been previously approved, admit non-Initial packets from those flows, and drop all others.  However, dropping short headers will effectively break Address Migration and NAT Rebinding when in Active Mode, as post-migration packets will arrive with a previously unknown 4-tuple.  This policy will also break connection attempts using any new QUIC versions that begin connections with a short header. If a Retry Service is integrated with a QUIC-LB compliant load balancer, it can verify that the Destination Connection ID is compliant, and only admit non-Initial packets with compliant DCIDs.  As the Connection ID encoding is invariant across QUIC versions, the Retry Service can do this for all short headers. Nothing in this section prevents Retry Services from making basic syntax correctness checks on packets with QUIC versions that it understands (e.g., enforcing the Initial Packet datagram size minimum in version 1) and dropping packets that are not compliant with the QUIC specification. </ins> 7.2. The no-shared-state retry service requires no coordination, except


BGP (I-D.ietf-idr-bgp-model) <del> PIM (I-D.liu-pim-yang) </del>  NAT management (RFC8512)

PIM ([I-D.liu-pim-yang]) is outadated
see
URL
Closed with commit

BGP (I-D.ietf-idr-bgp-model)  <ins> PIM (I-D.ietf-pim-yang) </ins> NAT management (RFC8512)


reused by other VPN-related YANG modules (e.g., L3NM, L3SM, Layer 2 Network Model): "ietf-vpn-common".  2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

as per a suggestion from the yangdoctor:
Yang doctor review in: URL URL Reviewer: Radek Krejčí Review result: Ready with Issues The I-D document contains a single YANG module ietf-l3vpn-ntw. The module is quite complex, but despite I'm not an expert in the area, the text of the draft seems very descriptive and helpful to understand all the parts of the module tree. From my perspective, the most problematic part of the module is the overall use of groupings and the current status of their specification in the module. Here are the specific issues: the module seems NMDA compliant, so it should be mentioned in Introduction (or some other) section: The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. the filename's revision part does not match the latest revision date (2020-04-03) of the module: file "EMAIL" all the imported modules must have their document (RFC) in the normative references section, but RFC 6991, RFC 8294, RFC 8299 and RFC 8519 are missing. since RFC 8277 is referenced in the module, it should appear in the normative references section. additional indentation (3 spaces on each line except the first one) in the module's contact statement seems weird and unnecessary/unintentional. some of the descriptions in the module use RFC 2119 key words, so the module's description is supposed to contain the following text: The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. typedef protocol-type; Are you really sure that the list of the underlying protocols is fixed forever in all its instances? Having it in the form of identity would allow later augmenting of the list of possible values. the whole groupings part need a cleanup and maybe some structural changes: most of the groupings are instantiated only once - having them defined this way makes sense only in case you believe they are useful for other modules to use. Splitting a complex module into groupings just for keeping its parts separated IMO decreases the readability and usability of the module - it is quite challenging to find a specific path or subtree because of intensive skipping from grouping to another. - there are also groupings that are not instantiated at all, if they are intended exclusively for use by other modules, I would prefer to have some note about it in their descriptions. - there are several comment out uses statements, there is also whole / UNUSED / part description of the service-status grouping seems to be invaliddescriptions of {grouping site-bearer-params}/site-bearers/bearer/bearer-id and {grouping vpn-route-targets}/vpn-polices nodes are empty I'm afraid about the usability of appendix A. The status of the implementations will tent to change quite intensively and having such information in RFC does not make much sense to me.
Editorial issues to be taken by Oscar. typedeft to identityref issue now separate issue Review of the grouping for a second round after the creation of the new module with the types For the implmentation section, see guidelines in RFC 7942 for the boilerplate text to add.
URL d125e87e6cedff5343eb8dc356ca769ccd38a207
For this one, I don't think we need to cite it as normative as RFC8407 says the following: If the reference statement identifies an informative reference that identifies a separate document, a corresponding informative reference to that document MAY appear in the Informative References section.
I think that all yangdoctor's issues are now addressed.
All issues solved in the latest yang version Reviewer: Radek Krejčí Review result: Ready with Issues The I-D document contains a single YANG module ietf-l3vpn-ntw. The module is quite complex, but despite I'm not an expert in the area, the text of the draft seems very descriptive and helpful to understand all the parts of the module tree. From my perspective, the most problematic part of the module is the overall use of groupings and the current status of their specification in the module. Here are the specific issues: the module seems NMDA compliant, so it should be mentioned in Introduction (or some other) section: The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. the filename's revision part does not match the latest revision date (2020-04-03) of the module: file "EMAIL" all the imported modules must have their document (RFC) in the normative references section, but RFC 6991, RFC 8294, RFC 8299 and RFC 8519 are missing. since RFC 8277 is referenced in the module, it should appear in the normative references section. additional indentation (3 spaces on each line except the first one) in the module's contact statement seems weird and unnecessary/unintentional. some of the descriptions in the module use RFC 2119 key words, so the module's description is supposed to contain the following text: The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. typedef protocol-type; Are you really sure that the list of the underlying protocols is fixed forever in all its instances? Having it in the form of identity would allow later augmenting of the list of possible values. the whole groupings part need a cleanup and maybe some structural changes: most of the groupings are instantiated only once - having them defined this way makes sense only in case you believe they are useful for other modules to use. Splitting a complex module into groupings just for keeping its parts separated IMO decreases the readability and usability of the module - it is quite challenging to find a specific path or subtree because of intensive skipping from grouping to another. - there are also groupings that are not instantiated at all, if they are intended exclusively for use by other modules, I would prefer to have some note about it in their descriptions. - there are several comment out uses statements, there is also whole / UNUSED / part description of the service-status grouping seems to be invaliddescriptions of {grouping site-bearer-params}/site-bearers/bearer/bearer-id and {grouping vpn-route-targets}/vpn-polices nodes are empty I'm afraid about the usability of appendix A. The status of the implementations will tent to change quite intensively and having such information in RFC does not make much sense to me.

reused by other VPN-related YANG modules (e.g., L3NM, L3SM, Layer 2 Network Model): "ietf-vpn-common". <ins> The YANG data models defined in this document conform to the Network Management Datastore Architecture (NMDA) RFC8342. </ins> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",


reused by other VPN-related YANG modules (e.g., L3NM, L3SM, Layer 2 Network Model): "ietf-vpn-common". <del> The YANG data models defined in this document conform to the Network Management Datastore Architecture (NMDA) RFC8342. </del> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Error: Unable to parse the XML document: draft-ietf-opsawg-l3sm-l3nm-URL : Line 4822: Entity 'RFC6991' not defined : Line 4823: Entity 'RFC8294' not defined : Line 4867: Entity 'RFC8277' not defined The command "xml2rfc draft-ietf-opsawg-l3sm-l3nm-URL" exited with 1. can you update?

reused by other VPN-related YANG modules (e.g., L3NM, L3SM, Layer 2 Network Model): "ietf-vpn-common".  2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",


between the administrative status vs. the operational status can be used as a trigger to detect anomalies. <del> Represents the point to which sites are connected. Note that, unlike in L2SM, the L2NM does not need to model the customer site, only the points where the traffic from the site are received (i.e., the PE side of PE-CE connections).  Hence, the VPN network access contains the connectivity information between the provider's network and the customer premises.  The VPN profiles ('vpn-profiles') have a set of routing policies that can be applied during the service creation. See sna for more details. 6.3.2.1. This sub-tree defines the L2VPN service type, according to the several signalling options to exchange membership information between PEs of an L2VPN.  The following signaling options are supported: Refers to the BGP control plane as described in RFC4761 and RFC6624. Refers to the BGP control plane as described in RFC7432 and RFC7209. Refers to LDP-signaled pseudowires RFC6074. Refers to L2TP-signaled pseudowires RFC6074. 6.3.2.2. A 'vpn-network-access' represents an entry point to a VPN service . In other words, this container encloses the parameters that describe the access information for the traffic that belongs to a particular L2VPN.  As such, every 'vpn-network-access' MUST belong to one and only one 'vpn-node'. A 'vpn-network-access' includes information such as the connection on which the access is defined , the specific layer 2 service requirements, etc. The VPN network access is comprised of: Identifier of the VPN network access. Text describing the VPN network access. Administrative and operational status of the service. Carries information about the service OAM. 6.3.2.2.1. The connection container is used to configure the relevant properties of the interface that is attached to the VPN, for example the encapsulation type, the physical interface or creating a lag. 6.3.2.2.2. This container is used to indicate the details of the ethernet service such as bandwidth or qos. </del> 7. 8.

We created a placeholder for items that seem to overlap. reconsider if access-diversity makes sense in the l2nm.
Certainly ethernet-segment-identifier is needed somewhere. But it could go directly under vpn-network-access. I don't think we need group-id and constraints in the l2nm, do you know a use-case for it?
Update Ethernet segment identifier to cover explicit generated and auto-asign according to the rules of section 5 of RFC 7432
Include DF election method (see draft-ietf-bess-evpn-pref-df-06)
This part of the module makes sense in the service module as it may impact how to attach a site. at the network level, these constraints are supposed to be taken into account (selection of PE, interfaces, etc.). I suggest we remove this from the L2NM.
This part is redundant with "esi-redundancy-mode" for the evpn case.
I lost the context about these two. What is the purpose of these two and how this is used to infer the underlying config?
The description refers to primary and secondary "L2VPN". That's vague.
The use case for the precedence is the following: ! The group-id combined with the precedence serves to model the primary and backup on the same vpn-node. So we agree to improve the description of the Leaf and Identities to reflect the use case usage and make it more clear. The figure for the usage must be inlcuded in the draft NAME

between the administrative status vs. the operational status can be used as a trigger to detect anomalies.  7. 8.


Relies upon application-specific classification. Groups a set of parameters that are used when CsC is enabled such <del> the use of BGP for signalling purposes RFC8277. </del>  Time synchronization may be needed in some VPNs such as infrastructure and management VPNs.  This container is used to

The term was used with signalling and signaling. I modified it to signaling, so it is aligned with L2NM as well

Relies upon application-specific classification. Groups a set of parameters that are used when CsC is enabled such  <ins> the use of BGP for signaling purposes RFC8277. </ins> Time synchronization may be needed in some VPNs such as infrastructure and management VPNs.  This container is used to


Abstract <del> This document defines a L2VPN Network YANG Model (L2NM) that can be </del>  used to manage the provisioning of Layer 2 Virtual Private Network (VPN) services within a network (e.g., service provider network). The L2NM complements the Layer 2 Service Model (L2SM) by providing a Refers to the YANG module that describes an L2VPN service with a network-centric view.  It contains information of the service <del> providers network and might include allocated resources.  Network </del>  controllers can use it to manage the Layer 2 VPN service configuration in the service providers network.  The YANG module can be consumed by a service orchestrator to request a VPN service controller. Denotes a functional entity responsible for the management of the <del> service providers network. </del>  Is an abstraction that represents a set of policies applied on a PE and that belong to a single VPN service.  A VPN service Is an abstraction that represents the network interfaces that are associated to a given VPN node.  Traffic coming from the VPN network access belongs to the VPN.  The attachment circuits <del> (bearers) between Customer Edges (CEs) and PEs are terminated in the VPN network access. </del>  Is a service providers that offers L2VPN-related services. related L2VPN types.  More details are provided in es. The 'vpn-services' container maintains the set of L2VPN services <del> managed in the service providers network.  The module allows to </del>  create a new L2VPN service by adding a new instance of 'vpn-service'. The 'vpn-service' is the data structure that abstracts the VPN service (l2_vpn_service). For the particular case of EVPN, the L2NM supports RT auto-derivation based on the Ethernet Tag ID specified in Section 7.10.1 of RFC7432. A VPN service provider can enable/disable this functionality by means <del> of 'auto-rt-enable'.  The asigned RT can be retrieved using 'auto- </del>  route-target'. For all BGP-based L2VPN flavors, other data nodes such as RD and RT

Abstract s/This document defines a L2VPN/This document defines an L2VPN/ Section 2 s/contains information of the service providers/contains information of the service provider’s/ s/management of the service providers network/management of the service provider’s network/ s/Is a service providers that offers/Is a service provider that offers/ …between Customer Edges (CEs) and PEs… You expand CE but never PE (until the acronym section). I thought it might be good for maximum clarity to outright define CE and PE in your terminology section. Section 6.1 s/managed in the service providers network/managed in the service provider’s network/ Section 6.5 s/Global parameters profile are defined/Global parameters profiles are defined/ You misspelled ce-vlan-cos-preservation here and in the YANG module below. Since this is a leaf, it really should have correct spelling. Section 6.6.1 s/The asigned RT can be/The assigned RT can be/ Section 6.6.2 s/Address Resolution Protocol (ARP) and Nighbour Discovery (ND)/ Address Resolution Protocol (ARP) and Neighbor Discovery (ND)/ On this, should you have a reference for ARP and ND? Section 6.7.1 You mention LAG and LACP here and below in the module. But I never see a reference or expansion for either. I think both the text and the module would benefit from both. Section 6.7.4 s/they take precendence over the one inlcudes/they take precedence over the one includes/ In your two IANA modules you have identities for PPP and VPLS and a couple of others where the description is the identity name itself. This is where I wonder if slightly better descriptions would add more clarity. At least expanding the acronym would be useful IMHO. YANG module s/The RObust Header Compression (ROHC) Framework/The Robust Header Compression (ROHC) Framework/ YANG module Concerning identity “precedence-type”: First, you misspelled “backup”. You say active and backup here, but you use primary and backup below. I typically see primary with secondary and active with backup. Either way, I think you need to be consistent. Also, since the base identity mentions the two defined sub-identities, should this really be an enumeration? Or should you just simplify this description so as not to mention any possible sub-identities? YANG module s/Indicates whether BGP auto-discovey/Indicates whether BGP auto-discovery/ s/Sets the indentifier of the VPN node/Sets the identifier of the VPN node/ s/contex of a VPN/context of a VPN/ s/Controles/Controls/g s/symetric/symmetric/ s/automatically assigned either withor/automatically assigned either with or/ s/maixmum/maximum/g YANG module Concerning leaf group-color: Okay, dumb question. What does a string for color provide here? While I’ve seen the concept of color used a lot in VPN examples, a free-form string that should be a color seems over-done here. The group-id is another open string. Why couldn’t that also be a color? I’d love to see some canonical reference that explains color use (if there is one). YANG module Concerning the number of different MTU-related leafs: The PW interface MTU is limited to 16-bits. Does it make sense to have a 32-bit service MTU here, then? Other than the pw-mtu, the other MTU leafs are all 32-bit, and I wonder if they shouldn’t all be 16. YANG module Concerning leaf color-type: Here is another use of color, but this time at least tied to an identity. Why couldn’t the other use also use this identity?
Thanks for taking care of the comments. Please see below some edits

Abstract  <ins> This document defines an L2VPN Network YANG Model (L2NM) that can be </ins> used to manage the provisioning of Layer 2 Virtual Private Network (VPN) services within a network (e.g., service provider network). The L2NM complements the Layer 2 Service Model (L2SM) by providing a Refers to the YANG module that describes an L2VPN service with a network-centric view.  It contains information of the service  <ins> provider's network and might include allocated resources.  Network </ins> controllers can use it to manage the Layer 2 VPN service configuration in the service providers network.  The YANG module can be consumed by a service orchestrator to request a VPN service controller. Denotes a functional entity responsible for the management of the  <ins> service provider's network. </ins> Is an abstraction that represents a set of policies applied on a PE and that belong to a single VPN service.  A VPN service Is an abstraction that represents the network interfaces that are associated to a given VPN node.  Traffic coming from the VPN network access belongs to the VPN.  The attachment circuits  <ins> (bearers) between Customer Edges (CEs) and Provider Edges (PEs) are terminated in the VPN network access. </ins> Is a service providers that offers L2VPN-related services. related L2VPN types.  More details are provided in es. The 'vpn-services' container maintains the set of L2VPN services  <ins> managed in the service provider's network.  The module allows to </ins> create a new L2VPN service by adding a new instance of 'vpn-service'. The 'vpn-service' is the data structure that abstracts the VPN service (l2_vpn_service). For the particular case of EVPN, the L2NM supports RT auto-derivation based on the Ethernet Tag ID specified in Section 7.10.1 of RFC7432. A VPN service provider can enable/disable this functionality by means  <ins> of 'auto-rt-enable'.  The assigned RT can be retrieved using 'auto- </ins> route-target'. For all BGP-based L2VPN flavors, other data nodes such as RD and RT


orchestrator in the L3NM (e.g., customer) or be used to feed some L3NM attributes (e.g., actual forwarding policies).  Also, some information captured in the L3SM may be maintained locally within the <del> orchestrator; which is in charge of maintaining the correspondence </del>  between a customer view and its network instantiation.  Likewise, some information captured and exposed using the L3NM can feed the service layer (e.g., capabilities) to drive VPN service order automated VPN service provisioning and delivery. An L3VPN involves nodes that are part of a topology managed by the <del> service provider network.  Such topology can be represented using the network topology module in RFC8345. </del>  L3NM is not a device model. will still be required. A common function that is supported by VPNs is the addition or <del> removal of customer sites.  Workflows can use the L3NM in these scenarios to add or prune nodes from the network data model as required. </del>  6.2. allocation can be performed by that management system.  In cases where the service spans across multiple management systems, the task of allocating RTs has to be aligned across the domains, therefore, <del> the service model must provide a way to specify RTs.  In addition, </del>  route distinguishers (RDs) must also be synchronized to avoid collisions in RD allocation between separate management systems.  An incorrect allocation might lead to the same RD and IP prefixes being Indicates the Autonomous System Number (ASN) that is configured for the VPN node. <del> As defined in I-D.ietf-opsawg-vpn-common, these RD assignment modes are supported: direct assignment, automatic assignment from a given pool, automatic assignment, and no assignment.  For illustration purposes, the following modes can be used in the deployment cases: </del>  The VPN service provider (service orchestrator) assigns explicitly RDs.  This case will fit with a brownfield scenario Indicates both operational and administrative status of a VPN network access. <del> Represents and groups the set of Layer 2 connectivity from where </del>  the traffic of the L3VPN in a particular VPN Network access is coming.  See connection. routes to the same destination prefix. Used to convey the status of a static route entry.  This data node <del> is used to control the (de)activation of individual static route entries. </del>  In addition, the L3NM supports the following CE-PE routing protocols: routing loops (Section 7 of RFC4364).  The Site of Origin attribute is encoded as a Route Origin Extended Community. <del> Carries an IPv6 Address Specific BGP Extended that is used to indicate the Site of Origin for VRF information RFC5701.  It is used to prevent routing loops. </del>  Controls whether the PE-CE link is advertised to other PEs.

Reviewer: Qin Wu Review result: Has Nits I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: This document defines L3VPN network model for provisioning L3VPN service within service provider network. It provides network centric view of L3VPN service. I think this document is well written and ready for publication. However I have a few editorial comments I want like authors to consider. Major issue: None Nits: Section 1, Paragraph 6 Is correspondence referred to corresponding relation or correlation? If they are equivalent, I am okay with the current wording. Section 5, Network topology module bullet s/using the network topology module in [RFC8345] /using the network topology module in [RFC8345] Or its extension module such as UNI topology module [I-D.ogondio-opsawg-uni-topology] 6.1 Paragraph 1 The last sentence describes Causal relationship between template and batch process and abstracting the parameter into upper SDN layer, it is not very clear to me that which one is cause? Which one is effect? Maybe I am wrong. 6.1 Paragraph 2 Customer sites are not modelled in the L3NM any more How about s/ the addition or removal of customer sites / the addition or removal of VPN nodes 6.1 Paragraph 2 Is RT/RD synchronization mechanism between Pes in the scope of document? If none, please make this clear. 6.2, Paragraph 2 s/service model/network model 6.3 Paragraph 2 Is MPLS P2MP the only transport for multicast traffic in this case or just an example transport? 7.4 'rd'definition s/ these RD/the following RD Section 7.6 'connection' definition s/from where/from which Section 7.6.3 said: "The L3NM supports the configuration of one or more IPv4/IPv6 static routes. Since the same structure is used for both IPv4 and IPv6, it was considered to have one single container to group both static entries independently of their address family, but that design was abandoned to ease the mapping with the structure in [RFC8299]. " I think you emphasize that the L2NM and L3NM to follow the similar structure to ease the mapping. 7.6.3, 'status' definition s/ is used to control the (de)activation/can also be used to control the (de)activation Section 7.6.3 'ipv6-site-of-origin' definition s/IPv6 Address Specific BGP Extended/IPv6 Address Specific BGP Extended Community Section 7.6.3 'authentition' definition under BGP I think we support different authentication modes such as TCP AO support, IPSEC support, TLS support. I am not sure that TCP MD5 should be supported as an option since it has break many protocols. Section 7.6.6 'Layer 4' definition s/data node under ‘l3’ (Figure 25)/data node under ‘l4’ (Figure 26) I didn’t check other figure number consistency. Section 8 s/RFC UUU/RFC XXX

orchestrator in the L3NM (e.g., customer) or be used to feed some L3NM attributes (e.g., actual forwarding policies).  Also, some information captured in the L3SM may be maintained locally within the  <ins> orchestrator; which is in charge of maintaining the correlation </ins> between a customer view and its network instantiation.  Likewise, some information captured and exposed using the L3NM can feed the service layer (e.g., capabilities) to drive VPN service order automated VPN service provisioning and delivery. An L3VPN involves nodes that are part of a topology managed by the  <ins> service provider network.  Such The topology can be represented using the network topology YANG module defined in RFC8345 or its extension such as a User-Network Interface (UNI) topology module (e.g., I-D.ogondio-opsawg-uni-topology). </ins> L3NM is not a device model. will still be required. A common function that is supported by VPNs is the addition or  <ins> removal of VPN nodes.  Workflows can use the L3NM in these scenarios to add or prune nodes from the network data model as required. </ins> 6.2. allocation can be performed by that management system.  In cases where the service spans across multiple management systems, the task of allocating RTs has to be aligned across the domains, therefore,  <ins> the network model must provide a way to specify RTs.  In addition, </ins> route distinguishers (RDs) must also be synchronized to avoid collisions in RD allocation between separate management systems.  An incorrect allocation might lead to the same RD and IP prefixes being Indicates the Autonomous System Number (ASN) that is configured for the VPN node.  <ins> As defined in I-D.ietf-opsawg-vpn-common, the following RD assignment modes are supported: direct assignment, automatic assignment from a given pool, automatic assignment, and no assignment.  For illustration purposes, the following modes can be used in the deployment cases: </ins> The VPN service provider (service orchestrator) assigns explicitly RDs.  This case will fit with a brownfield scenario Indicates both operational and administrative status of a VPN network access.  <ins> Represents and groups the set of Layer 2 connectivity from which </ins> the traffic of the L3VPN in a particular VPN Network access is coming.  See connection. routes to the same destination prefix. Used to convey the status of a static route entry.  This data node  <ins> can also be used to control the (de)activation of individual static route entries. </ins> In addition, the L3NM supports the following CE-PE routing protocols: routing loops (Section 7 of RFC4364).  The Site of Origin attribute is encoded as a Route Origin Extended Community.  <ins> Carries an IPv6 Address Specific BGP Extended Community that is used to indicate the Site of Origin for VRF information RFC5701.  It is used to prevent routing loops. </ins> Controls whether the PE-CE link is advertised to other PEs.


<del> A Network YANG Model for Service Attachment Points </del>  draft-ietf-opsawg-sap-latest Abstract view of the provider network topology containing the points from which its services can be attached (e.g., basic connectivity, VPN, network slices).  The data model augments the 'ietf-network' data <del> model by adding the concept of service attachment points (SAPs).  The service attachment points are the points to which network services (such as L3VPN or L2VPN) can be attached.  The customer endpoint of an attachment circuits are not covered in the SAP network topology. </del>  1. <del> The service attachment point (SAP) is an important architectural </del>  concept in many implementations and deployments of services such as <del> VPNs, SDWAN, or managed VoIP services.  It has already been used to decide where to attach and, thus, deliver the service in the L3SM RFC8299 and the L2SM RFC8466. </del>  This document defines a YANG network model for representing, <del> managing, and controlling the service attachment points (SAPs).  The data model augments the 'ietf-network' module RFC8345 by adding the concept of service attachment points.  The service attachment points are abstraction of the points where network services such as L3VPNs or L2VPNs can be attached. </del>  <del> This document does not make any assumption about the service provided by the network to the users.  VPN services are used for illustration purposes.  This concept can also be used to decide network slice SAPs I-D.ietf-teas-ietf-network-slices. </del>  In the context of Software-Defined Networking (SDN) RFC7426, the defined YANG data model in this document can be used to exchange provision and resource management discussed in I-D.ietf-opsawg-l2nm. Through this data model, the service orchestration layer can learn the available endpoints (i.e., SAPs) of interconnection resource of <del> the underlying network. The service orchestration layer can determine which endpoint of interconnection to add to L2VPN or L3VPN service.  With the help of other data models (e.g., L3SM RFC8299 or L2SM RFC8466), hierarchical control elements could determine the feasibility of an end-to-end IP connectivity or L2VPN connectivity and therefore derive the sequence of domains and the points of interconnection to use. </del>  This document explains the scope and purpose of a SAP network model <del> and its relation with the service models and describes how it can be used by a network operator.  The document also shows how the topology and service models fit together. </del>  The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) RFC8342. of RFC6241, RFC7950, and RFC8309.  The document uses terms from those documents. <del> Tree diagrams used in this document follow the notation defined in [RFC8340]. </del>  This document uses the term "network model" defined in Section 2.1 of RFC8969. An equipment owned and managed by the SP that can support multiple services (e.g., VPNs) for different customers.  A PE is directly <del> connected to one or more CEs via attachment circuits.  A PE is usually located at an SP point of presence (PoP). </del>  <del> Describes a service's end point characteristics and its reference </del>  to a Termination Point (TP) of the PE; used as service access point for service. Let us consider the example of a typical service provider network (fi2), with PE and P nodes. <del> The Service Orchestration layer does not need to know about the </del>  internals of the underlying network (e.g., P nodes). fi2a shows the abstract network view as seen by the Service Orchestrator.  However, this view is not enough to provide to the Service Orchestration layer Orchestration. A single SAP network topology can be used for one of multiple service <del> types (e.g., L3VPN, EVPN).  The network controller can then expose the service type(s) and associated interfaces via the SAPs. </del>  As shown in fi3a, the Service Orchestration layer will have also access to a set of Customer Service Model, e.g., an L3SM or L2SM data model in the customer-facing interface and a set of network models, <del> e.g., L3NM and Network topology data models in the resource-facing interface.  In this use case, it is assumed that the network </del>  controller is unaware of what happens beyond the PEs towards the CEs; it is only responsible for the management and control of the network between PEs. 4. The SAP network model builds on the network data model defined in the <del> 'ietf-network' module RFC8345, augmenting the nodes with service attachment points, which anchor the links and are contained in nodes. </del>  The 'service-attachment-point' attribute defined in the SAP network model is not a tunnel termination point (TTP) nor a link, but an abstraction of the termination point defined in RFC8345. Network slice I-D.ietf-teas-ietf-network-slices. <del> A service attachment point is identified by an interface name </del>  ("attachment-id"), an interface type ("type"), a status ("admin- <del> status", and "oper-status"), an encapsulation type ("encapsulation- type"), one or a list of service types ("sap-type") such as L3VPN or network slice, a description of the service(s) ("service- description"). </del>  5. The SAP network model can be seen as an inventory data associated <del> with service attachment points.  The model maintains an inventory of nodes contained in a network based on [RFC8345]. </del>  fig5 depicts the relationship of the SAP network model to other models.  The SAP network model augments from the Network model

Check if we need to expose SAPs per servcie-type and if so, how we can easily add support for it OLD: NEW:

<ins> A Network YANG Model for Service Attachment Points (SAPs) </ins> draft-ietf-opsawg-sap-latest Abstract view of the provider network topology containing the points from which its services can be attached (e.g., basic connectivity, VPN, network slices).  The data model augments the 'ietf-network' data  <ins> model by adding the concept of Service Attachment Points (SAPs).  The Service Attachment Points are the points to which network services (such as Layer 3 Virtual Private Network (L3VPN) or Layer 2 Virtual Private Network (L2VPN)) can be attached. The customer endpoints of an attachment circuit (Customer Edges (CEs), topically) are not covered in the SAP network topology. </ins> 1.  <ins> The Service Attachment Point (SAP) is an important architectural </ins> concept in many implementations and deployments of services such as  <ins> Virtual Private Networks (VPNs), Software-Defined Wide Area Network (SDWAN), or managed Voice over IP (VoIP) services.  It is used to decide where to attach and, thus, deliver the service in the Layer 3 VPN Service Model (L3SM) RFC8299 and the Layer 2 VPN Service Model (L2SM) RFC8466.  It can also be used to retrieve where services, such as the Layer 3 VPN Network Model (L3NM) I-D.ietf-opsawg-l3sm-l3nm, and the Layer 2 VPN Network Model (L2NM) I-D.ietf-opsawg-l2nm, are delivered. </ins> This document defines a YANG network model for representing,  <ins> managing, and controlling the Service Attachment Points.  The data model augments the 'ietf-network' module RFC8345 by adding the concept of Service Attachment Points.  The Service Attachment Points are abstraction of the points where network services can be attached. </ins>  <ins> This document does not make any assumption about the service(s) provided by the network to the users.  VPN services (such as Layer 3 Virtual Private Network (L3VPN) or Layer 2 Virtual Private Network (L2VPN)) are used for illustration purposes.  The SAP concept can be used to decide network slice SAPs I-D.ietf-teas-ietf-network-slices. </ins> In the context of Software-Defined Networking (SDN) RFC7426, the defined YANG data model in this document can be used to exchange provision and resource management discussed in I-D.ietf-opsawg-l2nm. Through this data model, the service orchestration layer can learn the available endpoints (i.e., SAPs) of interconnection resource of  <ins> the underlying network.  The service orchestration layer can determine which interconnection endpoints to add to an L2VPN or L3VPN service.  With the help of other data models (e.g., L3SM RFC8299 or L2SM RFC8466), hierarchical control elements can also assess the feasibility of an end-to-end IP connectivity or L2VPN connectivity and, therefore, derive the sequence of domains and the points of interconnection to use. </ins> This document explains the scope and purpose of a SAP network model  <ins> and its relation with the service models. </ins> The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) RFC8342. of RFC6241, RFC7950, and RFC8309.  The document uses terms from those documents.  <ins> The meanings of the symbols in tree diagrams are defined in RFC8340. </ins> This document uses the term "network model" defined in Section 2.1 of RFC8969. An equipment owned and managed by the SP that can support multiple services (e.g., VPNs) for different customers.  A PE is directly  <ins> connected to one or more CEs via attachment circuits. </ins>  <ins> Describes a service's endpoint characteristics and its reference </ins> to a Termination Point (TP) of the PE; used as service access point for service. Let us consider the example of a typical service provider network (fi2), with PE and P nodes.  <ins> The Service orchestration layer does not need to know about the </ins> internals of the underlying network (e.g., P nodes). fi2a shows the abstract network view as seen by the Service Orchestrator.  However, this view is not enough to provide to the Service Orchestration layer Orchestration. A single SAP network topology can be used for one of multiple service  <ins> types (e.g., L3VPN, Ethernet VPN (EVPN)).  The network controller can then expose the service type(s) and associated interfaces via the SAPs. </ins> As shown in fi3a, the Service Orchestration layer will have also access to a set of Customer Service Model, e.g., an L3SM or L2SM data model in the customer-facing interface and a set of network models,  <ins> e.g., the L3NM and Network topology data models in the resource- facing interface.  In this use case, it is assumed that the network </ins> controller is unaware of what happens beyond the PEs towards the CEs; it is only responsible for the management and control of the network between PEs. 4. The SAP network model builds on the network data model defined in the  <ins> 'ietf-network' module RFC8345, augmenting the nodes with Service Attachment Points, which anchor the links and are contained in nodes. </ins> The 'service-attachment-point' attribute defined in the SAP network model is not a tunnel termination point (TTP) nor a link, but an abstraction of the termination point defined in RFC8345. Network slice I-D.ietf-teas-ietf-network-slices.  <ins> A Service Attachment Point is identified by an interface name </ins> ("attachment-id"), an interface type ("type"), a status ("admin-  <ins> status" and "oper-status"), an encapsulation type ("encapsulation- type"), one or a list of service types ("sap-type"), a description of the service(s) ("service-description"). "attachment-id" may include a reference to a physical or a logical interface.  For example, an "attachment-id" may be the interface identifier of a VPN network access used in Section 7.6 of I-D.ietf- opsawg-l3sm-l3nm. </ins> 5. The SAP network model can be seen as an inventory data associated  <ins> with SAPs.  The model maintains an inventory of nodes contained in a network based on RFC8345. </ins> fig5 depicts the relationship of the SAP network model to other models.  The SAP network model augments from the Network model


the L3NM attribute (e.g., actual forwarding policies).  Some of the information captured in L3SM may be maintained locally within the Orchestrator; which is supposed to maintain a "glue" between a <del> Customer view and its network instantiation. </del>  The L3NM module does not attempt to address all deployment cases especially those where the L3VPN connectivity is supported through

Allows a controller to expose the L3SM to which an L3NM is bound
OK! It is optional. Should work typically the other way around, allows the service orchestrator to maintain the match and facilitate reconciliation. NAME Please add some text in the draft to explain the parameter
Please see the change: Will add more text once we will work seriously on the tree structure part.

the L3NM attribute (e.g., actual forwarding policies).  Some of the information captured in L3SM may be maintained locally within the Orchestrator; which is supposed to maintain a "glue" between a  <ins> Customer view and its network instantiation.  Likewise, some of the information captured and exposed using L3NM can fed the service layer (e.g., capabilities) to derive L3SM and drive VPN service order handling. </ins> The L3NM module does not attempt to address all deployment cases especially those where the L3VPN connectivity is supported through


IPv4 and IPv6 addresses MUST expose a different mDNS name for each address.  Note that any server-reflexive candidates generated from an mDNS host candidate will have IP addresses as their transport addresses, rather than mDNS hostnames.  Because their transport addresses are different

PR of
Currently it contains: c=IN IP4 address/ttl Obviously, putting one of the candidate's IP address there would defeat the purpose of use mDNS. Options: Can this be omitted? Should it have a fake IP address of the right address family? Should it be allowed to have an mDNS name?
Just use the mDNS name.
If we run into issues, we could use 0.0.0.0:9 as we do when there are no candidates, but that starts to get complicated (i.e. may require updates to other specs)
mDNS name with IP4?
good point - shouldn't matter that much, but IP4 seems like the safest choice.
Agreed to use mDNS + IP4. We'll reevaluate if this causes problems.
Fixed by
We have observed an interop issue in the experimental deployment. Endpoints can fail to parse the SDP when the c= line contains a FQDN. This is the current solution.
Well, at least we thought of the solution already :)

IPv4 and IPv6 addresses MUST expose a different mDNS name for each address. <ins> The mDNS name of an mDNS candidate MUST be used in the connection- address field of its candidate attribute.  When an mDNS candidate is the default candidate, its mDNS name MUST be used in the connection- address field of the SDP "c=" line.  Since an mDNS candidate also conceals its address family, the "c=" line SHOULD use "IP4" in the address-type field. </ins> Note that any server-reflexive candidates generated from an mDNS host candidate will have IP addresses as their transport addresses, rather than mDNS hostnames.  Because their transport addresses are different


regarding whether an address is safe to expose.  If so, expose the candidate and abort this process. <del> Check whether the ICE agent has a usable registered mDNS hostname resolving to the ICE candidate's IP address.  If one exists, skip ahead to Step 6. </del>  Generate a unique mDNS hostname.  The unique name MUST consist of a version 4 UUID as defined in RFC4122, followed by ".local".

PR for
In the section gather candidates, it says: "Check whether the ICE agent has a usable registered mDNS hostname resolving to the ICE candidate’s IP address. If one exists, skip ahead to Step 6." We, maybe, should clarify this refers to a registered mDNS hostname as produce by this spec, not another (possibly meaningful) name created in some other context.
Makes sense as an editorial cleanup.
Fixed by

regarding whether an address is safe to expose.  If so, expose the candidate and abort this process.  <ins> Check whether the ICE agent has previously generated, registered, and stored an mDNS hostname for this IP address as per Steps 3, 4, and 6.  If it has, skip ahead to Step 7. </ins> Generate a unique mDNS hostname.  The unique name MUST consist of a version 4 UUID as defined in RFC4122, followed by ".local".


4.3. <del> Note that backward compatibility does not present a significant issue for the mDNS technique.  When an endpoint that supports mDNS communicates with an endpoint that does not, the legacy endpoint will still provide its local IP addresses, and accordingly a direct connection can still be attempted, even though the legacy endpoint cannot resolve the mDNS names provided by the new endpoint.  In the event the legacy endpoint attempts to resolve mDNS names using </del>  Unicast DNS, this may cause ICE to take somewhat longer to fully complete, but should not have any effect on connectivity or connection setup time.  5. The examples below show how the mDNS technique is used during ICE

LGTM
In the draft, we currently have no clear definition on this aspect. One thought we have is to couple the IP revealing permission with the getUserMedia permission. This is in alignment with the existing practice of the network enumeration permission in browsers. A separate permission from the user for the IP revealing is the alternative that reduces the implications from a single permission.
I think this is outside the scope of this work - it's already addressed in rtcweb-ip-handling.
My concern is the current draft does not provide a precise mapping to modes in rtcweb-ip-handling and the privacy guideline, namely Section 5. We may need the reference to mode 2.1 in ip-handling-ex-mdns, which however delegates the privacy guideline to ip-handling, and meanwhile ip-handling currently has only a brief recommendation after mode 4. A link feels missing in deriving (transitively) the exact condition in the text. This issue will probably be gone after consolidating the two ip-handling drafts and editing Section 5. Let me know what you think.
URL tries to spell this out, referring back to mdns-ice-candidates. I don't think mdns-ice-candidates should ref ip-handling-ex-mdns; I would prefer that any mode discussion be confined to that document.
Discussed and plan is to simply add some text that legacy endpoints are more likely to malfunction with mDNS names (in the same section where we talk about performance/cost downsides)
LGTM

4.3.  <ins> For the most part, backward compatibility does not present a significant issue for the mDNS technique.  When an endpoint that supports mDNS communicates with an endpoint that does not, the legacy endpoint will still provide its local IP addresses, and accordingly a direct connection can still be attempted, even though the legacy endpoint cannot resolve the mDNS names provided by the new endpoint. In the event the legacy endpoint attempts to resolve mDNS names using </ins> Unicast DNS, this may cause ICE to take somewhat longer to fully complete, but should not have any effect on connectivity or connection setup time. <ins> However, some legacy endpoints are not fully spec-compliant and can behave unpredictably in the presence of ICE candidates that contain a hostname, potentially leading to ICE failure.  Such endpoints have been identified during testing of this technique, but appear to be rare. </ins> 5. The examples below show how the mDNS technique is used during ICE


IPv4 and IPv6 addresses MUST expose a different mDNS name for each address. <del> Any server-reflexive candidates generated from an mDNS local candidate MUST have their raddr field set to 0.0.0.0 and their rport field set to 0. </del>  Any candidates exposed to the web application via local descriptions MUST be identical to those provided during candidate gathering (i.e.,

RFC 8445 sayeth in S 5.1.3: We should add a note to make it clear that mDNS candidates have distinct transport addresses from their equivalent IPs, and so a srflx candidate created from a public mDNS candidate MUST NOT be discarded as redundant.

IPv4 and IPv6 addresses MUST expose a different mDNS name for each address.  <ins> Note that any server-reflexive candidates generated from an mDNS host candidate will have IP addresses as their transport addresses, rather than mDNS hostnames.  Because their transport addresses are different (i.e., not hostnames), they MUST NOT be considered redundant with their host counterparts, per the guidance in RFC8445, Section 5.1.3. To avoid accidental leakage, these candidates MUST have their raddr field set to 0.0.0.0 and their rport field set to 0. </ins> Any candidates exposed to the web application via local descriptions MUST be identical to those provided during candidate gathering (i.e.,


Abstract <del> WebRTC applications rely on ICE candidates to enable peer-to-peer connections between clients in as many network configurations as possible.  To maximize the probability to create a direct peer-to- peer connection, client private IP addresses are often exposed without user consent.  This is currently used as a way to track users.  This document describes a way to share IP addresses with other clients while preserving client privacy.  This is achieved by obfuscating IP addresses using dynamically generated names resolvable through Multicast DNS RFC6763. </del>  1. <del> As detailed in IPHandling, exposing client private IP addresses allows maximizing the probability to successfully create a connection between two clients.  This information is also used by many web sites as a way to fingerprint and identify users without their consent. The first approach exposes client private IP addresses by default, as can be seen from websites such as IPLeak.  The second approach implemented in the WebKit engine enforces the following policy: By default, use mode 3 as defined in IPHandling: any host ICE candidate is filtered out. Use mode 2 as defined in IPHandling if there is an explicit user action to trust the web site: host ICE candidates are exposed to the web site based on the use of navigator.mediaDevices.getUserMedia, which typically prompts the user to grant or deny access to cameras/microphones. The second approach supports most common audio/video conference applications but leads to failing or suboptimal connections for applications relying solely on data channel.  This is particularly an issue on unmanaged networks, typically home or small offices where NAT loopback might not be supported. To overcome the shortcomings of the above two approaches, this document proposes to register dynamically generated names using Multicast DNS when gathering ICE candidates.  These dynamically generated names are used to replace private IP addresses in host ICE candidates.  Only clients that can resolve these dynamically generated names using Multicast DNS will get access to the actual client IP address. </del>  2. <del> The gathering of ICE candidates without user consent is a well-known fingerprinting technique to track users.  This is particularly a concern when users are connected through a NAT which is a usual configuration.  In such a case, knowing both the private IP address and the public IP address will usually identify uniquely the user device.  Additionally, Internet web sites can more easily attack intranet web sites when knowing the intranet IP address range. A successful WebRTC connection between two peers is also a potential thread to user privacy.  When a WebRTC connection latency is close to zero, the probability is high that the two peers are running on the same device.  Browsers often isolate contexts one from the other. Private browsing mode contexts usually do not share any information with regular browsing contexts.  The WebKit engine isolates third- party iframes in various ways (cookies, ITP) to prevent user tracking.  Enabling a web application to determine that two contexts run in the same device would defeat some of the protections provided by modern browsers. 3. This section uses the concept of ICE agent as define in RFC5245.  In </del>  the remainder of the document, it is assumed that each browser execution context has its own ICE agent. <del> 3.1. </del>  For any host ICE candidate gathered by a browsing context as part of <del> RFC5245 section 4.1.1, obfuscation of the candidate is done as </del>  follows: Check whether the context ICE agent registered a name resolving to Replace the IP address of the ICE host candidate with the name with ".local" appended to it.  Expose the candidate. <del> 3.2. </del>  For any remote host ICE candidate received by the ICE agent, the following procedure is used: If the connection-address field value of the ICE candidate does not finish by ".local", process the candidate as defined in <del> RFC5245. </del>  Otherwise, remove the ".local" suffix to the value and resolve it using Multicast DNS. IPv6 address.  In that case, the IPv6 address may be used preferably to the IPv4 address. <del> 4. </del>  <del> 4.1. </del>  When there is no user consent, the following filtering should be done to prevent private IP address leakage: SDP does not expose any a=candidate line corresponding to a host ICE candidate which contains an IP address. <del> RTCIceCandidateStats dictionaries exposed to web pages do not contain any 'ip' member if related to a host ICE candidate. </del>  <del> 4.2. </del>  Dynamically generated names can be used to track users if used too often.  Conversely, registering too many names will also generate useless processing.  The proposed rule is to create and register a new generated name for a given IP address on a per execution context. <del> 4.3. Privacy might also be breached if two execution contexts can identify whether they are run in the same device based on a successful peer- to-peer connection.  The proposed rule is to not register any name using Multicast DNS for any ICE agent belonging to: </del>  <del> A third-party browser execution context, i.e. a context that is not same origin as the top level execution context. </del>  <del> A private browsing execution context. </del>  <del> 5. </del>  The proposal relies on identifying and resolving any Multicast DNS based ICE candidates as part of adding/processing a remote candidate.

Define a new STUN attribute and use it to flag a prflx candidate that may share the IP address with a host candidate.
Are we going to revise this to focus on Option 3?
Yes, the latest commit is focused on Option 3. PTAL.
We found there is an issue with prflx candidates, and we may need to clarify the de-duplication logic in the proposal. Suppose the local ICE agent is in the resolution process of an mDNS remote candidate, the remote ICE agent starts to ping the local agent with connectivity checks from the remote candidate we are resolving, we may need to define a reliable way to identify that the prflx candidate is the same one as the mDNS candidate and not create a duplicate candidate. Also, the identical and duplicate prflx candidate can be a source of IP leak (via stats).
Interesting issue, can it be handled similarly to other redundant candidates as defined in URL
Probably not, that covers a different scenario. I think that the priority attribute could be a solution here.
At the time we receive the STUN check, we have the mDNS candidate with its foundation and priority and host:port. In the received STUN check, we will only have the PRIORITY attribute (of the attributes noted above); the port may be mutated by an intervening NAT. And even the PRIORITY attribute will not match that of the mDNS candidate, as the type preference will be set to 110, per 5245, S 7.1.2.1. If we get a STUN check after we get the mDNS candidate but before resolution completes, we can check to see if the mDNS candidate priority matches the STUN check priority after adjusting the type preference of the mDNS candidate priority to 110. If there is a match, we can avoid creating a prflx candidate. However, what should stats say at this point? Also, what should happen if we get the STUN check before we get the mDNS candidate via signaling (as could be the case for the caller)?
I was thinking of using the PRIORITY attribute from the STUN check, particularly the value of type preference (before we change it to 110 when creating a prflx remote candidate) to infer the underlying type, but the value used in practice is only recommended by 8445 (or 5245), and the inter-op between different implementations is not well-defined. I am wondering if it is possible to define a must-level value of type preference for "hostname" candidate, e.g. in a separate spec for FQDN handling in ICE. I think for prflx candidates, RTCIceCandidateStats still applies and libwebrtc currently exposes it, which has the IP. We should create a prflx candidate (as libwebrtc currently would do), since there is no way to tell if we would have any remote host candidates with unresolved IPs. If we add an indication in the signaling to let the remote endpoint know we would use mDNS candidates, I feel it could be the same case as the one we receive a check during resolution.
This is a good question; I had a similar worry about the use of PRIORITY. Perhaps hostname candidates should include the hostname in the STUN check. I think that invalidates this technique; a web page could then easily use this loophole to get the local IP. (Create 2 PCs, never send the answer, observe IP resulting from prflx candidate). If we put a marker in the STUN check (that this is a check from a mDNS candidate), we could eat the check or queue it until the actual mDNS candidate had been received and resolved. Otherwise, I think we end up leaking the IP, as noted above.
Rather than a marker can't we add an STUN attribute containing the mDNS host-name in question? This eliminates the guesswork out of it: even with just supporting default routes, we could still have 2 mDNS candidates, one for IPv4 and one for IPv6 (and the mDNS candidate signaled doesn't tell us which is which) if at some point in the future we want to support non-default routes through mDNS, this might produce even more mDNS candidates This should then be a 'comprehension required' attribute, so that pre-mDNS ICE implementations don't inadvertently leak the IP.
Good point, and I feel this is much better than recommending adding anything in the signaling, which we cannot really ask the implementation to comply. This should also help the case when we receive the STUN check before getting the mDNS candidate via signaling. Would the plain hostname add too much payload (e.g. 128-bit UUID)? We have received the feedback that ICE overheads are quite heavy for low bandwidth. Also, if we do the above, should we stop the ongoing/imminent mDNS resolution? The STUN check basically provide one resolution in this case. The would-be prflx candidate would immediately be converted/merged to a host candidate. If we consider the STUN check with a hostname as one resolution as above, it looks to me that we could avoid creating prflx candidates that would leak private IPs. If we allow the mDNS resolution to start/continue, while also creating a host instead of prflx with IP of the check source, there is an issue of how to reconcile conflicts if the resolution later returns something different. This could be an alternative solution to using the info in the STUN check as a resolution as above. I am not sure which makes more sense at the moment.
It seems to me that the signaled mDNS host-name does need to be resolved through mDNS. The STUN check could be malicious in itself (e.g. part of a DoS attack), until we have done the mDNS resolution we can't tell whether the originator is a real candidate. Since STUN checks are in the clear, adding the host-name does leak some information that previously was protected through the signalling channel. If the mDNS host-names are randomly generated UUIDs, not sure this is an issue. If implementers were to use something not 100% random, this could be used for fingerprinting? I'm unsure what the bar is, but the IETF is putting a lot of emphasis on privacy.
From a privacy point of view, I believe the most important issue is to ensure that a simple page creating two peer connections cannot get access to the IP address. Since the same browser is controlling both endpoints, that should be made possible. In the case of a successful connection, the fact that the other party is leaking the private IP address cannot be fully addressed in general. I think stats should basically not provide the peer-reflexive IP address unless it can ensure that it is not breaking the privacy of the other party.
As discussed in URL, we could simplify the solution if we agree to not expose the RTCICeCandidateStats address member for prflx candidates. Let's discuss this approach in URL
Does mDNS itself have any protection against malicious advertisements? To NAME 's point above, an attacker would need to know the ICE ufrag/pwd and your local IP in order to send STUN checks with a bogus name from a bogus address - not sure this is realistic or creates a real-world problem - but maybe I'm not thinking about it right. Anyway, recapping the options we have: I kind of like having STUN serve as a mechanism for DNS. The downside here is that adding 44 bytes to the STUN check increases STUN bandwidth from non-TURN local candidates by 40% (URL). However, in Mode 2, with a small number of candidate pairs, this may be acceptable. Using the marker is a cheaper form of Option 1, but we have to delay servicing the check until we get and resolve the mDNS name, which will slow down connections slightly in some edge cases. Feels like the most complex option. NAME 's suggestion from w3c/webrtc-stats. Simple, easy to reason about. Probably causes some collateral damage to the stats of existing apps.
Regarding option 1: We could, instead of adding a 44 byte mDNS hostname, add the 16 byte random number that is the basis for the UUID. This would put a MUST requirement on the use of UUIDs for mDNS names and would maybe hamper server implementations down the road. At the same time, I think this also avoids (more easily) the case where we have multiple IP addresses associated with an MDNS name.
Agreed, we could have multiple attribs for the hostname - a string form or a compact uuid-bytes form, both of which would expand to the same thing.
Option 3 will be discussed at TPAC 2018. If the MDNS proposal is the only driver for changing STUN, I feel we should try to push for option 3. If it might provide benefit in other contexts, the story might be different (although I still think we should try to fix w3c/webrtc-stats)
As per TPAC discussion within WebRTC WG, we should be able to go on with option 3.
Approving with suggestion, will tweak location of text later

Abstract  <ins> WebRTC applications collect ICE candidates as part of the process of creating peer-to-peer connections.  To maximize the probability of a direct peer-to-peer connection, client private IP addresses are included in this candidate collection.  However, disclosure of these addresses has privacy implications.  This document describes a way to share local IP addresses with other clients while preserving client privacy.  This is achieved by obfuscating IP addresses with dynamically generated Multicast DNS RFC6763 names. </ins> 1.  <ins> As detailed in IPHandling, exposing client private IP addresses by default maximizes the probability of successfully creating direct peer-to-peer connection between two clients, but creates a significant surface for user fingerprinting.  IPHandling recognizes this issue, but also admits that there is no current solution to this problem; implementations that choose to use Mode 3 to address the privacy concerns often suffer from failing or suboptimal connections in WebRTC applications.  This is particularly an issue on unmanaged networks, typically homes or small offices, where NAT loopback may not be supported. This document proposes an overall solution to this problem by registering ephemeral Multicast DNS names for each local private IP address, and then providing those names, rather than the IP addresses, to the web application when it gathers ICE candidates. WebRTC implementations resolve these names to IP addresses and perform ICE processing as usual, but the actual IP addresses are not exposed to the web application. </ins> 2.  <ins> This section uses the concept of ICE agent as define in RFC8445.  In </ins> the remainder of the document, it is assumed that each browser execution context has its own ICE agent.  <ins> 2.1. </ins> For any host ICE candidate gathered by a browsing context as part of  <ins> RFC8445 section 5.1.1, obfuscation of the candidate is done as </ins> follows: Check whether the context ICE agent registered a name resolving to Replace the IP address of the ICE host candidate with the name with ".local" appended to it.  Expose the candidate.  <ins> 2.2. </ins> For any remote host ICE candidate received by the ICE agent, the following procedure is used: If the connection-address field value of the ICE candidate does not finish by ".local", process the candidate as defined in  <ins> RFC8445. </ins> Otherwise, remove the ".local" suffix to the value and resolve it using Multicast DNS. IPv6 address.  In that case, the IPv6 address may be used preferably to the IPv4 address.  <ins> 2.2.1. </ins>  <ins> A peer-reflexive remote candidate could be learned and constructed from the source transport address of the STUN Binding request as an ICE connectivity check.  The peer-reflexive candidate could share the same address as a remote host ICE candidate that will be signaled or has been signaled, received and is in the process of name resolution. In addition to the elimination procedure of redundant candidates defined in Section 5.1.3 of RFC8445, which could remove constructed peer-reflexive remote candidates, the address of any existing peer- reflexive remote candidate should not be exposed to Web applications by ICE agents that implement this proposal, as detailed in Section #guidelines. 3. 3.1. </ins> When there is no user consent, the following filtering should be done to prevent private IP address leakage: SDP does not expose any a=candidate line corresponding to a host ICE candidate which contains an IP address.  <ins> Statistics related to ICE candidates MUST NOT contain the resolved IP address of a remote mDNS candidate or the IP address of a peer- reflexive candidate, unless that IP address has already been learned through other means, e.g., receiving it in a separate server-reflexive remote candidate. </ins>  <ins> 3.2. </ins> Dynamically generated names can be used to track users if used too often.  Conversely, registering too many names will also generate useless processing.  The proposed rule is to create and register a new generated name for a given IP address on a per execution context.  <ins> 3.3. </ins>  <ins> As noted in IPHandling, privacy may be breached if a web application running in two browser contexts can determine whether it is running on the same device.  While the approach in this document prevents the application from directly comparing local private IP addresses, a successful local WebRTC connection can also present a threat to user privacy.  Specifically, when the latency of a WebRTC connection latency is close to zero, the probability is high that the two peers are running on the same device. </ins>  <ins> To avoid this issue, browsers SHOULD NOT register Multicast DNS names for WebRTC applications running in a third-party browser execution context (i.e., a context that has a different origin than the top- level execution context), or a private browser execution context. </ins>  <ins> 4. </ins> The proposal relies on identifying and resolving any Multicast DNS based ICE candidates as part of adding/processing a remote candidate.


connectivity, reduced throughput and increased latency, as well as increased cost in case of TURN relay.  One potential mitigation, as discussed in privacy, is to not conceal candidates created from RFC4941 IPv6 addresses.  This permits connectivity even in large internal networks or where mDNS is <del> disabled. The exact impact of the mDNS technique is being researched experimentally and will be provided before publication of this document. </del>  4.2. However, some legacy endpoints are not fully spec-compliant and can behave unpredictably in the presence of ICE candidates that contain a <del> hostname, potentially leading to ICE failure.  Such endpoints have been identified during testing of this technique, but appear to be rare. </del>  5.

ping
Will we get sources for these numbers that elaborate distribution and regional differences?
LGTM modulo the thought on mentioning the potential impact of c= line before the update.
No answer to my question?
NAME I struggled to respond to the question since it's so open-ended, and really outside the scope of this PR. Suggest filing an issue and we can discuss more there.

connectivity, reduced throughput and increased latency, as well as increased cost in case of TURN relay. <ins> During experimental testing of the mDNS technique across a set of known mDNS-aware endpoints that had configured a STUN server but not a TURN server, the observed impact to ICE connection rate was 2% (relative) when mDNS was enabled on both sides, compared to when mDNS was only enabled on one side.  In this testing, the percentage of connections that required STUN (i.e., went through a NAT) increased from 94% to 97%, indicating that mDNS succeeded about half the time, and fell back to NAT hairpin for the remainder.  The most likely explanation for the overall connection rate drop is that hairpinning failed in some cases. </ins> One potential mitigation, as discussed in privacy, is to not conceal candidates created from RFC4941 IPv6 addresses.  This permits connectivity even in large internal networks or where mDNS is  <ins> disabled.  Future versions of this document will include experimental data regarding this option. </ins> 4.2. However, some legacy endpoints are not fully spec-compliant and can behave unpredictably in the presence of ICE candidates that contain a  <ins> hostname, potentially leading to ICE failure.  Some endpoints may also fail to handle a connectivity check from an address that they have not received in signaling.  During the aforementioned experimental testing, the connection rate when interacting with endpoints that provided raw IP addresses (and therefore should be unaffected) decreased by 3% (relative), presumably for these reasons. </ins> 5.


and therefore distinct from the hostname transport address of the associated mDNS candidate, and as such MUST NOT be considered redundant per the guidance in RFC8445, Section 5.1.3.  To avoid <del> accidental IP address, this server-reflexive candidate MUST have its raddr field set to 0.0.0.0 and its rport field set to 0. </del>  Once an address has been identified as public, the ICE agent MAY cache this information and omit mDNS protection for that address in 3.1.2.3. The mDNS name of an mDNS candidate MUST be used in the connection- <del> address field of its candidate attribute.  When an mDNS candidate is the default candidate, its mDNS name MUST be used in the connection- address field of the SDP "c=" line.  Since an mDNS candidate also conceals its address family, the "c=" line SHOULD use "IP4" in the address-type field. </del>  Any candidates exposed to the application via local descriptions MUST be identical to those provided during candidate gathering (i.e., MUST

ping
NAME , PTAL
LGTM too
Currently it contains: c=IN IP4 address/ttl Obviously, putting one of the candidate's IP address there would defeat the purpose of use mDNS. Options: Can this be omitted? Should it have a fake IP address of the right address family? Should it be allowed to have an mDNS name?
Just use the mDNS name.
If we run into issues, we could use 0.0.0.0:9 as we do when there are no candidates, but that starts to get complicated (i.e. may require updates to other specs)
mDNS name with IP4?
good point - shouldn't matter that much, but IP4 seems like the safest choice.
Agreed to use mDNS + IP4. We'll reevaluate if this causes problems.
Fixed by
We have observed an interop issue in the experimental deployment. Endpoints can fail to parse the SDP when the c= line contains a FQDN. This is the current solution.
Well, at least we thought of the solution already :)

and therefore distinct from the hostname transport address of the associated mDNS candidate, and as such MUST NOT be considered redundant per the guidance in RFC8445, Section 5.1.3.  To avoid  <ins> accidental IP address disclosure, this server-reflexive candidate MUST have its raddr field set to "0.0.0.0"/"::" and its rport field set to "9", as discussed in ICESDP, Section 9.1. </ins> Once an address has been identified as public, the ICE agent MAY cache this information and omit mDNS protection for that address in 3.1.2.3. The mDNS name of an mDNS candidate MUST be used in the connection-  <ins> address field of its candidate attribute.  However, when an mDNS candidate would be the default candidate, typically because there are no other candidates, its mDNS name MUST NOT be used in the connection-address field of the SDP "c=" line, as experimental deployment has indicated that many remote endpoints will fail to handle such a SDP.  In this situation, the IP address values "0.0.0.0"/"::" and port value "9" MUST instead be used in the c= and m= lines, similar to how the no-candidates case is handled in ICESDP, Section 4.3.1. </ins> Any candidates exposed to the application via local descriptions MUST be identical to those provided during candidate gathering (i.e., MUST


as the hostname is expected to be unique, the ICE agent SHOULD skip probing of the hostname. <del> If registering of the mDNS hostname fails, abort these steps.  The candidate is not exposed. </del> Store the mDNS hostname and its related IP address in the ICE agent for future reuse. ICE agents can implement this procedure in any way as long as it produces equivalent results.  An implementation may for instance pre- <del> register mDNS hostnames by executing steps 3 to 6 and prepopulate an ICE agent accordingly.  By doing so, only step 7 of the above </del>  procedure will be executed at the time of gathering candidates. <del> An implementation may also detect that mDNS is not supported by the available network interfaces.  The ICE agent may skip steps 3 and 4 and directly decide to not expose the host candidate. </del>  This procedure ensures that an mDNS name is used to replace only one IP address.  Specifically, an ICE agent using an interface with both

Fixes URL
An implementation should probably expose mDNS candidates to a page regardless of successful registration or mDNS support in the network.

as the hostname is expected to be unique, the ICE agent SHOULD skip probing of the hostname.  Store the mDNS hostname and its related IP address in the ICE agent for future reuse. ICE agents can implement this procedure in any way as long as it produces equivalent results.  An implementation may for instance pre-  <ins> register mDNS hostnames by executing steps 3 to 5 and prepopulate an ICE agent accordingly.  By doing so, only step 6 of the above </ins> procedure will be executed at the time of gathering candidates.  <ins> In order to prevent web applications from using this mechanism to query for mDNS support in the local network, the ICE agent SHOULD still provide mDNS candidates in step 6 even if the local network does not support mDNS or mDNS registration fails in step 4. </ins> This procedure ensures that an mDNS name is used to replace only one IP address.  Specifically, an ICE agent using an interface with both


To prevent disclosure of the host IP address to a TURN server, the ICE agent MUST NOT form candidate pairs between its own relay <del> candidates and remote mDNS candidates.  Note that the converse is not an issue; the ICE agent MAY form candidate pairs between its own mDNS candidates and remote relay candidates, as in this situation host IPs will not be sent directly to the TURN server. </del>  This restriction has no effect on connectivity; in the cases where host IP addresses are private and need to be wrapped with mDNS names,

Fixes URL
It is required not to pair local relay candidates with remote mDNS candidates to avoid the leak via CreatePermission requests. As Phillip points in this issue (URL), an ICE agent should not rely on the candidate type field in a hostname candidate to reinforce this constraint. The a=candidate line in signaling can be modified to inject an arbitrary type. Suggest that we clarify the remote mDNS candidates include all hostname candidates with the .local pseudo-TLD.
Seems reasonable. The text does not restrict to "typ host", but being extra specific here would still be a good idea. Phillip also points out that we may want to do this for all DNS names, to prevent the browser from becoming a roundabout DNS resolver, but that is probably outside the scope of this document.

To prevent disclosure of the host IP address to a TURN server, the ICE agent MUST NOT form candidate pairs between its own relay  <ins> candidates and remote mDNS candidates.  This restriction must not be limited to remote mDNS candidates of a specific candidate type, typically host, as mDNS candidates are identified from their connection-address fields.  their connection-address field.  Note also that the converse is not an issue; the ICE agent MAY form candidate pairs between its own mDNS candidates and remote relay candidates, as in this situation host IPs will not be sent directly to the TURN server. </ins> This restriction has no effect on connectivity; in the cases where host IP addresses are private and need to be wrapped with mDNS names,