Re: [homenet] Introduction to draft-ietf-homenet-simple-naming

[Andrew Sullivan <[e-mail]>]

Hi,

Thanks for doing this.  Some comments inline.  These may seem a little
picky in a few cases, but I figure it's better to make the corrections
as we go.

On Wed, May 23, 2018 at 04:12:52PM -0400, Ted Lemon wrote:
> 
> Abstract
> 
>    This document describes how names are published and resolved on
>    homenets, and how hosts are configured to use these names to discover
>    services on homenets.  It presents the complete architecture, and
>    describes a simple subset of that architecture that can be used in
>    low-cost homenet routers.

I have never really understood how this could present the complete
architecture when we don't know what would go in a complete
architecture because we don't actually have one :)

> 1.  Introduction
> 
>    This document is a homenet architecture document.  The term 'homenet'
>    refers to a set of technologies that allow home network users to have
>    a local-area network (LAN) with more than one physical link and,
>    optionally, more than one internet service provider.  Home network
>    users are assumed not to be knowledgable in network operations, so
>    homenets automatically configure themselves, providing connectivity
>    and service discovery within the home with no operator intervention.

I would just say, "Homenets are intended for use with minimal or no
administration, so homenets automatically configure …."  Then we don't
need to have a boring discussion about what capabilities the user has.

>    The homenet naming architecture consists of two parts: the simple
>    naming architecture, and the advanced naming architecture. The
>    advanced architecture provides approximate parity of features with a
>    managed network, including the ability to publish services on the
>    internet.  The simple architecture provides a minimal set of features
>    required to enable seamless service discovery on a multi-link home
>    network, but does not attempt to provide feature parity with a
>    managed LAN.


As I think I suggested before, we have no evidence that we'll ever
come up with an advanced naming architecture, and I'm not too keen on
writing cheques that might never be negotiable.  Why not just skip
that claim, and say, "This document outlines a simple naming
architecture, which provides a minimal …," and be done with it?

> 
>    This document begins by presenting a motivational list of
>    requirements and considerations, which should give the reader a clear
>    idea of the scope of the problem being solved.  It then explains how
>    each requirement is addressed, and provides references for relevant
>    standards documents describing the details of the implementation.
>    Some requirements are not satisfied by the simple architecture

This suggests to me that, in fact, they're not really requirements.
If we have a simple architecture that can leave those use cases out,
they're not actually required at all, are they?

> 2.  Requirements
> 
>    Name service on a local area network (LAN) requires the following:
> 
>    o  Name: a forward domain under which information about local
>       services will be published
> 
>    o  Authority: a name server that is authoritative for at least a
>       forward and one or two reverse domains that are applicable to that
>       network

Are we confident that the reverses are really going to be needed?
They're often badly maintained in practice, and the rest of the
document doesn't really seem to indicate why they're so important.

>    o  Resolution: a full-service caching DNS resolver

According to 1123, all full-service resolvers have a cache, so this is
redundant.  

>    An additional requirement from the Homenet Architecture [9] is that
>    hosts are not required to implement any homenet-specific capabilities
>    in order to discover and access services on the homenet.  This
>    architecture may define optional homenet-specific features, but hosts
>    that do not implement these features must work on homenets.

What does "work" mean, there?  Work as expected at design time, or
work as the user expects given the homenet deployment?

Best regards,

A

-- 
Andrew Sullivan
[e-mail]