Vessel Monitoring Systems; Specification of Requirements for Mobile Transmitting Unit Type Approval, 5813-5817 [E8-1662]
Download as PDF
Federal Register / Vol. 73, No. 21 / Thursday, January 31, 2008 / Notices
The
Ocean.US Office, operating by
interagency agreement under the
statutory authority of the National
Oceanographic Partnership Program
(NOPP, 10 U.S.C. 7901 et seq.), serves as
the national agent for integrating ocean
observing activities (https://
www.ocean.us). Ocean.US is also the
focal point for relating U.S. ocean
observing system elements to associated
international efforts, such as the Global
Earth Observing System of Systems
(GEOSS) and the Intergovernmental
Oceanographic Commission (IOC)
sponsored Global Ocean Observing
System (GOOS). The U.S. IOOS
represents the U.S. contribution to the
ocean components of these international
partnership efforts. Key to the
realization of the U.S. IOOS is the
establishment of an integrated DMAC
infrastructure. This infrastructure will
enable users to discover, retrieve, and
use data from Federal and State
government, government-sponsored,
other public, private, and commercial
coastal and ocean observing activities
regardless of source or location. In 2005
Ocean.US established an IOOS DMAC
Steering Team drawn from government,
industry, academia, public, and nonprofit communities to: (a) Coordinate
and oversee the evolution of DMAC
standards; (b) identify and provide
recommendations regarding gaps in
needed standards; and, (c) help ensure
that the DMAC standards process is
conducted in an open, objective, and
balanced manner. That team adopted a
standards process in May 2006 that
includes these public comment periods
as a critical input to any decisions on
a particular standard.
SUPPLEMENTARY INFORMATION:
Review to Date of the Proposed
Standards
Proposed standards have been
reviewed by members of the DMAC
Steering Team and its Expert Teams for
non-technical and technical criteria.
Their designation as ‘proposed’
indicates the standard has potential
merit for application in IOOS and
should be evaluated further based on
actual use in pilot projects and
demonstrations and based on public
comments on experience using the
standard in IOOS applications.
rwilkins on PROD1PC63 with NOTICES
Authority: 10 U.S.C. 7901 et seq.
Dated: January 17, 2008.
Elizabeth R. Scheffler,
Associate Assistant Administrator for
Management, Ocean Services and Coastal
Zone Management.
[FR Doc. E8–1723 Filed 1–30–08; 8:45 am]
BILLING CODE 3510–22–P
VerDate Aug<31>2005
18:07 Jan 30, 2008
Jkt 214001
DEPARTMENT OF COMMERCE
National Oceanic and Atmospheric
Administration
RIN 0648–XF16
Vessel Monitoring Systems;
Specification of Requirements for
Mobile Transmitting Unit Type
Approval
National Marine Fisheries
Service (NMFS), National Oceanic and
Atmospheric Administration (NOAA),
Commerce.
ACTION: Revision of type approval
requirements for mobile transmitting
units.
AGENCY:
SUMMARY: This document provides
notice of type approval requirements for
Mobile Transmitting Units (MTU) to be
authorized for use on any vessel
participating in the NOAA Vessel
Monitoring System (VMS) program.
Vessels participating in VMS program
must acquire an NMFS-approved MTU
to comply with VMS standards set forth
in NMFS rules requiring the use of
VMS.
To obtain copies of the list
of NMFS-approved VMS MTU and VMS
communications service providers, or to
obtain information regarding the status
of VMS systems being evaluated by
NOAA, write to NOAA Fisheries, Office
for Law Enforcement (OLE), 8484
Georgia Avenue, Suite 415, Silver
Spring, MD 20910.
FOR FURTHER INFORMATION CONTACT: For
current listing information contact the
VMS Support Center by phone: 888–
210–9228, or by fax: 301–427–0049 or
for questions regarding VMS installation
and status of evaluations contact
Jonathan Pinkerton, National VMS
Program Manager by phone: 301 427
2300 or by fax: 301–427–0049.
SUPPLEMENTARY INFORMATION: This
notice supersedes all previous notices
on MTU type approval requirements.
Previously installed MTU approved
under prior notices will continue to be
approved for the remainder of their
service life. New installations of a
previously approved MTU occurring
120 days or more after the publication
date of this notice must comply with all
of the requirements herein. All new
requests for type approval must comply
with all of the requirements herein.
ADDRESSES:
Background
The Department of Commerce,
National Oceanic and Atmospheric
Administration, National Marine
Fisheries Service, Office for Law
Enforcement (OLE) maintains MTU
PO 00000
Frm 00025
Fmt 4703
Sfmt 4703
5813
specification requirements as an OLE
National Directive. This notice sets
prerequisite standards for the purpose of
type approval that must be met by an
MTU and any associated software before
it is authorized for use in the NOAA
VMS program. Vessels participating in
VMS program must acquire an NMFSapproved MTU to comply with the
specific VMS standards set forth in
NMFS rules requiring the use of VMS.
The MTU is a transceiver or
communications device, including
antennae, dedicated message terminal
and display, and an input device such
as a keyboard installed on fishing
vessels participating in the VMS
requirement. The MTU allows OLE to
determine the geographic position of the
vessel during specified intervals or
events. In addition, it enables mobile
communications services between OLE
and the vessel when using an NMFSaccepted Mobile Communication
Service Provider (MCSP). (Note:
Standards for the MCSP are written in
the complementary directive titled
Mobile Communication Service
Provider Specification of Requirements.)
Goal
OLE seeks to deploy an ‘‘open
system,’’ whereby the fishing industry
participants may select from a variety of
suppliers that qualify and have been
approved to participate in VMS
program. Fishermen must comply with
applicable Federal fishery regulations
regarding VMS and therefore may be
cited for a violation and held
accountable for monitoring anomalies
not attributable to faults in the MCSP or
MTU. Therefore, type approval is
essential to establish and maintain
uniformly high system integrity. By this
directive, OLE seeks to approve reliable,
robust, and secure MTU products and
thereby create and maintain a VMS
meeting the requirement of high
integrity. Specific VMS programs are
created to support particular NMFS
rules requiring the use of VMS, which
typically are designed to manage or
protect fish and other marine species
within designated areas.
Process
Based on a request for type approval
from an MTU supplier and certification
of certain minimal standards, OLE will
conduct a thorough evaluation and then
issue a statement accepting or denying
the type approval of the particular MTU.
An MTU must meet the minimal
national VMS standards, as required by
this directive, and the requirements of
the specific fisheries for which approval
is sought. MTU supplier requesters are
encouraged to review the national VMS
E:\FR\FM\31JAN1.SGM
31JAN1
5814
Federal Register / Vol. 73, No. 21 / Thursday, January 31, 2008 / Notices
standards and NMFS rules requiring the
use of VMS prior to submitting a request
for approval. Upon successful
demonstration of compliance with the
requirements set forth in this directive,
NMFS will issue an MTU type approval
within a particular communications
Class applicable to one or more VMS
operations targeting particular NMFS
rules requiring the use of VMS. OLE
will maintain a current list of type
approved MTU(s), and will forward lists
of type approved MTU(s) to the
respective regional Fisheries
Management Council(s), post the
information on the OLE website and
provide it by fax upon request.
NMFS approval will not necessarily
result in agency procurement of the
MTU. Instead, OLE will request that the
MTU supplier provide a fact sheet to the
fishing industry. The fact sheet will
allow fishermen to make purchase
decisions that are compatible with the
VMS standards and their individual
needs. Purchasing strategies are
determined on a per implementation
basis.
rwilkins on PROD1PC63 with NOTICES
Initiation
OLE will initiate the MTU type
approval process upon written request
from the supplier, subject to the
demonstration of compliance with this
directive and the availability of test
units. The requestor for type approval
may include the manufacturer, or an
OEM/labeler, distributor, and/or reseller
acting as a representative of the
manufacturer. The evaluation may
include consideration if that MTU has
already passed a comparable type
approval process to qualify for use in a
foreign fisheries management effort. If
applicable, the supplier should provide
the MTU’s identifying characteristics,
the details of the foreign VMS
requirement specifications, the MTU’s
level of compliance with them, and
appropriate contact details of the
approving authorities. NMFS also will
consider approving an MTU OEM
(original equipment manufacturer)
model built from an equivalent MTU
that already has received agency type
approval under this directive.
Interoperability
A supplier of an MTU seeking type
approval within a particular
communications class for VMS shall
demonstrate that it meets the standards
when using at least one qualified MCSP
within that same class. The standards in
this directive are intended to ensure that
type approval for a particular MTU will
permit its interoperability with all
qualified MCSPs within its same class.
A class refers to the medium, protocol,
VerDate Aug<31>2005
18:07 Jan 30, 2008
Jkt 214001
and frequency of the mobile
communications technology. Some
examples of existing classes include
Inmarsat-C and Qualcomm/OmniTracs.
To best promote interoperability within
a class, MTU and MCSP acceptance
standards are outlined in separate
directives. However, concurrent with
the approval process for an MTU, the
approval for a same-class MCSP must be
either in place or pending. Data received
by OLE from the MTU via an approved
MCSP must be in a format compatible
with OLE tracking software.
Submission
A supplier of an MTU requesting type
approval shall begin by certifying that
the MTU meets the minimum national
VMS standards as required by this
directive. Suppliers must describe in
detail the extent to which its MTU
complies with each of the requirements
for the VMS implementation of interest
as stated within this directive. The
supplier, or requestor for type approval,
must provide OLE with two MTUs for
each fishery for which application is
made for a minimum of 90-days for
testing and evaluation. The supplier
must also provide thorough MTU
documentation, including fact sheets,
installation guides, operator manuals,
user handbooks, the applicable
interfacing software, and technical
support. OLE shall review the
submissions against the criteria of this
directive. Next, OLE shall perform field
test and sea trials. For this, OLE will
either coordinate test conditions with
volunteer and/or contract fishing
vessels, or contract a third-party to
accomplish this task. The tests may
involve demonstrating every aspect of
MTU operation, including installation
of a registered MTU, location tracking,
messaging, and maintenance
procedures.
Submit requests for type approval,
along with hard and soft copies of
support material to: U.S. Department of
Commerce; National Oceanic and
Atmospheric Administration; National
Marine Fisheries Service; Office for Law
Enforcement; Attention: Vessel
Monitoring System Program; 8484
Georgia Ave. Suite 415; Silver Spring,
MD 20910 USA; voice 301–427–2300;
fax 301–427–0049.
Litigation Support
Due to the use of VMS for law
enforcement, all technical aspects of a
supplier’s submission are subject to
being admitted as evidence in a court of
law, if needed. The reliability of all
technologies utilized in the MTU may
be analyzed in court for, inter alia,
testing procedures, error rates, peer
PO 00000
Frm 00026
Fmt 4703
Sfmt 4703
review, and general industry
acceptance. Further, the supplier may
be required to provide technical and
expert support for a litigation to support
the MTU capabilities to establish OLE’s
case against violators. If the
technologies have previously been
subject to such scrutiny in a court of
law, the supplier should describe the
evidence and any court finding on the
reliability of the technology.
Additionally, to maintain the integrity
of VMS for fisheries management, the
supplier will be required to sign a nondisclosure agreement limiting the
release of certain information that might
compromise the effectiveness of the
VMS operations, such as, but not
limited to, details of anti-tampering
safeguards. The supplier shall include a
statement confirming its agreement with
these conditions.
Change Control
Once an MTU is approved, it is the
supplier’s responsibility to notify OLE
of any substantive change in the original
submission, such as changes to
firmware versions, and customer
support contacts. OLE reserves the right
to reconsider and revoke the MTU
approval if as a result of a change to the
MTU or VMS requirement the unit no
longer satisfies the requirement.
Any modification to the functionality
of an approved MTU including but not
limited to firmware, software, services,
or passwords unless expressly
authorized by NMFS OLE will
invalidate the type approval of the unit
and render it out of compliance with
NMFS rules requiring the use of VMS.
Any addition, deletion or change of the
firmware, software, services, or
passwords of an MTU unless expressly
authorized by NMFS OLE will also
invalidate the type approval of the unit
and render it out of compliance with
NMFS rules requiring the use of VMS.
Fishermen that are determined to be out
of compliance with Federal Fisheries
VMS regulations may be cited for
violations and held accountable for
monitoring anomalies not attributable to
faults in the MCSP or MTU.
Requester
Requesters must respond to each of
the items listed in sections 1 through 6
of this document. The response should
indicate how the requestor complies
with the requirement referred to in the
item. Items that the requestor does not
currently comply with must be
responded to by explaining how the
requestor will comply with the
requirement prior to approval.
E:\FR\FM\31JAN1.SGM
31JAN1
Federal Register / Vol. 73, No. 21 / Thursday, January 31, 2008 / Notices
Section 1. Identifiers
1. 1. Specify the identifying
characteristics of the MTU:
1.1.1. Communications Class.
1.1.2. Manufacturer.
1.1.3. Brand Name.
1.1.4. Model Name.
1.1.5. Model Number.
1.1.6. Software Version Number and
Date.
1.1.7. Firmware Version Number and
Date.
1.1.8. Hardware Version Number and
Date.
1.1.9. Antenna Type.
1.1.10. Antenna Model Number and
Date.
1.1.11. Monitor or terminal Model
Number and Date.
1.1.12. MCSP Providing
Communications Services.
1.2. For the following responsibilities,
name the business entities who act on
behalf of the manufacturer and supplier
applying for type approval. Include the
address, phone, contacts, email, and
designated geographic territory where
applicable.
1.2.1. Manufacturer.
1.2.2. Label or use MTU for an OEM.
This includes re-labeling OEM MTUs or
reselling. Reselling includes valueadded reselling. The MTU that is type
approved is the final, value-added
product and not the original
manufacturer’s MTU, if enhancements
or modifications have been made. For
example, if a transceiver is contained
within an enclosure, it is the new
enclosure including the transceiver that
is being type approved.
1.2.3. Distribute.
1.2.4. Sell.
1.2.5. Bench configures the MTU at
the warehouse or point of supply.
1.2.6. Install MTU onboard the vessel.
1.2.7. Offer limited warranty.
1.2.8. Offer maintenance and service
agreement.
1.2.9. Repair.
1.2.10. Train.
1.2.11. Advertise.
rwilkins on PROD1PC63 with NOTICES
Section 2. Messaging
The MTU must provide the following
messaging functionality:
2.1. Transmit mandatory,
automatically generated position
reports.
2.2. Onboard visible or audible alarms
for malfunctioning of the MTU.
2.3. Ability to disable non-essential
alarms in non-Global Maritime Distress
and Safety System (GMDSS)
installations.
2.4. Ability to provide comprehensive
and transparent communications, which
function uniformly within the entire
VerDate Aug<31>2005
18:07 Jan 30, 2008
Jkt 214001
geographic coverage area for that
communications class.
2.5. Two-way communications
between MCSP and MTU.
2.6. The ability to send and receive
free-form Internet email text messages
and electronic forms.
2.7. All messages should be relayed so
that OLE automatically receives no less
than 97 percent of all messages within
15 minutes or less of the MTU
timestamp and be transparent to the
geographic region.
Section 3. Position Data Formats and
Transmission
3.1. The MTU must provide position
information as required by the
applicable VMS rule in addition to:
3.1.1. Position fixes latitude and
longitude, including the hemisphere of
each.
3.1.2. The position fix precision must
be to the decimal minute hundredths.
3.1.3. Accuracy of the reported
position must be within 100 meters,
unless otherwise indicated by an
existing regulation or VMS requirement.
3.1.4. Communications between MTU
and MCSP must be secure from
tampering or interception, including the
reading of passwords and data.
Therefore, the MTU must have
mechanisms to prevent to the extent
possible:
3.1.4.1. Interception and ‘‘sniffing’’
during transmission from the MTU to
MCSP via either wireless or terrestrial
facilities.
3.1.4.2. Spoofing, whereby one MTU
is fraudulently identifying itself as
another MTU.
3.1.4.3. Modification of MTU
identification.
3.1.4.4. Interference with GMDSS or
other safety/distress functions.
3.1.4.5. Introduction of viruses that
may corrupt, disturb, or disrupt
messages, transmission, or the VMS
system.
3.1.4.6. Introduction of software
modifications through the use of input/
output devices. Item such as CDDVD
readers or writers should be removed,
physically disabled, or rendered
inaccessible, ports and connections not
directly used for connecting to the VMS
device or authorized peripherals should
be removed or permanently sealed.
3.2. MTU shall provide the ability to
meet minimum reporting requirements
and intervals as required for specific
NMFS rules requiring the use of VMS.
3.2.1. Provide automatically generated
position reporting, for vessels managed
individually or grouped by fleet, such
that OLE automatically receives no less
than 97 percent of the position reports
sent at defined intervals within 15
PO 00000
Frm 00027
Fmt 4703
Sfmt 4703
5815
minutes or less of the MTU timestamp
and be transparent to the geographic
region.
3.2.2. Have the ability to store 100
position fixes in local, non-volatile
memory.
3.2.3. Allow for defining variable
reporting intervals between 5 minutes
and 24 hours.
3.2.4. MTU must be able to change
reporting intervals remotely, and only
by authorized users.
3.3. An MTU must be able to transmit
automatically generated position
reports, which contain the following:
3.3.1. Unique identification of an
MTU within the communications class.
3.3.2. Date (year/month/day with
century in the year) and time (GMT)
stamp of the position fix.
3.4. In addition to automatically
generated position reports, specially
identified position reports shall be
generated upon:
3.4.1. Antenna disconnection
3.4.2. Loss of the positioning
reference signals.
3.4.3. Loss of the mobile
communications signals.
3.4.4. Security events, power-up,
power-down, and other status data.
3.4.5. The vessel crossing a predefined geographic boundary.
3.4.6. MTU status information such as
configuration of programming and
reporting intervals.
3.4.7. When an MTU is powered up,
it must automatically re-establish its
position reporting function without
manual intervention.
Section 4. Text Messaging
4.1.1. Text messaging from vessel to
shore with a minimum supported
message length of 1kb.
4.1.2. User interface must support an
’address book’ capability and a function
permitting a ‘‘reply’’ to a received
message without re-entry of the senders
e-mail address.
4.1.3. A confirmation of delivery
function is required such that a user can
ascertain whether a specific message
was successfully transmitted via the
satellite system to the MCSP e-mail
server(s).
4.1.4. Onward delivery to NMFS must
be reliable and make use of features
such as SMTP retries and delivery
confirmation to ensure a reliable
transport path exists for text messages
sent from the vessel to NMFS.
4.1.5. The user interface must provide
the ability to review by date order, or by
recipient, messages that were previously
sent. The terminal must support a
minimum message history of 20
messages - commonly referred to as an
‘‘Outbox’’ or ‘‘Sent’’ messages display.
E:\FR\FM\31JAN1.SGM
31JAN1
rwilkins on PROD1PC63 with NOTICES
5816
Federal Register / Vol. 73, No. 21 / Thursday, January 31, 2008 / Notices
4.1.6. Text messaging from shore to
vessel with a minimum supported
message length of 1kb.
4.1.7. The user interface must provide
the ability to review by date order, or by
sender, all messages received. The
terminal must support a minimum
message history of 20 messagescommonly referred to as an ‘‘Inbox’’.
4.1.8. Negative delivery notifications
must be sent to the originator where
delivery to the terminal could not be
completed for any reason. Such Non
Delivery Notification must include
sufficient information to uniquely
identify the message that failed and the
cause of failure (i.e., mobile number
invalid, mobile switched off etc.).
4.2. Electronic Forms
Pre-formatted messages are required
for the collection of validated data for
specific fisheries programs (i.e.,
declaration systems, catch effort
reporting). This capability is referred to
as Electronic Forms. The E-MTU must
support a minimum of 20 Forms,
selectable by the user from a menu.
Forms must be able to be updated over
the air. Copies of forms currently used
by NMFS are available upon request.
From time to time NMFS will provide
all E-MTU approved vendors with
updates defining new forms or
modifying existing forms. Such notice
will be at least 60 (sixty) days prior to
the implementation date for the new or
changed form. Vendors will be
responsible for translating the
requirements into MTU specific forms
definitions and transmitting the same to
all VMS terminals supplied to fishing
vessels. All forms software provided
with the E-MTU must be capable of
supporting the requirements described
in this specification. Additional
capabilities beyond those stated here are
acceptable, provided that the minimum
requirements are satisfied.
4.2.1. A form is defined as: (a) 1–40
characters describing the form, (b)
Delivery address (i.e., e-mail or other
network identifier), (c) Form number as
defined by NMFS to uniquely identify
the form, (d) Form version number
(numeric with one decimal place; i.e.,
1.2), and (e) a collection of 1–30 fields
and associated logic rules.
4.2.2. Each field (within a form) is
defined by the following elements.
Except where noted, all elements of the
field definition are mandatory: (a) Label
(0 to 40 characters, alpha numeric), (b)
Context Help Text (0 to 200 characters,
alpha numeric), (c)Type (Either;
enumeration, numeric, alpha,
alphanumeric or Boolean), (d) Default
Value, (e) Optional/Mandatory/Hidden/
Logic indicator, (f) Min/Max values (for
numeric fields only) in range 0.000 to
VerDate Aug<31>2005
18:07 Jan 30, 2008
Jkt 214001
999,999, (g) Decimal places (for numeric
fields only) 0–3, and (h) Min/Max
characters (for alpha/alphanumeric
fields only).
4.2.3. Up to 100 code/value/help text
pairs (enumerations only) must be
provided, where codes are defined as 1–
20 alphanumeric characters, values are
1–80 alphanumeric characters and help
text is 0–200 characters. Such fields are
typically used to permit a user to select
from a range of options (i.e., geographic
areas, gear types, fish species). Codes
are used to compress the form data for
efficient transmission. Help text would
typically be displayed only when the
user selects a specific value from the
enumeration.
4.2.4. Form Validation: Each field
must be defined as; Optional,
Mandatory or Logic Driven. Mandatory
fields must be entered by the user before
the form is complete, optional fields
that do not require data entry, and logic
driven fields have their attributes
determined by earlier form selections.
Specifically; it must be possible for
selection of an enumeration to change
the optional/mandatory setting, min/
max values, or the permitted
enumeration values on a later field
within the same form.
4.2.5. State Information: The
capability to populate a form based on
the last values used must be available.
This provides the user with an easy
mechanism to ‘‘modify’’ or ‘‘update’’ a
prior submission - without unnecessary
re-entry of data. The user must be able
to review a minimum of 20 past form
submissions and ascertain for each form
when the form was transmitted and
whether delivery was successfully
completed to the vendor’s processing
center. In the case of a transmission
failure, the user must be provided with
details of the cause and have the
opportunity to retry the form
submission.
4.2.6. Inclusion of VMS Position
Report: In addition to the manually
entered fields, the forms package must
permit the inclusion of VMS position
report fields such as latitude, longitude,
date and time. Such fields must be
obtained from the GPS function of the
MTU and transmitted along with the
manually entered form data within the
same transaction.
4.2.7. Delivery Format for Form Data:
It is preferred that form data be
transferred from the terminal to NMFS
using the same transport as for either
text messages or VMS position reports
(the selected option to be at the election
of the E-MTU vendor). Currently
supported protocols for transfer are;
FTP, SMTP, XML and HTTP Post. The
SMTP protocol is not permitted for the
PO 00000
Frm 00028
Fmt 4703
Sfmt 4703
transmission of data sent to the OLE.
The field coding within the data must
follow either CSV or XML formatting
rules. For CSV format the form must
contain an identifier and the version
number, and then the fields in the order
defined on the form. In the CSV format
strings that may contain ’’,’’ (comma)
characters must be quoted. XML
representations must use the field label
to define the XML element that contains
each field value.
Section 5. Customer Service
The MTU supplier or its designated
entities shall provide customer service
that is professional, courteous, and
responsive. It should provide MTU
diagnostic and troubleshooting support
to OLE and the fishermen. No services
shall be billed to any NOAA or any OLE
office without being specifically
contracted for in writing by an
authorized entity. Services shall
include:
5.1. Service level, warranty, and
maintenance agreements. Clarify
constraints, if any, on the geographic
territory, personnel availability, and
escalation procedures for problem
resolution covered by such services.
5.2. Facilities and procedures in place
to assist the fisherman in maintaining
and repairing their MTU on a 24 hour
basis, including timely responses to
requests, and general system service
turnaround time.
5.3. Help in the determination and
isolation of the cause of
communications anomalies.
5.4. Assist in the resolution of
communications anomalies that are
traced to the MTU.
5.5. All services will be considered to
be free of charge unless specifically
listed in service or purchase agreements.
Section 6. Other Information
6.1. The MTU must have the
durability and reliability necessary to
provide acceptable service in a marine
environment where the unit may be
subjected to saltwater (spray) in smaller
vessels, and in larger vessels where the
unit may be maintained in a
wheelhouse. The unit, cabling and
antenna must be resistant to moisture
and shock associate with the marine
environments.
6.2. The MTU must comply with any
additional requirements specified in the
regulations for the VMS implementation
for which application is made. The
requestor must review the applicable
NMFS rules requiring the use of VMS
and respond here to any specific
requirements listed therein.
6.3. All personally identifying
information provided by vessels owners
E:\FR\FM\31JAN1.SGM
31JAN1
Federal Register / Vol. 73, No. 21 / Thursday, January 31, 2008 / Notices
or other authorized personnel for the
purchase or activation of MTU or EMTU, or for the participation in any
NMFS VMS-approved fishery must be
protected from unauthorized disclosure.
Personally identifying information
includes, but is not limited to, names,
addresses, telephone numbers, social
security account numbers, credit card
numbers, vessel names, federal, state,
and local documentation numbers, email addresses, and crew lists. Any
information sent electronically to the
OLE must be transmitted by a secure
means that prevents interception,
spoofing, or viewing by unauthorized
individuals. Any release of such
information must be requested and
approved in writing by the vessel
owner, authorized personnel, or the
OLE. Inadvertent or intentional
unauthorized release of personally
identifying information will be grounds
for reconsideration and possible
revocation of the type approval for any
MTU supplied by the offending
provider.
Dated: January 25, 2008.
Samuel D. Rauch III
Deputy Assistant Administrator for
Regulatory Programs, National Marine
Fisheries Service.
[FR Doc. E8–1662 Filed 1–30–08; 8:45 am]
BILLING CODE 3510–22–S
DEPARTMENT OF COMMERCE
Patent and Trademark Office
rwilkins on PROD1PC63 with NOTICES
Submission for OMB Review;
Comment Request
The United States Patent and
Trademark Office (USPTO) will submit
to the Office of Management and Budget
(OMB) for clearance the following
proposal for collection of information
under the provisions of the Paperwork
Reduction Act (44 U.S.C. Chapter 35).
Agency: United States Patent and
Trademark Office (USPTO).
Title: Post Registration (Trademark
Processing).
Form Number(s): PTO–1583, PTO/
TM/1583, PTO–1597, PTO–1963, PTO–
4.16, PTO/TM/4.16.
Agency Approval Number: 0651–
0055.
Type of Request: Revision of a
currently approved collection.
Burden: 21,097 hours annually,
including 1,349 hours per year for
Section 7 Requests.
Number of Respondents: 133,587
responses per year, including 3,800
responses per year for Section 7
Requests.
Avg. Hours Per Response: The USPTO
estimates that the public will require
VerDate Aug<31>2005
18:07 Jan 30, 2008
Jkt 214001
approximately 20 to 23 minutes (0.33 to
0.38 hours) to supply the information
required for a Section 7 Request,
depending upon the amount and type of
information requested in a particular
case.
Needs and Uses: This collection of
information is required by the
Trademark Act, 15 U.S.C. 1051 et seq.,
which provides for the Federal
registration of trademarks, service
marks, collective trademarks and service
marks, collective membership marks,
and certification marks. Individuals and
businesses that use or intend to use
such marks in commerce may file an
application to register their marks with
the United States Patent and Trademark
Office (USPTO). Such individuals and
businesses may also submit various
communications to the USPTO,
including requests to correct or amend
their registrations.
The USPTO is proposing to add one
form to this information collection for
Section 7 Requests (PTO–1597).
Registrants may use a Section 7 Request
to request a correction or amendment to
the information appearing on the
certificate of registration. Requests for
changes that would result in a material
alteration of the registration are not
permitted under Section 7. Registrants
may submit the proposed new form to
the USPTO electronically through the
USPTO Web site or submit the required
information for the Section 7 Request to
the USPTO on paper.
Affected Public: Individuals or
households, businesses or other forprofits, and not-for-profit institutions.
Frequency: On occasion.
Respondent’s Obligation: Required to
obtain or retain benefits.
OMB Desk Officer: David Rostker,
(202) 395–3897.
Copies of the above information
collection proposal can be obtained by
any of the following methods:
• E-mail: Susan.Fawcett@uspto.gov.
Include ‘‘0651–0055 copy request’’ in
the subject line of the message.
• Fax: 571–273–0112, marked to the
attention of Susan Fawcett.
• Mail: Susan K. Fawcett, Records
Officer, Office of the Chief Information
Officer, Customer Information Services
Group, Public Information Services
Division, United States Patent and
Trademark Office, P.O. Box 1450,
Alexandria, VA 22313–1450.
Written comments and
recommendations for the proposed
information collection should be sent on
or before March 3, 2008 to David
Rostker, OMB Desk Officer, Room
10202, New Executive Office Building,
725 17th Street, NW., Washington, DC
20503.
PO 00000
Frm 00029
Fmt 4703
Sfmt 4703
5817
Dated: January 24, 2008.
Susan K. Fawcett,
Records Officer, USPTO, Office of the Chief
Information Officer, Customer Information
Services Group, Public Information Services
Division.
[FR Doc. E8–1727 Filed 1–30–08; 8:45 am]
BILLING CODE 3510–16–P
COMMODITY FUTURES TRADING
COMMISSION
Sunshine Act Meetings
1 p.m., Wednesday,
March 5, 2008.
PLACE: 1155 21st St., NW., Washington,
DC, 9th Floor Commission Conference
Room.
STATUS: Closed.
MATTERS TO BE CONSIDERED: Rule
Enforcement Review.
CONTACT PERSON FOR MORE INFORMATION:
Sauntia S. Warfield, 202–418–5084.
TIME AND DATE:
David A. Stawick,
Secretary of the Commission.
[FR Doc. 08–456 Filed 1–29–08; 1:03 pm]
BILLING CODE 6351–01–P
DEPARTMENT OF DEFENSE
Office of the Secretary
[DoD–2008–OS–0004]
Privacy Act of 1974; System of
Records
Office of the Secretary, DoD.
Notice to amend two systems of
AGENCY:
ACTION:
records.
SUMMARY: The Office of the Secretary of
Defense is amending two systems of
records notices in its existing inventory
of record systems subject to the Privacy
Act of 1974, (5 U.S.C. 552a), as
amended.
This proposed action will be
effective without further notice on
March 3, 2008, unless comments are
received which result in a contrary
determination.
DATES:
Send comments to the OSD
Privacy Act Coordinator, Records
Management Section, Washington
Headquarters Services, 1155 Defense
Pentagon, Washington, DC 20301–1155.
FOR FURTHER INFORMATION CONTACT: Ms.
Cindy Allard at (703) 588–2386.
SUPPLEMENTARY INFORMATION: The Office
of the Secretary of Defense systems of
records notices subject to the Privacy
Act of 1974, (5 U.S.C. 552a), as
amended, have been published in the
ADDRESSES:
E:\FR\FM\31JAN1.SGM
31JAN1
Agencies
[Federal Register Volume 73, Number 21 (Thursday, January 31, 2008)]
[Notices]
[Pages 5813-5817]
From the Federal Register Online via the Government Printing Office [www.gpo.gov]
[FR Doc No: E8-1662]
-----------------------------------------------------------------------
DEPARTMENT OF COMMERCE
National Oceanic and Atmospheric Administration
RIN 0648-XF16
Vessel Monitoring Systems; Specification of Requirements for
Mobile Transmitting Unit Type Approval
AGENCY: National Marine Fisheries Service (NMFS), National Oceanic and
Atmospheric Administration (NOAA), Commerce.
ACTION: Revision of type approval requirements for mobile transmitting
units.
-----------------------------------------------------------------------
SUMMARY: This document provides notice of type approval requirements
for Mobile Transmitting Units (MTU) to be authorized for use on any
vessel participating in the NOAA Vessel Monitoring System (VMS)
program. Vessels participating in VMS program must acquire an NMFS-
approved MTU to comply with VMS standards set forth in NMFS rules
requiring the use of VMS.
ADDRESSES: To obtain copies of the list of NMFS-approved VMS MTU and
VMS communications service providers, or to obtain information
regarding the status of VMS systems being evaluated by NOAA, write to
NOAA Fisheries, Office for Law Enforcement (OLE), 8484 Georgia Avenue,
Suite 415, Silver Spring, MD 20910.
FOR FURTHER INFORMATION CONTACT: For current listing information
contact the VMS Support Center by phone: 888-210-9228, or by fax: 301-
427-0049 or for questions regarding VMS installation and status of
evaluations contact Jonathan Pinkerton, National VMS Program Manager by
phone: 301 427 2300 or by fax: 301-427-0049.
SUPPLEMENTARY INFORMATION: This notice supersedes all previous notices
on MTU type approval requirements. Previously installed MTU approved
under prior notices will continue to be approved for the remainder of
their service life. New installations of a previously approved MTU
occurring 120 days or more after the publication date of this notice
must comply with all of the requirements herein. All new requests for
type approval must comply with all of the requirements herein.
Background
The Department of Commerce, National Oceanic and Atmospheric
Administration, National Marine Fisheries Service, Office for Law
Enforcement (OLE) maintains MTU specification requirements as an OLE
National Directive. This notice sets prerequisite standards for the
purpose of type approval that must be met by an MTU and any associated
software before it is authorized for use in the NOAA VMS program.
Vessels participating in VMS program must acquire an NMFS-approved MTU
to comply with the specific VMS standards set forth in NMFS rules
requiring the use of VMS. The MTU is a transceiver or communications
device, including antennae, dedicated message terminal and display, and
an input device such as a keyboard installed on fishing vessels
participating in the VMS requirement. The MTU allows OLE to determine
the geographic position of the vessel during specified intervals or
events. In addition, it enables mobile communications services between
OLE and the vessel when using an NMFS-accepted Mobile Communication
Service Provider (MCSP). (Note: Standards for the MCSP are written in
the complementary directive titled Mobile Communication Service
Provider Specification of Requirements.)
Goal
OLE seeks to deploy an ``open system,'' whereby the fishing
industry participants may select from a variety of suppliers that
qualify and have been approved to participate in VMS program. Fishermen
must comply with applicable Federal fishery regulations regarding VMS
and therefore may be cited for a violation and held accountable for
monitoring anomalies not attributable to faults in the MCSP or MTU.
Therefore, type approval is essential to establish and maintain
uniformly high system integrity. By this directive, OLE seeks to
approve reliable, robust, and secure MTU products and thereby create
and maintain a VMS meeting the requirement of high integrity. Specific
VMS programs are created to support particular NMFS rules requiring the
use of VMS, which typically are designed to manage or protect fish and
other marine species within designated areas.
Process
Based on a request for type approval from an MTU supplier and
certification of certain minimal standards, OLE will conduct a thorough
evaluation and then issue a statement accepting or denying the type
approval of the particular MTU. An MTU must meet the minimal national
VMS standards, as required by this directive, and the requirements of
the specific fisheries for which approval is sought. MTU supplier
requesters are encouraged to review the national VMS
[[Page 5814]]
standards and NMFS rules requiring the use of VMS prior to submitting a
request for approval. Upon successful demonstration of compliance with
the requirements set forth in this directive, NMFS will issue an MTU
type approval within a particular communications Class applicable to
one or more VMS operations targeting particular NMFS rules requiring
the use of VMS. OLE will maintain a current list of type approved
MTU(s), and will forward lists of type approved MTU(s) to the
respective regional Fisheries Management Council(s), post the
information on the OLE website and provide it by fax upon request.
NMFS approval will not necessarily result in agency procurement of
the MTU. Instead, OLE will request that the MTU supplier provide a fact
sheet to the fishing industry. The fact sheet will allow fishermen to
make purchase decisions that are compatible with the VMS standards and
their individual needs. Purchasing strategies are determined on a per
implementation basis.
Initiation
OLE will initiate the MTU type approval process upon written
request from the supplier, subject to the demonstration of compliance
with this directive and the availability of test units. The requestor
for type approval may include the manufacturer, or an OEM/labeler,
distributor, and/or reseller acting as a representative of the
manufacturer. The evaluation may include consideration if that MTU has
already passed a comparable type approval process to qualify for use in
a foreign fisheries management effort. If applicable, the supplier
should provide the MTU's identifying characteristics, the details of
the foreign VMS requirement specifications, the MTU's level of
compliance with them, and appropriate contact details of the approving
authorities. NMFS also will consider approving an MTU OEM (original
equipment manufacturer) model built from an equivalent MTU that already
has received agency type approval under this directive.
Interoperability
A supplier of an MTU seeking type approval within a particular
communications class for VMS shall demonstrate that it meets the
standards when using at least one qualified MCSP within that same
class. The standards in this directive are intended to ensure that type
approval for a particular MTU will permit its interoperability with all
qualified MCSPs within its same class. A class refers to the medium,
protocol, and frequency of the mobile communications technology. Some
examples of existing classes include Inmarsat-C and Qualcomm/OmniTracs.
To best promote interoperability within a class, MTU and MCSP
acceptance standards are outlined in separate directives. However,
concurrent with the approval process for an MTU, the approval for a
same-class MCSP must be either in place or pending. Data received by
OLE from the MTU via an approved MCSP must be in a format compatible
with OLE tracking software.
Submission
A supplier of an MTU requesting type approval shall begin by
certifying that the MTU meets the minimum national VMS standards as
required by this directive. Suppliers must describe in detail the
extent to which its MTU complies with each of the requirements for the
VMS implementation of interest as stated within this directive. The
supplier, or requestor for type approval, must provide OLE with two
MTUs for each fishery for which application is made for a minimum of
90-days for testing and evaluation. The supplier must also provide
thorough MTU documentation, including fact sheets, installation guides,
operator manuals, user handbooks, the applicable interfacing software,
and technical support. OLE shall review the submissions against the
criteria of this directive. Next, OLE shall perform field test and sea
trials. For this, OLE will either coordinate test conditions with
volunteer and/or contract fishing vessels, or contract a third-party to
accomplish this task. The tests may involve demonstrating every aspect
of MTU operation, including installation of a registered MTU, location
tracking, messaging, and maintenance procedures.
Submit requests for type approval, along with hard and soft copies
of support material to: U.S. Department of Commerce; National Oceanic
and Atmospheric Administration; National Marine Fisheries Service;
Office for Law Enforcement; Attention: Vessel Monitoring System
Program; 8484 Georgia Ave. Suite 415; Silver Spring, MD 20910 USA;
voice 301-427-2300; fax 301-427-0049.
Litigation Support
Due to the use of VMS for law enforcement, all technical aspects of
a supplier's submission are subject to being admitted as evidence in a
court of law, if needed. The reliability of all technologies utilized
in the MTU may be analyzed in court for, inter alia, testing
procedures, error rates, peer review, and general industry acceptance.
Further, the supplier may be required to provide technical and expert
support for a litigation to support the MTU capabilities to establish
OLE's case against violators. If the technologies have previously been
subject to such scrutiny in a court of law, the supplier should
describe the evidence and any court finding on the reliability of the
technology. Additionally, to maintain the integrity of VMS for
fisheries management, the supplier will be required to sign a non-
disclosure agreement limiting the release of certain information that
might compromise the effectiveness of the VMS operations, such as, but
not limited to, details of anti-tampering safeguards. The supplier
shall include a statement confirming its agreement with these
conditions.
Change Control
Once an MTU is approved, it is the supplier's responsibility to
notify OLE of any substantive change in the original submission, such
as changes to firmware versions, and customer support contacts. OLE
reserves the right to reconsider and revoke the MTU approval if as a
result of a change to the MTU or VMS requirement the unit no longer
satisfies the requirement.
Any modification to the functionality of an approved MTU including
but not limited to firmware, software, services, or passwords unless
expressly authorized by NMFS OLE will invalidate the type approval of
the unit and render it out of compliance with NMFS rules requiring the
use of VMS. Any addition, deletion or change of the firmware, software,
services, or passwords of an MTU unless expressly authorized by NMFS
OLE will also invalidate the type approval of the unit and render it
out of compliance with NMFS rules requiring the use of VMS. Fishermen
that are determined to be out of compliance with Federal Fisheries VMS
regulations may be cited for violations and held accountable for
monitoring anomalies not attributable to faults in the MCSP or MTU.
Requester
Requesters must respond to each of the items listed in sections 1
through 6 of this document. The response should indicate how the
requestor complies with the requirement referred to in the item. Items
that the requestor does not currently comply with must be responded to
by explaining how the requestor will comply with the requirement prior
to approval.
[[Page 5815]]
Section 1. Identifiers
1. 1. Specify the identifying characteristics of the MTU:
1.1.1. Communications Class.
1.1.2. Manufacturer.
1.1.3. Brand Name.
1.1.4. Model Name.
1.1.5. Model Number.
1.1.6. Software Version Number and Date.
1.1.7. Firmware Version Number and Date.
1.1.8. Hardware Version Number and Date.
1.1.9. Antenna Type.
1.1.10. Antenna Model Number and Date.
1.1.11. Monitor or terminal Model Number and Date.
1.1.12. MCSP Providing Communications Services.
1.2. For the following responsibilities, name the business entities
who act on behalf of the manufacturer and supplier applying for type
approval. Include the address, phone, contacts, email, and designated
geographic territory where applicable.
1.2.1. Manufacturer.
1.2.2. Label or use MTU for an OEM. This includes re-labeling OEM
MTUs or reselling. Reselling includes value-added reselling. The MTU
that is type approved is the final, value-added product and not the
original manufacturer's MTU, if enhancements or modifications have been
made. For example, if a transceiver is contained within an enclosure,
it is the new enclosure including the transceiver that is being type
approved.
1.2.3. Distribute.
1.2.4. Sell.
1.2.5. Bench configures the MTU at the warehouse or point of
supply.
1.2.6. Install MTU onboard the vessel.
1.2.7. Offer limited warranty.
1.2.8. Offer maintenance and service agreement.
1.2.9. Repair.
1.2.10. Train.
1.2.11. Advertise.
Section 2. Messaging
The MTU must provide the following messaging functionality:
2.1. Transmit mandatory, automatically generated position reports.
2.2. Onboard visible or audible alarms for malfunctioning of the
MTU.
2.3. Ability to disable non-essential alarms in non-Global Maritime
Distress and Safety System (GMDSS) installations.
2.4. Ability to provide comprehensive and transparent
communications, which function uniformly within the entire geographic
coverage area for that communications class.
2.5. Two-way communications between MCSP and MTU.
2.6. The ability to send and receive free-form Internet email text
messages and electronic forms.
2.7. All messages should be relayed so that OLE automatically
receives no less than 97 percent of all messages within 15 minutes or
less of the MTU timestamp and be transparent to the geographic region.
Section 3. Position Data Formats and Transmission
3.1. The MTU must provide position information as required by the
applicable VMS rule in addition to:
3.1.1. Position fixes latitude and longitude, including the
hemisphere of each.
3.1.2. The position fix precision must be to the decimal minute
hundredths.
3.1.3. Accuracy of the reported position must be within 100 meters,
unless otherwise indicated by an existing regulation or VMS
requirement.
3.1.4. Communications between MTU and MCSP must be secure from
tampering or interception, including the reading of passwords and data.
Therefore, the MTU must have mechanisms to prevent to the extent
possible:
3.1.4.1. Interception and ``sniffing'' during transmission from the
MTU to MCSP via either wireless or terrestrial facilities.
3.1.4.2. Spoofing, whereby one MTU is fraudulently identifying
itself as another MTU.
3.1.4.3. Modification of MTU identification.
3.1.4.4. Interference with GMDSS or other safety/distress
functions.
3.1.4.5. Introduction of viruses that may corrupt, disturb, or
disrupt messages, transmission, or the VMS system.
3.1.4.6. Introduction of software modifications through the use of
input/output devices. Item such as CDDVD readers or writers should be
removed, physically disabled, or rendered inaccessible, ports and
connections not directly used for connecting to the VMS device or
authorized peripherals should be removed or permanently sealed.
3.2. MTU shall provide the ability to meet minimum reporting
requirements and intervals as required for specific NMFS rules
requiring the use of VMS.
3.2.1. Provide automatically generated position reporting, for
vessels managed individually or grouped by fleet, such that OLE
automatically receives no less than 97 percent of the position reports
sent at defined intervals within 15 minutes or less of the MTU
timestamp and be transparent to the geographic region.
3.2.2. Have the ability to store 100 position fixes in local, non-
volatile memory.
3.2.3. Allow for defining variable reporting intervals between 5
minutes and 24 hours.
3.2.4. MTU must be able to change reporting intervals remotely, and
only by authorized users.
3.3. An MTU must be able to transmit automatically generated
position reports, which contain the following:
3.3.1. Unique identification of an MTU within the communications
class.
3.3.2. Date (year/month/day with century in the year) and time
(GMT) stamp of the position fix.
3.4. In addition to automatically generated position reports,
specially identified position reports shall be generated upon:
3.4.1. Antenna disconnection
3.4.2. Loss of the positioning reference signals.
3.4.3. Loss of the mobile communications signals.
3.4.4. Security events, power-up, power-down, and other status
data.
3.4.5. The vessel crossing a pre-defined geographic boundary.
3.4.6. MTU status information such as configuration of programming
and reporting intervals.
3.4.7. When an MTU is powered up, it must automatically re-
establish its position reporting function without manual intervention.
Section 4. Text Messaging
4.1.1. Text messaging from vessel to shore with a minimum supported
message length of 1kb.
4.1.2. User interface must support an 'address book' capability and
a function permitting a ``reply'' to a received message without re-
entry of the senders e-mail address.
4.1.3. A confirmation of delivery function is required such that a
user can ascertain whether a specific message was successfully
transmitted via the satellite system to the MCSP e-mail server(s).
4.1.4. Onward delivery to NMFS must be reliable and make use of
features such as SMTP retries and delivery confirmation to ensure a
reliable transport path exists for text messages sent from the vessel
to NMFS.
4.1.5. The user interface must provide the ability to review by
date order, or by recipient, messages that were previously sent. The
terminal must support a minimum message history of 20 messages -
commonly referred to as an ``Outbox'' or ``Sent'' messages display.
[[Page 5816]]
4.1.6. Text messaging from shore to vessel with a minimum supported
message length of 1kb.
4.1.7. The user interface must provide the ability to review by
date order, or by sender, all messages received. The terminal must
support a minimum message history of 20 messages-commonly referred to
as an ``Inbox''.
4.1.8. Negative delivery notifications must be sent to the
originator where delivery to the terminal could not be completed for
any reason. Such Non Delivery Notification must include sufficient
information to uniquely identify the message that failed and the cause
of failure (i.e., mobile number invalid, mobile switched off etc.).
4.2. Electronic Forms
Pre-formatted messages are required for the collection of validated
data for specific fisheries programs (i.e., declaration systems, catch
effort reporting). This capability is referred to as Electronic Forms.
The E-MTU must support a minimum of 20 Forms, selectable by the user
from a menu. Forms must be able to be updated over the air. Copies of
forms currently used by NMFS are available upon request. From time to
time NMFS will provide all E-MTU approved vendors with updates defining
new forms or modifying existing forms. Such notice will be at least 60
(sixty) days prior to the implementation date for the new or changed
form. Vendors will be responsible for translating the requirements into
MTU specific forms definitions and transmitting the same to all VMS
terminals supplied to fishing vessels. All forms software provided with
the E-MTU must be capable of supporting the requirements described in
this specification. Additional capabilities beyond those stated here
are acceptable, provided that the minimum requirements are satisfied.
4.2.1. A form is defined as: (a) 1-40 characters describing the
form, (b) Delivery address (i.e., e-mail or other network identifier),
(c) Form number as defined by NMFS to uniquely identify the form, (d)
Form version number (numeric with one decimal place; i.e., 1.2), and
(e) a collection of 1-30 fields and associated logic rules.
4.2.2. Each field (within a form) is defined by the following
elements. Except where noted, all elements of the field definition are
mandatory: (a) Label (0 to 40 characters, alpha numeric), (b) Context
Help Text (0 to 200 characters, alpha numeric), (c)Type (Either;
enumeration, numeric, alpha, alphanumeric or Boolean), (d) Default
Value, (e) Optional/Mandatory/Hidden/ Logic indicator, (f) Min/Max
values (for numeric fields only) in range 0.000 to 999,999, (g) Decimal
places (for numeric fields only) 0-3, and (h) Min/Max characters (for
alpha/alphanumeric fields only).
4.2.3. Up to 100 code/value/help text pairs (enumerations only)
must be provided, where codes are defined as 1-20 alphanumeric
characters, values are 1-80 alphanumeric characters and help text is 0-
200 characters. Such fields are typically used to permit a user to
select from a range of options (i.e., geographic areas, gear types,
fish species). Codes are used to compress the form data for efficient
transmission. Help text would typically be displayed only when the user
selects a specific value from the enumeration.
4.2.4. Form Validation: Each field must be defined as; Optional,
Mandatory or Logic Driven. Mandatory fields must be entered by the user
before the form is complete, optional fields that do not require data
entry, and logic driven fields have their attributes determined by
earlier form selections. Specifically; it must be possible for
selection of an enumeration to change the optional/mandatory setting,
min/ max values, or the permitted enumeration values on a later field
within the same form.
4.2.5. State Information: The capability to populate a form based
on the last values used must be available. This provides the user with
an easy mechanism to ``modify'' or ``update'' a prior submission -
without unnecessary re-entry of data. The user must be able to review a
minimum of 20 past form submissions and ascertain for each form when
the form was transmitted and whether delivery was successfully
completed to the vendor's processing center. In the case of a
transmission failure, the user must be provided with details of the
cause and have the opportunity to retry the form submission.
4.2.6. Inclusion of VMS Position Report: In addition to the
manually entered fields, the forms package must permit the inclusion of
VMS position report fields such as latitude, longitude, date and time.
Such fields must be obtained from the GPS function of the MTU and
transmitted along with the manually entered form data within the same
transaction.
4.2.7. Delivery Format for Form Data: It is preferred that form
data be transferred from the terminal to NMFS using the same transport
as for either text messages or VMS position reports (the selected
option to be at the election of the E-MTU vendor). Currently supported
protocols for transfer are; FTP, SMTP, XML and HTTP Post. The SMTP
protocol is not permitted for the transmission of data sent to the OLE.
The field coding within the data must follow either CSV or XML
formatting rules. For CSV format the form must contain an identifier
and the version number, and then the fields in the order defined on the
form. In the CSV format strings that may contain '','' (comma)
characters must be quoted. XML representations must use the field label
to define the XML element that contains each field value.
Section 5. Customer Service
The MTU supplier or its designated entities shall provide customer
service that is professional, courteous, and responsive. It should
provide MTU diagnostic and troubleshooting support to OLE and the
fishermen. No services shall be billed to any NOAA or any OLE office
without being specifically contracted for in writing by an authorized
entity. Services shall include:
5.1. Service level, warranty, and maintenance agreements. Clarify
constraints, if any, on the geographic territory, personnel
availability, and escalation procedures for problem resolution covered
by such services.
5.2. Facilities and procedures in place to assist the fisherman in
maintaining and repairing their MTU on a 24 hour basis, including
timely responses to requests, and general system service turnaround
time.
5.3. Help in the determination and isolation of the cause of
communications anomalies.
5.4. Assist in the resolution of communications anomalies that are
traced to the MTU.
5.5. All services will be considered to be free of charge unless
specifically listed in service or purchase agreements.
Section 6. Other Information
6.1. The MTU must have the durability and reliability necessary to
provide acceptable service in a marine environment where the unit may
be subjected to saltwater (spray) in smaller vessels, and in larger
vessels where the unit may be maintained in a wheelhouse. The unit,
cabling and antenna must be resistant to moisture and shock associate
with the marine environments.
6.2. The MTU must comply with any additional requirements specified
in the regulations for the VMS implementation for which application is
made. The requestor must review the applicable NMFS rules requiring the
use of VMS and respond here to any specific requirements listed
therein.
6.3. All personally identifying information provided by vessels
owners
[[Page 5817]]
or other authorized personnel for the purchase or activation of MTU or
E-MTU, or for the participation in any NMFS VMS-approved fishery must
be protected from unauthorized disclosure. Personally identifying
information includes, but is not limited to, names, addresses,
telephone numbers, social security account numbers, credit card
numbers, vessel names, federal, state, and local documentation numbers,
e-mail addresses, and crew lists. Any information sent electronically
to the OLE must be transmitted by a secure means that prevents
interception, spoofing, or viewing by unauthorized individuals. Any
release of such information must be requested and approved in writing
by the vessel owner, authorized personnel, or the OLE. Inadvertent or
intentional unauthorized release of personally identifying information
will be grounds for reconsideration and possible revocation of the type
approval for any MTU supplied by the offending provider.
Dated: January 25, 2008.
Samuel D. Rauch III
Deputy Assistant Administrator for Regulatory Programs, National Marine
Fisheries Service.
[FR Doc. E8-1662 Filed 1-30-08; 8:45 am]
BILLING CODE 3510-22-S