[homenet] Please volunteer for NomCom

[STARK, BARBARA H]

Hi homenet,
If you haven't volunteered for NomCom, please consider doing so by this coming 
*Wednesday*. It's really helpful to have people on NomCom from various Areas 
and WGs (NomCom tends to be dominated by people who participate in Routing). 
Robert Sparks has done a great job of making it real easy to know if you 
qualify and to volunteer. Just go to your datatracker profile and you'll find 
the Volunteer button and an eligibility indication.
https://datatracker.ietf.org/accounts/profile/

Barbara

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

[homenet] naming drafts

[STARK, BARBARA H]

Hi homenet WG,
Stephen and I have been chatting about the status of the 2 naming drafts 
(draft-ietf-homenet-front-end-naming-delegation and 
draft-ietf-homenet-naming-architecture-dhc-options). 

We started a 3-week WGLC about a month ago (04 May). Both drafts received 
comprehensive review from Med. Stephen reviewed front-end-naming-delegation. 
Bernie reviewed the formatting of the DHC option. 
The authors provided updates to resolve these comments. Bernie acknowledged 
satisfactory resolution of his comments.
Requests to change terminology were satisfactorily resolved -- but that 
discussion doesn't count as really being part of anyone's review of the drafts.
Stephen and Juliusz expressed that they're still not convinced that DDNS isn't 
a good enough solution for the use case.

Stephen and I do not believe these drafts have received enough review or 
support to put them forward as representing WG consensus.

But the authors have spent significant effort in creating these drafts and the 
associated implementation. We will work with Éric V (as INT area AD) and the 
authors to determine next steps.

Barbara and Stephen

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

[homenet] homenet naming drafts "terminology"

[STARK, BARBARA H]

I'm hoping not to start divisive discussion, but think it's better to discuss 
inside the WG rather than wait until IETF LC.

Might the authors consider whether a word other than "Master" could be used in 
the terms Distribution Master, Reverse Distribution Master, 
Distribution/Distributed Master Option [BTW, I notice that there are several 
instances of the "Distributed" instead of "Distribution" in the DHC option 
draft], Reverse Distribution Master Option, OPTION_DIST_MASTER, 
OPTION_REVERSE_DIST_MASTER?

Perhaps "Primary" could be used? Or something else?

If anyone needs context for my comment, I'm happy to provide it. Otherwise, 
I'll just leave it at this request for the authors to consider this question.
Thx,
Barbara

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

[homenet] WGLC started

[STARK, BARBARA H]

Hi homenet, intarea, dhc, and dprive,
Homenet has started WGLC for draft-ietf-homenet-front-end-naming-delegation-14 
and draft-ietf-homenet-naming-architecture-dhc-options-12.

https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/
 (Simple Provisioning of Public Names for Residential Networks)
https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-architecture-dhc-options/
 (DHCPv6 Options for Home Network Naming Authority)

We're including intarea, dhc, and dprive to get a slightly wider audience for 
the technical aspects of these drafts (dhc is specifically asked to look at the 
dhc-options draft).
The drafts do also need some editorial fixing-up. I'll be focusing on that so 
the technical experts can focus on the technical aspects.

I've made the WGLCs for 3 weeks instead of the normal 2. I'm doing this because
- we're reaching out to WGs that haven't seen this before and asking them for 
comments
- there are 2 drafts
- I'm on vacation next week and was getting stressed out by everything I need 
to get done by this Friday

The meeting minutes (from the homenet April 23 interim) list intarea, dprive, 
and dhc as other groups to request comments from. Is this the right list? Are 
there others?
Please let me know if I should broaden this.
Thx,
Barbara

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

[homenet] Homenet call on Friday

[STARK, BARBARA H]

Hi Homenet,
I just wanted to make sure everyone still remembered that we have a homenet 
call tomorrow.

2021-04-23 14:00 - 15:30 UTC
Meeting location (Webex): 
https://ietf.webex.com/ietf/j.php?MTID=m13cc475caad6a1a123d249c4bef63693
The meeting datatracker page that has links to agenda, codimd, etc.: 
https://datatracker.ietf.org/meeting/interim-2021-homenet-01/session/homenet

Agenda main topics:
- draft-ietf-homenet-front-end-naming-delegation-13: Simple Provisioning of
Public Names for Residential Networks 
- draft-ietf-homenet-naming-architecture-dhc-options-10: DHCPv6 Options for Home
Network Naming Authority
- Where to go from here

Barbara

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

[homenet] please review drafts

[STARK, BARBARA H]

Hi homenet,
Last Friday, I set up the interim call for Friday April 23 (2 weeks from now) 
to discuss the following 2 drafts:
Simple Provisioning of Public Names for Residential Networks
  - draft-ietf-homenet-front-end-naming-delegation-13 (
  - 
https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/

DHCPv6 Options for Home Network Naming Authority
 - draft-ietf-homenet-naming-architecture-dhc-options-10
 - 
https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-architecture-dhc-options/

But I realize an oversight: I forgot to ask people to read and review these 
drafts before that call and to provide comments and discussion on the list.
It would be really great if people did that!
Pretty please?
Thx,
Barbara

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

[homenet] interim scheduling

[STARK, BARBARA H]

Hi homenet,
Based on the Doodle poll, the interim will be scheduled for Friday, April 23 
14:00-15:30 UTC.
I'll set up things to get it properly scheduled in datatracker and WebEx. 
Barbara

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

[homenet] homenet interim poll

[STARK, BARBARA H]

Hi homenet,
I've put together a poll to (try to) figure out a date/time for an interim.
https://doodle.com/poll/pini9k5kpnwypsup?utm_source=poll_medium=link

We'll try to get the date/time picked and call set up by end of this week.
So remember: Vote early and often.
Thx,
Barbara

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

[homenet] minutes posted

[STARK, BARBARA H]

Hi dnssd and homenet,
The minutes Stuart took were excellent. I've posted. If anyone has comments on 
them, well, please comment.
Thx,
Barbara

https://datatracker.ietf.org/meeting/110/materials/minutes-110-homenet-00
https://datatracker.ietf.org/meeting/110/materials/minutes-110-dnssd-00

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

[homenet] IETF 110: starting early in 5 minutes

[STARK, BARBARA H]

The homenet part of the joint session will be beginning in 5 minutes at 45 
minutes past the hour.
Barbara

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

Re: [homenet] [Iotops] Ted's stub network document: draft-lemon-stub-networks{, -ps}

[STARK, BARBARA H]

Just addressing the administrivia point ...

> Ted posted draft-lemon-stub-networks-ps awhile ago, and I have attempted to
> collaborate with him on it.  There was a goof in the XML, so when he posted
> -01 of the document, it was named draft-lemon-stub-networks, and overwrote
> his previously uploaded solution document.
> 
> I think that this is a key architectural document on connecting IoT networks,
> although there is some resistance to putting such a specific use case into
> the title.
> 
> The Problem Statement is at:
>https://www.ietf.org/archive/id/draft-lemon-stub-networks-01.html 
> 
> The solution document is at:
>https://datatracker.ietf.org/doc/draft-lemon-stub-networks/00/ 

Ted asked for the Secretariat to fix this and both INT Area ADs have approved 
getting this fixed. I'll make sure 6man and homenet are notified if this 
happens.
Barbara
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] agenda planning

[STARK, BARBARA H]

Hi homenet,
draft-ietf-homenet-front-end-naming-delegation-12 and 
draft-ietf-homenet-naming-architecture-dhc-options-08 were posted towards the 
end of last year. There was some discussion on the list. We'll put them on the 
agenda; but we also want to discuss how best to progress them -- ensuring they 
get the review they deserve. 

Ted L: You had said maybe wanting to talk about stub resolvers. Do you still 
want time for that?

Anything I missed?
We have a total of 1 hour.
Barbara

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

[homenet] IETF 110 scheduling

[STARK, BARBARA H]

Hi homenet and dnssd,
We (ok, Éric) realized that the joint homenet/dnssd session was at the same 
time as the 2nd add session (Thursday Session I). And this made us very 
unhappy. So we moved it. The homenet+dnssd meeting is now Friday Session I.
Barbara 

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

Re: [homenet] IETF 110 and homenet

[STARK, BARBARA H]

OK. Sounds good. Thx,
Barbara

From: Ted Lemon 
Sent: Tuesday, January 19, 2021 5:21 PM
To: STARK, BARBARA H 
Cc: homenet@ietf.org
Subject: Re: [homenet] IETF 110 and homenet

On Jan 19, 2021, at 4:14 PM, STARK, BARBARA H 
mailto:bs7...@att.com>> wrote:
Since there were some WG draft updates published at the end of last year, we've 
decided to have a joint session with dnssd WG during IETF 110 so we can try to 
get some feedback on the drafts but also discuss how best to progress them and 
ensure they get the review they need/deserve.

I’m likely to want to do a presentation on stub networks as well—I should have 
a document for the wg to look at shortly. Not sure if homenet is the right 
place, but I think the group should get right of first refusal.

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

[homenet] IETF 110 and homenet

[STARK, BARBARA H]

Hi homenet,
Since there were some WG draft updates published at the end of last year, we've 
decided to have a joint session with dnssd WG during IETF 110 so we can try to 
get some feedback on the drafts but also discuss how best to progress them and 
ensure they get the review they need/deserve.

draft-ietf-homenet-front-end-naming-delegation-12
https://tools.ietf.org/html/draft-ietf-homenet-front-end-naming-delegation-12
Simple Provisioning of Public Names for Residential Networks

draft-ietf-homenet-naming-architecture-dhc-options-08
https://tools.ietf.org/html/draft-ietf-homenet-naming-architecture-dhc-options-08
DHCPv6 Options for Home Network Naming Authority

Barbara

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

Re: [homenet] [Editorial Errata Reported] RFC8375 (6378)

[STARK, BARBARA H]

> > My apologies, you are correct. I’ve now seen RFC 1034 which details the
> terminator.
> 
> Grand so. I'll ask Eric V. to hit the reject button on this
> when he gets back to work after the holidays.

Agreed. Thx, all. Happy New (Gregorian) Year.
Barbara
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] auto-passthrough from ISP routers

[STARK, BARBARA H]

> From: Michael Richardson 
> STARK, BARBARA H  wrote:
> >> From: Michael Richardson 
> >>
> >> In the ADD WG, Barbara STARK, BARBARA H  wrote:
> >> > [BHS] While my ISP requires me to use the CE router they supply, I’ve
> >> > never had an issue connecting that to my own router and then
> running
> >> my
> >> > home network from my router. The CE router from my particular ISP
> >> > (YMMV) even automatically passes on the public IPv4 address it
> acquires
> >> > and a /64 IPv6 prefix to my router (so IPv4 just has the single NAT 
> and
> >> > IPv6 works great). I have total ability to choose any router I want 
> and
> >> > configure that router as much as that router vendor’s GUI allows 
> (e.g.,
> >>
> >> 1) Does your ISP provides router auto-detect that there is another
> router
> >> behind
> >> it, and turn itself into a modem only?  or did you have configure that?
> 
> > The ISP router auto-detects the presence of a router on its LAN and
> > uses a capture screen to ask the user if they want the ISP router to go
> > into "IPv4 passthrough" mode. The ISP router does not become a
> 
> This is very cool.
> Is it written up as a specification somewhere?  What is the signal that the
> device behind is a router, and not a PC?

It's sort of written up in 
https://www.broadband-forum.org/technical/download/TR-124_Issue-5.pdf. Search 
for LAN.ADDRESS and go to 6. There are related requirements that reference 
"LAN.ADDRESS.6". Auto detection of routers behind the ISP CE router is 
imperfect (which is why manual configuration exists), but usually right. I 
forget what it is the ISP CE router sees that triggers it to think there is a 
router connecting to it. I'm thinking it could be some DHCPv4 options that 
routers tend to ask for but regular hosts don't; but I could be 
mis-remembering. Auto-detection isn't described in TR-124.

> Why isn't homenet standardizing this?

Reason 1: This is an IPv4 thing. Why would homenet or IETF standardize an IPv4 
thing since IPv4 is historic?
Reason 2: The functionality is accomplished within the ISP CE router without 
anything else needing to do anything special. No need to define requirements to 
accomplish interoperability. So the ISPs who knowingly wanted this 
functionality defined it in TR-124 because they use TR-124 to help with CE 
router RFPs. These ISPs perceive no additional benefit from the effort required 
to create an IETF RFC.

> > PPPoE is only legacy (old ADSL). The IPv4 passthrough does work there
> > (because the ISP router is still a router, as described above). IPv6 on
> > legacy is 6rd with a /60 -- so the IPv6 stuff is different. Fiber,
> > VDSL, and Gfast (and some newer ADSL) are IPoE (PTM), and not IP o
> > PPPoE o ATM.
> 
> Nobody has told Bell Canada the PPPoE is legacy :-)

LOL. You were asking about AT For AT it's legacy. I realize it's still 
widely used around the world. Your Network May Vary.

Barbara

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

Re: [homenet] auto-passthrough from ISP routers

[STARK, BARBARA H]

> -Original Message-
> From: Michael Richardson 
>
> In the ADD WG, Barbara STARK, BARBARA H  wrote:
> > [BHS] While my ISP requires me to use the CE router they supply, I’ve
> > never had an issue connecting that to my own router and then running
> my
> > home network from my router. The CE router from my particular ISP
> > (YMMV) even automatically passes on the public IPv4 address it acquires
> > and a /64 IPv6 prefix to my router (so IPv4 just has the single NAT and
> > IPv6 works great). I have total ability to choose any router I want and
> > configure that router as much as that router vendor’s GUI allows (e.g.,
> 
> 1) Does your ISP provides router auto-detect that there is another router
> behind
>it, and turn itself into a modem only?  or did you have configure that?

The ISP router auto-detects the presence of a router on its LAN and uses a 
capture screen to ask the user if they want the ISP router to go into "IPv4 
passthrough" mode. The ISP router does not become a modem-only. It is still a 
router. It still sets up the WAN connection and does all DHCP to the WAN and 
gets IP address and prefix delegations from the WAN. For IPv4 passthrough, it 
keeps a couple of ports of the public IPv4 address for its own management 
purposes, and delegates (DHCPv4) that public IPv4 address to the internal 
"passed through to" router (and forwards all inbound traffic to all other ports 
to the internal router). It has its own IPv6 /64 prefix, and requests a 2nd /64 
prefix it then delegates to the internal router. If any other DHCPv6 IA_PD 
requests come from the LAN, it will request additional /64 prefixes for those 
-- so this function is independent of passthrough mode which is an IPv4-only 
function.
 
> 2) I can imagine how a cable modem/router could become a bridge, and all
>would be well.
>But, I think that AT is more in the DSL space with PPPoE.
>Does this work for PPPoE, and if so, do you have to put the PPPoE
>password, into your "own" router?
>The ppp password is among those things that ISPs like to provision
> automatically.

PPPoE is only legacy (old ADSL). The IPv4 passthrough does work there (because 
the ISP router is still a router, as described above). IPv6 on legacy is 6rd 
with a /60 -- so the IPv6 stuff is different. Fiber, VDSL, and Gfast (and some 
newer ADSL) are IPoE (PTM), and not IP o PPPoE o ATM.

Here is some info (includes instructions to directly configuring IP 
passthrough):
https://www.att.com/Common/storefront/resources/pdf/att_bridged_mode_vs_ip_passthrough_nov2012_v3.pdf
 
> I'm really hoping that there is some technology out there that I'm ignorant 
> of.
> (but, I'm cynically thinking that the technology involves sending Barbara out
> in a GPS equipped truck)

Hah! No. We've been doing IPv4 passthrough for 15+ years.
Barbara
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] lack of discussion

[STARK, BARBARA H]

Hi homenet,
While Michael and Daniel put some effort into their draft prior to IETF 107, 
there's been no subsequent discussion of it on the list. And no new activity on 
the draft.
In the absence of activity, Stephen and I don't think homenet should request 
time during IETF 108.

It may be time to close homenet and move the draft elsewhere (like maybe INT 
area).

If you disagree, this is best expressed this through technical discussion and 
activities.
Thx,
Barbara

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

[homenet] IETF 108 survey

[STARK, BARBARA H]

Most of you have seen this already. But in the off-chance you haven't (or that 
you just need one more reminder to make you actually do it), here it is, again.
Barbara

This is a reminder that we need the IETF community to help us plan for the 
possibility that one or more upcoming IETF meetings in 2020 and possibly 2021 
may not be able to go ahead in person.  You can help us with this by filling 
out the following survey: 

https://www.surveymonkey.com/r/5328FFJ

So far we have 114 responses and we would ideally like 500 or more.

The survey contains the following pages and will take 15-20 minutes to complete:

1. Welcome
2. Online IETF 107 and the subsequent virtual interims
3. Replacing a cancelled in-person meeting
4. Online meeting format and timezone
5. Replicating humming
6. Replicating the hallway environment
7. Fees
8. Thanks and anything else

We run the survey in anonymous mode which means that we only see data that you 
explicitly provide.

Thank you in advance for your help.

-- 
Alissa Cooper, IETF Chair
Jay Daley, IETF Executive Director
Colin Perkins, IRTF Chair

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

[homenet] interim on *Monday* April 20

[STARK, BARBARA H]

Hi homenet,
I wanted to remind everyone we have an interim scheduled for Monday, April 20, 
14:30-16:00 UTC. That's 07:30 PDT for anyone on the North American West Coast. 
On a Monday. Which is real easy to forget about and sleep through. So, please, 
don't forget.
Barbara

Logistics:
==

Date and Time: 2020-04-20 14:30-16:00 UTC
Webex details: 
https://ietf.webex.com/ietf/j.php?MTID=mab3e771a8ed42ba6b338bc316524a757  
Jabber room: xmpp:home...@jabber.ietf.org?join  (will only be used if requested)
etherpad: https://etherpad.ietf.org/p/notes-20200420-homenet 
[Note: The previous agenda used a "etherpad.tools.ietf.org" URL. That has been 
changed to a URL without "tools".]

Agenda:
===

1. Agenda bash -- note that interim is scheduled for 90 minutes, but we may not 
use all of that 
2.  Outsourcing Home Network Authoritative Naming Service
(draft-ietf-homenet-front-end-naming-delegation-10) Michael Richardson / Daniel 
Migault (30 minutes) 
3. Stub networks (Ted Lemon) 
4. AOB
BEGIN:VCALENDAR
PRODID:-//Microsoft Corporation//Outlook 16.0 MIMEDIR//EN
VERSION:2.0
METHOD:PUBLISH
X-MS-OLK-FORCEINSPECTOROPEN:TRUE
BEGIN:VTIMEZONE
TZID:Eastern Standard Time
BEGIN:STANDARD
DTSTART:16011104T02
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=11
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010311T02
RRULE:FREQ=YEARLY;BYDAY=2SU;BYMONTH=3
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
CLASS:PUBLIC
CREATED:20200416T202957Z
DESCRIPTION:Logistics:\n==\n\nWebex details: https://ietf.webex.com
	/ietf/j.php?MTID=mab3e771a8ed42ba6b338bc316524a757  \nJabber room: xmpp:ho
	me...@jabber.ietf.org?join  (will only be used if requested)\netherpad: ht
	tps://etherpad.ietf.org/p/notes-20200420-homenet \n[Note: The previous age
	nda used a "etherpad.tools.ietf.org" URL. That has been changed to a URL w
	ithout "tools".]\n\nAgenda:\n===\n\n1. Agenda bash -- note that interi
	m is scheduled for 90 minutes\, but we may not use all of that \n2.  Outso
	urcing Home Network Authoritative Naming Service\n(draft-ietf-homenet-fron
	t-end-naming-delegation-10) Michael Richardson / Daniel Migault (30 minute
	s) \n3. Stub networks (Ted Lemon) \n4. AOB\n
DTEND;TZID="Eastern Standard Time":20200420T12
DTSTAMP:20200416T202957Z
DTSTART;TZID="Eastern Standard Time":20200420T103000
LAST-MODIFIED:20200416T202957Z
LOCATION:Webex
PRIORITY:5
SEQUENCE:0
SUMMARY;LANGUAGE=en-us:Homenet interim
TRANSP:OPAQUE
UID:04008200E00074C5B7101A82E008B0FF2B960B14D601000
	010008341FA7C4447FD4FA0DA0EE92A3A1797
X-ALT-DESC;FMTTYPE=text/html:\n\n\n\n\n\n\n\n\nLogistics:\n
	==\n\nWebex details: https://ietf.webex.com/ietf/
	j.php?MTID=mab3e771a8ed42ba6b338bc316524a757">https://ietf.webex.com/ietf/
	j.php?MTID=mab3e771a8ed42ba6b338bc316524a757\;\nJabber room: 
	xmpp:home...@jabber.ietf.org?join\; (will only be used if requested)<
	BR>\netherpad: https://etherpad.ietf.org/p/notes-20200420-homenet
	">https://etherpad.ietf.org/p/notes-20200420-homenet\n[Note: The p
	revious agenda used a \;etherpad.tools.ietf.org\; URL. That has 
	been changed to a URL without \;tools\;.]\n\nAgenda:
	\n===\n\n1. Agenda bash -- note that interim is scheduled for 
	90 minutes\, but we may not use all of that\n2.\; Outsourcing Hom
	e Network Authoritative Naming Service\n(draft-ietf-homenet-front-end-
	naming-delegation-10) Michael Richardson / Daniel Migault (30 minutes)
	\n3. Stub networks (Ted Lemon)\n4. AOB\n\n\n\n\n
X-MICROSOFT-CDO-BUSYSTATUS:BUSY
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-DISALLOW-COUNTER:FALSE
X-MS-OLK-AUTOFILLLOCATION:FALSE
X-MS-OLK-CONFTYPE:0
BEGIN:VALARM
TRIGGER:-PT5M
ACTION:DISPLAY
DESCRIPTION:Reminder
END:VALARM
END:VEVENT
END:VCALENDAR
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Homenet virtual interim

[STARK, BARBARA H]

Hi Homenet,
Our assigned virtual interim day is April 20. We do have some agenda items:

Outsourcing Home Network Authoritative Naming Service 
(draft-ietf-homenet-front-end-naming-delegation-10), Michael Richardson and 
Daniel Migault
Draft was updated 9 March (and there was a lot of activity on GitHub leading up 
to this, discussing issues and making updates)

Stub Networks, Ted Lemon 
Ted has committed to presenting some thoughts on this topic.

So we need to find a time that will work for most people (weighted towards 
reasonable awake hours of chairs, presenters, and our AD).
Because presenters, chairs, and AD are in North America and Europe, I've 
created a Doodle poll for 1.5 hour time slots between 7:30am PDT and 10pm CEST. 
7:30am PDT is a really rough time on a Monday morning, but no harm in seeing 
where we're at with that.

https://doodle.com/poll/gnfbway2te7ey8gv

We'll close the poll and pick the time next Friday, 27 March, at 23:59 UTC. You 
have 1 week to fill out the poll.
The meeting will be by WebEx.
Thx,
Barbara

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

[homenet] homenet agenda planning

[STARK, BARBARA H]

The joint dnssd+homenet session is currently scheduled for Thursday morning, 
10:00-12:00 PDT.
It is scheduled against cbor, gaia, icnrg, bmwg, spring, taps, and privacypass 
(BOF; looking at a new protocol).

I've seen a flurry of activity in GitHub from Michael and Daniel on the 
Outsourcing Home Network Authoritative Naming Service draft.
https://github.com/ietf-homenet-wg/ietf-homenet-hna, if you're curious.

Are there any requests for homenet agenda time from anyone (especially Daniel 
and Michael)?
Barbara

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

[homenet] IETF 106 homenet and dnssd agenda and sessions

[STARK, BARBARA H]

Yes, that's plural: sessions.
We went ahead and requested the Monday 18:10-19:10 time slot for dnssd privacy 
topics.
Because we now have this other hour, we will delay the start of the first 
session until 14:30.
There are still unhappy people, I know. But hopefully this is workable. 
Comments and complaints are, well, not unwelcome. But I won't be upset if I 
don't hear any (more).
Barbara

Here are highlights of the updated agenda (which has also been uploaded to 
datatracker):

IETF 106 - Homenet + DNSSD Agenda
13:30-15:30 Monday Afternoon session I (only 14:30 - 15:30 will be used)
18:10-19:10 Monday Afternoon session III (dnssd topics, only)
November 18, 2019

13:30 - 14:30 No Agenda for the first hour. The meeting will start at 14:30 to 
minimize overlap with other, simultaneous sessions.

Starting at 14:30:

Administrivia and Status Update: dnssd Chair slides (5 minutes)
Service Registration and roadmap (Ted Lemon or Stuart Cheshire, 15 minutes)
  * draft-ietf-dnssd-srp
Discovery Relay (Ted Lemon or Stuart Cheshire, 5 minutes)
  * draft-ietf-dnssd-mdns-relay
Rechartering discussions (led by chairs, 5 minutes)
-
Starting at 15:00:

Administrivia and Status Update: homenet Chair slides (5 minutes)
 - [hopefully notetaker and jabber scribe will be the same]
Homenet Naming architecture update (including hacking): Michael Richardson / 
Daniel Migault (10 minutes)
HNCP evolution: Ray Hunter / Daniel Migault (15 minutes)
-
Starting at 18:10

Administrivia: (5 minutes)
 - identify notetaker and jabber scribe for this session
 - recap of first session
Privacy topics/drafts (Christian Huitema, 20 minutes)
Conclusion (Chairs - 5 minutes)

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

[homenet] IETF 106 agenda

[STARK, BARBARA H]

A draft agenda for the joint homenet/dnssd session is posted now. To save you 
the trouble of unnecessary clicking here is what it says:

Administrivia and Status Update: Homenet Chair slides (5 minutes)
Homenet Naming architecture update (including hacking): Michael Richardson / 
Daniel Migault (10 minutes)
HNCP evolution: Ray Hunter / Daniel Migault (15 minutes

-

Administrivia and Status Update: dnssd Chair slides (5 minutes)
   [hopefully notetaker and jabber scribe will be the same]
Service Registration (Ted Lemon or Stuart Cheshire, 15 minutes)
  * draft-ietf-dnssd-srp
Discovery Relay (Ted Lemon or Stuart Cheshire, 5 mins)
  * draft-ietf-dnssd-mdns-relay
Privacy (TBD) [this is complicated by conflict with pearg]
Summary of on-list re-charting discussion (Chairs - 5 minutes)
Conclusion (Chairs - 5 minutes)

Of course, the pearg conflict is under discussion to potentially move the 
privacy discussion.
Barbara

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

[homenet] IETF 106

[STARK, BARBARA H]

Hi dnssd and homenet,
In case you haven't looked at the draft agenda, homenet and dnssd WGs are 
scheduled for a joint session, 13:30-15:30, Monday Afternoon session I. Other 
WGs scheduled for that same time slot are:
calext  Calendaring Extensions
extra   Email mailstore and eXtensions To Revise or Amend
lpwan   IPv6 over Low Power Wide-Area Networks  
dinrg   Decentralized Internet Infrastructure   
pearg   Privacy Enhancements and Assessments Research Group 
spring  Source Packet Routing in Networking 
txauth  Transactional Authorization and Delegation BOF  
tsvwg   Transport Area Working Group

If any key contributors have severe conflicts with these, please let your 
friendly dnssd and/or homenet chairs know.
And don't forget to send in your agenda requests!
Barbara

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

Re: [homenet] [babel] Éric Vyncke's Discuss on draft-ietf-babel-applicability-07: (with DISCUSS and COMMENT)

[STARK, BARBARA H]

Removing unnecessary participants from the discussion (I don't think its 
relevant to the IESG review of babel-applicability?), and adding homenet...

> > How does the HOMENET usage of babel fit into this?  I would be
> > surprised if they were expecting secure link layers to be used inside
> > the home, but it does seem like the threat model for HOMENET includes
> > hostile or compromised devices in the home.
> 
> Barbara will correct me if I'm wrong, but as far as I know, the Homenet
> working group hasn't decided on a security mechanism yet.  I have heard
> opinions to the effect that Homenet requires asymmetric authentication, in
> which case Babel-DTLS would be necessary, but I wouldn't presume to judge
> whether these opinions represent WG consensus.

Homenet WG hasn't documented its security requirements -- for anything.
The current model for securing home networks is to secure the physical layers. 
The normal practice for dealing with compromised devices in the home is to 
remove or fix them when someone figures out they're compromised.
My personal (individual) opinion is it's extremely important to have tools to 
discover when a device is causing trouble. On-going protection against such 
devices (so they can be safely(?) left on the home network indefinitely and 
people can feel secure) isn't important or even necessarily a good idea.

Babel-HMAC could identify anything trying to talk Babel without a key. If the 
compromised device has been given the keys (because the user thought it could 
be trusted and didn't know it was compromised), then neither HMAC nor DTLS will 
be of any protection.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet notes

[STARK, BARBARA H]

> From: Michael Richardson 
> 
> On 2019-07-23 10:09 a.m., STARK, BARBARA H wrote:
> >   - terminology (homenet)
> >   - front-end naming
> >   - SRP in homenet (assumes dnssd SRP draft)
> >   - HNCP for external domain
> >   - service discovery in homenet
> 
> It seems like "SRP in homenet" and "service discovery in homenet" might be
> the same thing.  I can't recall what the distinction was, but I recall that's 
> we'd
> wind up with five documents.
> 
>  > At IETF 106, see if we can have joint dnssd + homenet 2 hour session  > and
> give homenet 30 minutes to discuss service discovery in homenet.
>  > Before IETF 106, there should be day where Ted, Michael and Daniel  >
> hack and talk together. August 28 tentatively set as date.
> 
> I also think that maybe we should have a virtual interim in october?

I think it's reasonable to consider the possibility of having an October 
virtual interim. Perhaps a decision could be made during the August virtual 
interim?
Barbara

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

Re: [homenet] final planning for not formally meeting

[STARK, BARBARA H]

FYI. Coller is on the 3rd floor in the hallway on the “other” side of the 
elevators. 
Barbara 

> On Jul 22, 2019, at 11:57 PM, STARK, BARBARA H  wrote:
> 
> *** Security Advisory: This Message Originated Outside of AT ***.
> Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
> 
>> I reserved the Coller room for Tuesday morning (08:30 - 10:00). It says it 
>> holds up to 16 people. There are bigger rooms available (and additional 
>> times, but I figured you meant before the first session since there's an 
>> anima meeting Tuesday first session), but I thought this size might be 
>> better because I'm not expecting a lot of people? I can also support remote 
>> attendance with this size of room, using an iPad. 
> 
> I just wanted to remind those who are here that we’ll be meeting in an 
> unstructured way in the morning. I had no requests for Webex. If you do want 
> to remotely participate let me know and I’ll set it up in the morning just 
> before we meet. 
> Barbara 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_homenet=DwIF-g=LFYZ-o9_HUMeMTSQicvjIg=LoGzhC-8sc8SY8Tq4vrfog=E1jjmY5RvhwI_bCJLecGy7oq9qmf0_dJeleKron1s0M=lcTtq3B-YeMNwYGDMu_vnwR37gaBSGfd39hTfno5-FQ=

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

Re: [homenet] final planning for not formally meeting

[STARK, BARBARA H]

> I reserved the Coller room for Tuesday morning (08:30 - 10:00). It says it 
> holds up to 16 people. There are bigger rooms available (and additional 
> times, but I figured you meant before the first session since there's an 
> anima meeting Tuesday first session), but I thought this size might be better 
> because I'm not expecting a lot of people? I can also support remote 
> attendance with this size of room, using an iPad. 

I just wanted to remind those who are here that we’ll be meeting in an 
unstructured way in the morning. I had no requests for Webex. If you do want to 
remotely participate let me know and I’ll set it up in the morning just before 
we meet. 
Barbara 

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

Re: [homenet] final planning for not formally meeting

[STARK, BARBARA H]

If there are people interested in HNCP integration, I’m happy to reserve space 
for that (at a time different from the -naming effort), and I’m happy to 
participate in that as well.
Just pick a date/time.
Wherever there’s interest, I’d like to try to help get like-minded people 
together.
I’ll see about reflashing my router to the most current OpenWRT. It really 
needs updating, anyway.
Barbara


From: Ted Lemon 
Sent: Monday, July 15, 2019 3:55 PM
To: STARK, BARBARA H 
Cc: Michael Richardson ; homenet 
Subject: Re: [homenet] final planning for not formally meeting

On Jul 15, 2019, at 3:42 PM, STARK, BARBARA H 
mailto:bs7...@att.com>> wrote:
I reserved the Coller room for Tuesday morning (08:30 - 10:00). It says it 
holds up to 16 people. There are bigger rooms available (and additional times, 
but I figured you meant before the first session since there's an anima meeting 
Tuesday first session), but I thought this size might be better because I'm not 
expecting a lot of people? I can also support remote attendance with this size 
of room, using an iPad. You'll find the reservation listed at:
https://trac.ietf.org/trac/ietf/meeting/wiki/105sidemeetings<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.ietf.org_trac_ietf_meeting_wiki_105sidemeetings=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=LoGzhC-8sc8SY8Tq4vrfog=6WX9BNWncURSoCVOLeT7gjD4x8P5NJBGe6ERscM8Foc=_i0_ukESYyJFPuUfRMuoFfO_jyZ5iZACVpC2CeHI6Lo=>

This is opposite a “Technology Deep Dive” talk that some folks might want to go 
to.

I have an OpenWRT repo set up here that I’m using for the hacking I’m doing, 
and that we could use as a collaborative space if it seems useful: 
https://github.com/IETF-Hackathon/openwrt<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IETF-2DHackathon_openwrt=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=LoGzhC-8sc8SY8Tq4vrfog=6WX9BNWncURSoCVOLeT7gjD4x8P5NJBGe6ERscM8Foc=-G81Nu9eU4g4R48aO7c6Jp8DAX3BjRi0zuCHRe6jsHc=>

Right now the packages I’m working on don’t build out of the box, but I’ll fix 
that in the next day or so.   If anybody is interested in building what I’m 
building, I can supply some pointers.   I’m doing my development on the GL-iNet 
AR-750S router, which builds cleanly out of this repo.   In principle the repo 
is tracking OpenWRT current, but I haven’t merged in a few days.

My plan is to hack on homenet stuff—if there are folks who want to do naming, 
that would be great, but I wouldn’t mind doing some HNCP integration if there’s 
anyone who’s interested in that.

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

Re: [homenet] final planning for not formally meeting

[STARK, BARBARA H]

> > - I haven't scheduled
> > an unstructured meeting. Should I? Should I do a quick Doodle poll for
> > when? Or would people prefer to wing it when we get there? If we
> > schedule something, I could set up a WebEx for remote people.
> 
> I had suggested that it should be a *-naming "design team" focus, I had
> proposed Tuesday morning. I hadn't booked anything yet either.

I reserved the Coller room for Tuesday morning (08:30 - 10:00). It says it 
holds up to 16 people. There are bigger rooms available (and additional times, 
but I figured you meant before the first session since there's an anima meeting 
Tuesday first session), but I thought this size might be better because I'm not 
expecting a lot of people? I can also support remote attendance with this size 
of room, using an iPad. You'll find the reservation listed at:
https://trac.ietf.org/trac/ietf/meeting/wiki/105sidemeetings

Barbara

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

[homenet] final planning for not formally meeting

[STARK, BARBARA H]

Hi homenet,
Now that we're less than a week out...
- What planning should people do who can/will attend the hackathon? I intend to 
come, and can bring a (LEDE load, currently) wireless router and other items 
(Raspberry Pi ?). If that would be useful. Does anyone else want to share their 
plans or ask for something specific?
- I haven't scheduled an unstructured meeting. Should I? Should I do a quick 
Doodle poll for when? Or would people prefer to wing it when we get there? If 
we schedule something, I could set up a WebEx for remote people.

Please let me know what support you'd like to move your homenet efforts forward.
Thx,
Barbara

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

[homenet] Montreal homenet activities

[STARK, BARBARA H]

Hi homenet,
Stephen and I have decided not to have a formal homenet session in Montreal.
We encourage people wanting to work on homenet code to self-organize for the 
hackathon. I'll be happy to bring some OpenWRT devices to test with (and do 
some testing), if that would be useful. Let me know ...
If people would like to set a time to have an "unstructured" get-together in 
Montreal, please let us know. There will be spaces available that can be 
reserved. We can figure out a time and sign up for such a space. I'm also happy 
to have a WebEx up and running for anyone who would want to join in remotely to 
such a get-together.

Homenet is in danger of shutting down if we don't get more active participation.
But with that said, there's been activity on the homenet github site: 
https://github.com/ietf-homenet-wg/ietf-homenet-hna
Activity is a good thing.
Barbara

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

[homenet] homenet rechartering, meetings, and code

[STARK, BARBARA H]

Hi homenet,
In Prague, we had discussions about code, meetings, hackathon, and rechartering.
One thing said about code was that if we saw no activity on the list about 
people discussing code (writing and testing), that the chairs should "beat 
people up".
Consider yourselves beaten up ...
Where are we on code for the various drafts?

The Montreal Hackathon 
(https://trac.ietf.org/trac/ietf/meeting/wiki/105hackathon) currently shows:
HOMENET build-out
Champion(s)
TO BE DETERMINED, probably Ted. 
Project(s)
hook up multiple routers and do back-end and front-end naming tests

Should we be encouraging this on the list (i.e., is anyone intending to show up 
at the hackathon and work on homenet code)? BTW, I'm happy to bring a couple of 
OpenWRT routers and play with whatever code others produce.

Do we want a formal homenet session in Montreal?
Would it be good to structure an unstructured get-together in Montreal (that 
can be used for coding and draft discussion) during the week?

Rechartering: It was suggested in Prague that a rechartering discussion might 
re-energize homenet. I was just listening to the recording to refresh my memory 
(https://www.youtube.com/watch?v=y-7G2ItPwco). There was discussion starting 
around 55:30 into the recording on this topic. Does anyone want to kick off 
some list-based discussion on rechartering? There was a mention that maybe the 
charter doesn't cover architecture for IoT controllers subtended from a single 
router, and maybe the charter should specifically include this. Multiple 
routers just for the purpose of having multiple (general purpose) routers may 
not be a common use case? If there's interest in discussing the charter, it 
might be good to start that on a separate thread, rather than replying to this 
thread.
Barbara

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

Re: [homenet] wifi broadcast domain - Mikael Abrahamsson's comments

[STARK, BARBARA H]

> > prplMesh solves the wifi broadcast domain issue.
> >
> 
> >From their website: « prplMesh is an open-source, carrier-grade and
> certifiable implementation of the WiFi Alliance’s Multi-AP specification. »
> 
> That's a purely layer 2 solution that relies on a central controller.
> It depends on IEEE 1905:
>   

You can get the Wi-Fi Alliance MAP (branded EasyMesh) spec that prpl is 
implementing from the WFA website (after providing your name and contact info 
if you aren't a member):
https://www.wi-fi.org/file/multi-ap-specification-v10 

You can also see the prplMesh code in its current (incomplete -- the project is 
still underway) state at:
https://github.com/prplfoundation/prplMesh 

I am involved in the joint BBF effort that they mentioned. If someone wanted to 
join that project (it's free to join -- just requires agreeing to IPR policy 
and BSD+Patent open source license) and suggest and provide code for HNCP, they 
could. But since this is a purely Layer 2 network (routers will break it), the 
HNCP would really only be for other routers (e.g., IoT gateways attaching a 
Thread network) that aren't part of the Multi AP L2 network. If you'd like more 
info for joining the joint BBF/prpl project, let me know.
Barbara
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] draft minutes

[STARK, BARBARA H]

Oh, and thank you to Evan Hunt and Brian Haberman for taking notes in Etherpad, 
and to Mikael Abrahamsson for doing jabber. I thought the notes were 
outstanding.
Barbara

> From: STARK, BARBARA H
> 
> I've uploaded a draft of the IETF 104 meeting minutes. Please let us chairs
> know if you have comments.
> https://datatracker.ietf.org/meeting/104/materials/minutes-104-homenet-
> 00
> Barbara

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

[homenet] draft minutes

[STARK, BARBARA H]

I've uploaded a draft of the IETF 104 meeting minutes. Please let us chairs 
know if you have comments.
https://datatracker.ietf.org/meeting/104/materials/minutes-104-homenet-00 
Barbara

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

[homenet] homenet agenda

[STARK, BARBARA H]

Does anyone have requests for homenet agenda time?
Barbara

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

Re: [homenet] homenet: what now? ... next?

[STARK, BARBARA H]

... if your ISP-provided public IP address ever goes away, all of your RFC1918 
addresses on the homenet also go away.

 Not in any router I’ve ever had a hand in specifying or procuring! And 
not true of my Netgear router, or any of my older Linksys routers. Or OpenWRT 
loaded routers. My RFC1918 addresses absolutely stay put. I just can’t access 
the Internet (through that broadband connection) when my ISP-provided public IP 
address goes away. I’m not aware of any router that loses its RFC1918 addresses 
when the WAN goes down.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet: what now? ... next?

[STARK, BARBARA H]

> For the last 10 to 15 years the ISP-provided home router has come to
> dominate the market, with the belief by the ISPs that this is a MUST that they
> control the device.  Many (but not all) at the IETF do not share this view, 
> but
> most non-technical users see the ISP provided router is simply saving the trip
> to
> BestBuy, rather than an abdication of control over their home.   If this
> trend continues, then I believe that ISPs (residential IAPs) will come to want
> to control all IoT devices in the home -- because security -- telling 
> residential
> customers what they can and not connect.

Just to be clear, the main reasons most ISPs require use of the ISP CE router 
at the edge of mass market customer networks is because:
1. Providing instructions for installation and setup becomes easier, as well as 
ensuring the installation process is as trouble-free and easy as possible.
2. Improved but simplified security between the CE router and the access network
3. Cost of help desk support is greatly reduced because help desk personnel 
only have to know how to guide customers through one GUI, and the help desk can 
get permission from the customer (when on a call with the customer) to directly 
manage the router if the customer prefers that approach.

The cost of supporting a customer under a bring-your-own-random-CE-router model 
is considerably higher than the cost of supporting a customer in an 
ISP-managed/specified/provided-CE-router model.

None of which prevents anyone from putting their own router between the ISP CE 
router and their home network. That's what I do. The ISP doesn't control my 
home network and there's no requirement from the ISP that they control my home 
network. I have not abdicated control of my home network to my ISP.

Home automation services may be offered by an ISP, but I'm not aware of any 
case in the US (or Europe) where someone who wants home automation / security 
is required to get it from their ISP or where the ISP has to give permission 
for someone else (or for the homeowner) to operate such a service. I don't know 
the rest of the world.

Can we please avoid making these rather insulting and inflammatory claims 
without evidence? If there's evidence, please provide it. If the evidence 
indicates the practice is localized (to a single ISP, country, or geography), 
please note that when providing evidence. Broad claims that an entire 
IETF-stakeholder group is evil and trying to control everything are not nice.

> I believe that this direction will result in ISPs being 100% liable for 
> attacks on
> critical infrastructure; I don't think that this is a place that ISPs want to 
> be, but
> I'm not sure that they have understood this yet.

I don't know about other ISPs, but I do know my employer takes network security 
very seriously. And access network security (including preventing theft of a 
customer's access service) is one of the reasons I mentioned for providing 
customers with an ISP-provided CE router.

> It's clearly not in
> Amazon/Google/Facebook/Intel/Samsung/insert-another-IoT-
> conglomerate's
> interest to be told by ISPs what their products may or may not do.
> This is an ongoing tussle that that relates in some ways (but not all) to the 
> net
> neutrality debate and the desire my ISPs for a cut of the over-top-pie.
> My answer is that the consumer should be in control, and that ISPs need to
> get out of the home router business entirely.  Home router vendors (or the
> service companies they create) should provide first-level support for issues,
> and actual real connectivity issues should be submitted electronically.  Not 
> so
> different in the way that my furnace maintenance is not provided by my gas
> supplier, but my gas supplier gets to inspect the hookup.

No ISP in the US is in a position to tell these companies what they can or 
can't do in a device connected to a customer's network. I can't speak for other 
regions.
There is no evidence that all ISP routers provided by all ISPs in every corner 
of the world prevent all of their customers from being in complete control of 
the home network.  
I remain in complete control of my home network and the devices connected to 
it, independent of the fact that my home network edge router is connected 
through an ISP CE router. Therefore, I know this claim is false in my case.
In any case, I think this comment is well outside the realm of the homenet 
charter.



Barbara

> When we started this effort we heard of real situations such as Fred's 
> original
> FUN BOF slides on how dual-geek households are forced not to share
> printers due to corporate home firewall requirements.  And that we should
> expect the situation to get worse.  Those slides are close to ten years old.
> I'd like to know if they are still at relevant.  Maybe they aren't.
> If not, why not?
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-

___

Re: [homenet] homenet: what now? ... next?

[STARK, BARBARA H]

> > But Wi-Fi Alliance (WFA) has been working to provide a solution for
> seamless whole home coverage. And from what I can see, I think it's going to
> be successful. But WFA EasyMesh (release 1) is a tree-topology L2 bridged
> network. I do think this needs to move towards true mesh (and the reason
> they haven't is because they haven't yet been properly introduced to an
> easy method of loop avoidance).
> 
> 
> Do you know if they deal with differences in the security domains? Or is
> it punted to L3? Like in my example, I might want to let my neighbors
> access my hot tub controller, but not, say, my tv. You can envision the
> same thing with guest/kids nets.

Release 1 did not. 
Here is the Release 1 spec: 
https://www.wi-fi.org/file/multi-ap-specification-v10
They do make non-members provide contact info, but the download is free.

Release 2 hasn't been released, yet. And I've pledged to abide by their 
non-disclosure policies, so I can't tell non-members what's in it. I think it's 
safe to say, it adds functionality that many companies find desirable.
Barbara
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet: what now? ... next?

[STARK, BARBARA H]

> I would guess that even after 5 years, we still don't have much
> v6 deployment into homes and that's a pretty big problem. 

That's an interesting statement to make. Do you have evidence of that?
https://www.worldipv6launch.org/measurements/ shows considerable deployment. I 
know for a fact that the AT wireline network supports IPv6 to 100% of 
customers. The reason only 61.26% of traffic is IPv6 is *not* due to the ISP 
not supporting it. It's due to edge networks that don't support. And in this 
case, it's mostly due to enterprises not supporting. The 61.26% number is 
heavily weighted towards mass market customers using IPv6, because it was 
easier to push IPv6 support into managed CE routers.

What I *am* seeing, is a lack of random topology multi-router networks.
While it may be that continued use of IPv4 in home networks is a factor that 
drives people away from multi-router topologies, I don't think this is the same 
as saying that lack of IPv6 is a reason people aren't deploying.
I really don't think IPv6 (or even IPv6-only inside the mass market LAN -- 
which won't be happening for a long time) is a driver for multiple routers.
The biggest driver historically has been to get multiple Wi-Fi access points, 
to cover more of the premises. But many people resisted even this driver, 
because devices didn't seamlessly move between APs and the routed interfaces 
blocked multicast traffic (so you could only cast to your TV if you were on the 
same AP with the TV).

But Wi-Fi Alliance (WFA) has been working to provide a solution for seamless 
whole home coverage. And from what I can see, I think it's going to be 
successful. But WFA EasyMesh (release 1) is a tree-topology L2 bridged network. 
I do think this needs to move towards true mesh (and the reason they haven't is 
because they haven't yet been properly introduced to an easy method of loop 
avoidance). 

So if multi-access points was a driver for multiple routers, WFA EasyMesh may 
very well kill that off as a driver.

But even if the common home network won't have lots of routers, the need for a 
good naming architecture still exists, IMO.
And the need for good loop avoidance...

This is my personal, individual opinion, if that wasn't obvious.
Barbara
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] IETF 104 preliminary agenda

[STARK, BARBARA H]

Hi homenet,
The IESG has published the preliminary IETF 104 agenda. homenet is currently 
scheduled for 9:00-11:00   Tuesday Morning session I. Other sessions at that 
time are jmap, uta, dmm, netmod, rtgarea, cose, teep, and quic.

https://datatracker.ietf.org/meeting/104/agenda.html 

If any key homenet people think they will have issues with this time slot, 
please let your friendly and helpful homenet chairs know.

FYI, I'm seeing more claims of scheduling conflicts (lots of inter-chair 
chatter) with this schedule than I've seen in the past. It seems there are more 
scheduling conflicts because Wednesday afternoon has no sessions. Wednesday 
afternoon is experimentally being left open for people to schedule ad hoc 
meetings. 
Barbara

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

[homenet] draft minutes

[STARK, BARBARA H]

Hi homenet,
I've uploaded draft minutes.
https://datatracker.ietf.org/doc/minutes-103-homenet/

Please let us chairs know if changes are needed.
Barbara

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

[homenet] simple-naming-03: terminology

[STARK, BARBARA H]

I've done an individual review of simple-naming-03. I'm splitting the comments 
up into several emails, just in case there's anything to discuss related to 
each topic. It'll take me some time to get all the emails written (in between 
doing other things).

This email has all of my comments related to terminology.

Section 2
Name: a forward domain  under which information about local services will be 
published
 What is a forward domain? I can't find a definition for this term. 
There's forward DNS (as a process that is followed for domain name resolution), 
but not forward domain. It seems like this is just a domain. Maybe: 
Name: a domain name space that can be used to resolve queries for information 
about local (inside the homenet) services

Authority: a name server that is authoritative for at least one
  forward domain and one or two reverse domains  that are applicable
  to that network and is capable of signing and publishing the zones
  using DNSSEC
 I can't find the definition of "reverse domain", either.  Include DNSSEC 
reference. Could this be:
Authority: a name server that signs its DNS responses using DNSSEC [RFC4035], 
is authoritative for the local services domain name and for domains used for 
reverse DNS queries of IPv4 and IPv6 addresses of devices inside the homenet, 
and maintains SOA records for all zones within the local services domain

Resolution: a full-service caching DNS resolver that fully
  supports EDNS(0)  and queries with the DO  bit set
 Needs references: "... supports EDNS(0)  [RFC6891] and queries with the 
DNSSEC OK bit [RFC3225] set"

"publish"
 "publish" is widely used in the draft in various contexts, but I can't 
find a good definition of what is really meant by "publish" wrt DNS. Is there a 
different term that is used in DNS-related RFCs? I notice the DNS-SD RFC and 
dnssd roadmap don't use the term "publish".

Section 3 Terminology
 Put this before Requirements (directly after Introduction)?

HNR Homenet Router
 Should this maybe be "Homenet Router [RFC7368]"?

SHNR
 Term isn't used. But maybe it should be used in many places where "HNR" 
is used? And maybe it should be "Homenet Router that implements the 
requirements in this document".

AHNR
 Not used in document and not needed. Delete? Alternately, include 
reference to where AHNR is defined.

Forward Mapping  A mapping between a host name or service name and
  some information about that host or service.
 "some information" is very vague. Could this be "resource records"? And 
can we be explicit as to which RR is used to achieve the forward mapping? PTR?

Reverse Mapping  A mapping between an IP address and the host that
  has that IP address.
 Fuzzy definition. This is also done with PTR RR?

Homenet Domain  A domain name that is used for publishing the names
  of devices and services that are present on the homenet.  By
  default, 'home.arpa.'
 Reference at end to [RFC8375] ?

"root" and other "tree" language
There's a lot of DNS structure terminology in this doc that general readers may 
not be familiar with, such as "root", "tree", etc. Maybe include a reference 
where people can go to understand this terminology (pointed to from inside the 
terminology section)? I don't think you need to explain it here -- just tell 
people where to go.

" HNRs implementing this specification  "
 SHNR ?

stateless name service, stateful name service
 I'm not completely sure what "stateful" and "stateless" mean in the 
context of name services. Include in terminology with pointers to docs that 
define them? Is "stateful name server" the same as a name server that does DNS 
over TCP = RFC7766? And stateless means it doesn't do DNS over TCP? Or 
something else?

Name service for reverse mapping subdomains is only provided if one
   or more HNRs can provide stateful service.  If no such server is
   present, the reverse mapping subdomains are not served.  If stateful
   servers are present, the primary and secondary servers for these
   subdomains will be the same as for the homenet domain.
 I really didn't understand this paragraph. Not sure if it's a terminology 
issue for me.

5.2.  Link Names ...
These names are determined using HNCP .
 include reference: "...HNCP [RFC7788]"

7. Publication
Reverse mappings are published
   using Homenet Reverse Mapping Update Protocol Section 7.2.
 Include reference to draft?

8.  Host Configuration
   Each HNR provides a Homenet DNS Proxy .  
 What is a "Homenet DNS Proxy" and how does it differ from a Discovery 
Proxy for Multicast DNS-Based Service Discovery [draft-ietf-dnssd-hybrid]?
 nit: s/ descried  / described  /

14.  Management Considerations ...
   simply using the DNS Service Discovery
   protocol.
 Is DNS-SD really a protocol? I never thought of it as one.

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

[homenet] homenet IETF 103 draft agenda

[STARK, BARBARA H]

Hi homenet,
I've posted a draft agenda at 
https://datatracker.ietf.org/doc/agenda-103-homenet/. For convenience, it's 
copied below. Please let me and Stephen know what adjustments you'd like.
Barbara
-
  IETF 103 - Homenet Agenda
Bangkok, Thailand
13:50-15:20 local time (Wednesday Afternoon session I)
Chitlada 3 room

0. Administrivia and Status Update (5m)

Blue Sheets
Note taker - TBC
Jabber relay - TBC

2. Simple Naming (Ted Lemon, 50 min)
 -- 15 minutes of this time will be dedicated to allowing people 
who don't know what's going on to ask questions.
 -- draft has undergone significant changes -- please read

3. Securing the homenet?

4. SecureHomeGateway project demo video (Michael Richardson, 15 minutes)

5. Charter?

6. AOB and wrap-up (5 min)

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

Re: [homenet] Reminder: homenet call

[STARK, BARBARA H]

Indeed. I’m constantly amazed at Github’s usefulness. Who knew it could be used 
to extend submission cutoff.
For those of you who didn’t get the memo ...
In light of the GitHub outage and the fact that many participants rely on 
GitHub to author drafts, we have extended the I-D submission cut-off by 24 
hours. The new deadline is 23:59 UTC on October 23. Sorry for not being able to 
give earlier notice about this.

Barbara

From: Ted Lemon 
Sent: Monday, October 22, 2018 5:39 PM
To: STARK, BARBARA H 
Cc: HOMENET 
Subject: Re: [homenet] Reminder: homenet call

Okay, actually it's not before the submission cutoff.   So I guess we might as 
well meet.   Life is strange.   :]

On Mon, Oct 22, 2018 at 4:05 PM Ted Lemon 
mailto:mel...@fugue.com>> wrote:
I'm realizing that this is after the submission cutoff.   Would it make more 
sense to just have the conversation in Bangkok?

On Mon, Oct 22, 2018 at 3:37 PM STARK, BARBARA H 
mailto:bs7...@att.com>> wrote:
Hi homenet,
I just wanted to remind everyone we have a call scheduled tomorrow to progress 
the simple-naming draft.

Time: 11:00-12:00 EDT
Place: 
https://ietf.webex.com/ietf/j.php?MTID=mca447be3b15845189801f00cf05f1d21<https://urldefense.proofpoint.com/v2/url?u=https-3A__ietf.webex.com_ietf_j.php-3FMTID-3Dmca447be3b15845189801f00cf05f1d21=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=LoGzhC-8sc8SY8Tq4vrfog=WB2LfiIt07RucckmDQ_Z8kadiXjHucJoyXaUOfvwOLY=CQx93mzHwCGKnxmfFmOkWxvzs5BcGxzo-hZ8pnWHdHM=>
Agenda: 
https://datatracker.ietf.org/doc/agenda-interim-2018-homenet-11-homenet-01/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_agenda-2Dinterim-2D2018-2Dhomenet-2D11-2Dhomenet-2D01_=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=LoGzhC-8sc8SY8Tq4vrfog=WB2LfiIt07RucckmDQ_Z8kadiXjHucJoyXaUOfvwOLY=n5VmI-9UvLzaPFvNxXTqr3ZE3XOXVpSrbKfP1falEEM=>

Join Webex meeting
Meeting number (access code): 642 133 910
Meeting password:   G7ShuHYV

Join by phone
1-650-479-3208 Call-in toll number (US/Canada)

Barbara

___
homenet mailing list
homenet@ietf.org<mailto:homenet@ietf.org>
https://www.ietf.org/mailman/listinfo/homenet<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_homenet=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=LoGzhC-8sc8SY8Tq4vrfog=WB2LfiIt07RucckmDQ_Z8kadiXjHucJoyXaUOfvwOLY=nf6E3reSZk6-J_DC7uyIoHrMfagDmJrsMA8FgIo96vs=>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Reminder: homenet call

[STARK, BARBARA H]

Hi homenet,
I just wanted to remind everyone we have a call scheduled tomorrow to progress 
the simple-naming draft.

Time: 11:00-12:00 EDT
Place: https://ietf.webex.com/ietf/j.php?MTID=mca447be3b15845189801f00cf05f1d21
Agenda: 
https://datatracker.ietf.org/doc/agenda-interim-2018-homenet-11-homenet-01/

Join Webex meeting 
Meeting number (access code): 642 133 910 
Meeting password:   G7ShuHYV

Join by phone  
1-650-479-3208 Call-in toll number (US/Canada)  

Barbara

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

[homenet] homenet scheduling

[STARK, BARBARA H]

Hi homenet,
Homenet is currently scheduled to meet in Bangkok November 7 at 13:50-15:20 
(Wednesday Afternoon session I).

Important dates between now and then:
Document submission deadline: Monday, October 22
Interim call for simple-naming: Oct 23, 11:00-12:00 EDT (details at 
https://datatracker.ietf.org/doc/agenda-interim-2018-homenet-11-homenet-01/) 
Please provide agenda requests. We need to have draft WG agendas by Wednesday 
Oct 24.
Daylight saving time ends in some Middle East countries: Friday, October 26
Daylight saving time ends in parts of Europe, Antarctica, Mexico: Sunday, 
October 28
Daylight saving time ends in parts of US, Canada, Mexico (different parts): 
Sunday, November 4
[I just thought the time changes were useful info.]

Other:
Does anyone want to present with Meetecho?

I hope to see many of you in Bangkok!
Barbara

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

[homenet] interim calls before Bangkok

[STARK, BARBARA H]

Hi Homenet,
New plan for conference calls scheduled between now and Bangkok:

Canceling both Oct 2 and 16 calls. Scheduling a call for Oct 23 at 11:00-12:00 
EDT.
Barbara

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

[homenet] Oct 16 call

[STARK, BARBARA H]

Hi homenet,
Several very important people have conflicts with the Oct 16 call. Therefore, 
I'm cancelling it. 
Please let the homenet chairs know if you would like an additional call 
(11:00-12:00 ET) on Oct 30. Note that on Oct 30, Europe will have left Daylight 
Saving Time (Fall back 1 hour), but the US will not (US leaves Nov 4). So for 
Europeans, 11:00 EDT on Oct 30 will be 15:00 in the UK and 16:00 in central 
Europe. Oct 30 will also be less than a week before the IETF meets in Bangkok. 
So it might just be better to schedule additional F2F time while we're there 
(if relevant people will all be there).
Barbara

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

[homenet] Reminder: Call on Tuesday 11:00-12:30 EDT

[STARK, BARBARA H]

Hi homenet,

We have a call Tuesday, scheduled for 11:00 - 12:30 EDT (though we've been just 
doing 1 hour). We'll be continuing the review of simple-naming. You can ask Ted 
Lemon for access to the most up-to-date version on Google docs. The mostly 
up-to-date version is on the homenet github at 
https://github.com/ietf-homenet-wg/simple-naming.



Barbara


Join Webex 
meeting
Meeting number (access code): 649 597 722


Host key: 801521


Meeting password:

7JEESZ9U





Join by phone
1-650-479-3208 Call-in toll number (US/Canada)



Can't join the meeting? Contact support.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] homenet call on Tuesday

[STARK, BARBARA H]

Hi homenet,
I just wanted to remind everyone of the call this coming Tuesday. Webex details 
below.
Also, if you want to provide Ted with comments on the simple-naming draft, 
remember to send him an email to get invited to the Google docs rendition. I 
put in a few of my own comments there, and Ted addressed them nicely - which is 
to say the system works.
But we need more people reading and commenting.

The agenda (other than boilerplate Welcome, Note Well, taking minutes) is all 
about progressing the simple-naming draft. The official version of the agenda 
is posted at
https://datatracker.ietf.org/doc/agenda-interim-2018-homenet-03-homenet-01/..

All 3 active homenet WG drafts are also on the 
https://github.com/ietf-homenet-wg site. But the expectation for simple-naming 
is that the Google docs version is the most recent Editor's version. 
Periodically, we'll try to get changes from Google docs into github.
Barbara
--
Details for Tuesday September 4 call at 11:00 EDT.

Join Webex 
meeting
Meeting number (access code): 649 597 722


Host key: 801521


Meeting password:

7JEESZ9U



Join by phone
1-650-479-3208 Call-in toll number (US/Canada)


Can't join the meeting? Contact support.

IMPORTANT NOTICE: Please note that this Webex service allows audio and other 
information sent during the session to be recorded, which may be discoverable 
in a legal matter. You should inform all meeting attendees prior to recording 
if you intend to record the meeting.


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

Re: [homenet] Commentable version of the document is available.

[STARK, BARBARA H]

Thanks, Ted. I’ve also put this draft version on the homenet github site (I 
noted a few nit changes I had to make on the Google drafts page). I think what 
we said is the authors would periodically push a new version from what’s in 
Google docs onto the github page. Ted, Stuart, and Daniel should all have full 
access to the github repository.

https://github.com/ietf-homenet-wg/simple-naming

Barbara

From: homenet  On Behalf Of Ted Lemon
Sent: Tuesday, August 21, 2018 12:41 PM
To: HOMENET 
Subject: [homenet] Commentable version of the document is available.

We had our first interim meeting on the homenet naming architecture today.   
The chairs took good notes, so I assume they will summarize, but one of the 
action items was to convert the document to markdown and share it as a Google 
Doc, which I have done.   If you are interested in reading the document that 
way and commenting on it, please send me email privately and I'll send you a 
link.   I'm not going to send the link to the list because then it'll be in the 
archive and might get mobbed by spambots.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Home Networking (homenet) WG Virtual Meeting: 2018-09-04

[STARK, BARBARA H]

Thx Ted, for noticing. Looks like someone was having fun with time zones.
BTW, the messed up meeting times were for September 4 and beyond. Tomorrow’s 
was ok.
It’s late-ish for Stephen, now. So I’ve decided to go ahead and take care of 
this stuff. Hopefully Stephen doesn’t try to also fix things.

I went in and created brand new meeting requests for those September and 
October dates – with the correct time.
I guess there is some lag between when the meetings are requested and when 
they’re posted.
I also created the Sept/Oct meetings in WebEx. And I sent the WebEx meeting 
invitation for those *and for tomorrow* to homenet.
I’m addicted to having .ics invitations dropped into my calendar, and realized 
I didn’t have one for tomorrow. That could have been bad.

We (homenet chairs) still need to contact the secretariat to cancel the 
wrong-time-zone Sept/Oct meetings in datatracker.
Barbara

From: homenet  On Behalf Of Ted Lemon
Sent: Monday, August 20, 2018 12:59 PM
To: ietf 
Cc: HOMENET 
Subject: Re: [homenet] Home Networking (homenet) WG Virtual Meeting: 2018-09-04

I believe that this meeting was originally scheduled for 1500 UTC, which would 
be 1600 Dublin time, not 1100 Dublin time.   A time change the day before the 
meeting is (a) not enough notice and (b) I suspect not what was intended. :)

On Mon, Aug 20, 2018 at 12:21 PM, IESG Secretary 
mailto:iesg-secret...@ietf.org>> wrote:
The Home Networking (homenet) Working Group will hold
a virtual interim meeting on 2018-09-04 from 11:00 to 12:30 Europe/Dublin.

Agenda:
Continuing progressing issues with 
https://tools.ietf.org/html/draft-ietf-homenet-simple-naming-02

Information about remote participation:
Remote participation information will be obtained at the time of approval

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

Re: [homenet] [babel] about Babel security (questions for Juliusz Chroboczek)

[STARK, BARBARA H]

>   On Fri, 29 Jun 2018 17:46:35 +0100 STARK, BARBARA H
>  wrote   > Hi Denis,  > You appear to have perceived
> events and statements different from how others' have perceived these.
>  > I don't find this thread accusing Juliusz of bad behavior to be an
> appropriate way of addressing your perceptions.
>  > As chair of homenet (your email was sent to homenet and babel), I would
> appreciate an opportunity to talk to you directly (by phone / VoIP) to try to
> better address your perceptions. I find trying to do this by email very
> challenging.
>  > If others share Denis' perceptions, please let the chairs know.
>  > Thx,
>  > Barbara
> 
> It has been a month and a week since then and for clarity I find it necessary
> to follow up.
> 
> Barbara, you had sent me an e-mail directly and thoroughly explained why in
> your opinion I was doing a wrong thing. I had studied that with attention.
> 
> I had answered your message, at length, directly on 2 July and explained, as
> clearly as I could, which meaningful details you did not take into account 
> from
> my point of view. Also I had asked my own questions, including if you still 
> find
> my posts to the list(s) inappropriate given that input. I expected a reply, 
> but
> it never came.

Hi Denis,
I apologize for not replying to you earlier. I will respect your wish and reply 
to you on list, rather than unicast. I would much prefer to unicast you with 
what I have to say.
The chief reason I did not reply before was I felt I needed advice on handling 
this situation. I consider Juliusz to be a friend and needed to make sure I 
wasn't allowing friendship to get in the way of impartial chairing. At IETF in 
Montreal, I asked several people who are long-time, respected IETF leaders 
(with no homenet or babel affiliation, and who do not know you or Juliusz) to 
look at your postings, provide me with their opinions, and recommend a course 
of action. 

The reaction to your postings was universally negative. All who saw them 
considered them inappropriate and abusive. The recommendation was universally 
to remove you from WG email lists, if such postings did not stop.

I apologize again for not replying to you earlier, but this is a very difficult 
email for me to write. It is clear to me that you are a highly intelligent 
person who has considerable technical expertise and knowledge. I also believe 
that you are a good person with honest motivations. But you don't seem to 
interpret things the same as other people do.

Your personal attacks against Juliusz need to stop. What you are accusing him 
of is not a violation of IETF or WG procedures or policies. Therefore the 
accusations are not relevant. Furthermore, they appear to me to make baseless 
claims.

If the personal attacks do not stop on the homenet list, Stephen and I will be 
forced to take the recommended action and remove you from the list.
As Stephen is truly impartial here, I will ask him to make any final decisions 
on this matter.

I recognize that I'm not the right person to try to help you better understand 
how people are reacting to your emails. If you are willing, however, I would be 
happy to find someone who would volunteer to mentor you. I think you are a 
valuable human being with deep technical knowledge and expertise who has the 
potential to make a great contribution to IETF.
Barbara

> I accept people have their own plans for their own time. However, in order
> to avoid further misunderstanding in the working group(s), please mind that
> from now on I am unlikely to engage in off-list discussions about this 
> matter. I
> have already explained the problem on the list, several times over, and I
> have raised exactly the points I was going to raise. If Barbara or anybody 
> else
> has anything to add, please do it on the list under your name, like I do.
> 
> Thank you.
> 
> --
> Denis Ovsienko
> 
> 
> ___
> babel mailing list
> ba...@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_babel=DwICAg=LFYZ-
> o9_HUMeMTSQicvjIg=LoGzhC-8sc8SY8Tq4vrfog=rEUH5kHzbYNXLwd-
> cyPRyKR6UyRf8P7NpzoHgfucn48=AjodDmUXAB1a7IecLNpGVaxx5QElrd_S
> NPNF8MvrhUY=

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

Re: [homenet] drafts on github

[STARK, BARBARA H]

I’ve now finished the repository for -dhc-options, too. I saw the commits from 
Tomek were very old.
I think everything looks ok at 
https://github.com/ietf-homenet-wg,
 and the tools seem to work.
So I think that mainly just leaves setting up the editors and additional 
aotomations.
Barbara

for more information.
Daniel: Thanks for doing this.
Just to add more change (no that’s not really the reason – the reason is to 
formalize things with official Note Wells and integrated IETF tools and such), 
we have an official homenet-wg github site 
(https://github.com/ietf-homenet-wg).
 I’ve put the front-end-naming-delegation draft there. I did just a little bit 
to the .mkd Daniel created to make it Linux compatible (get rid of annoying 
end-of-line characters), added and deleted spaces to make markdown happy, and I 
successfully made the IETF tools stop complaining. And changed the extension to 
.md. The only “real” thing I changed was the howard-dnsop-ip6rdns draft 
reference to ietf-dnsop-ip6rdns. kramdown-rfc2629 successfully creates a .xml 
file for this .md; and xml2rfc successfully creates .html and .txt from that 
.xml.

Daniel, you should now have permission to do things to this draft? I need to 
add the other editors to the team – maybe if editors could unicast me with your 
github user names?

Next is -dhc-options. I see Tomek has been doing things, so I don’t want to set 
up the repository for this one till I know I have the latest.
Barbara



From: homenet mailto:homenet-boun...@ietf.org>> On 
Behalf Of Daniel Migault
Sent: Friday, August 03, 2018 6:02 PM
To: homenet mailto:homenet@ietf.org>>
Subject: [homenet] drafts on github

Hi,

To ease collaboration I have converted to mkd the following drafts
https://github.com/mglt/ietf-homenet-hna
https://github.com/mglt/ietf-homenet-hna-dhcp

I suggest we focus on the front-end-naming architecture draft, and I will catch 
up comments I have not yet answered.

During IETF102, I git that the draft was too long. I believe that is resulting 
from considering all feed backs and details. Though I believe these are 
important pieces, I agree that some of them could be better placed in an 
appendix. I would be happy to get what the WG wants to put in appendix as well  
as how the WG expects to shorten the draft.

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

Re: [homenet] drafts on github

[STARK, BARBARA H]

Daniel: Thanks for doing this.
Just to add more change (no that’s not really the reason – the reason is to 
formalize things with official Note Wells and integrated IETF tools and such), 
we have an official homenet-wg github site 
(https://github.com/ietf-homenet-wg). I’ve put the front-end-naming-delegation 
draft there. I did just a little bit to the .mkd Daniel created to make it 
Linux compatible (get rid of annoying end-of-line characters), added and 
deleted spaces to make markdown happy, and I successfully made the IETF tools 
stop complaining. And changed the extension to .md. The only “real” thing I 
changed was the howard-dnsop-ip6rdns draft reference to ietf-dnsop-ip6rdns. 
kramdown-rfc2629 successfully creates a .xml file for this .md; and xml2rfc 
successfully creates .html and .txt from that .xml.

Daniel, you should now have permission to do things to this draft? I need to 
add the other editors to the team – maybe if editors could unicast me with your 
github user names?

Next is -dhc-options. I see Tomek has been doing things, so I don’t want to set 
up the repository for this one till I know I have the latest.
Barbara



From: homenet  On Behalf Of Daniel Migault
Sent: Friday, August 03, 2018 6:02 PM
To: homenet 
Subject: [homenet] drafts on github

Hi,

To ease collaboration I have converted to mkd the following drafts
https://github.com/mglt/ietf-homenet-hna
https://github.com/mglt/ietf-homenet-hna-dhcp

I suggest we focus on the front-end-naming architecture draft, and I will catch 
up comments I have not yet answered.

During IETF102, I git that the draft was too long. I believe that is resulting 
from considering all feed backs and details. Though I believe these are 
important pieces, I agree that some of them could be better placed in an 
appendix. I would be happy to get what the WG wants to put in appendix as well  
as how the WG expects to shorten the draft.

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

Re: [homenet] standard way of configuring homenets

[STARK, BARBARA H]

> From: Ted Lemon 
> Hm, possibly there's been some miscommunication here: we aren't talking about 
> using tools developed for managed networks for amateurishly-managed networks. 
>   We are talking about the problem of making it possible to do some degree of 
> management of homenets.   I don't think anybody is assuming that we will just 
> forklift in SNMP or Netconf/Yang; indeed, at least one suggestion was to just 
> use HNCP.   HNCP actually possesses exactly the attack surface you are 
> talking about if we don't have some kind of enrollment protocol.

I don't see HNCP as being usable in DDoS attacks or as being useful in 
compromising a device. It can give a device bad config info, which could 
prevent the home network from working as desired. But it can't be used for a 
Mirai-like DDoS attack. And it doesn't have the ability (yet) to configure 
login credentials for more in-depth device management. It doesn't supply a 
management interface so much as send around best effort config info.

I agree with the need for some kind of enrollment to protect components of the 
homenet solution. I'd rather not rely on this enrollment to guarantee that 
components of the homenet solution cannot be used for DDoS attacks. I would 
prefer for homenet solutions to be natively incapable of being used in DDoS 
attacks.
Barbara

On Wed, Jul 25, 2018 at 12:40 PM, STARK, BARBARA H <mailto:bs7...@att.com> 
wrote:
> >  Since homenet is supposed to be about an unmanaged
> > network, and configuration via a management protocol requires somebody
> > who knows what they’re doing,
> 
> Traditionally, yes, but we do actually want to get away from that.
> (It's our explicit goal to do that in ANIMA, for which homenets are out of
> scope, but we assume that the starting point is a NOC staffed by people who
> know what they are doing.)
> 
> The idea of capturing a homenet config and saving it for future use doesn't
> seem outlandish to me, and using tools developed for managed networks,
> but operated robotically instead of manually, doesn't seem crazy either. But
> it might be a big effort and a distraction.


Using tools developed for managed networks in amateurishly-managed (or 
unmanaged) home network environments has historically turned out very badly.
Poorly implemented management protocols and "backdoors" are a leading cause of 
security vulnerabilities. These poor implementations are common and prevalent. 
Improperly secured, but (otherwise) well-implemented management protocols are 
another leading cause of security vulnerabilities. This is also common and 
prevalent.
And I'm not just talking about the device's or home network's security. I'm 
talking about Internet security -- this is how DDoS attacks are enabled.
As a data point: providers like Comcast actively block SNMP ports because SNMP 
is so easy to use in DDoS attacks. 
(https://urldefense.proofpoint.com/v2/url?u=https-3A__www.xfinity.com_support_articles_list-2Dof-2Dblocked-2Dports=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=LoGzhC-8sc8SY8Tq4vrfog=s27KbgGycHKQ4PdDhbU8u3hn_hJ6V8VXhZLiP1YXI-M=73RoZA55LrnReb6kBTz2o8DIdaoGN0pHtadgVDGVrL8=)
I realize netconf and restconf aren't SNMP. But please don't think that if 
these protocols were to be deployed in millions of consumer devices and placed 
under the control of end users we would discover them to be magically immune to 
poor implementations and being improperly secured. I have yet to see a 
management protocol that is immune to either of these issues.

Which isn't to say it couldn't be done or there might not be a good use case 
for it. I'm saying that it is a huge effort that would need to be done with 
extreme foresight and care. We would need to understand extremely well exactly 
what we do and don't want from such a management solution -- exactly what 
problems we are trying to solve and what our requirements are. Does it need to 
be a single management protocol to solve everything, or do we separate 
reporting of statistics from configuration backup from UI for user 
configuration? We would have to be rock-solid on requirements for securing any 
such management interface, understand what our strategy is for minimizing 
occurrence of poor implementations, and understand what our strategy is for 
minimizing occurrence of improperly-secured implementations.

On the plus side -- maybe if we were able to do this, it would keep developers 
from creating their own custom vulnerabilities (aka management interfaces) by 
giving them a viable properly secured solution.
Barbara

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

Re: [homenet] standard way of configuring homenets

[STARK, BARBARA H]

> STARK, BARBARA H  wrote:
> >  Since homenet is supposed to be about an unmanaged
> > network, and configuration via a management protocol requires
> somebody
> > who knows what they’re doing, it doesn’t fall within my interpretation
> > of the charter.
> 
> I don't think that management requires somebody who knows what they
> they are doing...  :-)
> 
> I'm thinking along the lines of being able to *backup* the configuration and
> restore it.   You may be right that it's out of charter regardless.
> 
> I think that the developers of homenet products need to be able to get
> telemetry about what went wrong: so at the least, *we* need to be able to
> debug what went wrong.

I think we could do something for config backup (and restoration) and supplying 
logs and statistics in a way that would not give me the heebie-jeebies (by 
enabling a fully-functional management interface). 
I still really like NetJSON (netjson.org) as a mechanism for supplying 
read-only statistics, logs, and config info. I think if we creating some custom 
NetJSON modules and getting a DNS-SD service name would be really simple and 
pretty flexible.
For backup, I think a device could create, name, and encrypt its own backup 
file, and would just need some place to put it. That backup store wouldn't need 
to be able to log into the device, otherwise configure the device, or be 
responsible for pulling these backups. 
Barbara
 
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] standard way of configuring homenets

[STARK, BARBARA H]

> >  Since homenet is supposed to be about an unmanaged
> > network, and configuration via a management protocol requires somebody
> > who knows what they’re doing,
> 
> Traditionally, yes, but we do actually want to get away from that.
> (It's our explicit goal to do that in ANIMA, for which homenets are out of
> scope, but we assume that the starting point is a NOC staffed by people who
> know what they are doing.)
> 
> The idea of capturing a homenet config and saving it for future use doesn't
> seem outlandish to me, and using tools developed for managed networks,
> but operated robotically instead of manually, doesn't seem crazy either. But
> it might be a big effort and a distraction.


Using tools developed for managed networks in amateurishly-managed (or 
unmanaged) home network environments has historically turned out very badly.
Poorly implemented management protocols and "backdoors" are a leading cause of 
security vulnerabilities. These poor implementations are common and prevalent. 
Improperly secured, but (otherwise) well-implemented management protocols are 
another leading cause of security vulnerabilities. This is also common and 
prevalent.
And I'm not just talking about the device's or home network's security. I'm 
talking about Internet security -- this is how DDoS attacks are enabled.
As a data point: providers like Comcast actively block SNMP ports because SNMP 
is so easy to use in DDoS attacks. 
(https://www.xfinity.com/support/articles/list-of-blocked-ports)
I realize netconf and restconf aren't SNMP. But please don't think that if 
these protocols were to be deployed in millions of consumer devices and placed 
under the control of end users we would discover them to be magically immune to 
poor implementations and being improperly secured. I have yet to see a 
management protocol that is immune to either of these issues.

Which isn't to say it couldn't be done or there might not be a good use case 
for it. I'm saying that it is a huge effort that would need to be done with 
extreme foresight and care. We would need to understand extremely well exactly 
what we do and don't want from such a management solution -- exactly what 
problems we are trying to solve and what our requirements are. Does it need to 
be a single management protocol to solve everything, or do we separate 
reporting of statistics from configuration backup from UI for user 
configuration? We would have to be rock-solid on requirements for securing any 
such management interface, understand what our strategy is for minimizing 
occurrence of poor implementations, and understand what our strategy is for 
minimizing occurrence of improperly-secured implementations.

On the plus side -- maybe if we were able to do this, it would keep developers 
from creating their own custom vulnerabilities (aka management interfaces) by 
giving them a viable properly secured solution.
Barbara

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

Re: [homenet] standard way of configuring homenets

[STARK, BARBARA H]

 Since homenet is supposed to be about an unmanaged network, 
and configuration via a management protocol requires somebody who knows what 
they’re doing, it doesn’t fall within my interpretation of the charter.
Barbara

From: homenet  On Behalf Of Ted Lemon
Sent: Tuesday, July 24, 2018 5:57 PM
To: Michael Richardson 
Cc: homenet 
Subject: Re: [homenet] standard way of configuring homenets

I don't think using HNCP in that particular way is a great plan, but I'm 
willing to be convinced.   I would hope that this is in charter.

On Tue, Jul 24, 2018 at 5:48 PM, Michael Richardson 
mailto:mcr+i...@sandelman.ca>> wrote:

I very much like the idea of having a standard way to configure homenets.
There is the YANG/NETCONF method, and I think that we should go in that
direction.

A thought I had though could a HOMENET configuration be recorded by
capturing just HNCP traffic?  Could a network configuration be restored
by essentially playing back that stuff?  I'm pretty sure that this won't
work, but the question is... should it?

Does this work fit into the charter?

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



___
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

[homenet] homenet 102 minutes

[STARK, BARBARA H]

Hi homenet,
Draft minutes have been posted. 
Thx to Phill Hallam-Baker for taking them.
https://datatracker.ietf.org/meeting/102/materials/minutes-102-homenet-01.html
Please let us know if you think they need changes.
Barbara and Stephen

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

Re: [homenet] (no subject)

[STARK, BARBARA H]

> > You're concerned with the homenet losing state when the master is 
> > unplugged.   By having the master in the cloud, this problem is eliminated.

> I can't speak for Juliusz, but my first question was "what if i don't want it 
> in the cloud"? For one thing, what if it's a cloudless day?

I was starting to accept the idea that selecting a subset of my devices to 
exist in global DNS. But absolutely, positively, not all. Any design I could 
buy into will *not* push all my DNS into the cloud.
Barbara

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

[homenet] agenda changes

[STARK, BARBARA H]

Hi homenet,
There've been some agenda changes, to let Daniel be in 2 places at once, and 
make the total allocated time add up to 90 minutes. I'll see y'all this 
afternoon.
Barbara

IETF 102 - Homenet Agenda

0. Administrivia (5m)

1. WG Status Update - Chairs (2 min)

2. Outsourcing Home Network Authoritative Naming Service (Daniel Migault, 
Jacques Latour, 20 minutes)
 - drafts on front-end-naming-delegation and naming-architecture-dhc-options, 
and their implementation

3. Simple Naming (Ted Lemon, 50 min)

4. Status report on security topics (Barbara Stark, 10 min)

5. AOB and wrap-up (3 min)

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

Re: [homenet] homenet agenda update

[STARK, BARBARA H]

Thx Juliusz. I’m not expecting discussion on this during the meeting. Hopefully 
we can resolve all issues on list. 
I’ll be more proactive going forward in pushing this to completion. 
Barbara 

On Jul 10, 2018, at 9:08 AM, Juliusz Chroboczek  wrote:

>> - draft-ietf-homenet-babel-profile-06 waiting on Juliusz for updated draft
> 
> My current draft of -07 is here:
> 
>  
> https://urldefense.proofpoint.com/v2/url?u=https-3A__raw.githubusercontent.com_jech_babel-2Ddrafts_master_draft-2Dietf-2Dhomenet-2Dbabel-2Dprofile_draft-2Dietf-2Dhomenet-2Dbabel-2Dprofile.xml=DwIDAw=LFYZ-o9_HUMeMTSQicvjIg=LoGzhC-8sc8SY8Tq4vrfog=Cv_FxXKuwwlL_848JgRA_aeBMMpFjHK3NzQS8qd3X0o=UMo9rrhllLEtoUP9IFgizKzcKn-zHnOceXdIDdLycPI=
> 
> It addresses all of Tim Chown's Opsdir review, almost all of Stewart
> Bryant's Genart review, and almost all of the IESG's comments.  I've
> allowed myself to disregard one of Stewart Bryan's comments, and only
> partially followed Alvaro's suggestion to remove normative language from
> the optional section.  Stewart, Alvaro, please let me know if you feel
> strongly about that.
> 
> Plan is to listen for any comments during the Montréal session (which I'll
> be attending remotely), and publish -07 as soon as the server reopens.
> 
> -- Juliusz

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

[homenet] homenet agenda update

[STARK, BARBARA H]

I've updated the homenet agenda. Further updates are still possible -- just let 
the chairs know. - Barbara

IETF 102 - Homenet Agenda

0. Administrivia (5m)

Blue Sheets
Note taker - TBC
Jabber relay - TBC

1. WG Status Update - Chairs (5 min)

Updated Drafts:

- draft-ietf-homenet-front-end-naming-delegation-07 (June 26)
- draft-ietf-homenet-naming-architecture-dhc-options-06 (June 26)

Progressing Drafts:

- draft-ietf-homenet-babel-profile-06 waiting on Juliusz for updated draft

Other Non-Expired WG Drafts

- draft-ietf-homenet-simple-naming-01 [I need to fix this to move it under 
Updated Drafts as -02. -Barbara]

2. Simple Naming (Ted Lemon, 50 min)

3. Front End Naming (Daniel Migault, 10 min)

4. Naming Architecture (Daniel Migault, 10 min)

5. Status report on security topics (Barbara Stark, 10 min)

6. AOB and wrap-up (5 min)

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

Re: [homenet] [babel] about Babel security (questions for Juliusz Chroboczek)

[STARK, BARBARA H]

Hi Denis,
You appear to have perceived events and statements different from how others' 
have perceived these.
I don't find this thread accusing Juliusz of bad behavior to be an appropriate 
way of addressing your perceptions.
As chair of homenet (your email was sent to homenet and babel), I would 
appreciate an opportunity to talk to you directly (by phone / VoIP) to try to 
better address your perceptions. I find trying to do this by email very 
challenging.
If others share Denis' perceptions, please let the chairs know.
Thx,
Barbara

> -Original Message-
> From: homenet  On Behalf Of Denis Ovsienko
> Sent: Friday, June 29, 2018 12:29 PM
> To: "Babel at IETF" ; "homenet" 
> Subject: Re: [homenet] [babel] about Babel security (questions for Juliusz
> Chroboczek)
> 
> Thank you for a prompt response Juliusz.
> 
> Right now I will comment only on one specific point, more follow-ups later.
> 
>   On Fri, 29 Jun 2018 10:53:03 +0100 Juliusz Chroboczek  
> wrote
>  [...]  > > The specification of "Stenberg-style security" for Babel was
> never  > > published. It is June 2018 and I have never seen it, although I
> asked  > > to.
>  >
>  > It was presented at IETF 101 in March 2018 (at which you were present).
> 
> I confirm I attended IETF-101 in person and listened to Antonin's talk and
> slides about DTLS for Babel. I did not see a written specification. At the
> meeting I did bring up the need to see a written spec.
> 
> So in this case "presented" does not go as far as "published".
> 
>  > The draft lives here:
>  >
>  >   https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__github.com_jech_babel-2Ddrafts_tree_master_draft-2Ddecimo-
> 2Dbabel-2Ddtls=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=LoGzhC-
> 8sc8SY8Tq4vrfog=Y3Hx49JV7xQXqwscUPkJtZiOFJkWg8DMoMcJq7RLJ7A&
> s=kEGB_5PgC8bf4Eby4oWRpm9ncUbR1a7KmmuTccFv9qo=
> 
> Thank you for making this update, I am glad a written specification of Babel
> DTLS now exists (i.e. has been published). I have been asking since early
> 2016.
> 
>  > I am not an author.  Please ask the authors, not me, about why it hasn't  >
> been published yet.
> 
> As far as the commit history goes, the file was first added to the repository
> above on 25 June 2018 (four days ago), then it was updated three times on
> 27 June 2018 and two times on 29 June 2018 (today, last time about three
> hours ago). The file is a 325 lines long .xml file, which yields a .txt file, 
> which is
> 8 pages long, 4 of which are boilerplates, the TOC, references and the likes.
> The other 4 pages are the actual specification. The document lists 3 authors.
> 
> I have studied the document and I find it difficult to discuss right now, to 
> be
> honest.
> 
> --
> Denis Ovsienko
> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_homenet=DwICAg=LFYZ-
> o9_HUMeMTSQicvjIg=LoGzhC-
> 8sc8SY8Tq4vrfog=Y3Hx49JV7xQXqwscUPkJtZiOFJkWg8DMoMcJq7RLJ7A&
> s=ZSAkpu4dIvdCqrdMUXoOu4QqeagnuF1ji4pt99IPz2U=

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

[homenet] agenda planning

[STARK, BARBARA H]

Hi homenet,
The recently released "subject to change" IETF agenda has homenet at 
15:20-16:50 on Wednesday.
It looks like a pretty good time with not a lot of contention. 

So what should we talk about?
Clearly we want homenet-simple-naming on the agenda. In fact, it probably makes 
sense to give that draft most of the time and maybe have some real discussion 
on it. So, everyone, please do your homework and read the draft *before* the 
meeting. And to tee things up, don't wait till the meeting to post your 
comments and questions on the list.

I haven't seen any movement in the area of security that would need discussion 
-- but that can always change...
Please let us chairs know what other agenda items you want to cover.
Barbara

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

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

[STARK, BARBARA H]

Hi homenet,
There was great conversation about homenet-simple-naming a couple of weeks ago. 
I wanted to see if I could summarize where that ended up.

Main points discussed were device (friendly? pretty?) name and/or identity 
(public key?) and basic end user management (like giving devices names).

What I read into the discussion (which may not be what others read -- in which 
case we can and should re-discuss) is:
Some users like to give their devices pretty/friendly names. We need to make 
sure that's possible, but not required.
Others will simply accept whatever name the device comes with.
These names are visible to users and should not be confused with credentials or 
a stable identity. But they do need to be unique.
Stable identity is also needed.

So how did I do? And where does this take us?
Barbara

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

[homenet] FW: RFC 8375 on Special-Use Domain 'home.arpa.'

[STARK, BARBARA H]

Congratulations to Ted, Pierre, homenet, et al for completion of another 
milestone. Now if we only had a naming architecture to make good use of this 
domain ...

Barbara

-Original Message-
From: rfc-edi...@rfc-editor.org

A new Request for Comments is now available in online RFC libraries.
 
RFC 8375

Title:  Special-Use Domain 'home.arpa.' 
Author: P. Pfister, 
T. Lemon
Status: Standards Track
Stream: IETF
Date:   May 2018
Mailbox:pierre.pfis...@darou.fr, 
mel...@fugue.com
Pages:  12
Characters: 27377
Updates:RFC 7788

I-D Tag:draft-ietf-homenet-dot-14.txt

URL:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_info_rfc8375=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=LoGzhC-8sc8SY8Tq4vrfog=FErFtj5LMztJl27aAHlGGPn8X9KVZL1W7vd53Koo1_c=XAO4LgxhZRJJSvj8yZEI-W_ENjQEdscwKb7ZI9nwesI=

DOI:10.17487/RFC8375

This document specifies the behavior that is expected from the Domain Name 
System with regard to DNS queries for names ending with '.home.arpa.' and 
designates this domain as a special-use domain name. 'home.arpa.' is designated 
for non-unique use in residential home networks.  The Home Networking Control 
Protocol (HNCP) is updated to use the 'home.arpa.' domain instead of '.home'.

This document is a product of the Home Networking Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track protocol 
for the Internet community, and requests discussion and suggestions for 
improvements.  Please refer to the current edition of the Official Internet 
Protocol Standards 
(https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_standards=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=LoGzhC-8sc8SY8Tq4vrfog=FErFtj5LMztJl27aAHlGGPn8X9KVZL1W7vd53Koo1_c=8O6ENb33W8B7gSLSq-RYgR0F8fXlcBGOp0_Aq9C-wpQ=)
 for the standardization state and status of this protocol.  Distribution of 
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ietf-2Dannounce=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=LoGzhC-8sc8SY8Tq4vrfog=FErFtj5LMztJl27aAHlGGPn8X9KVZL1W7vd53Koo1_c=hVepz2jUgU-0muxXt8NCNX16Q3qmxwTcL8da0wSNqWE=
  
https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.rfc-2Deditor.org_mailman_listinfo_rfc-2Ddist=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=LoGzhC-8sc8SY8Tq4vrfog=FErFtj5LMztJl27aAHlGGPn8X9KVZL1W7vd53Koo1_c=gDDrtYAj07ylraN_9DhBwlVu6wDXEqoh6yFr9xOHiTg=

For searching the RFC series, see 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_search=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=LoGzhC-8sc8SY8Tq4vrfog=FErFtj5LMztJl27aAHlGGPn8X9KVZL1W7vd53Koo1_c=Vxr4ZuU7hZJeyiC-OL2dPahrnxL5vNXxOu-S5-csJ_w=
For downloading RFCs, see 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_retrieve_bulk=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=LoGzhC-8sc8SY8Tq4vrfog=FErFtj5LMztJl27aAHlGGPn8X9KVZL1W7vd53Koo1_c=-X_idKX1_xr1R-quEbLwXGVT4GwT_faW187ZL9TG4Gg=

Requests for special distribution should be addressed to either the author of 
the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless specifically 
noted otherwise on the RFC itself, all RFCs are for unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
homenet mailing list
homenet@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_homenet=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=LoGzhC-8sc8SY8Tq4vrfog=FErFtj5LMztJl27aAHlGGPn8X9KVZL1W7vd53Koo1_c=BKlPqOyHoL1J4JSepUoNjyC2uZ9CGPQDeYz5DMDpMxA=
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Alvaro Retana's Discuss on draft-ietf-homenet-babel-profile-06: (with DISCUSS and COMMENT)

[STARK, BARBARA H]

Hi Alvaro,
Thanks for the comments. I agree we need to make sure the community is 
comfortable with the decision. I've inserted my comments in-line.
Barbara

> I would like to DISCUSS about the Intended Status of this document -- with
> the Chairs and AD.
> 
> I have to confess that I haven't been following the homenet WG as closely as
> I
> probably should have.  Hopefully that means that the topic below has been
> discussed and documented already, making this DISCUSS easy to resolve.
> 
> Back in 2015, the then-Chairs and the AD posted a note titled "Routing Design
> Team outcome and next steps"[1]; in it, they declared "rough consensus that
> Babel[*] shall be the “mandatory to implement” routing protocol for
> Homenet
> routers, albeit only on an Experimental basis at this time...we solicit
> Experimental Internet Drafts to document Homenet-specific profiles of any
> applicable routing solution and to report results of any relevant
> experimentation and implementation.  We expect that this decision will be
> revisited in a future Standards Track document based on specifications and
> running code available at that time."
> 
> My interpretation of the above text is that Babel is MTI, 

 There is no draft or published RFC that proposes making Babel MTI. The 
language of the quoted text is a bit odd (a MTI experimental protocol?), which 
makes it open to interpretation. My interpretation differs from yours. My 
interpretation was that people actively working to create (experimental) code 
for homenet stacks needed to implement Babel if they wanted to test out 
interoperability with other stacks. Those experimental stacks were created. 
Interoperability was tested. We have running code and a standards-track Babel 
draft (rfc6126bis) now. I don't believe a WG discussion has the ability to make 
a protocol MTI in the absence of a published RFC that states it is MTI in some 
context. No draft exists or has ever been submitted to propose making Babel 
MTI. 

> but that the work
> (documents) will be Experimental...and that this decision could change in the
> future (most likely towards confirming and moving to the Standards Track).
> This document was originally adopted as Experimental.  I didn't find an
> explicit discussion on the list about changing that original overall 
> direction,
> nor another declaration by the Chairs/AD.  I did find find a thread in which
> one of the Chairs (Barbara) asked about the status for this document (and
> this document only)[2]; the initial question was framed around the references
> being Standards Track documents (HNCP and rfc6126bis) -- just one answer came
> back (from the author of this document)...
>
> I'm treating this point as a DISCUSS because I think that the WG consensus
> may
> have not been determined to change the original declaration from the
> Chairs/AD
> (from 2015).  In my interpretation of that original declaration, moving Babel
> to the Standards Track means a recognition that it will be *the* protocol
> going
> forward (which changes that initial "only on an Experimental basis at this
> time" phrase), is something that should be discussed explicitly, and not just
> in light of this one document.  That is the part that I haven't seen.

 I consider the lack of alternate proposals as implying there are no 
technical objections to Babel being *the* protocol. It's hard not to be *the* 
protocol when you're the only protocol. Whether or not the 
homenet-babel-profile is Standards track, it is *the* protocol in the absence 
of others. And after 2 years of no other proposal being submitted and multiple 
Babel profile implementations, I suspect WG participants might push back 
heavily against adding another protocol. Another protocol would face a serious 
uphill battle. And this would be true independent of the status attached to the 
Babel profile. Two years is plenty of time to have submitted a draft. 

But there is nothing in the language of the Babel profile that would preclude 
submission of another protocol profile. 

> I note that in the conclusion of the thread about the status of this document
> [3] Barbara does include reasoning that may result in changing the original
> declaration (as does the Shepherd writeup), for example: "there exist
> multiple,
> interoperable implementations" and "no drafts proposing other homenet
> routing
> protocol profiles have been submitted"...but those points don't seem to
> have
> been considered/discussed by the WG (they were not in the original
> message and
> I didn't find another thread -- I also looked at the minutes of the last 
> couple
> of IETF meetings).
> 
> To be clear, I have no objection with Babel being used in homenet
> applications,
> or with it being the Standard protocol.  My point here is that it is not clear
> to me that the WG explicitly reached consensus to change the declaration
> from
> the Chairs/AD.  I will be happy to clear this DISCUSS when the Chairs/AD
> point
> me to the discussion that 

[homenet] minutes from IETF 101

[STARK, BARBARA H]

I've posted draft minutes for the IETF 101 homenet session. Please let us know 
if you have any comments.
https://datatracker.ietf.org/doc/minutes-101-homenet/

It was great fun. We'll have to meet like that again soon.
I hope to see as many of you as possible in Montreal. In the meantime, let's 
keep things going on the list!
Barbara

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

Re: [homenet] homenet - Requested session has been scheduled for IETF 101

[STARK, BARBARA H]

Hi homenet,
Just a quick reminder ...
Our session is scheduled for Friday morning (see details below). There will be 
plenty of room for all who want to attend.
The draft agenda is posted at 
https://datatracker.ietf.org/doc/agenda-101-homenet/
And the Internet Draft submission cut-off date is Monday, March 5. Yes, that's 
this coming Monday.
Have a great weekend!
Barbara

> -Original Message-
> From: "IETF Secretariat" [mailto:age...@ietf.org]
>
> The session(s) that you have requested have been scheduled.
> Below is the scheduled session information followed by the original request.
> 
> homenet Session 1 (1:30:00)
> Friday, Morning Session I 0930-1130
> Room Name: Sandringham size: 300

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

Re: [homenet] Genart last call review of draft-ietf-homenet-babel-profile-05

[STARK, BARBARA H]

> > Perhaps I could suggest something in the vein of "very important" or
> > "much desired feature"
> 
> This is not the notion that I tried to express, probably badly.  It's not
> necessarily the important feature, it's the one that will make people
> implement and deploy the protocol stack in the first place.

Suggestion for '"killer feature" of Homenet': driver for using Homenet

> > I found the term "bosses" leaving much to interpretation
> 
> This happens to be deliberate.  I am trying to avoid implying too much about
> the organisational structure to which the reader belongs -- the "boss" here
> could be the CIO, but it could be the leader of an Academic project, it could
> be the supervisor of the intern who's implementing Homenet, or it could be
> the Benevolent Dictator for Life of a Free Software project.
> 
> If you find a sufficiently stately term that covers all of the above, I'll 
> take it.
> (My thesaurus suggests "chieftain", but I tend to favour "foreman".)

Suggestion for "our bosses": decision makers
Which applies to all of the example people mentioned, but also spouses, 
significant others, and spoiled children -- who may be more relevant in the 
context of homenet.

Barbara

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

[homenet] homenet at IETF 101

[STARK, BARBARA H]

Hi homenetters,
As Stephen mentioned, the homenet session for IETF 101 in London is tentatively 
scheduled for Friday morning, session 1, 9:30-11:30.
We haven't heard anyone complain.
I'm working on the homenet agenda, now.
Please let the chairs (homenet-cha...@ietf.org) know if you would like to 
present. With 2 hours (which is more than we asked for), we should be able to 
give people a good chunk of time.
Barbara

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

Re: [homenet] homenet-babel-profile: status experimental?

[STARK, BARBARA H]

Hi homenet,
Since there has been no objection raised to changing the status of this draft 
from Informational to Proposed Standard, the change has been made.
If you do have a strong objection, though, I'd like to hear it.

The reasons in favor of the change are:
- the main reference, draft-ietf-babel-rfc6126bis, is currently Proposed 
Standard
- there exist multiple, interoperable implementations of this reference
- no drafts proposing other homenet routing protocol profiles have been 
submitted
- avoids needing to create a new revision (with new RFC number) at a later time 
to change from Experimental

Barbara

> -Original Message-
> Sent: Monday, November 20, 2017 2:55 PM
> Subject: Re: [homenet] homenet-babel-profile: status experimental?
> 
> > Currently the draft has intended status of "Experimental".
> 
> That's what Mark told me to do.
> 
> > Given the intended status of 6126bis is Standards Track (and HNCP (RFC
> > 7788) is also Standards Track), would it make sense to make
> > homenet-babel-profile Standards Track as well?
> 
> Yes, I think so.
> 
> > This question does depend on which Babel spec homenet-babel-profile
> > will reference (6126 or 6126bis). [I sent a separate email with
> > comments related to references.] If homenet-babel-profile is going to
> > use 6126 as its spec reference, then Experimental probably would make
> more sense.
> 
> It's going to use 6126bis.
> 
> -- Juliusz

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

Re: [homenet] Link between IEEE 1905.1 and homenet work?

[STARK, BARBARA H]

> From:  Kennedy, Smith 
> My work has recently exposed me to IEEE 1905.1. I am still learning about
> 1905.1, but I began wondering whether there was anything in the IETF that
> extended access to the 1905.1 ecosystem above the 1905.1 abstracted MAC
> layer? I found an old thread on this reflector from nearly 3 years ago
> expressing interest, and discussing an IETF / IEEE SA liaison, but no
> subsequent messages that included "1905.1". Where did this end up?

Hi Smith,
There has been no work in IETF related to IEEE 1905.1 over the past 3 years. 
There is work going on in other organizations related to 1905.1, such as ITU-T 
creating extensions for power management and BBF publishing an open source 
implementation. And some other efforts. If you want to know more, please feel 
free to unicast me.
Barbara

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

Re: [homenet] homenet-babel-profile: references

[STARK, BARBARA H]

> >> draft-chouasne-babel-tos-specific-00 may also cause issues, even
> >> though it is just informational. You may want to consider removing
> >> the reference so it doesn't create issues.
> 
> > Ok.
> 
> Does the same apply to [BABEL-Z]?

I see the Style Guide does allow you to reference work in progress in the 
format you've used. So I defer to the Style Guide and guess all the informative 
reference Work in Progress refs are ok. I guess I need to put the RFC Style 
Guide on my vacation reading list.
Barbara

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

Re: [homenet] homenet-babel-profile: references

[STARK, BARBARA H]

> > If you choose to go with a friendly name for the 6126(bis) reference,
> > consider also friendly-naming RFC 7788 to something like [HNCP] and
> > RFC
> > 7298 to [BABEL-HMAC].
> 
> I've previously been chastised for the opposite (using friendly names instead
> of the RFC numbers), so I'm leaving it as it is right now.  If you're sure of
> yourself, I'll be glad to change to friendly names.

My bad. You're right. I found it in the Style Guide that it's supposed to be 
[RFC].
https://www.rfc-editor.org/rfc/pdfrfc/rfc7322.txt.pdf 
Barbara

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

[homenet] homenet-babel-profile: determining link type

[STARK, BARBARA H]

Hi Juliusz,
Not as chair
I have a question about the following requirement:

   REQ6: a Homenet implementation of Babel SHOULD distinguish between
   wired and wireless links ; if it is unable to determine whether a link
   is wired or wireless, it SHOULD make the worst-case hypothesis that
   the link is wireless.  It SHOULD dynamically probe the quality of
   wireless links and derive a suitable metric from its quality
   estimation.  The algorithm described in Appendix A of RFC 6126 MAY be
   used.

Some older powerline technologies perform worse than Wi-Fi. But since powerline 
is "wired", this requirement suggests it would be preferred.
Also, it's not uncommon to use Wi-Fi to Ethernet or powerline bridges in home 
networks. A router attached to Ethernet that is subsequently bridged to Wi-Fi 
would look to the router like a wired link.

Should we really only suggest that the router dynamically probe the quality of 
wireless links? Or would it make sense to suggest dynamic probing of all links, 
because assuming the entire path between 2 routers uses a single physical layer 
technology may not be a good assumption?
Barbara

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

[homenet] homenet-babel-profile: status experimental?

[STARK, BARBARA H]

One of the most frequent comments I see for drafts post-WGLC is "why did you 
choose status x for your draft?". So I'd like for the WG to consciously agree 
on the status to be used for homenet-babel-profile.

Currently the draft has intended status of "Experimental".
Given the intended status of 6126bis is Standards Track (and HNCP (RFC 7788) is 
also Standards Track), would it make sense to make homenet-babel-profile 
Standards Track as well?
This question does depend on which Babel spec homenet-babel-profile will 
reference (6126 or 6126bis). [I sent a separate email with comments related to 
references.] If homenet-babel-profile is going to use 6126 as its spec 
reference, then Experimental probably would make more sense.

Barbara

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

[homenet] homenet-babel-profile: references

[STARK, BARBARA H]

Here is a set of comments related just to references in homenet-babel-profile.
Barbara

The first 4 references to the "Babel routing protocol" spec are to 
[RFC6126bis]. All subsequent mentions are to RFC 6126. RFC 6126 is not included 
as a reference in the References section. I find this disconcerting, and don't 
understand why requirements are against 6126 while introductory paragraphs 
proclaim 6126bis to be the protocol spec.

Since 6126bis is expected to obsolete 6126, I think it would be best to pick 
one of these two and consistently reference just the one. If we expect 6126bis 
to continue without issues through its WGLC and beyond (so it is roughly on the 
same timeline for completion), then 6126bis would probably be the better 
choice. The two docs could get assigned neighboring numbers. But if we want to 
prevent the 6126bis timeline from creating a publication dependency for 
homenet-babel-profile, then we could just stick with 6126. When 6126bis 
obsoletes 6126, any reference to 6126 will automatically be understood as then 
being to 6126bis. Since this draft is proposed as Experimental, I suspect 
either would be ok, but leave it to those more knowledgeable than I to say for 
sure.

If 6126bis, then I suggest changing the reference name from [RFC6126bis] to 
something like [BABEL-PROTOCOL]. Then replace all cases of "RFC 6126" with 
[BABEL-PROTOCOL]. And the one instance of "RFC 6126 Babel" would also become 
[BABEL-PROTOCOL].

If 6126, then change the reference to RFC 6126. It can be named either 
[BABEL-PROTOCOL] or [RFC6126]. Replace all instances of "RFC 6126bis", 
"[RFC6126bis]", "RFC 6126" as appropriate. If 6126, do you also need a mention 
of RFC 7557 somewhere?

If you choose to go with a friendly name for the 6126(bis) reference, consider 
also friendly-naming RFC 7788 to something like [HNCP] and RFC 7298 to 
[BABEL-HMAC]. 

Since babel-source-specific is normative and not yet published, it will hold up 
publication of this doc. In which case waiting for 6126bis may not  be an 
issue, since 6126bis appears to be timewise ahead of babel-source-specific.
draft-chouasne-babel-tos-specific-00 may also cause issues, even though it is 
just informational. You may want to consider removing the reference so it 
doesn't create issues.

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

[homenet] homenet agenda posted

[STARK, BARBARA H]

Hi homenet,
I've posted a draft agenda for homenet at IETF 100.
https://datatracker.ietf.org/doc/agenda-100-homenet/

Please bash.
Barbara

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

Re: [homenet] IETF WG state changed for draft-ietf-homenet-babel-profile

[STARK, BARBARA H]

Hi homenet,
As agreed in Prague, we're starting WGLC on draft-ietf-homenet-babel-profile, 
now that it has been updated.
I've set the duration for 3 weeks so it will last through the IETF meeting. 
Even though Juliusz won't be there, we can still discuss, if we want.
It might even be more fun without him. Though that's hard to imagine. ;)
Barbara

> -Original Message-
> 
> The IETF WG state of draft-ietf-homenet-babel-profile has been changed to
> "In WG Last Call" from "WG Document" by Barbara Stark:
> 
> https://datatracker.ietf.org/doc/draft-ietf-homenet-babel-profile/
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] support for HNCP in IPv6 CE routers

[STARK, BARBARA H]

As chair...
I think it would be useful for homenet to discuss how to propagate its 
protocols into general purpose home network routers (that people may use at the 
edge or interior) and also what may or may not be good to include in 
requirements specifically targeting routers at the customer's edge (CE). 

Jordi: if you would like to bravely volunteer to help guide this discussion by 
being the person at the presenter microphone, that would be great. We could 
base discussion on the 7084-bis draft so you don't need to have another draft; 
but maybe some slides focused on the specific homenet questions. 

If others in homenet think having this discussion is a bad idea please let 
me/us know. 
Barbara

> On Oct 24, 2017, at 1:07 AM, JORDI PALET MARTINEZ 
>  wrote:
> 
> Hi James,
> 
> I included HNCP in RFC7084-bis following your request :-(
> 
> So even if I’d only a couple of answers, I think it we are on the right track 
> …
> 
> So, concentrating in homenet.
> 
> Do, repeating my 2nd questions, do we believe we need a specific document 
> HOMENET document to suggest to include in CE, or to say how to do it, or 
> whatever?
> 
> Maybe it is interesting, if the chairs agree, to include this question in the 
> WG agenda for the next meeting?
> 
> Regards,
> Jordi
> 
> 
> -Mensaje original-
> De: homenet  en nombre de james woodyatt 
> 
> Responder a: 
> Fecha: lunes, 23 de octubre de 2017, 22:12
> Para: JORDI PALET MARTINEZ , HOMENET 
> 
> Asunto: Re: [homenet] support for HNCP in IPv6 CE routers
> 
>On Oct 23, 2017, at 00:48, JORDI PALET MARTINEZ 
>  wrote:
> 
> 
>Now, in this version I’ve NOT included the HNCP support as a requirement, 
> however I still mention it as:
> 
>The end-user network is a stub network, in the sense that is not
>   providing transit to other external networks.  However, HNCP
>   ([RFC7788]) allows support for automatic provisioning of downstream
>   routers.  Figure 1 illustrates the model topology for the end-user
>   network.
> 
>Now, the questions I’ve for this WG is:
> 
>1) Do you think I should mention other homenet documents ?
>2) Do you think we should have a specific homenet document requiring the 
> support of homenet for IPv6 CE routers, so for example this becomes an 
> integral part of testing by ISPs, IPv6 Ready Logo, or even RFQs, etc.?
> 
>I will be happy to work in a homenet document if we believe that 2 above 
> is needed. Anyone else interested?
> 
> 
> 
> 
> 
>I think it would be better if you leave aside all mention of HOMENET 
> protocols from the RFC 7084-bis draft. That document is mainly intended for 
> first-mile internet service providers, and I think the less the have to say 
> about how residential networks operate behind the demarcation point at the 
> edge of their networks, the better for everyone. This would give HOMENET 
> optimal freedom to write standards for interoperability of devices intended 
> for home networks without having to get mired in the tar pit of dealing with 
> first-mile internet service provider stuff.
> 
> 
>--james woodyatt 
> 
> 
> 
> 
>___
>homenet mailing list
>homenet@ietf.org
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_homenet=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=LoGzhC-8sc8SY8Tq4vrfog=_bR9FvzwQbxh-O6P0rZaAVc0qP9N51NHDxBJbsA_U3g=WZA2wxLl7avD8GFCF7eXUzLwkfVvFzOxKZFGPXPtYDE=
>  
> 
> 
> 
> 
> **
> IPv4 is over
> Are you ready for the new Internet ?
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.consulintel.es=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=LoGzhC-8sc8SY8Tq4vrfog=_bR9FvzwQbxh-O6P0rZaAVc0qP9N51NHDxBJbsA_U3g=HKL3FbaYGYEKqIpNRC_7FRP4YfGsmyViXh2wV5zCEw8=
>  
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or 
> confidential. The information is intended to be for the exclusive use of the 
> individual(s) named above and further non-explicilty authorized disclosure, 
> copying, distribution or use of the contents of this information, even if 
> partially, including attached files, is strictly prohibited and will be 
> considered a criminal offense. If you are not the intended recipient be aware 
> that any disclosure, copying, distribution or use of the contents of this 
> information, even if partially, including attached files, is strictly 
> prohibited, will be considered a criminal offense, so you must reply to the 
> original sender to inform about this communication and delete it.
> 
> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> 

Re: [homenet] homenet "no host changes" assumption and DNS

[STARK, BARBARA H]

> > Currently, there is no host that expects to use .home.arpa (or any other
> domain) inside the premises.
> 
> I don't think the "or any other domain" claim is true.  At the very least, 
> _lots_
> of hosts are already using local. in homenets -- indeed, that's how we got to
> this pass.

Yes. I should have been clearer. I meant this in the context of DNS. Though 
mDNS uses the same protocol semantics and Record structure as DNS, I see mDNS 
as a rather distinct architecture from that of DNS. Maybe I'm mistaken in 
looking at it that way.  I'm not aware of widespread use by hosts of local. for 
DNS queries. Implementations for processing (when to send, how to respond, what 
to do with the info) of mDNS and DNS tend to be distinct.
 
> > There is no host that expects a general-purpose in-home domain name
> system to work or be present.
> 
> That's because there is no host that "expects an in-home domain name
> system" at all.  I think your position is starting from a position with which 
> I
> disagree pretty strongly.  

My primary position is that homenet solutions must do no harm. They must not 
cause people to have a worse or more  frustrating experience and must not 
impose cost on anyone who does not benefit from them (cause other people's 
experience to be worse by making one person's experience better).
My secondary position is they should create an improved user experience. And 
the improvement should be desirable by average people, perceived by these 
people to be worth the cost, and easy for these people to get.
In the context of homenet naming architecture, my position is that a solution 
must meet these "do no harm" and "create an improved experience" positions.

> In my view, what we did many years ago was hook
> up individual machines to an ISP's network.  When broadband home access
> came along, we continued to pretend that the link in the CPE was just a node
> in an ISP's network, and pretended that the home network was not a first-
> class network that was internetworked together with other networks to
> make the Internet.  We ended up with multiple classes of network, some of
> which are only kinda part of the Internet.

I don't understand this concept of first and second class networks. I do see a 
distinction between my home network and networks that participate as part of 
the "public" Internet (including access ISP networks). My home network is mine. 
I don't care whether it uses the same architectural elements as in the "public" 
Internet as long as it does what I want. I recently participated in writing a 
paper with a number of other technology people from various companies, and one 
thing we determined was we could not decide on a definition of "the Internet". 
So I don't know what definition you use. I do know that by my definition, my 
home network is not part of "the Internet", and I don't ever want it to be part 
of "the Internet". I do not want it to be assimilated. This doesn't make my 
home network a lower class network, IMO. It makes it a distinct and different 
network. I agree we have ended up with multiple networks. I disagree they are 
of different classes. They are, simply, different.

I've spent many years focused on understanding and meeting the needs of 
consumers and their home networks. I believe my view of my home network is 
consistent with how most people think of their home network. If you ask an 
average person whether their home network is part of the Internet, I believe 
they will say "no".
 
> The reason that homenet is being worked on in the IETF as opposed to, say,
> the Broadband Forum, is exactly that we are trying to provide
> internetworking services for these surprisingly sophisticated, unmanaged
> networks.  So to say that there's no "general-purpose in-home domain name
> system" misses the point: it's _the_ domain name system, and the homenet
> is part of that global DNS just as surely as com. is, and participates in the
> global name space just as surely as onion. and local. do.

I'm not quite sure what you mean by "global DNS" or what conclusions I should 
draw from this statement. AFAIK, local. is only used with mDNS (which, as I 
mentioned above, I consider to be distinct from DNS, in spite of using the same 
protocol semantics and record structures). I do know, absolutely, that I don't 
ever want my home network names exposed to the public Internet or resolvable by 
everyone "out there". I also know that I don't care how similar or dissimilar 
my home network naming architecture is to "global DNS", as long as it works and 
meets my needs. And I'm quite sure this sentiment is very much shared by 
regular consumers -- the target homenet deployers. 
 
> So, the reason we can't expect host changes for naming is because any plan
> for internetworking that starts, "First, upgrade all the hosts,"
> is doomed.  That hasn't worked since 1983.

I have no expectation of updating *all* hosts. But I do think it may be 
reasonable to expect "if a host 

[homenet] homenet "no host changes" assumption and DNS

[STARK, BARBARA H]

No hat.
I'm proposing something radical here. Let the tomatoes fly.
I'd like to question whether we really need to maintain the "no changes to the 
host" assumption when it comes to architecting homenet DNS.
Currently, there is no host that expects to use .home.arpa (or any other 
domain) inside the premises. There is no host that expects a general-purpose 
in-home domain name system to work or be present. The widest use of in-home 
domains is the way ISPs use domains like ".home". To the best of my knowledge, 
they use those for access to the ISP-supplied router's HTTP-served content. 
Nothing else. The "no host changes" tenet was primarily about not breaking 
existing host functionality. A fully functional in-home domain name system is 
not something any legacy host has expectations or functionality for. As long as 
we don't break usage of Internet DNS, there should not be any requirement or 
mandate that we have to make in-home DNS work for legacy hosts.

If we got rid of the "no changes to host" tenet (for hosts that can make use of 
the home naming architecture), that would give us much more freedom to create 
an in-home DNS architecture without a dependency on homenet routers 
implementing the DNS Proxy kludge. Or any other kludge. It would let us create 
an architecture that would finally start to move us away from DNS Proxy and 
other methods that intercept DNS queries to make supposedly "intelligent" 
decisions on behalf of stupid hosts. And we would not be further entrenching 
use of these DNS intercept functions.

I would like to require the hosts that want to make use of the new homenet 
naming architecture responsible for understanding the different provisioning 
domains and simultaneously launching queries to the advertised (or internally 
configured) DNS servers for each provisioning domain. 

The host that gets multiple DNS responses needs to be responsible for making 
the decision that's right for it. In the case of multiple Internet connections: 
if the application needs high bandwidth and low loss but latency isn't 
important (e.g., streaming video), then maybe it picks the high bandwidth high 
latency low loss connection. If it needs low latency but not much bandwidth 
(e.g., VoIP), then maybe it picks the low bandwidth low latency connection. The 
CE router should not be making this decision (which DNS response to supply to 
the host) on behalf of apps it knows nothing about.

Make the home domain a different provisioning domain, and insist that hosts 
wanting to make use of domain names in the home domain must understand 
provisioning domains and how to use and interact with them. The home domain DNS 
server can be advertised by mDNS or other means.

I truly believe we need to start moving towards providing hosts with the info 
they need to make their own decisions. DNS Proxy mandates (or other DNS 
intercept mechanisms) are antithetical to this. 
Barbara



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

Re: [homenet] tuscles and conflicting goals / trust with draft-tldm-simple-homenet-naming CFA

[STARK, BARBARA H]

> This suggests to me that the next step in HOMENET, which I think the naming
> architecture could lead, is to provide for (automatic) collection of 
> statistics for
> diagnostics purposes.
> i.e. Homenet OAM.

Not as chair...
I disagree this has anything to do with the naming architecture.
I have long felt the best way to accomplish this would be to have a 
discoverable (DNS-SD) NetJSON (http://netjson.org/) "service" on all consumer 
routers, which would supply NetJSON types via http.
I agree supplying statistics info to the home network would be a good thing for 
homenet to tackle. 
I've been wanting to propose this for a while, but keep getting side-tracked.
Barbara

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

[homenet] homenet has adopted draft-tldm-simple-homenet-naming

[STARK, BARBARA H]

I have moved the doc to the adopted state. Ted/Daniel, you should be able to 
upload a WG revision as your next rev.
Barbara

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

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

[STARK, BARBARA H]

> From: Ted Lemon
> Barbara, I seem to recall that you were enthusiastic about the work when it 
> was discussed in the meeting.   You're allowed to be one of the people who's 
> in favor of it, despite being chair.   Indeed, as > chair, you can just adopt 
> it by fiat if you want.   I actually agree with Ray and Michael that Juliusz 
> reasoning was flawed, and am definitely in favor of adopting it and working 
> on it.   I also agree with 
> Andrew that it shouldn't be the final word on naming in the homenet.

Here are my non-chair thoughts.
I do think there is value in defining a home network naming / DNS architecture. 
I (enthusiastically) support adoption of the concept.
The non-boilerplate part of the table of contents is about "Name Resolution", 
with headers for "Configuring Resolvers", "Configuring Service Discovery", 
"Resolution of local names", "DNSSEC Validation", "Support for Multiple 
Provisioning Domains", "Using the Local Namespace While Away From Home". I 
support these as a good initial set of headers for a table of contents.
I don't like requiring DNS proxy in all homenet routers and would like to 
explore other options. But the DNS resolver does have to be somewhere in the 
premises.
I'd like to actually explore what we could for DNSSEC in the context of some 
holistic home network "key" architecture, and maybe we could discuss some more 
even while agreeing it's out of scope for this doc. 
I agree with scoping to internal resolution and not dealing with external 
resolution. But I recognize others might want to discuss more.
I fully agree with this being a separate "provisioning domain", but I'm not 
fully convinced the proposed solution is the right one. 

Conclusion: As long as we can keep discussion alive and healthy, and not go to 
WGLC prematurely, I'm in favor of adoption.
The main reason I hesitated to lend support is from bad experience in other 
groups where authors have tried to object to comments on the basis of "you 
supported adoption, this text was in the draft when it was adopted, and you 
didn't object to this text prior to adoption". But so long as the chairs don't 
tolerate this sort of attitude, I think we'll be fine. BTW, I've never seen 
that attitude from Ted or Daniel. And I have confidence in the chairs' ability 
to be intolerant.

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

[homenet] Status of draft-tldm-simple-homenet-naming CFA

[STARK, BARBARA H]

With one day left in CFA for draft-tldm-simple-homenet-naming, here is my 
summary of what I think I've read.

Exactly 3 people have expressed support for adoption (Daniel [author], Michael 
R, James). Hmm. That's not a lot.

Juliusz expressed opposition to adoption, but Ray and Michael said the 
reasoning for objection was flawed (that Juliusz was setting the bar too high 
and the procedural objections were not valid in the context of IETF 
procedures). Ray said the purpose of a CFA is "to get agreement that a document 
is an appropriate direction for the WG to explore, even if it might require 
substantial work".
Ted [author] said he thought it might be reasonable to put the CFA on hold 
until Daniel did another update.
Tim C said he thought it was early for adoption (for this and related dnssd 
drafts).

I hope I got this summary right. Did I miss anything important?
Does anyone else have an opinion? Does anyone who has expressed an opinion want 
to express a new and different opinion?
Barbara




___
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"

[STARK, BARBARA H]

Thanks Daniel. And you’re not too late. The call ends this coming Friday. So if 
anyone else wants to chime in, please do. I’ll try to create a summary Thursday 
describing what I think I’ve heard so far. That should give everyone a brief 
chance to tell me how badly I’ve misinterpreted their statements before the 
call ends.
Barbara

From: homenet [mailto:homenet-boun...@ietf.org] On Behalf Of Daniel Migault
Sent: Wednesday, August 09, 2017 2:37 PM
To: Michael Richardson 
Cc: homenet@ietf.org
Subject: Re: [homenet] The HOMENET WG has placed 
draft-tldm-simple-homenet-naming in state "Call For Adoption By WG Issued"

Hi,
I apology for the late response (I was off for two weeks). I will update the 
draft by the end of the month integrating numerous feed backs we received.
As a co-author I am supporting the adoption of this document architecture. I 
believe that given the current situation regarding homenet and naming, the 
simple but useful scope of the draft will help the WG to move forward regarding 
naming and home network. I agree the document is not yet in a final version and 
feed back from the WG will be very helpful. That said I think, since last IETF, 
we have a pretty good view on where we are going.
Yours,
Daniel



On Mon, Jul 31, 2017 at 10:07 AM, Michael Richardson 
> wrote:
Ted Lemon > 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.

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

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  [
] m...@sandelman.ca  
http://www.sandelman.ca/
|   ruby on rails[

___
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] I-D Action: draft-ietf-homenet-dot-10.txt

[STARK, BARBARA H]

> In order for a PKI solution to work, it has to be possible for any given cert 
> to apply to a unique name, the ownership of which can be defended somehow.   
> The CABF has spoken unequivocally on this topic:
> https://www.digicert.com/internal-names.htm
> The point of having PKI in the homenet is so that we have secure connections 
> between browsers and servers, and so that users aren't trained to click 
> through certificate warnings just to get things working.   Any solution to 
> this problem has to meet those two requirements.   And to achieve the second 
> requirement, the CABF is going to want it to be the case that the cert 
> identifies a specific endpoint for communication.
> When I say "I don't know how to do that," this is what I'm talking about.   
> Actually, I do know how to do it: get a public delegation.

The CABF is about "publicly trusted certificates". There is no need or 
applicability of "publicly trusted certificates" in the context of a home 
network. No certificate authority in the world is capable of certifying that a 
device inside a specific home network actually belongs there. The only entity 
capable of identifying devices that belong in the home network is the home 
(network) owner. This isn't about public trust. It's about private trust.

In reading Stephen's email about what he did wrt certificates, what stood out 
to me were:
 (1) The primary goal was to stop the annoying browser warnings. [note that 
neither HNCP nor Babel would be expected to check against CAs stored in 
browsers, so they would not be subjected to this annoyance; but the annoyance 
is something to prevent when considering the broader "naming architecture"]
 (2) Stephen (the home network owner) was the assigner of trust. He was the 
root certificate authority.

We had discussed (back in Chicago) that a first step should be to figure out 
first what our goals were wrt "security". From the perspective of the end user, 
here is my starter list of considerations:
1. End users would like to know that device software / firmware has no Trojans 
and is "good". This is not a good fit for X.509 certificates or PKI. This would 
be something for some logo-based certification program (like a UL, Good 
Housekeeping, IPv6 Ready, etc. stamp). I think this is outside the (current) 
scope of homenet and there are other orgs working on this sort of thing. In any 
case, it has nothing to do with encryption and X.509 certificates.
2. End users are the absolute (root) authority as to what does and doesn't 
belong on the home network. No one else. Even in the case of "unmanaged" home 
networks. Verisign and others are incapable of telling me whether or not a 
device belongs on my home network.
3. End users want it to be very easy to add devices/services to the home 
network. 
4. End users want it to be very easy to remove devices/services.
5. End users want to know when devices on the home network are misbehaving, and 
they want to easily identify such devices.
6. End users don't want annoying "untrusted" warnings for devices and services 
inside the home network that they have decided to add to it.

Does this seem like a reasonable list? Are there items y'all disagree with? 
Others to add?
Thanks,
Barbara



___
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"

[STARK, BARBARA H]

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:ietf-secretariat-re...@ietf.org]
> Sent: Friday, July 28, 2017 9:05 AM
> 
> 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/

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

Re: [homenet] Clarification on homenet-dot slides

[STARK, BARBARA H]

> The draft states:
> "The top-level domain name '.homenet.' is to be used for naming within
>a home network.  Names ending with '.homenet.'  MUST refer to
>services that are located within a home network (e.g., a printer, or
>a toaster)."
> 
> Which I think is more correct and hopefully less ambiguous.

My comment was that I find the term "home network" ambiguous. Given this is a 
"MUST", I would like if either (1) "home network" was defined (Stuart proposed 
one possible definition, which I think may have problems, but would prefer to 
see that proposed definition in a written form before judging; I suggested 
using something like the Internal/External interface definitions of RFC 7788, 
but people didn't like that idea), or (2) it was made clear that identifying 
whether an interface served as a home network boundary was left to the 
implementer.
Barbara
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] write up of time without clocks

[STARK, BARBARA H]

> >I could be wrong, but I believe that Dyn was DDoSed by the Mirai
> >botnet, which propagates by exploiting devices configured with default
> credentials.
> >This has nothing to do with outdated firmwares.
> 
> The problem is that you cannot realistically update those firmwares.

Many companies provide devices that do automated updates. It's totally 
realistic to update firmwares. There exist various methods, tools and best 
practices. The problem is that some manufacturers don't bother to make their 
devices upgradable. By not having to maintain the firmware of shipped devices, 
the devices can be sold very inexpensively. So price-conscious consumers will  
buy them, instead of the more expensive, well-maintained devices. 

> It is trivial to compile a new firmware for those devices that doesn't request
> upnp to open ports to telnet or ssh. But is is impossible to deploy such an
> update.

I can't speak for others, but DIRECTV set-top-boxes all do auto update, as do 
Digital Life IoT devices, and U-verse residential gateways. I think iControl 
IoT devices do, too. So, no, it's not impossible. It's just cheaper and 
requires less skill and effort to create devices that can't be updated. The 
exploited vulnerabilities (in the Dyn attack) have been known for years, and 
fixes have been available for years. Even after they were known, new units were 
still shipping with the vulnerability. Secure methods for updating devices and 
best practices for using these methods have existed for years. If the device 
manufacturer had built in a mechanism to allow for secure, automated updates 
(and not hard-coded a default password for access to all devices that couldn't 
even be changed by firmware update), and had made updates available in a timely 
manner, there wouldn't have been vast numbers of devices to exploit. 

> For consumer electronics, we cannot rely on consumers to actually download
> and install new firmware. So part of the solution to securing those devices
> has to be that (out of the box) they will update automatically.

+1
 
> For the same reason, having lots of devices on the internet that have been
> abandoned by the vendor is also a huge security risk. So ideally those devices
> should shutdown automatically.

Which means the vendor would still be responsible for building in a remote 
"kill switch". Ideally, manufacturers would be required to warn consumers prior 
to purchase that the device will be bricked (or maybe just have all IP 
connectivity disabled) if it is ever discovered to have an easily exploitable 
vulnerability.
 
> Note that PCs, browsers, etc. are now somewhat secure because they
> update automatically. We need to do the same with all other devices
> connected to the internet.

+1

Barbara

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

Re: [homenet] [Babel-users] Detecting bridges

[STARK, BARBARA H]

> Homenet, the issue we're dealing with is that babeld performs badly when
> there is a transparent wireless bridge connected to a wired interface: the
> interface is treated as a lossless wired interface, and if it suffers packet 
> loss,
> there is repeated link flapping.  

I've had a lot of experience with trying to use both Wi-Fi and powerline 
bridges. Powerline bridges can suffer from a lot of the same flapping as Wi-Fi. 
I'm aware of an IPTV provider who experimented with using 802.11-Ethernet 
bridges to connect set-top boxes (STBs) to the router. They wanted super-duper 
good wireless for the STBs, so they used proprietary 802.11-based technology 
and this 802.11 was dedicated to just the STBs (so it wasn't using the same 
Wi-Fi as the home network). They ended up building this 802.11 technology into 
the STBs and into the home router (separate radio from the home Wi-Fi), because 
the bridged connection just wasn't resilient. I'm also aware of powerline 
bridges being used in lots of IoT "smart home" deployments. And then there are 
the powerline to Wi-Fi bridges (Wi-Fi extenders) which I'm seeing more and more 
of. 

The main problem I've seen with frequently flapping bridges is host IP/Ethernet 
stacks (where the host -- including router WAN "host" -- thinks it has an 
Ethernet connection) that give up "quickly" on the connection. Reboots or even 
just disabling and then enabling the network interface cause the connection to 
be seen again and IP connectivity re-established. Forced DHCP release/renew 
doesn't tend to work, which leads me to believe the problem may be in the 
Ethernet stack, and not with IP and DHCP. I've never bothered trying to figure 
out the root cause -- instead I just stop using the bridges that don't work, 
and do something different that does work. I've definitely seen this problem a 
lot, though.

My take-away from my experiences:
Bridges are incredibly useful -- when they work. The better they work, the more 
people will use them. Homenets (including hosts) need to be resilient to 
flapping Ethernet links.
There are host IP/Ethernet interface issues (including router WAN "host") that 
are prevalent and need to be solved independent of anything Babel does. Issues 
that cause hosts to decide there is no connectivity on Ethernet links that flap.
The problem is not limited to Wi-Fi bridges. It also exists on powerline.
I'm curious as to the prevalence of LLDP in bridges. If LLDP is being included 
in bridges, it could be used to detect them. Hmm. I should try to find out.
I don't know right now what the right answer is for Babel.

Barbara

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

Re: [homenet] The minimal Babel profile for Homenet

[STARK, BARBARA H]

> > Maybe conditionally mandatory? If the router can be used for routing
> 
> That's what SHOULD is *for*
> If you are concerned it won't get implemented, then any weasel room you
> leave will be exploited.  At that point, the market gets to decide.


No, SHOULD and conditionally mandatory are 2 very different types of 
requirements. When designing a test tool to automate testing of requirements, a 
tool generally issues a warning when a "SHOULD" is not implemented (correctly). 
But for conditional mandatory, a tool will test for the condition and then 
issue a failure if the requirement is not implemented (correctly). But I agree 
that in IETF, I haven't seen use of conditional mandatory. I think that's 
unfortunate and I think this is the reason many IETF "SHOULD" requirements 
aren't implemented when they need to be implemented. 

But I'm not willing to spend more time arguing in this particular case. CE 
router vendors are a tremendously pragmatic bunch. If it's easy and could cause 
dissatisfaction with their product if not implemented, they will more than 
likely do it. This looks pretty easy to me, especially with the availability of 
a lot of open source code for it.
Barbara

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