Re: [homenet] RFC 7788-bis (and also draft-cheshire-homenet-dot-home-03)

[Ted Lemon]

BTW, to do your excellent disquisition on this topic a tiny bit more
justice, I think the point where you and Stuart probably disagree is that
you want to take into account networks that will use homenet router
technology that are already using .home for something else, whereas Stuart
doesn't think this is a real use case.

I agree with you that it is a real use case we need to account for.

On Sun, Jul 17, 2016 at 6:38 PM, Ted Lemon  wrote:

> Violent agreement here.   Hence, ".homenet".   :)
>
> On Sun, Jul 17, 2016 at 6:34 PM, Andrew Sullivan 
> wrote:
>
>> Dear colleagues,
>>
>> On Fri, Jun 17, 2016 at 09:37:06AM +0100, Ray Bellis wrote:
>>
>> > Whilst there may be "undermined" ways it's being used, it's clear that
>> > most of the ways it's used are just because some vendors and sites
>> > decided to use that for their default *site local* domain which makes it
>> > completely consistent with what we need.
>> >
>> > I therefore completely disagree on point #1 - officially allocating
>> > .home for this purpose and having it "sunk" by default on internet
>> > facing recursive resolvers would IMHO actually *help* with the traffic
>> > hitting the root and reduce leakage of it.
>>
>> The argument above, which is rehearsed to some extent in
>> draft-cheshire-homenet-dot-home-03 (although there IMO more subtly),
>> is interesting to me, in that it appears to start with the exact same
>> premises I do and reach the exact opposite conclusion.  I believe this
>> is because of some unstated premises, and so I'm going to attempt to
>> lay out the premises as I understand them as completely as I can.
>>
>> To do this, I'm going to draw some inferences about what Ray was
>> arguing and about what is in draft-cheshire-homenet-dot-home-03.  I
>> hope the authors indulge me, and I hope you, Gentle Reader, do not
>> mistake my inferences as speaking correctly either for Ray or for
>> Stuart.  Since they're both here, they can correct what I get wrong;
>> but I think trying to lay out this different story might help us.
>>
>> I think we all agree that the label home, in the top-most position of
>> a domain name (but maybe not a name in the DNS), is in use by some
>> people.  I think we all agree that at least some uses of that name are
>> somehow related to "stuff in my house behind my home-router-like
>> thing".  And I think we all agree that, whatever basis for that use
>> is, it either is not or ought not to be related to any actual
>> delegation of the name in the DNS.
>>
>> With the above premises, I conclude that home is by definition not
>> suitable for our purposes.  I conclude that from these additional
>> premises:
>>
>> • that, given the detectable pollution of the namespace at and
>>   beneath home, there is a significant population already using
>>   the name for some purposes, we know not what;
>>
>> • that if we want an identifier to be some sort of protocol switch
>>   by which we tell software to do something novel, we need an
>>   identifier that has at least a modest chance of not running into
>>   widely-deployed use for some purpose not defined to be
>>   consistent with the protocol switch;
>>
>> • that it is at least fantastically difficult to suss out all the
>>   strange things people are already doing with "in the wild"
>>   undelegated names in the DNS, even if we make the dubious
>>   assumption that there is something like a rigorous design behind
>>   those doings;
>>
>> • that strings that could be used as protocol switches are
>>   fundamentally machine-directed rather than human-directed, and
>>   therefore have a certain arbitrariness about them.
>>
>> With the same premises, I think the opposite argument is that home is
>> entirely good for our purposes, because of the following additional
>> premises:
>>
>> • that we have (or we can get, which is what
>>   draft-cheshire-homenet-dot-home-03 is asking for) a pretty clear
>>   idea that all the uses of home are already more or less what
>>   we're trying to do;
>>
>> • that picking the same string is very unlikely to break any of
>>   the existing behaviour;
>>
>> • that a meaningful string to a human user is of high importance
>>   here;
>>
>> • that a primary (or even important secondary) motivation for the
>>   allocation would be to capture traffic that should never have
>>   been destined for the root in the first place;
>>
>> • that with adequate documentation, a possibly-conflicting use of
>>   home would not have negative effects.
>>
>>
>>
>>
>> I think the effort to document what people are actually doing with
>> home is laudable, and I hope it succeeds in producing a more-or-less
>> complete account of the use of that name.  But I do not see how we can
>> get from "documenting these uses is good" to "having documented it,
>> you can then use the name that way."  The 

Re: [homenet] RFC 7788-bis (and also draft-cheshire-homenet-dot-home-03)

[Ted Lemon]

Violent agreement here.   Hence, ".homenet".   :)

On Sun, Jul 17, 2016 at 6:34 PM, Andrew Sullivan 
wrote:

> Dear colleagues,
>
> On Fri, Jun 17, 2016 at 09:37:06AM +0100, Ray Bellis wrote:
>
> > Whilst there may be "undermined" ways it's being used, it's clear that
> > most of the ways it's used are just because some vendors and sites
> > decided to use that for their default *site local* domain which makes it
> > completely consistent with what we need.
> >
> > I therefore completely disagree on point #1 - officially allocating
> > .home for this purpose and having it "sunk" by default on internet
> > facing recursive resolvers would IMHO actually *help* with the traffic
> > hitting the root and reduce leakage of it.
>
> The argument above, which is rehearsed to some extent in
> draft-cheshire-homenet-dot-home-03 (although there IMO more subtly),
> is interesting to me, in that it appears to start with the exact same
> premises I do and reach the exact opposite conclusion.  I believe this
> is because of some unstated premises, and so I'm going to attempt to
> lay out the premises as I understand them as completely as I can.
>
> To do this, I'm going to draw some inferences about what Ray was
> arguing and about what is in draft-cheshire-homenet-dot-home-03.  I
> hope the authors indulge me, and I hope you, Gentle Reader, do not
> mistake my inferences as speaking correctly either for Ray or for
> Stuart.  Since they're both here, they can correct what I get wrong;
> but I think trying to lay out this different story might help us.
>
> I think we all agree that the label home, in the top-most position of
> a domain name (but maybe not a name in the DNS), is in use by some
> people.  I think we all agree that at least some uses of that name are
> somehow related to "stuff in my house behind my home-router-like
> thing".  And I think we all agree that, whatever basis for that use
> is, it either is not or ought not to be related to any actual
> delegation of the name in the DNS.
>
> With the above premises, I conclude that home is by definition not
> suitable for our purposes.  I conclude that from these additional
> premises:
>
> • that, given the detectable pollution of the namespace at and
>   beneath home, there is a significant population already using
>   the name for some purposes, we know not what;
>
> • that if we want an identifier to be some sort of protocol switch
>   by which we tell software to do something novel, we need an
>   identifier that has at least a modest chance of not running into
>   widely-deployed use for some purpose not defined to be
>   consistent with the protocol switch;
>
> • that it is at least fantastically difficult to suss out all the
>   strange things people are already doing with "in the wild"
>   undelegated names in the DNS, even if we make the dubious
>   assumption that there is something like a rigorous design behind
>   those doings;
>
> • that strings that could be used as protocol switches are
>   fundamentally machine-directed rather than human-directed, and
>   therefore have a certain arbitrariness about them.
>
> With the same premises, I think the opposite argument is that home is
> entirely good for our purposes, because of the following additional
> premises:
>
> • that we have (or we can get, which is what
>   draft-cheshire-homenet-dot-home-03 is asking for) a pretty clear
>   idea that all the uses of home are already more or less what
>   we're trying to do;
>
> • that picking the same string is very unlikely to break any of
>   the existing behaviour;
>
> • that a meaningful string to a human user is of high importance
>   here;
>
> • that a primary (or even important secondary) motivation for the
>   allocation would be to capture traffic that should never have
>   been destined for the root in the first place;
>
> • that with adequate documentation, a possibly-conflicting use of
>   home would not have negative effects.
>
>
>
>
> I think the effort to document what people are actually doing with
> home is laudable, and I hope it succeeds in producing a more-or-less
> complete account of the use of that name.  But I do not see how we can
> get from "documenting these uses is good" to "having documented it,
> you can then use the name that way."  The kind of exhaustive survey
> that would be needed to show the real uses of home would cost far more
> in time, effort, and money than the convenience of the string
> presents.  Moreover, it's not even clear that this would be the
> "right" string.  For lots of people on Earth don't use Latin writing,
> never mind English words.
>
> I hope this explains why I think proceeding with home is problematic.
>
> Andrew (speaking only for myself).
>
> --
> Andrew Sullivan
> a...@anvilwalrusden.com
>
> ___
> homenet mailing 

Re: [homenet] RFC 7788-bis (and also draft-cheshire-homenet-dot-home-03)

[Andrew Sullivan]

Dear colleagues,

On Fri, Jun 17, 2016 at 09:37:06AM +0100, Ray Bellis wrote:

> Whilst there may be "undermined" ways it's being used, it's clear that
> most of the ways it's used are just because some vendors and sites
> decided to use that for their default *site local* domain which makes it
> completely consistent with what we need.
> 
> I therefore completely disagree on point #1 - officially allocating
> .home for this purpose and having it "sunk" by default on internet
> facing recursive resolvers would IMHO actually *help* with the traffic
> hitting the root and reduce leakage of it.

The argument above, which is rehearsed to some extent in
draft-cheshire-homenet-dot-home-03 (although there IMO more subtly),
is interesting to me, in that it appears to start with the exact same
premises I do and reach the exact opposite conclusion.  I believe this
is because of some unstated premises, and so I'm going to attempt to
lay out the premises as I understand them as completely as I can.

To do this, I'm going to draw some inferences about what Ray was
arguing and about what is in draft-cheshire-homenet-dot-home-03.  I
hope the authors indulge me, and I hope you, Gentle Reader, do not
mistake my inferences as speaking correctly either for Ray or for
Stuart.  Since they're both here, they can correct what I get wrong;
but I think trying to lay out this different story might help us.

I think we all agree that the label home, in the top-most position of
a domain name (but maybe not a name in the DNS), is in use by some
people.  I think we all agree that at least some uses of that name are
somehow related to "stuff in my house behind my home-router-like
thing".  And I think we all agree that, whatever basis for that use
is, it either is not or ought not to be related to any actual
delegation of the name in the DNS.

With the above premises, I conclude that home is by definition not
suitable for our purposes.  I conclude that from these additional
premises:

• that, given the detectable pollution of the namespace at and
  beneath home, there is a significant population already using
  the name for some purposes, we know not what;

• that if we want an identifier to be some sort of protocol switch
  by which we tell software to do something novel, we need an
  identifier that has at least a modest chance of not running into
  widely-deployed use for some purpose not defined to be
  consistent with the protocol switch;

• that it is at least fantastically difficult to suss out all the
  strange things people are already doing with "in the wild"
  undelegated names in the DNS, even if we make the dubious
  assumption that there is something like a rigorous design behind
  those doings;

• that strings that could be used as protocol switches are
  fundamentally machine-directed rather than human-directed, and
  therefore have a certain arbitrariness about them.

With the same premises, I think the opposite argument is that home is
entirely good for our purposes, because of the following additional
premises:

• that we have (or we can get, which is what
  draft-cheshire-homenet-dot-home-03 is asking for) a pretty clear
  idea that all the uses of home are already more or less what
  we're trying to do;

• that picking the same string is very unlikely to break any of
  the existing behaviour;

• that a meaningful string to a human user is of high importance
  here;

• that a primary (or even important secondary) motivation for the
  allocation would be to capture traffic that should never have
  been destined for the root in the first place;

• that with adequate documentation, a possibly-conflicting use of
  home would not have negative effects.




I think the effort to document what people are actually doing with
home is laudable, and I hope it succeeds in producing a more-or-less
complete account of the use of that name.  But I do not see how we can
get from "documenting these uses is good" to "having documented it,
you can then use the name that way."  The kind of exhaustive survey
that would be needed to show the real uses of home would cost far more
in time, effort, and money than the convenience of the string
presents.  Moreover, it's not even clear that this would be the
"right" string.  For lots of people on Earth don't use Latin writing,
never mind English words.

I hope this explains why I think proceeding with home is problematic.

Andrew (speaking only for myself).

-- 
Andrew Sullivan
a...@anvilwalrusden.com

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] RFC 7788-bis

[Peter Koch]

On Fri, Jun 17, 2016 at 09:37:06AM +0100, Ray Bellis wrote:

> As for #2, yeah, that's hard, but it seems ICANN won't do anything about
> ".home" because of #1 anyway, but they seemed stalled on outright
> rejecting it and have said (AFAICR) that an RFC 6761 registration would
> allow them to reject (and refund) those applications.

which is even another reason for the IETF not to step into this particular trap.

-Peter

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] RFC 7788-bis

[Ray Bellis]

On 17/06/2016 02:00, Andrew Sullivan wrote:

> … it is not.  We know both that (1) it is already in use in the wild
> in undetermined ways and (2) that some people have spent a bunch of
> money attempting to get it delegated to them in the global DNS.  We
> should not, IMO, even for a moment consider using a name with
> well-known conflicting properties.



Whilst there may be "undermined" ways it's being used, it's clear that
most of the ways it's used are just because some vendors and sites
decided to use that for their default *site local* domain which makes it
completely consistent with what we need.

I therefore completely disagree on point #1 - officially allocating
.home for this purpose and having it "sunk" by default on internet
facing recursive resolvers would IMHO actually *help* with the traffic
hitting the root and reduce leakage of it.

As for #2, yeah, that's hard, but it seems ICANN won't do anything about
".home" because of #1 anyway, but they seemed stalled on outright
rejecting it and have said (AFAICR) that an RFC 6761 registration would
allow them to reject (and refund) those applications.

Ray

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] RFC 7788-bis

[Michael Richardson]

Ray Bellis  wrote:
>> In my opinion, it is important for the exact requirements and
>> semantics for the default domain be defined, perhaps even before the
>> default domain itself is selected.  It's not clear to me whether the
>> domain carried in the Domain-Name TLV can be a delegated domain or it
>> has to be a special use domain name for location-relative name
>> resolution like .local, or if either type of name is OK.

> It's my understanding (albeit this may change depending on Ted's work)
> that it may be either.

> The particular point of ".home" (or whatever) would be to provide a
> "special use" domain that is known to have "homenet site local"
> semantics that should leak as little as possible outside of that.

Yes, agreed. When you as for printer.home, you expect a ULA that you can reach.
When you ask for printer.delegatedomain.isp.example.net, you could get a
number of things: GUAs, or even ULAs that you can't reach (because they are
in my home, or because they are in your *other* home [and the VPN is down?]...)

> I think it would also be appropriate to add whatever name is chosen to
> the BCP 163 list of "Locally Server DNS Zones" such that any queries
> that do happen to leak beyond the site get sunk by the recursive
> resolver that receives them.

Agreed... and AS112?

-- 
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] RFC 7788-bis

[Ray Bellis]

On 16/06/2016 19:48, Ralph Droms wrote:

> In my opinion, it is important for the exact requirements and
> semantics for the default domain be defined, perhaps even before the
> default domain itself is selected.  It's not clear to me whether the
> domain carried in the Domain-Name TLV can be a delegated domain or it
> has to be a special use domain name for location-relative name
> resolution like .local, or if either type of name is OK.

It's my understanding (albeit this may change depending on Ted's work)
that it may be either.

The particular point of ".home" (or whatever) would be to provide a
"special use" domain that is known to have "homenet site local"
semantics that should leak as little as possible outside of that.

I think it would also be appropriate to add whatever name is chosen to
the BCP 163 list of "Locally Server DNS Zones" such that any queries
that do happen to leak beyond the site get sunk by the recursive
resolver that receives them.

Ray

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] RFC 7788-bis

[Tim Wicinski]

On 6/16/16 2:48 PM, Ralph Droms wrote:



On Jun 16, 2016, at 1:26 PM 6/16/16, Ray Bellis  wrote:

As was alluded to in my email of 9th June, we have been asked to replace
RFC 7788 (HNCP) with an RFC 7788-bis as soon as possible to incorporate
the errata raised by the DNSOP chair regarding the unintended apparent
reservation of ".home" as the default domain TLV within HNCP.

We should also take that opportunity to fix the error in the diagrams
for the DHCPv4_DATA and DHCPv6_DATA TLVs where the numbers shown
conflict with the IANA registrations for those TLVs.

Those two changes will be the only ones made, unless any further errata
are made in the meantime.

Slightly longer term, and notwithstanding our previously stated desire
to wait until Ted Lemon's Naming Architecture was further progressed, we
would like to obtain WG consensus on whether ".home" is indeed a
suitable default domain for HNCP.  In the meantime, implementors are
hereby advised that ".home" is potentially subject to change.


In my opinion, it is important for the exact requirements and semantics for the 
default domain be defined, perhaps even before the default domain itself is 
selected.  It's not clear to me whether the domain carried in the Domain-Name 
TLV can be a delegated domain or it has to be a special use domain name for 
location-relative name resolution like .local, or if either type of name is OK.

- Ralph



+1 on this.

tim

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] RFC 7788-bis

[Ralph Droms]

> On Jun 16, 2016, at 1:26 PM 6/16/16, Ray Bellis  wrote:
> 
> As was alluded to in my email of 9th June, we have been asked to replace
> RFC 7788 (HNCP) with an RFC 7788-bis as soon as possible to incorporate
> the errata raised by the DNSOP chair regarding the unintended apparent
> reservation of ".home" as the default domain TLV within HNCP.
> 
> We should also take that opportunity to fix the error in the diagrams
> for the DHCPv4_DATA and DHCPv6_DATA TLVs where the numbers shown
> conflict with the IANA registrations for those TLVs.
> 
> Those two changes will be the only ones made, unless any further errata
> are made in the meantime.
> 
> Slightly longer term, and notwithstanding our previously stated desire
> to wait until Ted Lemon's Naming Architecture was further progressed, we
> would like to obtain WG consensus on whether ".home" is indeed a
> suitable default domain for HNCP.  In the meantime, implementors are
> hereby advised that ".home" is potentially subject to change.

In my opinion, it is important for the exact requirements and semantics for the 
default domain be defined, perhaps even before the default domain itself is 
selected.  It's not clear to me whether the domain carried in the Domain-Name 
TLV can be a delegated domain or it has to be a special use domain name for 
location-relative name resolution like .local, or if either type of name is OK.

- Ralph

> 
> It should be noted (as pointed out to us by the Chair of the IAB) that
> the default domain need not be a single-label "pseudo-TLD" - it could be
> a sub-domain of an existing name in the DNS such as ".arpa".
> 
> Whichever domain is chosen, we will then instigate a new WG document (or
> perhaps resurrect draft-cheshire-homenet-dot-home if ".home" is
> preferred) to follow due process and formally reserve a default domain
> as a "special use domain name".
> 
> Ray and Mark
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] RFC 7788-bis

[Ray Bellis]

As was alluded to in my email of 9th June, we have been asked to replace
RFC 7788 (HNCP) with an RFC 7788-bis as soon as possible to incorporate
the errata raised by the DNSOP chair regarding the unintended apparent
reservation of ".home" as the default domain TLV within HNCP.

We should also take that opportunity to fix the error in the diagrams
for the DHCPv4_DATA and DHCPv6_DATA TLVs where the numbers shown
conflict with the IANA registrations for those TLVs.

Those two changes will be the only ones made, unless any further errata
are made in the meantime.

Slightly longer term, and notwithstanding our previously stated desire
to wait until Ted Lemon's Naming Architecture was further progressed, we
would like to obtain WG consensus on whether ".home" is indeed a
suitable default domain for HNCP.  In the meantime, implementors are
hereby advised that ".home" is potentially subject to change.

It should be noted (as pointed out to us by the Chair of the IAB) that
the default domain need not be a single-label "pseudo-TLD" - it could be
a sub-domain of an existing name in the DNS such as ".arpa".

Whichever domain is chosen, we will then instigate a new WG document (or
perhaps resurrect draft-cheshire-homenet-dot-home if ".home" is
preferred) to follow due process and formally reserve a default domain
as a "special use domain name".

Ray and Mark

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet