44th IETF: BOFs - RESCAP, REMBOOT

Resource Capabilities Discovery BOF (rescap)

Monday, March 15 at 1530-1730
=============================

Chairs: James M Galvin <[email protected]>
        Ned Freed <[email protected]>

DESCRIPTION:

A variety of resource identifiers have been widely deployed on the 
Internet as a means of identifying various resources, services, and 
destinations. However, a means of attaching a set of attributes or 
characteristics to a given resource identifier and subsequently 
assessing those attributes or characteristics has not been specified 
and deployed.

A particularly important resolution service of this general type is 
one which, when given a mail address identifying a particular mail 
recipient, will return a series of attributes describing the 
capabilities of that recipient. This differs from a directory service 
in that no searching or other advanced query operations are involved.

The first task of this working group will be to define a general 
resolution protocol that will translate resource identifiers to a list 
of attributes. At a minimum the service must be capable of returning 
mail recipient capabilities as described above, but ideally the service 
should also handle more general capability and characteristics 
discovery.

The second task of this working group will be to define an 
administrative model and update protocol that can be used to set up and 
maintain the information the resolution protocol accesses.

The service resulting from the combination of these two protocols must 
meet the following requirements:

(0) The resolution protocol must be highly scalable, as the intent is 
    to deploy it very widely.

(1) Resolution protocol and server overhead must be very low, as some
    applications will make very heavy use of it.

(2) Identifiers input to the resolution service must be formatted as
    Uniform Resource Identifiers (URIs) containing one or more DNS 
    domains. Note that mail addresses can be presented as mailto: URIs  
    to meet this requirement.

(3) Facilities to support inheritance within the attribute store will
    be essential, as the number of identifiers may be very large. 
    Specifically, mechanisms must be provided by which administrators 
    can set default values for members of their administrative domains.

(4) Existing protocols will be profiled for use as part of this service
    whenever possible rather than developing new protocols. In 
    particular:

    (a) The DNS must be used as the first step in the resolution
        service. This is because all the URIs under consideration here
        contain a DNS domain and the DNS is already properly delegated.
    (b) Existing DNS record types such as SRV and NAPTR will be used if
        feasible, to ease deployment.
    (c) A lightweight resolution protocol may be defined by this working 
        group if no existing protocol proves to be suitable.
    (c) A lightweight resolution protocol may be defined by this working
        group if no existing protocol proves to be suitable.
    (d) An existing administrative model and maintenance protocol will 
        be used if feasible. Possible candidates for this include ACAP
        and LDAPv3. The protocol and security model by which a user can
        update his or her own attributes must be covered.

The means to register and extend the set of attributes must be 
specified. However, specification of actual attributes needed by 
various applications of this service is outside of the scope of this 
working group.

AGENDA:

Charter review/bashing (20 mins)
Query protocol requirements (30 mins)
Administrative/update protocol requirements (30 mins)
Use of existing protocols for administration/update (10 mins)

======================================================================
Remote Boot Protocol BOF (remboot)

Thursday, March 18 at 1530-1730
===============================

Chair:  Michael Henry <[email protected]>

DESCRIPTION:

The Remote Boot Protocol Working Group is chartered to define a standard 
protocol between the remote boot client and the responding server. The 
Working Group objective is to produce a protocol that insures remote boot 
clients, of arbitrary platform and instruction set architecture, will be
able to choose and obtain an appropriate boot program from a arbitrary 
variety of boot servers, without the necessity of site specific 
pre-configuration of the client.

The working group will consider existing remote boot methods. The protocol 
defined by the working group will be consistent with DHCP and the Service 
Location Protocol. The working group will coordinate with both the Dynamic 
Host Configuration Protocol and the Service Location Protocol Working
Groups.  The output of this WG will consist of a base architectural document 
that provides the framework for how remote boot will be done (i.e., defines 
the protocol), together with one or more documents defining the required 
capabilities of the remote boot client and the responding server. The 
protocol document will describe how the remote boot client will discover an 
appropriate boot server, how the client will identify itself to the boot 
server, and how the remote boot client will obtain a boot program. If 
possible, an existing protocol to locate a boot service (e.g. Service 
Location Protocol) will be used. IANA registration for types of remote boot 
clients and types of boot servers will be specified as part of the base 
protocol. Documenting necessary capabilities of the remote boot client and 
boot server will be done elsewhere (i.e., in standalone documents).

AGENDA:

1. Introduction and Agenda review
2. Problem Statement: Limitations of DHCP/bootfile remote boot - WG charter
   review
3. Review PXE boot protocol ID (to be submitted 2/25)
4. Review Multicast use in PXE boot protocol ID (to be submitted 2/23)
5. Decision on consensus to pursue working group status.

Mailing Lists: 

[email protected]


------- End of Forwarded Message

----- End of forwarded message from Steve Coya -----