Subject: Re: [Lwip] Lwip Digest, Vol 20, Issue 3

From: Antonio Jara <[email-masked]>
Date: Tue, 22 May 2012 21:09:39 +0200

Dear  Dijk and Yan,

We are also implementing a lightweight version of mDNS and DNS protocol for
constrained environments.

Our approach is mainly focused on the optimizations of the replies included
in the packet, e.g. only include at the beginning the PTR record instead of
the PTR + SRV + AAAA.

It is also considering the options of include some special query to ask
specify TXT tuples, instead of general TXT entries, since the idea is to
describe the devices in a set of TXT records etc...

We are finishing our implementation, therefore, we are highly interested to
write an informational document about the design issues considered for the
lightweight considerations for DNS.

I enclose a paper with some initial considerations, but we are extending it
and implementing it right now on Contiki OS. Therefore, as soon as we have
the final conclusions, guidelines based on the results and stable
implementation. We can start to define this draft.

In conclusion, we would like to know about the interest for this work from
the WG and the possibilities to reach a collaborative approach with Dr.
Wang.

Best regards,
Antonio J. Jara

On Tue, May 22, 2012 at 9:00 PM, <[email-masked]> wrote:

> If you have received this digest without all the individual message
> attachments you will need to update your digest options in your list
> subscription.  To do so, go to
>
> https://www.ietf.org/mailman/listinfo/lwip
>
> Click the 'Unsubscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set this option
> globally for all the list digests you receive at this point.
>
>
>
> Send Lwip mailing list submissions to
>        [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://www.ietf.org/mailman/listinfo/lwip
> or, via email, send a message with subject or body 'help' to
>        [email-masked]
>
> You can reach the person managing the list at
>        [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Lwip digest..."
>
> Today's Topics:
>
>   1. Re: questions on LWIG (Dijk, Esko)
>
>
> ---------- Forwarded message ----------
> From: "Dijk, Esko" <[email-masked]>
> To: Yan Wang <[email-masked]>, "[email-masked]" <[email-masked]>
> Cc:
> Date: Tue, 22 May 2012 09:57:48 +0000
> Subject: Re: [Lwip] questions on LWIG
>
> Hello Yan,
>
>
>
> the empty sections in the document are currently still open to
> contributions.  As far as I know, nobody is working on these sections now.
> The scope of DNS is indeed not a simplified DNS protocol, but rather
> light-weight implementation techniques of DNS.  In my view that includes
> DNS client used for “typical DNS duties”; and also multicast-DNS (mDNS).
>
>
>
> regards,
>
> Esko
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Yan Wang
> *Sent:* Thursday 17 May 2012 8:38
> *To:* [email-masked]
> *Subject:* [Lwip] questions on LWIG
>
>
>
> Hi all,
>
>
>
> I am interested in LWIG group. I read draft-bormann-lwig-guidance-01, and
> the Section 3 is much helpful to my work. But I saw that most chapters in
> the Section 4 only have the title/outline. I don’t know whether there is
> nobody interested in them, or they just follow the conventional ways and
> don’t need much explanation, or somebody are working on them.
>
>
>
> My current work is focus on DNS, and I know IETF does not want DNS to take
> duties of non-DNS. So what is the defined range of DNS in Section 4.4 in
> this draft? I think it shouldn’t be defining a simplified DNS protocol. Is
> it the implementation experience on constrained networks similar to
> dnsmasq/mdns? Please give your kind advices.
>
>
>
>
>
> Best regards,
>
> Yan Wang
>
>
>
> ------------------------------
> The information contained in this message may be confidential and legally
> protected under applicable law. The message is intended solely for the
> addressee(s). If you are not the intended recipient, you are hereby
> notified that any use, forwarding, dissemination, or reproduction of this
> message is strictly prohibited and may be unlawful. If you are not the
> intended recipient, please contact the sender by return e-mail and destroy
> all copies of the original message.
>
> _______________________________________________
> Lwip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lwip
>
>

---

From: "Yan Wang" <[email-masked]>
Date: Wed, 23 May 2012 10:18:10 +0800

Dear Antonio and Dijk,

That’s great! We are also willing to share and discuss our experience and
the problems we meet. Let’s keep contact and go on discussion, hope to
provide good experience and guidelines to WG. Other interested people are
welcome to take part in the discussion.

Best regards, 

Yan

发件人: Antonio Jara [mailto:[email-masked]] 
发送时间: 2012年5月23日 3:10
收件人: [email-masked]; [email-masked]; Yan Wang
主题: Re: Lwip Digest, Vol 20, Issue 3

Dear  Dijk and Yan,

Best regards,

Antonio J. Jara

Today's Topics:

---------- Forwarded message ----------
From: "Dijk, Esko" <[email-masked]>
To: Yan Wang <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: 
Date: Tue, 22 May 2012 09:57:48 +0000
Subject: Re: [Lwip] questions on LWIG

Hello Yan,

the empty sections in the document are currently still open to
contributions.  As far as I know, nobody is working on these sections now.
The scope of DNS is indeed not a simplified DNS protocol, but rather
light-weight implementation techniques of DNS.  In my view that includes DNS
client used for “typical DNS duties”; and also multicast-DNS (mDNS).

regards,

Esko

From: [email-masked] [mailto:[email-masked]] On Behalf Of Yan
Wang
Sent: Thursday 17 May 2012 8:38
To: [email-masked]
Subject: [Lwip] questions on LWIG

Hi all,

 

Best regards, 

Yan Wang

  _____  

The information contained in this message may be confidential and legally
protected under applicable law. The message is intended solely for the
addressee(s). If you are not the intended recipient, you are hereby notified
that any use, forwarding, dissemination, or reproduction of this message is
strictly prohibited and may be unlawful. If you are not the intended
recipient, please contact the sender by return e-mail and destroy all copies
of the original message.

---

From: "Marc Lampo" <[email-masked]>
Date: Wed, 23 May 2012 09:58:27 +0200 (CEST)

Hello,

In the attached .pdf, page 6, there are remarks about the “size of DNS 
replies”.
It points out that the authority and additional records mean higher 
overload.
In that text you add a footnote (3) about “avoiding the inclusion of these 
sections”.
The footnote states, I quote :
“It can be removed with dig using the options +noauthority +noadditional”

I hope you’re not too serious about this !
>From dig help :
                +[no]answer         (Control display of answer)
                +[no]authority      (Control display of authority)
                +[no]additional     (Control display of additional)
→ these options control the *display* of the sections,
     not if a name server should include them in the reply !

Otherwise said : the (DNS) client has *no control* about what the name 
server
 will include in its answers.
 That control has to be exercised on the name server itself, if at all 
possible.
 (for Bind, look at the option : minimal-responses)

What I fail to see in the text is how data about smart objects gets 
published
 in/by DNS servers in the first place.
 This can be static, but I guess that rapidly one will want a more dynamic 
way :
 like an object registering itself upon waking up ?
 (just like Windows AD service updates DNS with SRV records upon starting)
 And that – dynamically updating – introduces security challenges,
 certainly if smart objects would be “out there” somewhere on the Internet
 and the required DNS server to send updates to,
 is visible to the Internet as well.

Kind regards,

Marc Lampo
Security Officer
EURid (for .eu)

From: Antonio Jara [mailto:[email-masked]]
Sent: 22 May 2012 09:10 PM
To: [email-masked]; [email-masked]; Yan Wang
Subject: Re: [Lwip] Lwip Digest, Vol 20, Issue 3

Dear  Dijk and Yan,

Best regards,
Antonio J. Jara

Today's Topics:

---------- Forwarded message ----------
From: "Dijk, Esko" <[email-masked]>
To: Yan Wang <[email-masked]>, "[email-masked]" <[email-masked]>
Cc:
Date: Tue, 22 May 2012 09:57:48 +0000
Subject: Re: [Lwip] questions on LWIG
Hello Yan,

regards,
Esko

Hi all,

I am interested in LWIG group. I read draft-bormann-lwig-guidance-01, and 
the Section 3 is much helpful to my work. But I saw that most chapters in 
the Section 4 only have the title/outline. I don’t know whether there is 
nobody interested in them, or they just follow the conventional ways and don’t 
need much explanation, or somebody are working on them.

Best regards,
Yan Wang

________________________________________

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 23 May 2012 10:12:40 +0200

On May 23, 2012, at 09:58, Marc Lampo wrote:

> an object registering itself

Most current activity in this space is around Zach/Srdjan's resource directory draft.

http://tools.ietf.org/html/draft-shelby-core-resource-directory

Grüße, Carsten

---

From: Antonio Jara <[email-masked]>
Date: Wed, 23 May 2012 11:06:08 +0200

Dear Marco,

On Wed, May 23, 2012 at 9:58 AM, Marc Lampo <[email-masked]> wrote:
> Hello,
>
> In the attached .pdf, page 6, there are remarks about the "size of DNS
> replies".
> In that text you add a footnote (3) about "avoiding the inclusion of these
> sections".
> "It can be removed with dig using the options +noauthority +noadditional"
>
> I hope you're not too serious about this !
> From dig help :

Yes, you are true, it is only for display issues. We were testing at
the beginning only as a proof of concept the capabilities of reducing
the DNS overload reducing the number of entries.

Right now, we are in progress of our own implementation on Contiki in
order to select by ourself the replies to be included. As soon as we
complete the Contiki version and we evaluate it on the nodes, we will
evaluate it over directly.

Anyway, the dig options are interesting, since although it is true
that it is only removing in the display, the analysis of the overload
presented is regarding to the displayed authorities and answers.
Therefore, it continues being useful :-).
>  (for Bind, look at the option : minimal-responses)

Yes, our idea is similar to offer an implementation of
minimal-responses for smart things, and right now the analysis is
focused on what is a minimal response for a constrained node, i.e.
only the PTR record, only the TXT of the interested attribute...

>  like an object registering itself upon waking up ?

Yes, for that reason it is mixed also with mDNS, and right now the
idea is that the "mDNS discover" is linked with the DNS record from
BIND9 in order to store in the zone record dynamically the entries
conforming it is receiving messages from the nodes via mDNS announcing
their services.

It is also a way with the BIND9 (DNS-SD) support to avoid that
continuously is required the answer from the constrained node via
mDNS.

>  And that - dynamically updating - introduces security challenges,
>  certainly if smart objects would be "out there" somewhere on the Internet

Yes, it is an advantage and a problem, it is an advantage since it is
discoverable globally and it is a disadvantage because the privacy
issues. But, anyway the authorization for accessing to a service is an
ancillary part from CoAP or the application protocol.

Thanks so much for your highly relevant feedback.

Best regards,
Antonio J. Jara
> client used for "typical DNS duties"; and also multicast-DNS (mDNS).
>
> regards,
> Esko
>
> the Section 4 only have the title/outline. I don't know whether there is
> nobody interested in them, or they just follow the conventional ways and don't
> this draft? I think it shouldn't be defining a simplified DNS protocol. Is

---

From: "Yan Wang" <[email-masked]>
Date: Wed, 23 May 2012 19:29:41 +0800

Dear Antonio and Marco,

> > In that text you add a footnote (3) about "avoiding the inclusion of
> > these sections".
> Yes, you are true, it is only for display issues. We were testing at the
beginning
> only as a proof of concept the capabilities of reducing the DNS overload
reducing
> the number of entries.
order to
> select by ourself the replies to be included. As soon as we complete the
Contiki
> version and we evaluate it on the nodes, we will evaluate it over
directly.
> 
> Anyway, the dig options are interesting, since although it is true that it
is only
> removing in the display, the analysis of the overload presented is
regarding to the
> displayed authorities and answers.
> > server  will include in its answers.
> Yes, our idea is similar to offer an implementation of minimal-responses
for smart
> things, and right now the analysis is focused on what is a minimal
response for a
> constrained node, i.e.

Usually we deploy this option on recursive server in the internet, because
the information is useless for end user. So it can reduce payload to client.

I don’t know whether it could be supported on the client. Usually not do it
on client in the internet, I think.
As I know a lot of recursive servers use this option, such as Google's. One
possible option is that we just use the recursive server with dig :-). But
it can't solve the problem at all, research on minimal response is still
need. 

Best regards, 
Yan

---

From: Zhen Cao <[email-masked]>
Date: Mon, 28 May 2012 13:46:38 +0800

> http://tools.ietf.org/html/draft-shelby-core-resource-directory

I think the context of is about registration of the dns names, not
data content.

-- 
Best regards,
Zhen

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 28 May 2012 08:46:46 +0200

The question here is: what is the point of registering a smart obiect's name without providing a way to know its resources. 

Sent from Mobile

---

From: Zhen Cao <[email-masked]>
Date: Mon, 28 May 2012 16:26:32 +0800

The sensor, if acting like a server, should have a name for its IP
reachability.

-- 
Best regards,
Zhen

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 30 May 2012 22:18:48 +0200

Naming things is generally a good idea. What is not so clear is whether the DNS is always the best place to keep the mapping from these names to the addresses behind them.  Even where it is being used, it is not clear whether the object itself is the entity responsible for establishing the mapping.  I think it will be interesting to see how the smart object discovery architectures will evolve and what role DNS will play in each of them.

Sent from Mobile

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 30 May 2012 16:54:45 -0400

Hi,

> in the packet, e.g. only include at the beginning the PTR record instead of

I had a look at the PDF you enclosed.

First, I can't tell whether you're actually using DNS and mDNS or
not.  Part of V of the paper suggests that you're using a DNS-like
packet format over CoAP, in which case you're not actually using
either of them; instead, you're using the same payload format but a
different protocol, since DNS uses UDP and TCP.

