* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Dbound Status Pages

Domain Boundaries (Concluded WG)
Art Area: Barry Leiba, Adam Roach, Alexey Melnikov | ?? — 2015-Apr-09 
Chairs
 
 


2017-03-30 charter

Domain Boundaries (dbound)
--------------------------

 Charter

 Current Status: Active

 Chairs:
     Murray Kucherawy <superuser@gmail.com>
     Pete Resnick <presnick@qti.qualcomm.com>

 Applications and Real-Time Area Directors:
     Ben Campbell <ben@nostrum.com>
     Alexey Melnikov <aamelnikov@fastmail.fm>
     Adam Roach <adam@nostrum.com>

 Applications and Real-Time Area Advisor:
     Alexey Melnikov <aamelnikov@fastmail.fm>

 Mailing Lists:
     General Discussion: dbound@ietf.org
     To Subscribe:       http://www.ietf.org/mailman/listinfo/dbound
     Archive:            https://mailarchive.ietf.org/arch/browse/dbound/

Description of Working Group:

  Various Internet protocols and applications require some mechanism for
  determining whether two domain names are related. The meaning of
  "related" in this context is not a unitary concept. The DBOUND working
  group will develop one or more solutions to this family of problems,
  and will clarify the types of relations relevant.

  For example, it is often necessary or useful to determine whether
  example.com and foo.example.com, or even example.net, are subject to
  the same administrative control. To humans, the answer to this may be
  obvious. However, the Domain Name System (DNS), which is the service
  that handles domain name queries, does not provide the ability to mark
  these sorts of relationships. This makes it impossible to discern
  relationships algorithmically. The right answer is not always "compare
  the rightmost two labels".

  Applications and organizations impose policies and procedures that
  create additional structure in their use of domain names. This creates
  many possible relationships that are not evident in the names
  themselves or in the operational, public representation of the names.

  Prior solutions for identifying relationships between domain names have
  sought to use the DNS namespace and protocol to extract that information
  when it isn't actually there.  See the "Additional Background
  Information" section of the working group wiki for more details:
  https://trac.tools.ietf.org/wg/dbound/trac/wiki/AdditionalBackgroundInformation

  For the purpose of this work, "domain names" are identifiers used by
  organizations and services, independent of underlying protocols or
  mechanisms, and an "organizational domain" is defined as a name that
  is at the top of an administrative hierarchy, defining transition from
  one "outside" administrative authority to another that is "inside" the
  organization.

  The current way most of this is handled is via a list published at
  publicsuffix.org (commonly known as the "Public Suffix List" or "PSL"),
  and the general goal is to accommodate anything people are
  using that for today.  However, there are broadly speaking two use
  patterns. The first is a "top ancestor organization" case. In this case,
  the goal is to find a single superordinate name in the DNS tree that can
  properly make assertions about the policies and procedures of
  subordinate names. The second is to determine, given two different
  names, whether they are governed by the same administrative authority.
  The goal of the DBOUND working group is to develop a unified solution,
  if possible, for determining organizational domain boundaries. However,
  the working group may discover that the use cases require different
  solutions. Should that happen, the working group will develop those
  different solutions, using as many common pieces as it can.

  Solutions will not involve the proposal of any changes to the DNS
  protocol.  They might involve the creation of new resource record types.

  This working group will not seek to amend the consuming protocols
  themselves (standards for any web, email, or other such protocols) under
  this charter.  If such work is desirable, it will be assigned to another
  appropriate working group or defined as a work item in an updated
  charter. Rechartering will only be considered after completion of the
  base work.

  The working group has a pre-IETF draft to consider as a possible
  starting point: draft-sullivan-dbound-problem-statement

Goals and Milestones:


All charter page changes, including changes to draft-list, rfc-list and milestones:



Generated from PyHt script /wg/dbound/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -