Domain Registration Protocol BOF @ IETF-43

Text:     <draft-crispin-srs-00.txt>

Slides:  <http://www.brandenburg.com/presentations/drp-bof>

Authors:
    [email protected]
    [email protected]
    [email protected]
    [email protected]

Presenters:
    Dave Crocker / DC
    Kent Crispin  / KC

Area Directors
    Patrik F�ltstr�m
    Keith Moore

Note Taker:
    Eric Brunner / EB <[email protected]>

Introduction (DC):

    Dave's opening remarks discussed the time-line for
    effective work on the issue of shared registries
    (aggressive), the need to form a WG charter in the 2
    hours allotted for the BOF, and to select a forward-
    progress goal. These issues were re-visited towards the
    end of the BOF, motivated by the observations of the
    two ADs present, and the sense of the BOF attendees.

    Dave gave an intro to the issue(s) and the draft,
    running through the first six (6) slides.
         #2 introduced the SRS (shared registry service)
         terminology,
         #3 introduced the two basic models -- light vs
         heavy, and slides
         #4 and #5  discussed the salient details of these
         two models, with slide
         #6 covering the trade-offs of each.

Requirements (KC)

    Kent's first slide and oral history covered the issue
    since new-dom. The second slide covered the general
    architecture of the SRSP, and elicited a comment
    concerning the need for ccTLD-specific extension,
    specifically the insertion of a "Registry Authority" in
    the SRSP sequence of transactions.  The authority would
    mediate the transaction.

    This was characterized (EB) as a non-delegated
    transaction to an external authority, similar in nature
    to any name conflict resolution transaction, and also
    characterized (DC) as a policy issue for which the SRS
    protocol needed only to provide a mechanism.

    Sustained discussion on several basic issues occurred
    at this point, in summary the issues of ccTLD-specific-
    vs gTLD-specific policies, equity of access within a
    registry, and name portability within a registry took
    place. This clarified the distinctions between registry
    and registrars, and the assumption that gTLD
    requirements could be extended to meet those of ccTLDs.

    The outcome of this phase of the discussion was that

    1. if necessary to distinguish, the WG scope is gTLD
specific,

    2. many registrars acting on hierarchies of gTLD-rooted
    registries

    3. equity of access within each registry is desired

    4. name portability "within" each registry is desired

    Kent continued with slide #3 covering registry data and
    slide #4 covering access functions. There was some
    terminology haggling and "inquire" was substituted for
    "access" function. A question was posed on the internal
    representation of registries and the "format free"
    burden one registrar could place upon subsequent
    registrars upon change-of-registrar by users.

    A question was posed on the authentication mechanism(s)
    that ran into the content of Kent's slide #5
    (security), arising from the outcome of separation of
    registries from registrars. This question was followed
    up by several more related to the existing SRS
    authentication issues.  One of the two ADs attending
    (Patrik) observed that we should not require the use of
    a risk-prone authentication mechanism.

    Kent continued with slide #6 (transport), a summary of
    questions and answers follows:

    a) is there a performance requirement for the protocol

         ans: no.

    b) scope

         1. scale (registry deltas) to 15 mins granularity?

         ans: (DC) scale to arbitrary numbers, hence yes
         generally. ans: (KC) key verification is the
         performance bottleneck, hence not "dynamic DNS".

         2. geographic and other extensions?

         ans: (DC/KC) additional objects and fields
         suffice, hence no.

    c) no coupling of protocol and transport (design
    principle assertion from the floor)

         ans: (DC) email as transport is a conscious choice
         to mandate a minimal level of services required,
         consistent with basic principle of equity of
         access, and "SHALL" is appropriate.

    d) another ccTLD comment, which EB understood to again
    seek some form of two-phase commit (external authority
    hook)

    e) is the SRS model wanted below the level of 2SLDs?

         ans: (DC/KC) yes, recursive generally.

    At this point AD Patrik made a comment with respect to
    priorities and the ccTLD vs gTLD choice for the WG, in
    brief strongly advising that the gTLD issues are more
    pressing.

Charter (DC)

    Only 10 of the approximate 50 attendees had seen the
    draft charter, so the draft charter was read. There was
    more discussion of the ccTLD vs gTLD issue, of ASCII vs
    UTF8, and email as "a" (not "the exclusive") mandated
    transport.

    KC observed that the issue of ASCII vs UTF8 had been
    discussed previously on the mailing list, and that the
    question was still open.

    The issue of registrar-specific variable/private data
    within registries again was discussed (see "format
    free" above), as was the external authority issue, and
    DC suggested that "extensibility", along with specific
    wording changes to the charter be taken to the mailing
    list.

    It was the sense of the room that the mandate for email
    as transport was sound.

Milestones (DC)

    Dave discussed the motivation for moving fast on the
    issue, followed by point by one of the ADs that this WG
    cannot form until January for IESG-internal reasons.

    It was the sense of the room that the existing draft
    and charter, with the changes arising from the BOF,
    were sufficient to forward on to the ADs for action,
    and that the choice to act "fast" was adopted.

Outstanding Issues (KC)

    1. Extensibility (but not dynamic DNS), KC "easy to
    add"

    2. Policy (firewalls and external authority)

    3. Dynamic private, KC "hard"

    The BOF ended with 20-30 people committing to work on
    the documents and 10+ people committing to "really
    working" on the texts over the immediate future to meet
    the "fast" time-line requirements.