Reading your paper, however, it seems to me you have deep
misunderstandings of the DNS, the way it works, and its relationship
to mDNS.  To be clear: mDNS to date is almost exactly the same thing
as the DNS, only responding to multicast addresses in a
multicast-friendly way and on a different port.  Apart from that, all
the RRTYPEs and everything else about the DNS are the same.  Your
suggestion in (V) that mDNS or DNS-SD add resource record types to DNS
is mistaken.  (There is a problem in that there's no guarantee that
things will stay this way.  That's a problem for another community,
however.)

If you are actually using DNS, then TXT in the way you are using it is
a serious mistake.  There are _no_ semantics for TXT records, and there
is no way you can be sure that someone else won't put a TXT record of
the same name in the DNS.  Importantly, TXT records _are not_
"designed to be associated with the SRV entry", there is no mechanism
for making that association except your client's interpretation, and
there is no way whatever even to be sure that you'll see a consistent
view of the target zone, since there might be caches in the way.

What seems to be a more serious problem is your discussion in (VI)
about the size of responses.  In general, there is no way to control
this from the client side, and if you are actually using DNS you are
going to have to be able to cope with these additional parts of the
message.  In some cases, anyway, you won't be able to do anything
without them, for the Additional section is where glue records
(necessary to bootstrap the entire DNS chain) go. 

I get the impression that you _want_ to use DNS because it gives you
an already-deployed Internet-wide infrastructure, but mDNS doesn't
work outside the LAN, and DNS requires some mechanism of updating a
central database (the mechanism for which is not clear in your plan).
I am also having a hard time understanding the extent to which DNS is
actually a good match for the problem you're trying to solve, since
most of your goal seems to be to provide information about a node
(hence all the TXT records).  I don't see how the DNS is a good place
to store this, and it is poorly adapted for transporting the data.
And, of course, if you're using CoAP you're not using DNS at all, in
which case I don't see why you'd want to pay the cost of the poor
adaptation of DNS RRTYPEs for the problems you seem to have.  Why not
just put a name and an address in the DNS, as you suggest in (V), and
ask that node what its state is?  Why cart all that stuff into the
DNS, and then have to hack around the way the DNS makes your life
hard?
 
> describe the devices in a set of TXT records etc...

I don't think I understand this sentence, but if what you're hoping to
do is to cram additional sub-RR queries into the DNS query format,
then there's a working way to do this: get some new RRTYPEs.  TXT is
not what you want if you want structured data.  If you really must,
you could presumably do it with an underscore convention, although I
don't see a reliable way to make most of this tractable given that you
don't know what kind of device someone might be trying to address.

This is the second time in this WG I've seen attempts to use the DNS
to achieve something, and I still don't know what that something is.
Apart from getting the address of a named object -- a task at which
the DNS excels -- I'm not sure I understand how the DNS is adapted to
the task.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]