Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-iot-dns-considerations-08
Michael Richardson <mcr+ietf@sandelman.ca> Thu, 08 February 2024 19:51 UTC
Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB83C14CEF9; Thu, 8 Feb 2024 11:51:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsloqBef32FH; Thu, 8 Feb 2024 11:51:52 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16932C14F614; Thu, 8 Feb 2024 11:51:48 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C44BF3898D; Thu, 8 Feb 2024 14:51:47 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id h_KuKBJiDN9c; Thu, 8 Feb 2024 14:51:45 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 245DB3898C; Thu, 8 Feb 2024 14:51:45 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; s=mail; t=1707421905; bh=s+PyB4GrwwqpkxTBvKkvg26XO7gBV/GC7rFvOjxkTtM=; h=From:To:cc:Subject:In-Reply-To:References:Date:From; b=hfPecZZghIjeJE2kv/X1PkqcsLQNTMtOqQH8A9/9+F1psSTuKa4JiGNzKM9M/zpUr LnNbfiWe3bdNAQzJUU36okL0rwN5brrSGx56IFv5R6Ad5pSqgWH5NLPbYiR4iJjiKn 1ZjPPdWb5To3zuPvYPWrOHBFz4bt3FLiVXBP7PkRnzcep7rYL9n8diVs/miLu33iob XjS/pVlDp0PgalHoWYlJylQIXRxjCwY7+2ueIfioa6bWLrB4UgZqGUEtL2NrbsVrZw /XHFrvdFX1yUd+ChIZGFTRAIpO+YaZiJ/o5NJ0Dk/HCcxakQJmFpM3NAgWCyNH0tt3 vaE3J6kG2JPhQ==
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1BE1A2B3; Thu, 8 Feb 2024 14:51:45 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>, "opsawg@ietf.org" <opsawg@ietf.org>
cc: "draft-ietf-opsawg-mud-iot-dns-considerations@ietf.org" <draft-ietf-opsawg-mud-iot-dns-considerations@ietf.org>, Eliot Lear <lear@lear.ch>, Toerless Eckert <tte@cs.fau.de>, Mahesh Jethanandani <mjethanandani@gmail.com>
In-Reply-To: <LV8PR11MB853690BAFD9A35FFBA745C9BB5472@LV8PR11MB8536.namprd11.prod.outlook.com>
References: <BY5PR11MB419663E50375EFC179E7CE65B5D2A@BY5PR11MB4196.namprd11.prod.outlook.com> <12876.1697643420@localhost> <BY5PR11MB4196CE6084B4DC26BD0EC11EB5DBA@BY5PR11MB4196.namprd11.prod.outlook.com> <25964.1698074879@localhost> <a730368b-886c-402a-9fcb-717622c0cce4@lear.ch> <ZTmYaTXQDphVbR5n@faui48e.informatik.uni-erlangen.de> <3097919.1698327837@dyas> <ZTpwsJsn0aBcJkai@faui48e.informatik.uni-erlangen.de> <17967.1698356948@localhost> <ZTrmUnxmtdu6phZa@faui48e.informatik.uni-erlangen.de> <LV8PR11MB853690BAFD9A35FFBA745C9BB5472@LV8PR11MB8536.namprd11.prod.outlook.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 28.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
X-Attribution: mcr
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Thu, 08 Feb 2024 14:51:45 -0500
Message-ID: <10878.1707421905@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/PYFqi1RyKciTHv--oN-DI9KOJPM>
Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-iot-dns-considerations-08
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Feb 2024 19:51:57 -0000
{noting that you reviewed -08, and we are up to -10 since, so some of your comments/text are no longer applicable} Rob Wilton (rwilton) <rwilton@cisco.com> wrote: > I’ve just re-reviewed -10.I still think that the English to be cleaned > up further. I know that the RFC editor would likely find and fix most okay. > Minor level comments: > (1) p 2, sec 1. Introduction > [RFC8520] provides a standardized way to describe how a specific > purpose device makes use of Internet resources. Access Control > Lists > (ACLs) can be defined in an RFC8520 Manufacturer Usage Description > (MUD) file that permit a device to access Internet resources by DNS > name. > "specific purpose device" sounds like slight strange phrasing to me. As previously discussed for acceptable-urls, this comes from RFC8520, although that document does not use those exact words. I'd sure like a comment from Eliot about whether this is the way to explain MUD. > (2) p 2, sec 1. Introduction > Use of a DNS name rather than IP address in the ACL has many > advantages: not only does the layer of indirection permit the > mapping > of name to IP address to be changed over time, it also generalizes > automatically to IPv4 and IPv6 addresses, as well as permitting > loading balancing of traffic by many different common ways, > including > multi-CDN deployments wherein load balancing can account for > geography and load. > "many different common ways" sounds like strange phrasing to me. How > can something be both different and common, which do you mean? rewritten to: } generalizes automatically to IPv4 and IPv6 addresses, as well as } permitting a variety of load balancing strategies, including multi-CDN } deployments wherein load balancing can account for geography and } load. > (3) p 2, sec 1. Introduction > At the MUD policy enforcement point -- the firewall -- there is a > problem. The firewall has only access to the layer-3 headers of the > packet. This includes the source and destination IP address, and if > not encrypted by IPsec, the destination UDP or TCP port number > present in the transport header. The DNS name is not present! > "önly access" -> "äccess only" fixed. > (4) p 2, sec 1. Introduction > It has been suggested that one answer to this problem is to provide > a > forced intermediate for the TLS connections. This could in theory > be > done for TLS 1.2 connections. The MUD policy enforcement point > could > observe the Server Name Identifier (SNI) [RFC6066]. Some > Enterprises > do this already. But, as this involves active termination of the > TCP > connection (a forced circuit proxy) in order to see enough of the > traffic, it requires significant effort. > "This could in theory be done" => "In theory, this could be done", or > "This could, in theory, be done". fixed. > (5) p 3, sec 1. Introduction > The second section of this document details how common manufacturer > anti-patterns get in the way of this mapping. > The third section of this document details how current trends in DNS > resolution such as public DNS servers, DNS over TLS (DoT), DNS over > QUIC (DoQ), and DNS over HTTPS (DoH) cause problems for the > strategies employed. Poor interactions with content-distribution > networks is a frequent pathology that can result. > Do you really mean pathology here? "the scientific study of disease" or "a disease or medical condition:" I certainly do not mean the first, but I do mean it results in a disease. I'm going to just remove the sentence. > (6) p 3, sec 1. Introduction > The fourth section of this document makes a series of > recommendations > ("best current practices") for manufacturers on how to use DNS and > IP > addresses with specific purpose IoT devices. > Perhaps just "with MUD supporting IoT devices". Otherwise what is the > difference between a general purpose IoT device and a specific purpose > IoT device? okay. > (7) p 3, sec 3. Strategies to map names > The most naive method is to try to map IP addresses to names using > the in-addr.arpa (IPv4), and ipv6.arpa (IPv6) mappings. > For readability, it might be helpful to indicate when this mapping > would occur. ...ipv6.arpa (IPv6) mappings at the time the packet is seen. > (8) p 4, sec 3.1.1. Too slow > While subsequent connections to the same site (and subsequent > packets > in the same flow) will not be affected if the results are cached, > the > effects will be felt. The ACL results can be cached for a period of > time given by the TTL of the DNS results, but the lookup must be > performed again in a number of hours to days. > Please consider whether it would read better as: "but the DNS lookup > must be repeated, e.g., in a few hours or days, when the cached IP > address to name binding expires." okay. now: } The ACL results can be cached for a period of time given by the TTL } of the DNS results, but the DNS lookup must be repeated, e.g, in a few } hours or days,when the cached IP address to name binding expires. > (9) p 4, sec 3.1.2. Reveals patterns of usage > By doing the DNS lookups when the traffic occurs, then a passive > attacker can see when the device is active, and may be able to > derive > usage patterns. They could determine when a home was occupied or > not. This does not require access to all on-path data, just to the > DNS requests to the bottom level of the DNS tree. > Is it worth mentioning that there are now mechanisms available (like > DoH, or Ohttp that can be used to mitigate this)? I'm not convinced that ohttp will be ubiquitously available enough to be useful to *MUD controllers*. What is the business case for running ohttp independently of a browser, or OS vertical? Anyway, this section is about things that don't work. Making them work slightly less bad seems not worth explaining. > (10) p 6, sec 3.2. A successful strategy > In order to compensate for this, the MUD controller SHOULD regularly > perform DNS lookups in order to never have stale data. These > lookups > must be rate limited to avoid excessive load on the DNS servers, and > it may be necessary to avoid local recursive resolvers. The MUD > controller SHOULD incorporate its own recursive caching DNS server. > Properly designed recursive servers should cache data for many > minutes to days, while the underlying DNS data can change at a > higher > frequency, providing different answers to different queries! > I suggest changing "for many minutes to days" to "for at least some > number of minutes, up to some number of days". okay. > (11) p 8, sec 4.1. Use of IP address literals in-protocol > The second reason to avoid a DNS in the URL is when an inhouse > content-distribution system is involved that involves on-demand > instances being added (or removed) from a cloud computing > architecture. > Should it be "avoid in IP address literal in the URL"? Also, inhouse > => in-house. Hmm. I guess so. The point is that when instances/come go really fast, it can seem to be hard to refer to them quickly using names rather than IP addresses. Maybe this can be more clearly explained by a CDN person. > (12) p 9, sec 4.1. Use of IP address literals in-protocol > Finally, third-party content-distribution networks (CDN) tend to use > DNS names in order to isolate the content-owner from changes to the > distribution network. > A non-deterministic name or address that is returned within the > update protocol, the MUD controller is unable to know what the name > is. It is therefore unable to make sure that the communication to > retrieve the new firmware is permitted by the MUD enforcement point. > The first sentence above doesn't make sense to me, please can it be > rephrased. I have rewritten this to: } Finally, it is common in some content-distribution networks (CDN) to } use multiple layers of DNS CNAMEs in order to isolate the } content-owner's naming system from changes in how the distribution } network is organized. As an example of what I'm talking about, I recently came across: dyas-[~](2.6.6) mcr 10001 %host login.my.gov.nl.ca login.my.gov.nl.ca is an alias for gnlprod.azurefd.net. gnlprod.azurefd.net is an alias for azurefd-t-prod.trafficmanager.net. azurefd-t-prod.trafficmanager.net is an alias for shed.dual-low.part-0008.t-0009.t-msedge.net. shed.dual-low.part-0008.t-0009.t-msedge.net is an alias for part-0008.t-0009.t-msedge.net. and you just can't do this kind of thing with an IP address :-) > (13) p 10, sec 4.2. Use of non-deterministic DNS names in-protocol > The firmware vendor is therefore likely to be asked to point a CNAME > to the CDN network, to a name that might look like "g7.a.example", > with the expectation that the CDN vendors DNS will do all the > appropriate work to geolocate the transfer. This can be fine for a > MUD file, as the MUD controller, if located in the same geography as > the IoT device, can follow the CNAME, and can collect the set of > resulting IP addresses, along with the TTL for each. The MUD > controller can then take charge of refreshing that mapping at > intervals driven by the TTL. > In some cases, a complete set of geographically distributed servers > is known at ahead of time, and the firmware vendor can list all of > those addresses in the name that it lists in the MUD file. As long > as the active set of addresses used by the CDN is a strict subset of > that list, then the geolocated name can be used for the firmware > download itself. This use of two addresses is ripe for confusion > however. > Where are the addresses being listed? In the DNS or with the CDN? the addresses are listed in the DNS reply. While strongly geofenced zones will return a single reply: dyas-[lwork/opsawg/iot-mud-dns-considerations](2.6.6) mcr 10032 %host google.com google.com has address 172.217.13.110 google.com has IPv6 address 2607:f8b0:4020:804::200e others will return a long list of all possible addresses, and often the order will be rotated in the hope the client will use the first one, creating some amount of round-robin load balancing. dyas-[lwork/opsawg/iot-mud-dns-considerations](2.6.6) mcr 10036 %host microsoft.com microsoft.com has address 20.112.250.133 microsoft.com has address 20.231.239.246 microsoft.com has address 20.76.201.171 microsoft.com has address 20.70.246.20 microsoft.com has address 20.236.44.162 microsoft.com has IPv6 address 2603:1030:b:3::152 microsoft.com has IPv6 address 2603:1030:20e:3::23c microsoft.com has IPv6 address 2603:1030:c02:8::14 microsoft.com has IPv6 address 2603:1020:201:10::10f microsoft.com has IPv6 address 2603:1010:3:3::5b microsoft.com mail is handled by 10 microsoft-com.mail.protection.outlook.com. (there are longer answers I've seen which even push the answer to TCP, but I suspect that this results in poorer results and operators back off from that) I've rewritten: } In some cases, a complete set of geographically distributed servers } is known at ahead of time, and the firmware vendor can list all of } those addresses DNS for the the name that it lists in the MUD file. > (14) p 10, sec 4.3. Use of a too generic DNS name > Some CDNs make all customer content at a single URL (such as > s3.amazonaws.com) This seems to be ideal from a MUD point of view: > a completely predictable URL. > "Make all customer content at" => "Make all customer content available > at" fixed. > (15) p 11, sec 6. Recommendations to IoT device manufacturer on MUD > and DNS usage > The difficult part is determining what to put into the MUD file > itself. There are currently tools that help with the definition and > analysis of MUD files, see [mudmaker]. The remaining difficulty is > now the semantic contents of what is in the MUD file. An IoT > manufacturer must now spend some time reviewing the network > communications by their device. > Could "The remaining difficulty is now the semantic contents of what is > in the MUD file." is a bit vague, could it be more precisely explained > please? now: } The remaining difficulty is now the actual list of expected connections to put in the MUD file. > (16) p 12, sec 6.5. Prefer DNS servers learnt from DHCP/Route > Advertisements > The ADD WG has written [I-D.ietf-add-dnr] and [I-D.ietf-add-ddr] to > provided. > This sentence doesn't scan. } The ADD WG has written {{?I-D.ietf-add-dnr}} and } {{?I-D.ietf-add-ddr}} to provide information to end devices on how to } find locally provisioned secure/private DNS servers. > (17) p 12, sec 7. Privacy Considerations > The use of DoT and DoH eliminates the threat from passive > eavesdropping, but still exposes the list to the operator of the DoT > or DoH server. There are additional methods, such as described by > [RFC9230]. > Perhaps "There are additional methods to help preserve privacy, such as > ..." fixed. > (18) p 13, sec 7. Privacy Considerations > The use of DoT and DoH eliminates the threat from passive > eavesdropping, but still exposes the list to the operator of the DoT > or DoH server. There are additional methods, such as described by > [RFC9230]. > The use of unencrypted (Do53) requests to a local DNS server exposes > the list to any internal passive eavesdroppers, and for some > situations that may be significant, particularly if unencrypted WiFi > is used. Use of Encrypted DNS connection to a local DNS recursive > resolver is a preferred choice. > Use of an Encrypted ... is the preferred choice. fixed. > Nit level comments: > (19) p 4, sec 3.1.3. Mappings are often incomplete > In some cases there are multiple layers of CNAME between the > original > name and the target service name. This is often due to a layer of > load balancing in DNS, followed by a layer of load balancer at the > HTTP level. > "Load balancing layer in the DNS" and "Load balancing layer at the HTTP > level" would probably read better. fixed. > (20) p 7, sec 3.2. A successful strategy > 3. if any addresses have been omitted in a round-robin DNS process, > the cache will have the set of addresses that were returned. > Possibly, "the same set of addresses"? fixed. > (21) p 10, sec 4.2. Use of non-deterministic DNS names in-protocol > The firmware vendor is therefore likely to be asked to point a CNAME > to the CDN network, to a name that might look like "g7.a.example", > with the expectation that the CDN vendors DNS will do all the > appropriate work to geolocate the transfer. This can be fine for a > MUD file, as the MUD controller, if located in the same geography as > the IoT device, can follow the CNAME, and can collect the set of > resulting IP addresses, along with the TTL for each. The MUD > controller can then take charge of refreshing that mapping at > intervals driven by the TTL. > In some cases, a complete set of geographically distributed servers > is known at ahead of time, and the firmware vendor can list all of > those addresses in the name that it lists in the MUD file. As long > as the active set of addresses used by the CDN is a strict subset of > that list, then the geolocated name can be used for the firmware > download itself. This use of two addresses is ripe for confusion > however. > at ahead of time => ahead of time. all of those => all those fixed. > (22) p 13, sec 7. Privacy Considerations > The use of a publically specified firmware update protocol would > also > enhance privacy of IoT devices. In such a system the IoT device > would never contact the manufacturer for version information or for > firmware itself. Instead, details of how to query and where to get > the firmware would be provided as a MUD extension, and an > Enterprise- > wide mechanism would retrieve firmware, and then distribute it > internally. Aside from the bandwidth savings of downloading the > firmware only once, this also makes the number of devices active > confidential, and provides some evidence about which devices have > been upgraded and which ones might still be vulnerable. (The > unpatched devices might be lurking, powered off, lost in a closet) > publically => publicly fixed. (Is that a US/English thing? Or just me being educated to spell in french first) > (23) p 13, sec 7. Privacy Considerations > The use of a publically specified firmware update protocol would > also > enhance privacy of IoT devices. In such a system the IoT device > would never contact the manufacturer for version information or for > firmware itself. Instead, details of how to query and where to get > the firmware would be provided as a MUD extension, and an > Enterprise- > wide mechanism would retrieve firmware, and then distribute it > internally. Aside from the bandwidth savings of downloading the > firmware only once, this also makes the number of devices active > confidential, and provides some evidence about which devices have > been upgraded and which ones might still be vulnerable. (The > unpatched devices might be lurking, powered off, lost in a closet) > In such a system the => In such a system, the fixed. > Spellings: inhouse, inprotocol, middleboxes is "in-protocol" wrong? > Grammar Warnings: > Section: 3.1.3, draft text: To limit churn of DNS PTR records, and > reduce failures of the MUD ACLs, operators would want to add all > possible names for each reverse name, whether or not the DNS load > balancing in the forward DNS space lists that end-point at that moment. > Warning: Consider shortening this phrase to just 'whether', unless you > mean 'regardless of whether'. Suggested change: "whether" I think I stick with what I have. > Section: 3.1.4, draft text: For instance, github.io, which is used for > hosted content, including the Editors' copy of internet drafts stored > on github, does not actually publish any names. Warning: The official > name of this software platform is spelled with a capital "H". > Suggested change: "GitHub" DNS name. > Section: 3.1.4, draft text: Instead a wildcard exists to answer all > potential names: requests are routed appropriate once they are > received. Warning: A comma may be missing after the > conjunctive/linking adverb 'Instead'. Suggested change: "Instead," okay. > Section: 3.2, draft text: The MUD controller and the device get a > matching set, and the ACLs that are setup cover all possibilities. > Warning: The verb 'set up' is spelled as two words. The noun 'setup' is > spelled as one. Suggested change: "set up" okay. > Section: 3.2, draft text: The simplest is when the round robin does not > return all addresses. Warning: This word is normally spelled with a > hyphen. Suggested change: "round-robin" okay. > Section: 4.1, draft text: A common pattern for a number of devices is > to look for firmware updates in a two step process. Warning: This word > is normally spelled with a hyphen. Suggested change: "two-step" okay. > Section: 4.1, draft text: An initial query is made (often over HTTPS, > sometimes with a POST, but the method is immaterial) to a vendor system > that knows whether or not an update is required. Warning: Consider > shortening this phrase to just 'whether', unless you mean 'regardless > of whether'. Suggested change: "whether" okay. > Section: 4.1, draft text: The current firmware model of the device is > sometimes provided and then the authoritative server provides a > determination if a new version is required, and if so, what version. > Warning: Use a comma before "and" if it connects two independent > clauses (unless they are closely connected and short). Suggested > change: ", and" okay. > Section: 4.2, draft text: Even if the content provider chosen names are > deterministic they may change at a rate much faster then MUD files can > be updated. Warning: Did you mean faster than? Suggested change: > "faster than" fixed. > Section: 4.2, draft text: This use of two addresses is ripe for > confusion however. Warning: Consider inserting a comma before > 'however'. Suggested change: ", however" fixed. > Section: 4.3, draft text: Exactly what the risk is depends upon what > the other customers are doing: it could be limited to simply causing a > distributed denial of service attack resulting in high costs to those > customers, or such an attack could potentially include writing content. > Warning: It appears that hyphens are missing. Suggested change: > "denial-of-service" okay. > Section: 6, draft text: It can even be done without code changes via > the use of a QR code affixed to the packaging (see [RFC9238]. Warning: > Unpaired symbol: ')' seems to be missing closing added... > Section: 6.2, draft text: While it used to be costly to have a large > number of aliases in a web server certificate, this is no longer the > case. Warning: Specify a number, remove phrase, or simply use many or > numerous Suggested change: "many" I think i'm fine. > Section: 6.5, draft text: The ADD WG has written [I-D.ietf-add-dnr] and > [I-D.ietf-add-ddr] to provided. Warning: The verb after "to" should be > in the base form. Suggested change: "provide" fixed. > Section: 7, draft text: The use of unencrypted (Do53) requests to a > local DNS server exposes the list to any internal passive > eavesdroppers, and for some situations that may be significant, > particularly if unencrypted WiFi is used. Warning: Did you mean Wi-Fi? > (This is the officially approved term by the Wi-Fi Alliance.) > Suggested change: "Wi-Fi" okay. Posting new version in two minutes. -- Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
- [OPSAWG] AD review of draft-ietf-opsawg-mud-iot-d… Rob Wilton (rwilton)
- Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-i… Michael Richardson
- Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-i… Michael Richardson
- Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-i… mohamed.boucadair
- Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-i… Rob Wilton (rwilton)
- Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-i… Michael Richardson
- Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-i… Michael Richardson
- Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-i… Eliot Lear
- Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-i… Michael Richardson
- Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-i… Toerless Eckert
- Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-i… Michael Richardson
- Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-i… Toerless Eckert
- Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-i… Michael Richardson
- Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-i… Toerless Eckert
- Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-i… Rob Wilton (rwilton)
- Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-i… Michael Richardson
- Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-i… Qin Wu
- Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-i… Michael Richardson
- Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-i… Qin Wu
- Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-i… Michael Richardson
- Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-i… Michael Richardson
- Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-i… Rob Wilton (rwilton)
- Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-i… Michael Richardson