Subject: Re: [Dots] Call for adoption on draft-boucadair-dots-server-discovery

From: Roman Danyliw <[email-masked]>
Date: Wed, 9 Jan 2019 19:17:14 +0000

Hello!

Excluding support from the draft authors, the interest in adoption (or any response) was low on the list (one) and also at IETF 103.  The previous discussion around this draft was more spirited.  My concern is that this call may have been lost in the end of year holidays.  To that end, I'm extending the call for adoption. 

Please provide feedback to the list/chairs if you believe that this document should be adopted as a WG document.  This extended adoption call will end on Tuesday, January 22.

Regards,
Roman and Frank

> -----Original Message-----
> From: Dots [mailto:[email-masked]] On Behalf Of Roman Danyliw
> Sent: Friday, November 30, 2018 5:22 PM
> To: [email-masked]
> Subject: [Dots] Call for adoption on draft-boucadair-dots-server-discovery
> 
> Hello!
> 
> This is the start of a two week call for input on the WG adoption of the
> document:
> 
> draft-boucadair-dots-server-discovery
> https://tools.ietf.org/html/draft-boucadair-dots-server-discovery-05
> 
> The document has been presented and discussed at IETF 103, IETF 100 and
> IETF 99;  and revisions have been made based on WG feedback.  Discussion
> of adoption of this draft was previously deferred pending submission of the
> signal draft for publication (which occurred in September 2018).
> 
> At the IETF 103 meeting, there were not many participants who had read the
> draft.
> 
> Please provide feedback to the list/chairs if you believe that this document
> should be adopted as a WG document.  The adoption call will end on
> December 14 2018.
> 
> Regards,
> Roman and Frank
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Teague, Nik" <[email-masked]>
Date: Mon, 14 Jan 2019 11:37:17 +0000

Hi,

I would like to register my support for adoption of this draft as a working group document.

Thanks,

-Nik

> On 9 Jan 2019, at 19:17, Roman Danyliw <[email-masked]> wrote:
> 
> Hello!
>

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 14 Jan 2019 11:57:17 -0000

Hi there,

I support adoption of this document as a WG document.

Other that already discussed, nothing else currently leaps out at me to say
- this needs thinking about / fixing.

Regards

Jon

-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of Roman Danyliw
Sent: 09 January 2019 19:17
To: [email-masked]
Subject: Re: [Dots] Call for adoption on

Hello!

Excluding support from the draft authors, the interest in adoption (or any
response) was low on the list (one) and also at IETF 103.  The previous
discussion around this draft was more spirited.  My concern is that this
call may have been lost in the end of year holidays.  To that end, I'm
extending the call for adoption. 

Please provide feedback to the list/chairs if you believe that this document
should be adopted as a WG document.  This extended adoption call will end on
Tuesday, January 22.

Regards,
Roman and Frank

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 14 Jan 2019 12:29:20 -0500

I support WG adoption of this draft.

Thanks

-- Flemming

On 1/9/19 2:17 PM, Roman Danyliw wrote:
> .

---

From: Daniel Migault <[email-masked]>
Date: Mon, 14 Jan 2019 22:23:30 -0500

I support the adoption of the draft.

While this should not prevent the adoption, I would avoid mDNS and prefer
the use of SD with unicast DNS. For homenet, .local should be replaced by
home.arpa.  I am not sure NAPTR solution could not be replaced by DNS-SD as
well. I am happy to look at these discussions.

Yours,
Daniel

On Mon, Jan 14, 2019 at 12:29 PM Flemming Andreasen <[email-masked]>
wrote:

> From: Dots [mailto:[email-masked] <[email-masked]>] On Behalf Of Roman Danyliw
> draft-boucadair-dots-server-discoveryhttps://tools.ietf.org/html/draft-boucadair-dots-server-discovery-05
>
> Dots mailing [email-masked]://www.ietf.org/mailman/listinfo/dots
>
> Dots mailing [email-masked]://www.ietf.org/mailman/listinfo/dots
> ..
>
>
>

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 15 Jan 2019 07:28:10 +0000

Hi Daniel,

After the discovery of the DOTS server, the DOTS client must authenticate the DOTS server and vice-versa. If the DOTS agents cannot mutually authenticate each other, the discovery mechanism is of no use.

The only way to automate the discovery of DOTS server and automatically configure the explicit trust anchor store for the attached domain on the DOTS client is to use BRSKI (see https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-17), using BRSKI the device (co-located with DOTS client) would have already learned and validated the network domain name, and can use DNS-SD to discover the DOTS server.

Further, S-NAPTR lookup helps provision the preferred DOTS signal channel transport protocol b/w the client and server, and the destination port of the DOTS server.

I don’t see the need to support mDNS and “.local” or “.home.apra”.

Cheers,
-Tiru

From: Dots <[email-masked]> On Behalf Of Daniel Migault
Sent: Tuesday, January 15, 2019 8:54 AM
To: Flemming Andreasen <[email-masked]>
Cc: Roman Danyliw <[email-masked]>; [email-masked]
Subject: Re: [Dots] Call for adoption on draft-boucadair-dots-server-discovery

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________
I support the adoption of the draft.

While this should not prevent the adoption, I would avoid mDNS and prefer the use of SD with unicast DNS. For homenet, .local should be replaced by home.arpa.  I am not sure NAPTR solution could not be replaced by DNS-SD as well. I am happy to look at these discussions.

Yours,
Daniel

On Mon, Jan 14, 2019 at 12:29 PM Flemming Andreasen <[email-masked]<mailto:[email-masked]>> wrote:
I support WG adoption of this draft.

Thanks

-- Flemming

Hello!

Regards,

Roman and Frank

-----Original Message-----

To: [email-masked]<mailto:[email-masked]>

Hello!

document:

draft.

December 14 2018.

Regards,

Roman and Frank

Dots mailing list

[email-masked]<mailto:[email-masked]>

Dots mailing list

[email-masked]<mailto:[email-masked]>

...

_______________________________________________
Dots mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dots

---

From: kaname nishizuka <[email-masked]>
Date: Thu, 17 Jan 2019 17:04:16 +0900

And I agree with the concern Dan mentioned last month.
 > However, I would really encourage the working group to analyze if all 4 discovery methods are really necessary.
I believe that the draft can solve this issue.

thanks,
kaname

---

From: "Panwei (William)" <[email-masked]>
Date: Sat, 26 Jan 2019 09:38:00 +0000

Hi,

I support adoption of this draft.

Two typos:

1. Section 5
When only DOTS server' IP
               ^^^^^^^
addresses are configured, a reference identifier must also be
configured for authentication purposes.

"server'" should be "server's".

2. Section 9.1.2 and 9.2.2
9.1.2. Format Format of DOTS Address Option
       ^^^^^^^^^^^^^
9.2.2. Format Format of DOTS Address Option
       ^^^^^^^^^^^^^

Duplicate "Format".

Two comments:

1. Section 9.1.1 and 9.2.1 describe the DOTS Reference Identifier Option, but the content of these Option is DOTS server name. I'm not quite familiar with this, so I just raise this and want to make sure if the content is right.

2. In section 9.1.2, the "List of DOTS IPv4 Addresses" contains one or more IPv4 addresses of a DOTS server, and the "OPTION_V4_DOTS" can include multiple lists. When the "OPTION_V4_DOTS" includes multiple lists, do these lists belong to one DOTS server or multiple DOTS servers? My understanding is that multiple lists belong to multiple DOTS servers and one DOTS server only has one list. I'm not quite sure, maybe an example can be added in the draft.

Best Regards

Wei Pan

> Sent: Saturday, December 01, 2018 6:22 AM

> The document has been presented and discussed at IETF 103, IETF 100

> and IETF 99;  and revisions have been made based on WG feedback.

> Discussion of adoption of this draft was previously deferred pending

> submission of the signal draft for publication (which occurred in

> September 2018).

> At the IETF 103 meeting, there were not many participants who had read

> the draft.

> Please provide feedback to the list/chairs if you believe that this

> document should be adopted as a WG document.  The adoption call will

> end on December 14 2018.