Little bit off topic so Beer
However we have been asked to deliver a Video Teleconference Bridge in our system for customers whose speeds and connectivity vary (ADSL1, ADSL2, VDSL, Radio, Fibre, UFB) and so I am looking for anyones experiences with conference bridge hardware that can take connections from customers who may be using any of these connections into our network and that is smart enough to remux the video / audio streams out to cater to the connection speeds available.
If anyone has any history with such a device I would love to hear about it off list.
Preferring devices that will have a master bridge inside our core with good monitoring and management and easy to use remote units that are also reliable (remote customers make for hard trips to work on) however any relevant information would be appreciated.
(I am arguing for on topic ish due to the handling of different grade customer connections across the network)
Neilson Productions Limited
021 329 681
022 456 2326
My name is Qinwen(Steven) Hu from the University of Auckland. I am
working on my PhD thesis in which I am trying to observe potential new
security issues in IPv6 networks. I have two questions I would like to
ask network operators:
1) Recently, we did a survey to investigate how network administrators
are actually allocating IPv6 Interface IDs around the world.
Our results show that 82% of domains use sequential small integer
values in the interface ID field for their IPv6 addresses.
- What IPv6 address allocation mechanisms do you (or will you) use
in your IPv6 network/services? could you please give us your
reasons for using these mechanisms?
2) What new security issues, i.e. issues that don't exist in IPv4, do
you think are likely to arise?
Any replies would be very helpful, please send them to me off-list.Many
thanks for your kind consideration. Have a nice day.
Ph.D. Candidate, Computer Science, University of Auckland
奥克兰大学 计算机科学 博士研究生
People on this list might also want to submit responses.
[mailto:email@example.com] On Behalf Of Kim
Sent: Thursday, February 06, 2014 12:38 PM
To: DNS Operations
Subject: [dns-operations] Trusted Community Representation for Root KSK
ICANN is currently performing a consultation on how to evolve the
participation of Trusted Community Representatives in the management of
the root key signing key. I think this consultation is of particular
interest to this group as ultimately these TCRs are there to instill
trust in the DNS operations community that the KSK is being managed in a
I'd encourage you to provide feedback to this consultation - available
14-en.htm - by 11th February. It is important we have a model of TCR
participation that is satisfactory to the community.
For convenience, here are the terms of reference replicated:
Since July 2010, the DNS Root Zone has been secured using DNSSEC. The
model of using DNSSEC in the DNS Root Zone revolves around a "key
signing key" (KSK) that is managed by ICANN in two secure facilities.
Four times a year, a ceremony is conducted at these facilities to
perform operations involving the KSK. As a key part of this process, a
minimum of three from a pool of 21 trusted community representatives
(TCRs) attend each ceremony to enable access to the secure materials, to
witness the procedure, and to attest that the ceremony was conducted
Each ceremony is attended by ICANN staff, the TCRs, representatives of
the Root Zone Maintainer (Verisign), representatives of an independent
audit firm retained by ICANN to monitor the process, and often
additional external witnesses. Ceremonies are recorded by three audit
cameras and webcast online. A typical ceremony lasts approximately four
hours, and involves a process of temporarily removing the key signing
key from a safe and performing key-signing operations in a secure manner
following a formal script. The script is designed to perform each
operation in a transparent manner to ensure the key signing key is only
used for its proper purpose, and there is no ability for its contents to
be disclosed for other purposes. Materials from each ceremony - such as
the scripts, video recordings, and system output - are posted online.
De-briefings and discussions are conducted post-ceremony, where
participants discuss how to improve future ceremonies. This feedback
helps inform the evolution of the KSK ceremony to be both efficient and
effective, while ensuring maximum trust in how ceremonies are performed.
The TCRs were selected from the global community based on a number of
criteria. These selection criteria relate to the volunteers ability
to travel to ceremonies, conscientiously oversee the process, ensure
transparency in its operation, and ultimately contribute to the broader
community's trust that the private component of the key signing key has
not been compromised. The TCRs are privately funded volunteers who are
not reimbursed or compensated by ICANN for their participation nor their
expenses. The original TCR proposal was silent on the length of service
of individual TCRs.
Of the 21 TCRs, seven are credentialed as "crypto officers" (COs) for
each of the two facilities, and the remaining seven act as "recovery key
shareholders" who only participate in ceremonies in the event the
requisite number of COs are unable to participate or there is a need to
rebuild the KSK following an unforeseen event. Of the seven COs for each
facility, ICANN aims to have four attend each ceremony, with an absolute
minimum of three required to successfully perform a ceremony. Each
facility hosts two ceremonies per year, approximately once every six
months. In practice, a TCR will attend at minimum one ceremony per year,
and some will attend two in order to ensure sufficient attendance.
Of the initial pool of 21 TCRs, one has resigned and been replaced from
the pool of recovery key shareholders. No TCR has been removed owing to
the other three criteria for replacement in the TCR selection document,
relating to lack of integrity or trustworthiness; assumption of a
conflicting role within a root management organization; or being unable
to serve in their position.
Based on feedback from the current TCRs and our experience from the
first 14 ceremonies, we are reviewing what changes, if any, should be
made to the current model of TCR participation.
Comments are welcome on any aspect of the consultation, and specifically
on the following questions:
1. Is the current TCR model effectively performing its function of
ensuring trust in the KSK management process?
2. Is the current size of the TCR pool appropriate to ensure sufficient
participation in the ceremonies, while not overburdening the
availability of specific volunteers?
3. Should there be a minimum level of participation required of a TCR in
order to be considered to be successfully discharging their duties?
4. There is no standard provision to refresh the list of TCRs except
when they are replaced due to inability to effectively perform their
function. Should there be a process to renew the pool of TCRs, such as
using term limits or another rotation mechanism?
5. The current model does not compensate TCRs for their services in
order to ensure their independence from ICANN.
a. Should the model of TCRs paying the costs of their participation
b. Would some form of compensation to offset the expenses incurred
by the TCRs detract from their independence in performing the role?
c. If you support compensating TCRs for their expenses, are there
requirements or limitations on whom the funding organization should be?
Please send your comments to
You may want to try geekzone.co.nz as there are a few good Telecom contacts
Sent: Wednesday, February 5, 2014 12:01 PM
Subject: NZNOG Digest, Vol 134, Issue 2
Send NZNOG mailing list submissions to
To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of NZNOG digest..."
1. Telecom NZ Contact (Trent Farrell)
Date: Tue, 4 Feb 2014 12:19:25 +0000
From: Trent Farrell <tfarrell(a)riotgames.com>
To: "nznog(a)list.waikato.ac.nz" <nznog(a)list.waikato.ac.nz>
Subject: [nznog] Telecom NZ Contact
Content-Type: text/plain; charset="us-ascii"
Looking for someone from Telecom NZ to reach out off list, your customers
are having issues with parts of our service.
NZNOG mailing list
End of NZNOG Digest, Vol 134, Issue 2