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

[Daniel Migault <[e-mail]>]

Hi Andrew,

Thanks you for providing the feed backs. An few comments inline.


On Mon, May 28, 2018 at 2:05 PM, Andrew Sullivan <[e-mail]>
wrote:

> 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 :)


I believe that complete architecture here shoudl be read as the set of
functions/properties the naming homenet architecture should provide. The
simple naming architecture defines a best match between the expectation and
what is available. Would something around these lines address your
comments.

This document describes the expected properties and functions a naming
architecture needs to fulfill in a homenet: Names are published, resolved
on homenets, and hosts are configured to use these names to discover
services on homenets.  The document describes how these functions are best
achieved in environments were a single and low cost Homenet Router  (HNR)
is deployed and with minimal or no administration. As a result, the simple
naming architecture may only partially fulfill the initial expected
functions which are expected to be extended in more advanced naming
architectures.




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

I agree. I also believe that not expecting intervention helps in keeping
description deterministic and simple. I like your text.

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

I believe that the main reason mentioning the advanced naming architecture
was to state the simple naming architecture is not expected to be complete
and future developments are expected.

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

It seems to me these are more the functionalities one expect from such
architecture. As requirements can be SHOULD ;-) I believe that requirement
is appropriated, but we can relax it with consideration as well - in my
opinion.

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

I would like to make the situation better than worst, so yes we need to
provide motivations. - usability, DNS-SD, ...

>
> >    o  Resolution: a full-service caching DNS resolver
>
> According to 1123, all full-service resolvers have a cache, so this is
> redundant.
>
> Agree. I think the redundancy wanted to clarify with (stub) resolver, but
I agree we do not need another terminology.

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

I think that is the second option.

>
> Best regards,
>
> A
>
> --
> Andrew Sullivan
> [e-mail]
>
> _______________________________________________
> homenet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/homenet
>