Re: [homenet] The HOMENET WG has placed draft-tldm-simple-homenet-naming in state "Call For Adoption By WG Issued"
I have read homenet-naming. It wasn't quite the document I was expecting. But rather seems to leverage upon a number of other draft-sctl* documents in progress. What are the plans for draft-sctl-*? and then there is draft-ietf-mid-mpvd-ndp-support as a normative reference. Will homenet will to adopt that too? So it seems that I have to read the other documents in detail before I can make any clear opinion as to how this all fits together. (I think I've missed the last two homenet WG meetings due to conflicts; I should watch them on meetecho recording to learn more I guess) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] The HOMENET WG has placed draft-tldm-simple-homenet-naming in state "Call For Adoption By WG Issued"
> It wasn't quite the document I was expecting. But rather seems to > leverage upon a number of other draft-sctl* documents in progress. I agree with Michael -- this is not a protocol definition, it is an informal outline of how a number of other protocols can be made to fit together. It has normative dependencies on no less than 5 different -sctl- drafts, none of which have been adopted by dnssd yet. I believe that it would be premature to adopt this document. Let us please wait and see whether dnssd decides to adopt the depended-upon drafts. Let us also see whether the implementation complexity is manageable, and whether the large number of moving parts causes undesired brittleness. I have some other fairly serious nits about this document, but I believe that the argument above is sufficient. I am opposed to adoption at this stage, but look forward to reconsidering once dnssd has had a serious look at the protocols. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] The HOMENET WG has placed draft-tldm-simple-homenet-naming in state "Call For Adoption By WG Issued"
Hi, > On 30 Jul 2017, at 18:19, Michael Richardson wrote: > > I have read homenet-naming. > > It wasn't quite the document I was expecting. > But rather seems to leverage upon a number of other draft-sctl* documents in > progress. > > What are the plans for draft-sctl-*? I don’t think they’re cited in this draft. Many of them are over in the dnssd WG. See Stuart’s deck from Prague for context: https://www.ietf.org/proceedings/99/slides/slides-99-dnssd-dns-sd-update-and-new-work-items-00.pdf > and then there is draft-ietf-mid-mpvd-ndp-support as a normative reference. > Will homenet will to adopt that too? > > So it seems that I have to read the other documents in detail before I can > make any clear opinion as to how this all fits together. > (I think I've missed the last two homenet WG meetings due to conflicts; I > should watch them on meetecho recording to learn more I guess) It turned out that only 4 people had time to read them for Prague. The interesting twist is the pushback on multicast for future specs. I agree it’s early for an adoption call, likewise for the draft-sctl-* drafts in dnssd. Tim > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] The HOMENET WG has placed draft-tldm-simple-homenet-naming in state "Call For Adoption By WG Issued"
> I have some other fairly serious nits about this document, but I believe > that the argument above is sufficient. I am opposed to adoption at this > stage, but look forward to reconsidering once dnssd has had a serious look > at the protocols. I didn't want the point of the previous mail to be diluted by a list of nits, so I've kept it short. Here are just some of the more serious issues I've noticed when doing a first read of the document. Please be aware that even if these issues were resolved, I would not necessarily support adoption. > 1. Introduction > o Provisioning of a domain name under which names can be published >and services advertised This document doesn't mention HNCP's mechanisms to do that. Either this document updates HNCP to not provision a domain name, in which case it should say so, or it relies on HNCP's mechanism, in which case it should say so. > 1. Some names may be published in a broader scope than others. This implies that the local and global publication mechanism are the same, which does not reflect WG consensus as far as I am aware. I've already mentioned on this list that I believe that local and global naming should use different mechanisms -- by merging the two, you're converting two tractable problems into one that is difficult. > 6. Homenet explicitly supports multihoming--connecting to more than > one Internet Service Provider--and therefore support for multiple > provisioning domains [6] is required to deal with situations > where the DNS may give a different answer depending on whether > caching resolvers at one ISP or another are queried. This implies that mpvd is the preferred mechanism. As far as I know, this does not reflect WG consensus. > 3.1. Configuring Resolvers > Hosts on the homenet receive a set of resolver IP addresses using > either DHCP or RA. IPv4-only hosts will receive IPv4 addresses of > resolvers, if available, over DHCP. IPv6-only hosts will receive > resolver IPv6 addresses using either stateful (if available) or > stateless DHCPv6, or through the domain name option in router > advertisements. All homenet routers provide resolver information > using both stateless DHCPv6 and RA; support for stateful DHCPv6 and > DHCPv4 is optional, however if either service is offered, resolver > addresses will be provided using that mechanism as well. Either this restates the requirements in RFC 7788, in which case it must say so, or it updates RFC 7788, in which case it must say in what way. > every HNR is required to provide name resolution service. I do not believe that this reflects WG consensus. (Speaking as the author of shncpd -- I think it's a bad idea.) > 3.3. Resolution of local names > IP addresses and names advertised locally MUST use addresses in the > homenet's ULA prefix and/or RFC1918 prefix. I do not understand this requirement. Is it about direct or reverse resolution? > Homenet hybrid proxies MUST filter out global IP addresses, providing > only ULA addresses, Is this a restatement of the requirement above, or is it a new requirement? > Artificial link names will be generated using HNCP. These should only > be visible to the user in graphical user interfaces in the event that > the same name is claimed by a service on two links. It is not our job to standardise the behaviour of GUIs. If such advice is desired, it should go into an informative appendix. > 3.5. Support for Multiple Provisioning Domains > Homenets must support the Multiple Provisioning Domain Architecture [6]. As mentioned at the beginning of this mail, this does not represent WG consensus. > In order to support this architecture, each homenet router that > provides name resolution must provide one resolver for each > provisioning domain (PvD). Each homenet router will advertise one > resolver IP address for each PvD. So not only does this document require having a DNS proxy on each router, but it actually requires a complex form of split horizon. I believe the WG should think the consequences very carefully before committing to such a path. (Speaking as the author of shncpd -- this is out of the question as far as I'm concerned.) > When queries are made to the homenet-PvD-specific resolver for names > that are not local to the homenet, the resolver will use a round-robin > technique, alternating between service providers with each step in the > round-robin process, This is exactly the wrong thing to do, since it makes the Homenet resolver as unreliable as the most unreliable of the providers' resolvers. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] The HOMENET WG has placed draft-tldm-simple-homenet-naming in state "Call For Adoption By WG Issued"
Tim Chown wrote: > See Stuart’s deck from Prague for context: > https://www.ietf.org/proceedings/99/slides/slides-99-dnssd-dns-sd-update-and-new-work-items-00.pdf >> and then there is draft-ietf-mid-mpvd-ndp-support as a normative reference. >> Will homenet will to adopt that too? >> >> So it seems that I have to read the other documents in detail before I can >> make any clear opinion as to how this all fits together. >> (I think I've missed the last two homenet WG meetings due to conflicts; I >> should watch them on meetecho recording to learn more I guess) > It turned out that only 4 people had time to read them for Prague. > The interesting twist is the pushback on multicast for future specs. > I agree it’s early for an adoption call, likewise for the draft-sctl-* > drafts in dnssd. Actually, if the relevant draft-sctl-* drafts were clearly about to adopted by dnssd, then I would have no problem with the timing of the adoption call. (I don't know: I'm truly ignorant here. I can't read every ML and attend every WG session, sadly) The document does not, as Juliuz says, define a protocol, but it does provide a clear profile on how to use other work. I'm also fond of adopting a document as soon as it looks like the table of contents is sane :-) But, the question as to: > and then there is draft-ietf-mif-mpvd-ndp-support as a normative reference. concerns me most. Unless it's in RFC-editor queue (it's not, it's expired!), I'm pretty sure it's a very much normative reference. So Homenet needs an answer as to how to deal with this dependancy. It seems that we'd need to adopt it, copy and paste the text into this document, or reboot MIF... -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt
DNSSEC describes the delegation as "insecure". Old: In addition, it's necessary, for compatibility with DNSSEC (Section 6), that an unsigned delegation be present for the name. There is an existing process for allocating names under '.arpa' [RFC3172]. No such process is available for requesting a similar delegation in the root at the request of the IETF, which does not administer that zone. As a result, the use of '.home' is deprecated. New: In addition, it's necessary, for compatibility with DNSSEC (Section 6), that an insecure delegation be present for the name. There is an existing process for allocating names under '.arpa' [RFC3172]. No such process is available for requesting a similar delegation in the root at the request of the IETF, which does not administer that zone. As a result, the use of '.home' is deprecated. Paragraph 5 doesn't read well and won't match reality once the insecure delegation of home.arpa is in place. 5. No special processing of 'home.arpa.' is required for authoritative DNS server implementations. It is possible that an authoritative DNS server might attempt to check the authoritative servers for 'home.arpa.' for a delegation beneath that name before answering authoritatively for such a delegated name. In such a case, because the name always has only local significance there will be no such delegation in the 'home.arpa.' zone, and so the server would refuse to answer authoritatively for such a zone. A server that implements this sort of check MUST be configurable so that either it does not do this check for the 'home.arpa.' domain, or it ignores the results of the check. The delegatation is INSECURE and SIGNED not UNSIGNED. The wording here is *important*. Old: 7. Delegation of 'home.arpa.' In order to be fully functional, there must be a delegation of 'home.arpa.' in the '.arpa.' zone [RFC3172]. This delegation MUST NOT be signed, MUST NOT include a DS record, and MUST point to one or more black hole servers, for example 'blackhole-1.iana.org.' and 'blackhole-2.iana.org.'. The reason that this delegation must not be signed is that not signing the delegation breaks the DNSSEC chain of trust, which prevents a validating stub resolver from rejecting names published under 'home.arpa.' on a homenet name server. New: 7. Delegation of 'home.arpa.' In order to be fully functional, there must be a delegation of 'home.arpa.' in the '.arpa.' zone [RFC3172]. This delegation MUST be insecure, MUST NOT include a DS record, and MUST point to one or more black hole servers, for example 'blackhole-1.iana.org.' and 'blackhole-2.iana.org.'. The reason that this delegation must be insecure is that it breaks the DNSSEC chain of trust, which prevents a validating stub resolver from rejecting names published under 'home.arpa.' on a homenet name server. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
