Subject: [homenet] The HOMENET WG has placed draft-tldm-simple-homenet-naming in state "Call For Adoption By WG Issued"

From: IETF Secretariat <[email-masked]>
Date: Fri, 28 Jul 2017 06:04:52 -0700

The HOMENET WG has placed draft-tldm-simple-homenet-naming in state
Call For Adoption By WG Issued (entered by Barbara Stark)

The document is available at
https://datatracker.ietf.org/doc/draft-tldm-simple-homenet-naming/

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 28 Jul 2017 13:22:37 +0000

Hi homenet,
Thanks to all of you for your well-wishes and congratulations (and condolences) for my new role as a homenet chair.
As my first official act, under the excellent tutelage of Ray, I'm launching a 2 week Call for Adoption on draft-tldm-simple-homenet-naming. The call will end August 11. 
Please read the draft (if you haven't done so already), and express your thoughts on whether and why we should adopt this draft. 

And don't forget to yell at me whenever I do anything wrong! I'm new to all this IETF chairing process and fully expect to make all sorts of new and exciting mistakes.
Barbara

> -----Original Message-----
> From: IETF Secretariat [mailto:[email-masked]]
> Sent: Friday, July 28, 2017 9:05 AM
>

---

From: james woodyatt <[email-masked]>
Date: Fri, 28 Jul 2017 10:32:19 -0700

On Jul 28, 2017, at 06:04, IETF Secretariat <[email-masked]> wrote:
> 
> The HOMENET WG has placed draft-tldm-simple-homenet-naming in state Call For Adoption By WG Issued (entered by Barbara Stark)

I can support adoption, but I have some criticisms to raise before it goes to last call.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: Michael Richardson <[email-masked]>
Date: Sun, 30 Jul 2017 13:19:41 -0400

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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 30 Jul 2017 20:01:34 +0200

> 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

---

From: Tim Chown <[email-masked]>
Date: Sun, 30 Jul 2017 19:49:20 +0000

Hi,

> On 30 Jul 2017, at 18:19, Michael Richardson <[email-masked]> wrote:
> 

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

> 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

> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 30 Jul 2017 23:10:13 +0200

> stage, but look forward to reconsidering once dnssd has had a serious look

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

---

From: Michael Richardson <[email-masked]>
Date: Sun, 30 Jul 2017 21:20:56 -0400

> I agree it’s early for an adoption call, likewise for the draft-sctl-*

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...

---

From: Ted Lemon <[email-masked]>
Date: Mon, 31 Jul 2017 05:53:07 -0400

> adopt it, copy and paste the text into this document, or reboot MIF...

There was widespread agreement in INTAREA to adopt this:

https://tools.ietf.org/html/draft-bruneau-intarea-provisioning-domains-02 <https://tools.ietf.org/html/draft-bruneau-intarea-provisioning-domains-02>

I actually intended to reference this—I just got my wires crossed because google gave me the link to the other one, which as you say is dead.

The current rev of the homenet naming architecture is pretty thin—I put a lot of work into the dnssd stuff, because I wanted to have it pretty solid before referencing it in the MPVD architecture document.   If you weren't in homenet, it might indeed be worth reviewing my presentation in the meetecho.   Stuart's presentation in dnssd might also be worth reviewing.

Anyway, a consequence of the emphasis on the dnssd work is that I had about an hour to update the naming architecture document before the submission deadline, and the update is minimal, to be as charitable as possible.

Daniel wanted to do another update, but we needed to sync up first, and I don't know where he is at with that now, but I think it would be reasonable to put the CFA on hold pending that update.   There have been some good comments already, though; in particular, I think Juliusz' point that it would be nice to actually try some of this in practice is good, and is what I'm working on now.   I think having that done before the document is adopted is a pretty high bar, but I don't really care either way.

That said, what I said in the working group is that we've been spinning our wheels on this for several years, and I wanted to know if the scope of this is reasonable and is what the working group wants to take on.   If it's not, then I don't actually know how to proceed.

(BTW, Juliusz, yes, HNCP is where the domain name is agreed upon.)

---

From: Ray Bellis <[email-masked]>
Date: Mon, 31 Jul 2017 11:00:20 +0100

On 31/07/2017 10:53, Ted Lemon wrote:

> Daniel wanted to do another update, but we needed to sync up first, and
> I don't know where he is at with that now, but I think it would be
> reasonable to put the CFA on hold pending that update.   There have been
> some good comments already, though; in particular, I think Juliusz'
> point that it would be nice to actually try some of this in practice is
> good, and is what I'm working on now.   I think having that done before
> the document is adopted is a pretty high bar, but I don't really care
> either way.
> 
> That said, what I said in the working group is that we've been spinning
> our wheels on this for several years, and I wanted to know if the scope
> of this is reasonable and is what the working group wants to take on.  
> If it's not, then I don't actually know how to proceed.

The point of a CFA is not to have a document that's nearly ready to publish.

It's to get agreement that a document is an appropriate direction for
the WG to explore, even if it might require substantial work.

As part of that, adoption also cedes change control from the authors to
the WG.

I'd therefore like to leave this in place for now, and request that
reviewers re-examine it bearing the above in mind.

thanks,

Ray

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 31 Jul 2017 13:36:03 +0200

> I wanted to know if the scope of this is reasonable and is what the
> working group wants to take on.

I think the scope of this is too wide.  It tries to solve a number of
different problems:

  1. naming within the Homenet;
  2. publishing names of Homenet nodes outside the Homenet;
  3. resolving names outside the Homenet in the presence of multiple providers;
  4. announcing multiple providers' naming spaces when the providers
     provide inconsistent information.

My gut feeling is that if you insist on a single protocol that solves all
four, you'll end up with more complexity than if you solve each problem on
its own.

> If it's not, then I don't actually know how to proceed.

I suggest picking just one problem and solving it.  (1) in the above list
would be the obvious choice.

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Mon, 31 Jul 2017 08:09:07 -0400

This is an architecture document, not a protocol specification.

---

From: Tim Chown <[email-masked]>
Date: Mon, 31 Jul 2017 12:21:58 +0000

Hi,

I’d recommend people who are interested in this topic read draft-cheshire-dnssd-roadmap-00, which you might miss if just looking at the draft-sctl-* drafts.

Tim

> On 31 Jul 2017, at 13:09, Ted Lemon <[email-masked]> wrote:
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 31 Jul 2017 10:07:49 -0400

Ted Lemon <[email-masked]> wrote:
    > to put the CFA on hold pending that update. There have been some good
    > comments already, though; in particular, I think Juliusz' point that it
    > would
    > be nice to actually try some of this in practice is good, and is what
    > I'm

We require interoperable implementations for Internet Standard, not to adopt
a document.  Implementation reports would be good for WGLC, not here!
We need to lower the bar here, not raise it.  WGs can abandon documents too.

    > of this is reasonable and is what the working group wants to take
    > on. If it's not,
    > then I don't actually know how to proceed.

I think that it's the right approach, and given the sort out of the MVDP,
I support adoption.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [