Subject: [mdnsext] Fwd: FW: Mail lost yesterday
From: Tim Chown <[email-masked]>
To: "[email-masked] mdnsext" <[email-masked]>
Date: Thu, 29 Aug 2013 23:02:52 +0100
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <mdnsext.ietf.org>

Begin forwarded message:
> 
> -------- Original Message --------
> 
> From: Adrian Farrel <[email-masked]>
> Reply-To: <[email-masked]>
> To: <[email-masked]>
> 
> For those of you who haven't noticed the message from Steve Young in
> your In box, mail to all IETF lists between 15:30 and and 20:55 Pacific
> Time yesterday seems to have been lost. Aside from needing to re-send
> all mail you personally sent during that time period, you also need to
> inform your working groups.

From: Ralph Droms <[email-masked]>
Date: Wed, 28 Aug 2013 15:04:30 -0700
To: SM <[email-masked]>
Cc: "[email-masked] mdnsext" <[email-masked]>, Chown Tim <[email-masked]>
Subject: Re: [mdnsext] dnssdext charter

On Aug 28, 2013, at 2:47 PM 8/28/13, SM <[email-masked]> wrote:

> Hi Tim,
> At 02:44 28-08-2013, Tim Chown wrote:
>> If candidate WGs were treated the same way as real WGs within the =
tools system, related drafts could presumably also be automatically =
listed, for example?
>=20
> The IETF will end up having side-working groups.  It's not a good idea =
in my opinion. :-)

Suppose the instantiation of these candidate WGs were constrained with =
an expiration date?

- Ralph

>=20
> Regards,
> -sm=20
> _______________________________________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mdnsext

Date: Wed, 28 Aug 2013 14:47:46 -0700
To: Tim Chown <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [mdnsext] dnssdext charter

Hi Tim,
At 02:44 28-08-2013, Tim Chown wrote:
>If candidate WGs were treated the same way as real WGs within the 
>tools system, related drafts could presumably also be automatically 
>listed, for example?

The IETF will end up having side-working groups.  It's not a good 
idea in my opinion. :-)

Regards,
-sm 

From: Ralph Droms <[email-masked]>
Date: Wed, 28 Aug 2013 09:24:10 -0700
To: Tim Chown <[email-masked]>
Cc: "[email-masked] mdnsext" <[email-masked]>
Subject: Re: [mdnsext] dnssdext charter

On Aug 28, 2013, at 2:44 AM 8/28/13, Tim Chown <[email-masked]> =
wrote:

> On 28 Aug 2013, at 09:54, SM <[email-masked]> wrote:
>=20
>> Hi Tim,
>> At 01:44 28-08-2013, Tim Chown wrote:
>>> I had also assumed we could use an IETF wiki, but it seems those are =
only available once a WG is formed, under the tools area.
>>=20
>> See http://trac.tools.ietf.org/bof/trac/wiki/WikiStart
>=20
> Hi - thanks, I'm aware of that one, and used it for mdnsext/dnssdext, =
but it's somewhat clumsy being mixed in with other information and BoFs, =
espeially when we had over ten BoFs in Berlin; what I was hoping for was =
a dedicated wiki area as per the WGs, which could be used at the same =
time as a mailing list is formed and independently of whether/when a BoF =
is being held (for example there was no mdnsext BoF at IETF87, but there =
was a first one at 86 then a second at 88).
>=20
> If candidate WGs were treated the same way as real WGs within the =
tools system, related drafts could presumably also be automatically =
listed, for example?

The current set of tools seems to be part way there.  I've put a request =
in to see if BoFs can be made more equal to WGs in the tools.

- Ralph

>=20
> Tim
>=20
>> You could also use the Area wiki if the relevant Area Director is =
okay with that.
>>=20
>> Regards,
>> -sm=20
>> _______________________________________________
>> mdnsext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mdnsext
>=20
> _______________________________________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mdnsext

From: Tim Chown <[email-masked]>
Date: Wed, 28 Aug 2013 15:48:44 +0100
To: "[email-masked] mdnsext" <[email-masked]>
Subject: [mdnsext] Draft minutes, dnssdext BoF, Berlin

--Apple-Mail=_3C579C9D-26CF-4350-9FF1-651E9E4CF4F2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

We need to finalise the dnssdext minutes by the end of the week. Draft =
minutes are available at

http://www.ietf.org/proceedings/87/minutes/minutes-87-dnssdext

If you have any corrections, please let myself or Ralph know, or reply =
here.

Ralph and I encourage people to contribute to the charter thread, and to =
the requirements draft, which Kerry and Stuart will hopefully be =
updating based on the BoF comments. These are both important tasks =
towards the potential WG formation.

Many thanks,
Tim=

--Apple-Mail=_3C579C9D-26CF-4350-9FF1-651E9E4CF4F2
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi,<div><br></div><div>We need to finalise the dnssdext minutes by the end of the week. Draft minutes are available at</div><div><br></div><div><a href="http://www.ietf.org/proceedings/87/minutes/minutes-87-dnssdext">http://www.ietf.org/proceedings/87/minutes/minutes-87-dnssdext</a></div><div><br></div><div>If you have any corrections, please let myself or Ralph know, or reply here.</div><div><br></div><div>Ralph and I encourage people to contribute to the charter thread, and to the requirements draft, which Kerry and Stuart will hopefully be updating based on the BoF comments. These are both important tasks towards the potential WG formation.</div><div><br></div><div>Many thanks,</div><div>Tim</div></body></html>
--Apple-Mail=_3C579C9D-26CF-4350-9FF1-651E9E4CF4F2--

Sender: [email-masked]
Date: Wed, 28 Aug 2013 08:47:07 -0400
From: Kerry Lynn <[email-masked]>
To: Tim Chown <[email-masked]>
Cc: "[email-masked] mdnsext" <[email-masked]>
Subject: Re: [mdnsext] dnssdext charter

--089e013d0db021380304e50163f3
Content-Type: text/plain; charset=ISO-8859-1

There's Google Docs, but I think administering permissions might be work
than
the actual writing.  I can check into it if that will work for most people.

-K-

On Wed, Aug 28, 2013 at 5:44 AM, Tim Chown <[email-masked]> wrote:

> On 28 Aug 2013, at 09:54, SM <[email-masked]> wrote:
>
> > Hi Tim,
> > At 01:44 28-08-2013, Tim Chown wrote:
> >> I had also assumed we could use an IETF wiki, but it seems those are
> only available once a WG is formed, under the tools area.
> >
> > See http://trac.tools.ietf.org/bof/trac/wiki/WikiStart
>
> Hi - thanks, I'm aware of that one, and used it for mdnsext/dnssdext, but
> it's somewhat clumsy being mixed in with other information and BoFs,
> espeially when we had over ten BoFs in Berlin; what I was hoping for was a
> dedicated wiki area as per the WGs, which could be used at the same time as
> a mailing list is formed and independently of whether/when a BoF is being
> held (for example there was no mdnsext BoF at IETF87, but there was a first
> one at 86 then a second at 88).
>
> If candidate WGs were treated the same way as real WGs within the tools
> system, related drafts could presumably also be automatically listed, for
> example?
>
> Tim
>
> > You could also use the Area wiki if the relevant Area Director is okay
> with that.
> >
> > Regards,
> > -sm
> > _______________________________________________
> > mdnsext mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mdnsext
>
> _______________________________________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mdnsext
>

--089e013d0db021380304e50163f3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>There&#39;s Google Docs, but I think administeri=
ng permissions might be work than<br></div>the actual writing.=A0 I can che=
ck into it if that will work for most people.<br><br></div>-K-<br><div><div=
>
<br></div></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmai=
l_quote">On Wed, Aug 28, 2013 at 5:44 AM, Tim Chown <span dir=3D"ltr">&lt;<=
a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]=
</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 28 Aug 2013, at 09:54, =
SM &lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br=
>
<br>
&gt; Hi Tim,<br>
&gt; At 01:<a href=3D"tel:44%2028-08-2013" value=3D"+14428082013">44 28-08-=
2013</a>, Tim Chown wrote:<br>
&gt;&gt; I had also assumed we could use an IETF wiki, but it seems those a=
re only available once a WG is formed, under the tools area.<br>
&gt;<br>
&gt; See <a href=3D"http://trac.tools.ietf.org/bof/trac/wiki/WikiStart" tar=
get=3D"_blank">http://trac.tools.ietf.org/bof/trac/wiki/WikiStart</a><br>
<br>
</div>Hi - thanks, I&#39;m aware of that one, and used it for mdnsext/dnssd=
ext, but it&#39;s somewhat clumsy being mixed in with other information and=
 BoFs, espeially when we had over ten BoFs in Berlin; what I was hoping for=
 was a dedicated wiki area as per the WGs, which could be used at the same =
time as a mailing list is formed and independently of whether/when a BoF is=
 being held (for example there was no mdnsext BoF at IETF87, but there was =
a first one at 86 then a second at 88).<br>

<br>
If candidate WGs were treated the same way as real WGs within the tools sys=
tem, related drafts could presumably also be automatically listed, for exam=
ple?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Tim<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt; You could also use the Area wiki if the relevant Area Director is okay=
 with that.<br>
&gt;<br>
&gt; Regards,<br>
&gt; -sm<br>
&gt; _______________________________________________<br>
&gt; mdnsext mailing list<br>
&gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/mdnsext" target=3D"_b=
lank">https://www.ietf.org/mailman/listinfo/mdnsext</a><br>
<br>
_______________________________________________<br>
mdnsext mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/mdnsext" target=3D"_blank"=
>https://www.ietf.org/mailman/listinfo/mdnsext</a><br>
</div></div></blockquote></div><br></div>

--089e013d0db021380304e50163f3--

From: Tim Chown <[email-masked]>
Date: Wed, 28 Aug 2013 10:44:29 +0100
To: "[email-masked] mdnsext" <[email-masked]>
Subject: Re: [mdnsext] dnssdext charter

On 28 Aug 2013, at 09:54, SM <[email-masked]> wrote:

> Hi Tim,
> At 01:44 28-08-2013, Tim Chown wrote:
>> I had also assumed we could use an IETF wiki, but it seems those are =
only available once a WG is formed, under the tools area.
>=20
> See http://trac.tools.ietf.org/bof/trac/wiki/WikiStart

Hi - thanks, I'm aware of that one, and used it for mdnsext/dnssdext, =
but it's somewhat clumsy being mixed in with other information and BoFs, =
espeially when we had over ten BoFs in Berlin; what I was hoping for was =
a dedicated wiki area as per the WGs, which could be used at the same =
time as a mailing list is formed and independently of whether/when a BoF =
is being held (for example there was no mdnsext BoF at IETF87, but there =
was a first one at 86 then a second at 88).

If candidate WGs were treated the same way as real WGs within the tools =
system, related drafts could presumably also be automatically listed, =
for example?

Tim

> You could also use the Area wiki if the relevant Area Director is okay =
with that.
>=20
> Regards,
> -sm=20
> _______________________________________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mdnsext

Date: Wed, 28 Aug 2013 01:54:00 -0700
To: Tim Chown <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [mdnsext] dnssdext charter

Hi Tim,
At 01:44 28-08-2013, Tim Chown wrote:
>I had also assumed we could use an IETF wiki, but it seems those are 
>only available once a WG is formed, under the tools area.

See http://trac.tools.ietf.org/bof/trac/wiki/WikiStart

You could also use the Area wiki if the relevant Area Director is 
okay with that.

Regards,
-sm 

From: Tim Chown <[email-masked]>
Date: Wed, 28 Aug 2013 09:44:08 +0100
To: "[email-masked] mdnsext" <[email-masked]>
Subject: Re: [mdnsext] dnssdext charter

--Apple-Mail=_DAC8037F-E651-466A-88FE-0704B3F80868
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

On 28 Aug 2013, at 08:23, "Albrecht, Harald" =
<[email-masked]> wrote:

> Hi,
> =20
> just my two cents: I=92m also under the impression that github is kind =
of too-big tool. I was thinking along the lines of a wiki system; is =
there one that the IETF operates for such purposes? It would give the =
opportunity to see the change history and multiple people may work on it =
simultaneously; similar to github but geared more towards texts. =
However, if there is no wiki then github surely is a good solution as it =
is readily available.
> =20
> -- Harald

I had also assumed we could use an IETF wiki, but it seems those are =
only available once a WG is formed, under the tools area. =20

It would be nice for BoFs to have such a facility too - and very helpful =
for charter-bashing as we are here up to and even at a BoF meeting.  If =
there is such a facility, I can't find it, and would welcome a pointer. =
I have emailed the tools team to query/suggest it as github may be =
heavyweight for some.

Tim=

--Apple-Mail=_DAC8037F-E651-466A-88FE-0704B3F80868
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"><base href=3D"x-msg://4234/"></head><body =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><div><div>On 28 Aug 2013, at =
08:23, "Albrecht, Harald" &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a=
>&gt; wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div lang=3D"DE" link=3D"blue" vlink=3D"purple" =
style=3D"font-family: Helvetica; font-size: medium; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: =
0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =
0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; =
"><div class=3D"WordSection1" style=3D"page: WordSection1; "><div =
style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times =
New Roman', serif; "><span lang=3D"EN-US" style=3D"font-size: 11pt; =
font-family: Calibri, sans-serif; color: rgb(31, 73, 125); =
">Hi,<o:p></o:p></span></div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
lang=3D"EN-US" style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif; color: rgb(31, 73, 125); ">&nbsp;</span></div><div =
style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times =
New Roman', serif; "><span lang=3D"EN-US" style=3D"font-size: 11pt; =
font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">just my two =
cents: I=92m also under the impression that github is kind of too-big =
tool. I was thinking along the lines of a wiki system; is there one that =
the IETF operates for such purposes? It would give the opportunity to =
see the change history and multiple people may work on it =
simultaneously; similar to github but geared more towards texts. =
However, if there is no wiki then github surely is a good solution as it =
is readily available.<o:p></o:p></span></div><div style=3D"margin: 0cm =
0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; =
"><span lang=3D"EN-US" style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif; color: rgb(31, 73, 125); ">&nbsp;</span></div><div =
style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times =
New Roman', serif; "><span lang=3D"EN-US" style=3D"font-size: 11pt; =
font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">-- =
Harald</span></div></div></div></blockquote><div><br></div>I had also =
assumed we could use an IETF wiki, but it seems those are only available =
once a WG is formed, under the tools area. =
&nbsp;</div><div><br></div><div>It would be nice for BoFs to have such a =
facility too - and very helpful for charter-bashing as we are here up to =
and even at a BoF meeting. &nbsp;If there is such a facility, I can't =
find it, and would welcome a pointer. I have emailed the tools team to =
query/suggest it as github may be heavyweight for =
some.</div><div><br></div><div>Tim</div></body></html>=

--Apple-Mail=_DAC8037F-E651-466A-88FE-0704B3F80868--

From: "Albrecht, Harald" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 28 Aug 2013 07:23:07 +0000
Accept-Language: de-DE, en-US
Subject: Re: [mdnsext] dnssdext charter

--_000_E36F274013087B4EA05E08EB503750390BE3A6B4DENBGAT9EK1MSXw_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

--_000_E36F274013087B4EA05E08EB503750390BE3A6B4DENBGAT9EK1MSXw_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

--_000_E36F274013087B4EA05E08EB503750390BE3A6B4DENBGAT9EK1MSXw_--

Sender: [email-masked]
Date: Wed, 28 Aug 2013 00:22:45 -0400
From: Kerry Lynn <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [mdnsext] O'Reilly "Zero Configuration Networking" on sale...

--001a11c309e864441c04e4fa5752
Content-Type: text/plain; charset=ISO-8859-1

If you're too busy to read RFCs 6762 and 6763, then I recommend this
O'Reilly
book on the Bonjour protocols (Stuart is the co-author) which is currently
on sale
in ebook form: http://shop.oreilly.com/product/9780596101008.do?code=B2S3

The book has more explanation and rationale (plus examples) and I refer to
it
often.

-K-

--001a11c309e864441c04e4fa5752
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>If you&#39;re too busy to read RFCs 6762 an=
d 6763, then I recommend this O&#39;Reilly<br>book on the Bonjour protocols=
 (Stuart is the co-author) which is currently on sale<br>in ebook form: <a =
href=3D"http://shop.oreilly.com/product/9780596101008.do?code=3DB2S3">http:=
//shop.oreilly.com/product/9780596101008.do?code=3DB2S3</a><br>
<br></div>The book has more explanation and rationale (plus examples) and I=
 refer to it<br></div>often.<br><br></div>-K-<br></div>

--001a11c309e864441c04e4fa5752--

From: Alf Watt <[email-masked]>
To: "Ralph Droms (rdroms)" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 28 Aug 2013 01:11:45 +0000
Accept-Language: en-US
Subject: Re: [mdnsext] dnssdext charter

I'd like to make sure we don't loose track of the 'A' Personal Area
Networks scenario, +1 for including that in the charter.

Best,
Alf

On 8/26/13 10:07 AM, "Ralph Droms (rdroms)" <[email-masked]> wrote:

>I'm revising the draft dnssdext charter according to the discussion
>during the BoF in Berlin.  One issue that occurs to me that we didn't
>explicitly discuss during the BoF is the list of the deployment scenarios
>to be considered by the WG.  The draft charter includes a list of four
>scenarios:
>
>   a) Commercial enterprise networks
>   b) Academic/educational/university campus networks
>   c) Multi-link home networks, such as those envisaged by the
>      HOMENET WG=20
>   d) Multi-link/single subnet (mesh) networks, such as those
>      described by the ZigBee Alliance Z-IP specification
>
>while draft-lynn-mdnsext-requirements includes a list of six scenarios:
>
>   (A) Personal Area networks, e.g., one laptop and one printer.
>   This is the simplest example of an mDNS network.
>
>   (B) Home networks, consisting of:
>
>   * Single exit router: the network may have multiple upstream
>     providers or networks, but all outgoing and incoming trafic goes
>     through a single router.
>
>   * One level depth: all links on the network are connected to the
>     same default router.
>
>   * Single administrative domain: all nodes under the same admin
>     entity.
>
>   (C) Like B but may have a tree of links behind the single exit
>   router.  However, the forwarding nodes are almost self-configured
>   and do not require routing protocol administrators.
>
>   (D) Enterprise networks, consisting of:
>
>   * Any depth of the forwarding tree, under a single administrative
>     domain.  The large majority of the forwarding and security
>     devices are configured.
>
>   (E) Higher Education networks, consisting of:
>
>   * Any depth of the forwarding tree, core network under a central
>     administrative domain but leaf networks under multiple
>     administrative entities.  The large majority of the forwarding
>     and security devices are configured.
>
>   (F) Mesh networks such as RPL/6LoWPAN, multi-link but single prefix
>   networks.
>
>The list of scenarios from draft-lynn-mdnsext-requirements was the basis
>for discussion of requirements during the BoF.
>
>We likely need to coordinate the list of requirements in the charter with
>the list in the draft-lynn-mdnsext-requirements.  The two lists are
>actually not that far apart; the requirements docs includes (A) which is
>not in the draft charter, and (B) and (C) could perhaps be combined into
>one scenario, matching c) from the charter.
>
>I'm looking for consensus about how to proceed:
>
>* Modify the charter to align with draft-lynn-mdnsext-requirements
>* Modify draft-lynn-mdnsext-requirements to align with the charter
>* Replace the specific list of scenarios from the charter with a pointer
>to the requirements document
>* Modify both draft-lynn-mdnsext-requirements and the charter to bring
>them into alignment
>
>Note that I'm deferring consideration of specific edits to the scenarios,
>such as s/tree of links/arbitrary topology/ in (C) from
>draft-lynn-mdnsext-requirements.
>
>- Ralph
>
>_______________________________________________
>mdnsext mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mdnsext
>

From: Ralph Droms <[email-masked]>
Date: Tue, 27 Aug 2013 15:41:43 -0700
To: Kerry Lynn <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [mdnsext] dnssdext charter

--Apple-Mail=_EBCC91A2-21BC-425F-935D-94B984303F13
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

On Aug 27, 2013, at 5:05 AM 8/27/13, Kerry Lynn <[email-masked]> wrote:

> Ralph,
>=20
> First, I'd propose that we put the proposed charter version(s) on =
github as
> Carsten has done: https://github.com/6lo/charter.  Would you like me =
to do
> that this evening?

Although I think github is more mechanism than we need, I can't find a =
good alternative for posting a current charter so, yes, please put the =
proposed charter on github.  I've attached the initial draft charter =
from the BoF request and a revised charter with additional WG logistical =
info.

>=20
> Second, I believe the charter must include the base case that was =
added
> in the last draft to make it explicit that any solution MUST NOT =
strand the
> millions of mDNS servers (printers and the like) that have already =
been
> deployed.
>=20
> I agree with Peter that we probably don't need to include multiple =
homenet
> scenarios in the charter, especially since we have no requirements =
from that
> WG yet.
>=20
> I would propose that we order the scenarios according to =
administrative
> complexity, from base case to enterprise.  (It will be interesting to =
define the
> differences of enterprise dnssdext vs. fully managed DNS-SD.)

Please send text with a concrete proposal?

>=20
> Lastly, are we set on the designation "dnssdext", and will it be in =
the Apps
> area?

As far as I know, we're going with dnssdext.  Other suggestions can be =
considered.  I expect it will be in INT area.

- Ralph

--Apple-Mail=_EBCC91A2-21BC-425F-935D-94B984303F13
Content-Disposition: attachment;
	filename=dnssdext-charter-00.txt
Content-Type: text/plain;
	x-unix-mode=0644;
	name="dnssdext-charter-00.txt"
Content-Transfer-Encoding: 7bit

Currently, zeroconf networking protocols are generally used to
discover services within the scope of a single link. In particular,
the Bonjour protocols suite, comprising mDNS (RFC 6762) and DNS-SD
(RFC 6763), are widely used for discovery and resolution of services
and names on a single link.

The Bonjour protocol suite is commonly used in many scenarios,
including home networks, commercial and campus enterprise networks,
and may be of use in certain mesh networks.  However, the multicast
Bonjour protocols are constrained to link-local scope, so can only be
used to discover services on the same link. In a typical current home
network, which is a single link, users should experience the desired
discovery behavior. However, in future multi-link home networks (as
envisaged by the homenet WG) and in routed campus or enterprise
networks, devices and thus users can only discover services on the
same link, which is a significant limitation. Such limitations have
led to calls, such as those by the Educause petition, to develop an
appropriate solution to span multiple links, or to perform discovery
across a wide area (not necessarily on directly connected links).

In addition, the ZigBee Alliance Smart Energy Profile 2.0 commercial
standard currently under development has specified the Bonjour
protocols as its method of zero configuration discovery. However, its
use of wireless mesh multi-link subnets and its use across traditional
routed networks will require extensions to the Bonjour protocols to
allow operation across multiple links.

As demand for service discovery across wider area routed networks
grows, some vendors are beginning to ship their own early
solutions. It is thus both timely and important that efforts to
develop improved, scalable, autonomous service discovery solutions for
routed networks are coordinated towards producing a single, standards-
based solution.

Goals

To that end, the primary goals of the sadnssd WG are as follows:

1. To document a set of requirements for scalable, autonomous
   DNS-based service discovery in routed, multi-link networks in the
   following four scenarios:

    a) Commercial enterprise networks
    b) Academic/educational/university campus networks
    c) Multi-link home networks, such as those envisaged by the
       HOMENET WG 
    d) Multi-link/single subnet (mesh) networks, such as those
       described by the ZigBee Alliance Z-IP specification

2. To develop an improved, scalable solution for wide-area service
   discovery that can operate in multi-link networks, applicable to
   the scenarios above.

3. To develop a BCP for the coexistence of zeroconf (mDNS) and unicast
   (global DNS) name services in such multi-link networks, which
   should include consideration of both the name resolution mechanism
   and the namespace.

It is important that the sadnssd WG takes input from stakeholders in
the scenarios it is considering. For example, the homenet WG is
currently evaluating its own requirements for naming and service
discovery; it is up to the homenet WG as to whether it wishes to
recommend adoption of the solution developed in the mdsnext WG, and
thus coordination between the WGs is desirable.

Deliverables

The WG will produce three documents: an Informational RFC on the
requirements for wide-area service discovery protocols; a Standards
Track RFC documenting a wide-area service discovery solution that is
applicable to those scenarios; and a BCP document describing the most
effective method to integrate mDNS and global DNS name services.

Milestones

Sep 2013 Formation of the WG
Oct 2013 Adopt requirements draft as WG document
Nov 2013 Submit requirements draft to the IESG as an Informational RFC
Mar 2014 Adopt wide-area service discovery solution draft as WG
         document 
Mar 2014 Adopt zeroconf and unicast DNS integration BCP draft as WG
         document 
Sep 2014 Submit wide-area service discovery solution draft to the IESG
         as Standards Track RFC 
Sep 2014 Submit zeroconf and unicast DNS integration solution draft to
         the IESG as BCP 

--Apple-Mail=_EBCC91A2-21BC-425F-935D-94B984303F13
Content-Disposition: attachment;
	filename=dnssdext-charter-01.txt
Content-Type: text/plain;
	x-unix-mode=0644;
	name="dnssdext-charter-01.txt"
Content-Transfer-Encoding: 7bit

dnssdext Draft Charter, rev -01

Group Name:	DNS-SD Extensions for Scalability
Acronym:	dnssdext
Area:		Internet Area (int)
State:		Active
Charter:	

Personnel
Chairs:		<TBD>
Area Director:	Ted Lemon <[email-masked]>
Mailing List
Address:	[email-masked]
To Subscribe:	[email-masked]
Archive:	http://www.ietf.org/mail-archive/web/dnssdext
		http://www.ietf.org/mail-archive/web/mdnsext (1st BoF)
Jabber Chat
Room Address:	xmpp:[email-masked]
Logs:		http://jabber.ietf.org/logs/dnssdext
		http://jabber.ietf.org/logs/mdnsext (1st BoF)

Background
----------

Currently, zeroconf networking protocols are generally used to
discover services within the scope of a single link. In particular,
the Bonjour protocols suite, comprising mDNS (RFC 6762) and DNS-SD
(RFC 6763), are widely used for discovery and resolution of services
and names on a single link.

The Bonjour protocol suite is commonly used in many scenarios,
including home networks, commercial and campus enterprise networks,
and may be of use in certain mesh networks.  However, the multicast
Bonjour protocols are constrained to link-local scope, so can only be
used to discover services on the same link. In a typical current home
network, which is a single link, users should experience the desired
discovery behavior. However, in future multi-link home networks (as
envisaged by the homenet WG) and in routed campus or enterprise
networks, devices and thus users can only discover services on the
same link, which is a significant limitation. Such limitations have
led to calls, such as those by the Educause petition, to develop an
appropriate solution to span multiple links, or to perform discovery
across a wide area (not necessarily on directly connected links).

In addition, the "Smart Energy Profile 2 Application Protocol
Standard", published by ZigBee Alliance and Homeplug Alliance
specifies the Bonjour protocols as its method of zero configuration
discovery. However, its use of wireless mesh multi-link subnets and
its use across traditional routed networks will require extensions to
the Bonjour protocols to allow operation across multiple links.

As demand for service discovery across wider area routed networks
grows, some vendors are beginning to ship their own early
solutions. It is thus both timely and important that efforts to
develop improved, scalable, autonomous service discovery solutions for
routed networks are coordinated towards producing a single, standards-
based solution.

Working Group Description
-------------------------

To that end, the primary goals of the sadnssd WG are as follows:

1. To document a set of requirements for scalable, autonomous
   DNS-based service discovery in routed, multi-link networks in the
   following five scenarios:

   (A) Personal Area networks, e.g., one laptop and one printer.
   This is the simplest example of an mDNS network. 

   (B) Home networks, consisting of:

   * Single exit router: the network may have multiple upstream
     providers or networks, but all outgoing and incoming trafic goes
     through a single router.

   * One level depth: all links on the network are connected to the
     same default router.

   * Single administrative domain: all nodes under the same admin
     entity.

   (C) Like B but may have a tree of links behind the single exit
   router.  However, the forwarding nodes are almost self-configured
   and do not require routing protocol administrators.

   (D) Enterprise networks, consisting of:

   * Any depth of the forwarding tree, under a single administrative
     domain.  The large majority of the forwarding and security
     devices are configured.

   (E) Higher Education networks, consisting of:

   * Any depth of the forwarding tree, core network under a central
     administrative domain but leaf networks under multiple
     administrative entities.  The large majority of the forwarding
     and security devices are configured.

   (F) Mesh networks such as RPL/6LoWPAN, multi-link but single prefix
   networks.

   a) Commercial enterprise networks
   b) Academic/educational/university campus networks
   c) Multi-link home networks, such as those envisaged by the
      HOMENET WG 
   d) Multi-link/single subnet (mesh) networks, such as those
      described by the ZigBee Alliance Z-IP specification

2. To develop an improved, scalable solution for wide-area service
   discovery that can operate in multi-link networks, applicable to
   the scenarios above.  The solution will consider tradeoffs between
   reusing/extending existing protocols and developing entirely new
   protocols. 

3. To publish an Informational RFC that documents challenges and
   problems encountered in the coexistence of zeroconf (mDNS) and unicast
   (global DNS) name services in such multi-link networks, which
   should include consideration of both the name resolution mechanism
   and the namespace.

It is important that the sdnssd WG takes input from stakeholders in
the scenarios it is considering. For example, the homenet WG is
currently evaluating its own requirements for naming and service
discovery; it is up to the homenet WG as to whether it wishes to
recommend adoption of the solution developed in the dnssdext WG, and
thus coordination between the WGs is desirable.

Deliverables:

The WG will produce three documents: an Informational RFC on the
requirements for wide-area service discovery protocols; a Standards
Track RFC documenting a wide-area service discovery solution that is
applicable to those scenarios; and an Informational RFC describing the
most effective method to integrate mDNS and global DNS name services.

Milestones:

Sep 2013 Formation of the WG
Oct 2013 Adopt requirements draft as WG document
Nov 2013 Submit requirements draft to the IESG as an Informational RFC
Mar 2014 Adopt wide-area service discovery solution draft as WG
         document 
Mar 2014 Adopt zeroconf and unicast DNS integration BCP draft as WG
         document 
Sep 2014 Submit wide-area service discovery solution draft to the IESG
         as Standards Track RFC 
Sep 2014 Submit zeroconf and unicast DNS integration solution draft to
         the IESG as BCP 

--Apple-Mail=_EBCC91A2-21BC-425F-935D-94B984303F13
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

>=20
> Regards, -K-
>=20
>=20
> On Tue, Aug 27, 2013 at 4:50 AM, peter van der Stok =
<[email-masked]> wrote:
> Ralph,
>=20
> I would suggest to keep the 4 scenarios in the charter.
> In the draft lynn-mdnsnext-requirements a mapping from req scenarios =
to charter scenarios can be done.
> Remembering the discussions during the Bof, the req doc. may end up =
with more scenarios than its current 6.
> Possibly they can be classified and then mapped to the 4 charter =
scenarios.
>=20
> Peter
>=20
>=20
>=20
> Ralph Droms (rdroms) schreef op 2013-08-26 19:07:
>=20
> I'm revising the draft dnssdext charter according to the discussion
> during the BoF in Berlin.  One issue that occurs to me that we didn't
> explicitly discuss during the BoF is the list of the deployment
> scenarios to be considered by the WG.  The draft charter includes a
> list of four scenarios:
>=20
> a) Commercial enterprise networks
> b) Academic/educational/university campus networks
> c) Multi-link home networks, such as those envisaged by the
> HOMENET WG
> d) Multi-link/single subnet (mesh) networks, such as those
> described by the ZigBee Alliance Z-IP specification
>=20
> while draft-lynn-mdnsext-requirements includes a list of six =
scenarios:
>=20
> (A) Personal Area networks, e.g., one laptop and one printer.
> This is the simplest example of an mDNS network.
>=20
> (B) Home networks, consisting of:
>=20
> * Single exit router: the network may have multiple upstream
> providers or networks, but all outgoing and incoming trafic goes
> through a single router.
>=20
> * One level depth: all links on the network are connected to the
> same default router.
>=20
> * Single administrative domain: all nodes under the same admin
> entity.
>=20
> (C) Like B but may have a tree of links behind the single exit
> router.  However, the forwarding nodes are almost self-configured
> and do not require routing protocol administrators.
>=20
> (D) Enterprise networks, consisting of:
>=20
> * Any depth of the forwarding tree, under a single administrative
> domain.  The large majority of the forwarding and security
> devices are configured.
>=20
> (E) Higher Education networks, consisting of:
>=20
> * Any depth of the forwarding tree, core network under a central
> administrative domain but leaf networks under multiple
> administrative entities.  The large majority of the forwarding
> and security devices are configured.
>=20
> (F) Mesh networks such as RPL/6LoWPAN, multi-link but single prefix
> networks.
>=20
> The list of scenarios from draft-lynn-mdnsext-requirements was the
> basis for discussion of requirements during the BoF.
>=20
> We likely need to coordinate the list of requirements in the charter
> with the list in the draft-lynn-mdnsext-requirements.  The two lists
> are actually not that far apart; the requirements docs includes (A)
> which is not in the draft charter, and (B) and (C) could perhaps be
> combined into one scenario, matching c) from the charter.
>=20
> I'm looking for consensus about how to proceed:
>=20
> * Modify the charter to align with draft-lynn-mdnsext-requirements
> * Modify draft-lynn-mdnsext-requirements to align with the charter
> * Replace the specific list of scenarios from the charter with a
> pointer to the requirements document
> * Modify both draft-lynn-mdnsext-requirements and the charter to bring
> them into alignment
>=20
> Note that I'm deferring consideration of specific edits to the
> scenarios, such as s/tree of links/arbitrary topology/ in (C) from
> draft-lynn-mdnsext-requirements.
>=20
> - Ralph
>=20
> _______________________________________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mdnsext
> _______________________________________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mdnsext
>=20
> _______________________________________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mdnsext

--Apple-Mail=_EBCC91A2-21BC-425F-935D-94B984303F13--

From: Ralph Droms <[email-masked]>
Date: Tue, 27 Aug 2013 15:34:49 -0700
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mdnsext] dnssdext charter

On Aug 27, 2013, at 1:50 AM 8/27/13, peter van der Stok =
<[email-masked]> wrote:

> Ralph,
>=20
> I would suggest to keep the 4 scenarios in the charter.

OK.  Keep them as is; no changes?

> In the draft lynn-mdnsnext-requirements a mapping from req scenarios =
to charter scenarios can be done.
> Remembering the discussions during the Bof, the req doc. may end up =
with more scenarios than its current 6.
> Possibly they can be classified and then mapped to the 4 charter =
scenarios.

OK.

- Ralph

>=20
> Peter
>=20
>=20
>=20
> Ralph Droms (rdroms) schreef op 2013-08-26 19:07:
>> I'm revising the draft dnssdext charter according to the discussion
>> during the BoF in Berlin.  One issue that occurs to me that we didn't
>> explicitly discuss during the BoF is the list of the deployment
>> scenarios to be considered by the WG.  The draft charter includes a
>> list of four scenarios:
>> a) Commercial enterprise networks
>> b) Academic/educational/university campus networks
>> c) Multi-link home networks, such as those envisaged by the
>> HOMENET WG
>> d) Multi-link/single subnet (mesh) networks, such as those
>> described by the ZigBee Alliance Z-IP specification
>> while draft-lynn-mdnsext-requirements includes a list of six =
scenarios:
>> (A) Personal Area networks, e.g., one laptop and one printer.
>> This is the simplest example of an mDNS network.
>> (B) Home networks, consisting of:
>> * Single exit router: the network may have multiple upstream
>> providers or networks, but all outgoing and incoming trafic goes
>> through a single router.
>> * One level depth: all links on the network are connected to the
>> same default router.
>> * Single administrative domain: all nodes under the same admin
>> entity.
>> (C) Like B but may have a tree of links behind the single exit
>> router.  However, the forwarding nodes are almost self-configured
>> and do not require routing protocol administrators.
>> (D) Enterprise networks, consisting of:
>> * Any depth of the forwarding tree, under a single administrative
>> domain.  The large majority of the forwarding and security
>> devices are configured.
>> (E) Higher Education networks, consisting of:
>> * Any depth of the forwarding tree, core network under a central
>> administrative domain but leaf networks under multiple
>> administrative entities.  The large majority of the forwarding
>> and security devices are configured.
>> (F) Mesh networks such as RPL/6LoWPAN, multi-link but single prefix
>> networks.
>> The list of scenarios from draft-lynn-mdnsext-requirements was the
>> basis for discussion of requirements during the BoF.
>> We likely need to coordinate the list of requirements in the charter
>> with the list in the draft-lynn-mdnsext-requirements.  The two lists
>> are actually not that far apart; the requirements docs includes (A)
>> which is not in the draft charter, and (B) and (C) could perhaps be
>> combined into one scenario, matching c) from the charter.
>> I'm looking for consensus about how to proceed:
>> * Modify the charter to align with draft-lynn-mdnsext-requirements
>> * Modify draft-lynn-mdnsext-requirements to align with the charter
>> * Replace the specific list of scenarios from the charter with a
>> pointer to the requirements document
>> * Modify both draft-lynn-mdnsext-requirements and the charter to =
bring
>> them into alignment
>> Note that I'm deferring consideration of specific edits to the
>> scenarios, such as s/tree of links/arbitrary topology/ in (C) from
>> draft-lynn-mdnsext-requirements.
>> - Ralph
>> _______________________________________________
>> mdnsext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mdnsext
> _______________________________________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mdnsext

Sender: [email-masked]
Date: Tue, 27 Aug 2013 08:05:47 -0400
From: Kerry Lynn <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [mdnsext] dnssdext charter

--e89a8ff1cd6673d38504e4ecb101
Content-Type: text/plain; charset=ISO-8859-1

Ralph,

First, I'd propose that we put the proposed charter version(s) on github as
Carsten has done: https://github.com/6lo/charter.  Would you like me to do
that this evening?

Second, I believe the charter must include the base case that was added
in the last draft to make it explicit that any solution MUST NOT strand the
millions of mDNS servers (printers and the like) that have already been
deployed.

I agree with Peter that we probably don't need to include multiple homenet
scenarios in the charter, especially since we have no requirements from that
WG yet.

I would propose that we order the scenarios according to administrative
complexity, from base case to enterprise.  (It will be interesting to
define the
differences of enterprise dnssdext vs. fully managed DNS-SD.)

Lastly, are we set on the designation "dnssdext", and will it be in the Apps
area?

Regards, -K-

On Tue, Aug 27, 2013 at 4:50 AM, peter van der Stok <[email-masked]>wrote:

