ICGSF (00) 27

From:	Hector [geradsa3@telecomm.net.mx]
Sent:	01 April 2000 03:24
To:	WhittingK@ra.gtnet.gob.uk; llcelaya@sct.gob.mx; jrojasr@sct.gob.mx; cardenas@cft.gob.mx; hmonroy@sct.gob.mx; jhsanche@sct.gob.mx; airtelec@telecomm.net.mx
Subject:	CA/75 Comments

Mr. Keith Whittingham

Please find attached the comments in order to the CA/75, about "Improving satellite coordination and notification processes".

1.. Suppression of the API process for networks subject to coordination;
    ./.
    
    We are not agreeing with the suppression of the API.
    
    Because, the API is a presentation of the Administration*s intention that permit to the Administration makes the internal promotion in order to evaluate the way of fulfilling the actions to continue.

    And the API is the shooting regulatory times for the implementations of the satellites networks and establish one period of time that the Administrations used for complemented the internal process and had a available for summit the appendices APS4 information for coordination process. 

    We needed.

    2.. Mandatory electronic filing for new requests for coordination or notification; 
    Is necessary clarify what does mean the concept of "electronic notification" (CD, diskettes, Internet, etc.).
    
    We need studies more this issue. We should be considered that it is an acceptable alternative, but it is necessary a software that provide the validation of the data in real time, including the tools for the footprint of satellites.
    
    One special issue the request consideration it*s the validation of the electronic signature and the identification of single point of contact for Administration in order to avoid the illegality of the subjection.
    
    3.. Establish methods for rapid electronic capture of filings still awaiting processing;
    We considerate this is an internal process of the BR, but any simplification of the procedures for the coordination most take in consideration first the applications that has in backlog inside of the BR.
    
    4.. The use of a coordination arc as a trigger in identifying coordination requirements for FSS in certain cases;
    In principle we support this issue.
    
    But, is necessary considerate the bands and the services of the satellite system.
    
    5.. Separation of uplink and downlink data in determining the need for coordination;
    Acceptable
    
    6.. Make available on the ITU Website, in the SNS database, details of new (electronic) filings "as received" with no further examination other than through the application of validation software tools;
    Not acceptable, since this could generate conflict. Because the data is not certificate that the coordination process is terminated. For other hand, we considerate that the information is available in the coordination database.
    
    7.. Publication to include only findings by the Bureau and a list of administrations with which coordination is required. Other detailed APS4 information to be available in the SNS database on the Web. This information could also include details of networks that triggered the need for coordination;
    The backlog of the BR in the coordination process is almost 3 years, that means that when interesting administration recived the inforrmtaion from the BR with who need to coordinate the satellite system need to have in the orbit. This is the main problem.
    
    With think that many regulatory process in the RR establish the extra charge to the BR and many these tasks should be development by the involved administrations. 
    
    In particular we proposed suppress the S9.30 and modify S9.29 in order to administration identify with who need to coordinate and start that coordination. And also we think is necessary modify S9.34 to S9.39 in order for the BR just validate if the coordination is carry out with all administration that are required to do so.
    
    8.. Eliminate duplication of data requirements and technical/regulatory examination between coordination (S9) and notification (S11);
    Is necessary to considerate, that the data could be modified between the steps of coordination and notification, for that reason is necessary considerate the upgrade data process in the step of coordination. In this way, when the coordination process is finish we have to transfer the coordination data to the notification master register.
    
    9.. Restrict the number of modifications to a network filing that can be made over a given period of time;
    We are not support. Because firsts is necessary define what kind of modification should be considerate as acceptable and which not, instead of establish discussion about of the number of these from the begging.
    
    10.. Simplification of the Master Register;
    It*s necessary identifying the minimum parameters for the registration, in order to make and validate the coordination process.

Yours faithfully,

Mexican Satellite Coordination Task Group