[ispcp] Fwd: [isoc-advisory-council] ISOC Draft Response to the US Department of Commerce IANA Further Notice of Inquiry

Malcolm Hutty malcolm at linx.net
Wed Jul 20 09:41:46 UTC 2011


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tony,

Have you seen the draft response from ISOC?

I think it makes some good points, in particular with regard to the role
of the Contractor in assessing whether policies and national laws have
been complied with (see below, "Finally, and most importantly,").

I would be pleased if the ISPCP response could incorporate at least this
last point in its own response.

Also, are we really at the point where we're calling for every last
vestige of US oversight of the IANA function to be withdrawn?

Malcolm.
- -------- Original Message --------
Subject: [isoc-advisory-council] ISOC Draft Response to the US
Department of Commerce IANA Further Notice of Inquiry
Date: Mon, 18 Jul 2011 11:33:25 +0200
From: Markus Kummer <kummer at isoc.org>
To: isoc-advisory-council at elists.isoc.org

Dear Advisory Council Members,

I refer to the email I sent out on 19 June, seeking your input for our
response to the US Department of Commerce IANA Further Notice of Inquiry
(FNOI). Meanwhile, we have had the opportunity to assess the FNOI more
in detail and also exchange views with others, including representatives
of the National Telecommunications and Information Administration
(NTIA). First and foremost, we welcome the open and transparent  process
which should ultimately contribute to broadening transparency,
predictability and global confidence in the way the Department of
Commerce deals with the IANA function.

Nevertheless, we have some areas of concern. In our draft response to
the FNOI, which is attached to this email, .we highlight the following
areas where we believe further clarifications are needed:

First, the Internet technical community should be recognized as
“materially affected parties” to the contract.

Second, the FNOI is “DNS centric”. The DNS component of the IANA
Functions Contract  is only one of three IANA functions that are of
equal importance to the well-functioning Internet. The Contract  should
therefore be drafted in such a way that the full range of IANA functions
to be performed by the Contractor are reflected throughout the document
and treated as separate functions of equal importance.

Third, the functional separation between the processing of the IANA
functions and the development of associated policies needs further
clarification. We believe the current wording is too rigid. The IANA
staff are sometimes uniquely qualified to provide informed inputs to the
policy making process, based on their technical expertise and
operational experience. A good policy development process requires
informed technical advice from professional staff to understand why a
proposed policy may or may not be implementable, or where it could be
more effective, if it is put forward in one way rather than another.

Finally, and most importantly, we believe the requirement for the IANA
Contractor to document compliance with relevant policies and procedures
or, more critically, with relevant national laws, needs to be revisited.
To be consistent with the requirement for the functional separation
between the processing of the IANA functions and the development of
associated policies, it is essential that IANA staff not be required to
assess whether or not requests for processing are compliant with
relevant policies and procedures, and most certainly not whether they
are compliant with relevant national laws.  Compliance is a matter for
the policy-making bodies – the ICANN Board, the RIRs through the NRO,
and the IETF. The final SOW must make it clear that the IANA
Contractor’s staff is responsible only for documenting that the relevant
organization has stated that their decision is compliant with policy,
procedures and laws, and not for judging the accuracy of such statements.

Please let us know if you have any comments. Any response submitted by
24 July will be considered in the finalization of our response.

Best regards
Markus


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4motoACgkQJiK3ugcyKhSbMgCgqTnQyD6r6wVsGMkwUyUbIFa2
m2QAnikOTuuRYdJHoHXxddGdLYW5MCaZ
=gz6t
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FNOI.ISOC_response. DRAFT.pdf
Type: application/pdf
Size: 87444 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ispcp/attachments/20110720/04fc067e/FNOI.ISOC_response.DRAFT.pdf>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Attached Message Part
URL: <http://mm.icann.org/pipermail/ispcp/attachments/20110720/04fc067e/AttachedMessagePart.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Attached Message Part
URL: <http://mm.icann.org/pipermail/ispcp/attachments/20110720/04fc067e/AttachedMessagePart-0001.ksh>


More information about the ispcp mailing list