> Ralph,
>
> I would suggest to keep the 4 scenarios in the charter.
> In the draft lynn-mdnsnext-requirements a mapping from req scenarios to
> charter scenarios can be done.
> Remembering the discussions during the Bof, the req doc. may end up with
> more scenarios than its current 6.
> Possibly they can be classified and then mapped to the 4 charter scenarios.
>
> Peter
>
>
>
> Ralph Droms (rdroms) schreef op 2013-08-26 19:07:
>
>  I'm revising the draft dnssdext charter according to the discussion
>> during the BoF in Berlin.  One issue that occurs to me that we didn't
>> explicitly discuss during the BoF is the list of the deployment
>> scenarios to be considered by the WG.  The draft charter includes a
>> list of four scenarios:
>>
>> a) Commercial enterprise networks
>> b) Academic/educational/**university campus networks
>> c) Multi-link home networks, such as those envisaged by the
>> HOMENET WG
>> d) Multi-link/single subnet (mesh) networks, such as those
>> described by the ZigBee Alliance Z-IP specification
>>
>> while draft-lynn-mdnsext-**requirements includes a list of six scenarios:
>>
>> (A) Personal Area networks, e.g., one laptop and one printer.
>> This is the simplest example of an mDNS network.
>>
>> (B) Home networks, consisting of:
>>
>> * Single exit router: the network may have multiple upstream
>> providers or networks, but all outgoing and incoming trafic goes
>> through a single router.
>>
>> * One level depth: all links on the network are connected to the
>> same default router.
>>
>> * Single administrative domain: all nodes under the same admin
>> entity.
>>
>> (C) Like B but may have a tree of links behind the single exit
>> router.  However, the forwarding nodes are almost self-configured
>> and do not require routing protocol administrators.
>>
>> (D) Enterprise networks, consisting of:
>>
>> * Any depth of the forwarding tree, under a single administrative
>> domain.  The large majority of the forwarding and security
>> devices are configured.
>>
>> (E) Higher Education networks, consisting of:
>>
>> * Any depth of the forwarding tree, core network under a central
>> administrative domain but leaf networks under multiple
>> administrative entities.  The large majority of the forwarding
>> and security devices are configured.
>>
>> (F) Mesh networks such as RPL/6LoWPAN, multi-link but single prefix
>> networks.
>>
>> The list of scenarios from draft-lynn-mdnsext-**requirements was the
>> basis for discussion of requirements during the BoF.
>>
>> We likely need to coordinate the list of requirements in the charter
>> with the list in the draft-lynn-mdnsext-**requirements.  The two lists
>> are actually not that far apart; the requirements docs includes (A)
>> which is not in the draft charter, and (B) and (C) could perhaps be
>> combined into one scenario, matching c) from the charter.
>>
>> I'm looking for consensus about how to proceed:
>>
>> * Modify the charter to align with draft-lynn-mdnsext-**requirements
>> * Modify draft-lynn-mdnsext-**requirements to align with the charter
>> * Replace the specific list of scenarios from the charter with a
>> pointer to the requirements document
>> * Modify both draft-lynn-mdnsext-**requirements and the charter to bring
>> them into alignment
>>
>> Note that I'm deferring consideration of specific edits to the
>> scenarios, such as s/tree of links/arbitrary topology/ in (C) from
>> draft-lynn-mdnsext-**requirements.
>>
>> - Ralph
>>
>> ______________________________**_________________
>> mdnsext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/mdnsext<https://www.ietf.org/mailman/listinfo/mdnsext>
>>
> ______________________________**_________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/mdnsext<https://www.ietf.org/mailman/listinfo/mdnsext>
>

--e89a8ff1cd6673d38504e4ecb101
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div><div><div><div><div><div><div><di=
v>Ralph,<br><br></div>First, I&#39;d propose that we put the proposed chart=
er version(s) on github as<br></div>Carsten has done: <a href=3D"https://gi=
thub.com/6lo/charter">https://github.com/6lo/charter</a>.=A0 Would you like=
 me to do<br>
</div>that this evening?<br><br></div>Second, I believe the charter must in=
clude the base case that was added<br></div>in the last draft to make it ex=
plicit that any solution MUST NOT strand the<br></div>millions of mDNS serv=
ers (printers and the like) that have already been<br>
deployed.<br><br></div>I agree with Peter that we probably don&#39;t need t=
o include multiple homenet<br>scenarios in the charter, especially since we=
 have no requirements from that<br></div>WG yet.<br><br></div>I would propo=
se that we order the scenarios according to administrative<br>
</div>complexity, from base case to enterprise.=A0 (It will be interesting =
to define the<br>differences of enterprise dnssdext vs. fully managed DNS-S=
D.)<br><br></div>Lastly, are we set on the designation &quot;dnssdext&quot;=
, and will it be in the Apps<br>
area?<br><br></div>Regards, -K-<br></div><div class=3D"gmail_extra"><br><br=
><div class=3D"gmail_quote">On Tue, Aug 27, 2013 at 4:50 AM, peter van der =
Stok <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"=
_blank">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Ralph,<br>
<br>
I would suggest to keep the 4 scenarios in the charter.<br>
In the draft lynn-mdnsnext-requirements a mapping from req scenarios to cha=
rter scenarios can be done.<br>
Remembering the discussions during the Bof, the req doc. may end up with mo=
re scenarios than its current 6.<br>
Possibly they can be classified and then mapped to the 4 charter scenarios.=
<br>
<br>
Peter<br>
<br>
<br>
<br>
Ralph Droms (rdroms) schreef op 2013-08-26 19:07:<div class=3D"HOEnZb"><div=
 class=3D"h5"><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I&#39;m revising the draft dnssdext charter according to the discussion<br>
during the BoF in Berlin. =A0One issue that occurs to me that we didn&#39;t=
<br>
explicitly discuss during the BoF is the list of the deployment<br>
scenarios to be considered by the WG. =A0The draft charter includes a<br>
list of four scenarios:<br>
<br>
a) Commercial enterprise networks<br>
b) Academic/educational/<u></u>university campus networks<br>
c) Multi-link home networks, such as those envisaged by the<br>
HOMENET WG<br>
d) Multi-link/single subnet (mesh) networks, such as those<br>
described by the ZigBee Alliance Z-IP specification<br>
<br>
while draft-lynn-mdnsext-<u></u>requirements includes a list of six scenari=
os:<br>
<br>
(A) Personal Area networks, e.g., one laptop and one printer.<br>
This is the simplest example of an mDNS network.<br>
<br>
(B) Home networks, consisting of:<br>
<br>
* Single exit router: the network may have multiple upstream<br>
providers or networks, but all outgoing and incoming trafic goes<br>
through a single router.<br>
<br>
* One level depth: all links on the network are connected to the<br>
same default router.<br>
<br>
* Single administrative domain: all nodes under the same admin<br>
entity.<br>
<br>
(C) Like B but may have a tree of links behind the single exit<br>
router. =A0However, the forwarding nodes are almost self-configured<br>
and do not require routing protocol administrators.<br>
<br>
(D) Enterprise networks, consisting of:<br>
<br>
* Any depth of the forwarding tree, under a single administrative<br>
domain. =A0The large majority of the forwarding and security<br>
devices are configured.<br>
<br>
(E) Higher Education networks, consisting of:<br>
<br>
* Any depth of the forwarding tree, core network under a central<br>
administrative domain but leaf networks under multiple<br>
administrative entities. =A0The large majority of the forwarding<br>
and security devices are configured.<br>
<br>
(F) Mesh networks such as RPL/6LoWPAN, multi-link but single prefix<br>
networks.<br>
<br>
The list of scenarios from draft-lynn-mdnsext-<u></u>requirements was the<b=
r>
basis for discussion of requirements during the BoF.<br>
<br>
We likely need to coordinate the list of requirements in the charter<br>
with the list in the draft-lynn-mdnsext-<u></u>requirements. =A0The two lis=
ts<br>
are actually not that far apart; the requirements docs includes (A)<br>
which is not in the draft charter, and (B) and (C) could perhaps be<br>
combined into one scenario, matching c) from the charter.<br>
<br>
I&#39;m looking for consensus about how to proceed:<br>
<br>
* Modify the charter to align with draft-lynn-mdnsext-<u></u>requirements<b=
r>
* Modify draft-lynn-mdnsext-<u></u>requirements to align with the charter<b=
r>
* Replace the specific list of scenarios from the charter with a<br>
pointer to the requirements document<br>
* Modify both draft-lynn-mdnsext-<u></u>requirements and the charter to bri=
ng<br>
them into alignment<br>
<br>
Note that I&#39;m deferring consideration of specific edits to the<br>
scenarios, such as s/tree of links/arbitrary topology/ in (C) from<br>
draft-lynn-mdnsext-<u></u>requirements.<br>
<br>
- Ralph<br>
<br>
______________________________<u></u>_________________<br>
mdnsext mailing list<br>
<a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><=
br>
<a href=3D"https://www.ietf.org/mailman/listinfo/mdnsext" target=3D"_blank"=
>https://www.ietf.org/mailman/<u></u>listinfo/mdnsext</a><br>
</blockquote>
______________________________<u></u>_________________<br>
mdnsext mailing list<br>
<a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><=
br>
<a href=3D"https://www.ietf.org/mailman/listinfo/mdnsext" target=3D"_blank"=
>https://www.ietf.org/mailman/<u></u>listinfo/mdnsext</a><br>
</div></div></blockquote></div><br></div>

--e89a8ff1cd6673d38504e4ecb101--

Date: Tue, 27 Aug 2013 10:50:54 +0200
From: peter van der Stok <[email-masked]>
To: [email-masked]
Organization: vanderstok consultancy
Mail-Reply-To: [email-masked]
Subject: Re: [mdnsext] dnssdext charter
Reply-To: [email-masked]

Ralph,

I would suggest to keep the 4 scenarios in the charter.
In the draft lynn-mdnsnext-requirements a mapping from req scenarios to 
charter scenarios can be done.
Remembering the discussions during the Bof, the req doc. may end up with 
more scenarios than its current 6.
Possibly they can be classified and then mapped to the 4 charter 
scenarios.

Peter

Ralph Droms (rdroms) schreef op 2013-08-26 19:07:
> I'm revising the draft dnssdext charter according to the discussion
> during the BoF in Berlin.  One issue that occurs to me that we didn't
> explicitly discuss during the BoF is the list of the deployment
> scenarios to be considered by the WG.  The draft charter includes a
> list of four scenarios:
> 
> a) Commercial enterprise networks
> b) Academic/educational/university campus networks
> c) Multi-link home networks, such as those envisaged by the
> HOMENET WG
> d) Multi-link/single subnet (mesh) networks, such as those
> described by the ZigBee Alliance Z-IP specification
> 
> while draft-lynn-mdnsext-requirements includes a list of six scenarios:
> 
> (A) Personal Area networks, e.g., one laptop and one printer.
> This is the simplest example of an mDNS network.
> 
> (B) Home networks, consisting of:
> 
> * Single exit router: the network may have multiple upstream
> providers or networks, but all outgoing and incoming trafic goes
> through a single router.
> 
> * One level depth: all links on the network are connected to the
> same default router.
> 
> * Single administrative domain: all nodes under the same admin
> entity.
> 
> (C) Like B but may have a tree of links behind the single exit
> router.  However, the forwarding nodes are almost self-configured
> and do not require routing protocol administrators.
> 
> (D) Enterprise networks, consisting of:
> 
> * Any depth of the forwarding tree, under a single administrative
> domain.  The large majority of the forwarding and security
> devices are configured.
> 
> (E) Higher Education networks, consisting of:
> 
> * Any depth of the forwarding tree, core network under a central
> administrative domain but leaf networks under multiple
> administrative entities.  The large majority of the forwarding
> and security devices are configured.
> 
> (F) Mesh networks such as RPL/6LoWPAN, multi-link but single prefix
> networks.
> 
> The list of scenarios from draft-lynn-mdnsext-requirements was the
> basis for discussion of requirements during the BoF.
> 
> We likely need to coordinate the list of requirements in the charter
> with the list in the draft-lynn-mdnsext-requirements.  The two lists
> are actually not that far apart; the requirements docs includes (A)
> which is not in the draft charter, and (B) and (C) could perhaps be
> combined into one scenario, matching c) from the charter.
> 
> I'm looking for consensus about how to proceed:
> 
> * Modify the charter to align with draft-lynn-mdnsext-requirements
> * Modify draft-lynn-mdnsext-requirements to align with the charter
> * Replace the specific list of scenarios from the charter with a
> pointer to the requirements document
> * Modify both draft-lynn-mdnsext-requirements and the charter to bring
> them into alignment
> 
> Note that I'm deferring consideration of specific edits to the
> scenarios, such as s/tree of links/arbitrary topology/ in (C) from
> draft-lynn-mdnsext-requirements.
> 
> - Ralph
> 
> _______________________________________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mdnsext

From: "Ralph Droms (rdroms)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 26 Aug 2013 17:07:36 +0000
Accept-Language: en-US
Subject: [mdnsext] dnssdext charter

I'm revising the draft dnssdext charter according to the discussion during =
the BoF in Berlin.  One issue that occurs to me that we didn't explicitly d=
iscuss during the BoF is the list of the deployment scenarios to be conside=
red by the WG.  The draft charter includes a list of four scenarios:

   a) Commercial enterprise networks
   b) Academic/educational/university campus networks
   c) Multi-link home networks, such as those envisaged by the
      HOMENET WG=20
   d) Multi-link/single subnet (mesh) networks, such as those
      described by the ZigBee Alliance Z-IP specification

while draft-lynn-mdnsext-requirements includes a list of six scenarios:

   (A) Personal Area networks, e.g., one laptop and one printer.
   This is the simplest example of an mDNS network.=20

   (B) Home networks, consisting of:

   * Single exit router: the network may have multiple upstream
     providers or networks, but all outgoing and incoming trafic goes
     through a single router.

   * One level depth: all links on the network are connected to the
     same default router.

   * Single administrative domain: all nodes under the same admin
     entity.

   (C) Like B but may have a tree of links behind the single exit
   router.  However, the forwarding nodes are almost self-configured
   and do not require routing protocol administrators.

   (D) Enterprise networks, consisting of:

   * Any depth of the forwarding tree, under a single administrative
     domain.  The large majority of the forwarding and security
     devices are configured.

   (E) Higher Education networks, consisting of:

   * Any depth of the forwarding tree, core network under a central
     administrative domain but leaf networks under multiple
     administrative entities.  The large majority of the forwarding
     and security devices are configured.

   (F) Mesh networks such as RPL/6LoWPAN, multi-link but single prefix
   networks.

The list of scenarios from draft-lynn-mdnsext-requirements was the basis fo=
r discussion of requirements during the BoF.

We likely need to coordinate the list of requirements in the charter with t=
he list in the draft-lynn-mdnsext-requirements.  The two lists are actually=
 not that far apart; the requirements docs includes (A) which is not in the=
 draft charter, and (B) and (C) could perhaps be combined into one scenario=
, matching c) from the charter.

I'm looking for consensus about how to proceed:

* Modify the charter to align with draft-lynn-mdnsext-requirements
* Modify draft-lynn-mdnsext-requirements to align with the charter
* Replace the specific list of scenarios from the charter with a pointer to=
 the requirements document
* Modify both draft-lynn-mdnsext-requirements and the charter to bring them=
 into alignment

Note that I'm deferring consideration of specific edits to the scenarios, s=
uch as s/tree of links/arbitrary topology/ in (C) from draft-lynn-mdnsext-r=
equirements.

- Ralph

From: "Bhavik Fajalia (bfajalia)" <[email-masked]>
To: "Yi Yang (yiya)" <[email-masked]>, Alf Watt <[email-masked]>,  "[email-masked]" <[email-masked]>
Date: Wed, 7 Aug 2013 03:50:36 +0000
Accept-Language: en-US
Subject: Re: [mdnsext] The Scope Swamp: Wireless Considerations

From: "Yi Yang (yiya)" <[email-masked]>
To: Alf Watt <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 6 Aug 2013 19:49:59 +0000
Accept-Language: en-US
Subject: Re: [mdnsext] The Scope Swamp: Wireless Considerations

From: Alf Watt <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 5 Aug 2013 21:47:24 +0000
Accept-Language: en-US
Subject: [mdnsext] The Scope Swamp: Wireless Considerations

Following up from the BoF discussion in Berlin today on scoping of service
advertisements.

The discussion of scope needs to acknowledge the difference between wired
and wireless networks.

In all IP networks the size of the broadcast domain is a fundamental
limitation, as the number of devices on the link increases the broadcast
traffic begins to consume a larger and larger percentage of the available
bandwidth. Traditionally large wired networks were segmented along
physical lines, by floor or wing, for example, with each area being
assigned a subnet and routed to provide end-to-end connectivity.

Wi-Fi users expect (and the 802.11 protocol requires) that users on a
single SSID are connected to the same IP network and broadcast domain so
that they can roam seamlessly anywhere within a particular ESS (which can
be a building, campus or metro area). Limiting the size of these broadcast
domains means separating users onto different Wi-Fi networks depending on
their role, instead of their location.

So for wired networks we have a natural, physical scope depending on the
physical connection of hosts, in wireless networks we have scopes which
depend largely on the users access rights (since Wi-Fi is almost always
the security demarkation in networks).

It=B9s also worth nothing that the BCP for broadcast domain size is only 25=
5
hosts (a /24) which makes the 802.11 ESS requirement for a single
broadcast domain behind a given ESS difficult to achieve for large
networks, which is why many Wi-Fi vendors support multicast filtering,
client isolation and ARP proxies all of which can impact mDNS usability.

Best,
Alf

FYA http://www.youtube.com/watch?v=3D-FizhXOW2VM&noredirect=3D1