Subject: [dhcwg] draft-bhandari-dhc-class-based-prefix

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 15 Mar 2013 01:11:28 +0000

I was thinking:

- when prefix classes or properties come via an authenticated interface such as the mobile (3g/lte) radio interface, the trust and meaning of the "local" bits might be clear (mapping provided by provider) and perhaps little further authentication is needed. Though roaming makes this interesting as the "local" meaning of the roaming partner may not be known - and therefore only useful when connected to "home" provider. Unlocked devices are also likely to have issues.

- in other cases (i.e., wifi or roaming), the information is unlikely to be trusted and there is no good way to map it to useful things.

So, why not use the DNS for this information? It can be "trusted" with dnssec and use well known names perhaps in the reverse zone for the first hop router or elsewhere in the tree can be queried and the information exchange can be much richer ... perhaps using txt RRs.

This is a bit like mdns advertises services and capabilities of devices, but in this case it provides the class/property information. It would only be looked up when needed. 

An application could also query this for application specific information. Service providers would need to populate this information as they desire (or not). Some "default" value(s) can also be present which would only be used if the application specific wasn't available.

TTL on records provides an ability to cache them (for appropriate length of time).

Anyway, this may be something to think about as it would be significantly richer it is descriptive ability and be able to provide much finer grained information.

- Bernie

---

From: "Shwetha Bhandari (shwethab)" <[email-masked]>
Date: Fri, 15 Mar 2013 10:59:50 +0000

Bernie,

We are trying to address:

1. Mapping prefix to metadata
2. Understanding what the metadata means

 For providing the metadata that is attached to prefix itself providing it
via DHCP or RA seems to be inline with what we do in DHCP/SLAAC to make
the prefix usable. draft-bhandari-dhc-class-based-prefix-04 splits
metadata into property that has a well defined meaning. And the
colour/class that is local significance and could be treated as a service.

What you are proposing is useful for (2) to derive addition information
especially for class/colour as it is of local significance and may need a
DNS-SD/mdns or any new proposal that will be made for conveying multiple
provisioning domains. How this will be used by the applications for
influencing SAS - e.g. Will the application be hardcoded to prefer a
certain class in a certain domain or learns this information somehow needs
more thought. If application is picking the class via user interface may
be providing more information will help a user choose and hence more
descriptive information about the class be useful.

Shwetha

On 3/15/13 6:41 AM, "Bernie Volz (volz)" <[email-masked]> wrote:

>I was thinking:
>
>- when prefix classes or properties come via an authenticated interface
>such as the mobile (3g/lte) radio interface, the trust and meaning of the
>"local" bits might be clear (mapping provided by provider) and perhaps
>little further authentication is needed. Though roaming makes this
>interesting as the "local" meaning of the roaming partner may not be
>known - and therefore only useful when connected to "home" provider.
>Unlocked devices are also likely to have issues.
>
>- in other cases (i.e., wifi or roaming), the information is unlikely to
>be trusted and there is no good way to map it to useful things.
>
>So, why not use the DNS for this information? It can be "trusted" with
>dnssec and use well known names perhaps in the reverse zone for the first
>hop router or elsewhere in the tree can be queried and the information
>exchange can be much richer ... perhaps using txt RRs.
>
>This is a bit like mdns advertises services and capabilities of devices,
>but in this case it provides the class/property information. It would
>only be looked up when needed.
>
>An application could also query this for application specific
>information. Service providers would need to populate this information as
>they desire (or not). Some "default" value(s) can also be present which
>would only be used if the application specific wasn't available.
>
>Anyway, this may be something to think about as it would be significantly
>richer it is descriptive ability and be able to provide much finer
>grained information.
>
>- Bernie
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dhcwg