On Thu, 7 Mar 2013, Dave Crocker wrote:
The IESG defines the job requirements. The Nomcom selects according to those
criteria.
I'm been in a number of Nomcom's that wished for some flexibility concerning
job requirements, but each of these Nomcoms was very clear that it did not
have a
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like
On Mon, 30 Jul 2012, NomCom Chair wrote:
I am pleased to report at this time we have 98 qualified individuals
who have generously volunteer their time to serve on this year's
NomCom.
Sorting that list by affiliation and counting the number of names from
each affiliation, the volunteer list
On Thu, 2 Aug 2012, Yoshihiro Ohba wrote:
What is the exact definition of affiliation in IETF?
Quoting from RFC3777:
Rather than defining precise rules for how to define affiliation,
the IETF community depends on the honor and integrity of the
participants to make the process work.
As a
No objection. Thank you for asking.
Just as with any project that you don't really want to take on, make
sure the price is high enough that you're willing to do it should
someone be foolish enough to pay the asking price.
Also consider adding an automatic fee escalation clause (e.g. permit
On Fri, 20 Jul 2012, Behcet Sarikaya wrote:
I don't understand why this issue is coming up.
Maybe you don't know, IETF 84 falls in the month of Ramadan for
Muslims and nobody asked to change it?
I think focusing on the religious roots of the holiday is misguided.
The question is what effect
General comment: no objection.
The table in section 2.2 is odd: in addition to the three entries
being updated, it lists some BUT NOT ALL of the other assignments
already made. I suspect that's a historical artifact. My suggestion:
since the intro text in that section says The list of ..
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like
On Tue, 24 Apr 2012, David Morris wrote:
The IETF meetings are actually not totally public. You must purchase a
'ticket' to attend. We would not allow someone to walk in off the street
and photograph the functions, or even sit in a meeting and take notes.
Without commenting specifically about
On Sunday, 7 November, the secretariat announced to the 79all list:
Please note that you will need to wear your badge at all times
during the meeting to gain access to the various meeting rooms.
Onsite security will be here to verify that only registered
attendees are allowed access to
Thank you very much for the timely response.
*** Ole: I don't see the items listed as being at odds with
anything, they are simply reasons why it might be a good idea to
have a badge policy, but:
Why might it be a good idea? is not the question of the week. The
question of the week is
On Thu, 16 Sep 2010, Bhatia, Manav (Manav) wrote:
In describing each routing protocol's authentication options, it
would be helpful to say whether there's any in-band negotiation
available.
I am not sure I understand whats being meant by in-band negotiation
here?
Many protocols negotiate
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just
On Thu, 6 May 2010, The IESG wrote:
The IESG observes that attending a single day of the IETF meeting is not
sufficient for a new participant to learn the culture of the IETF or the
qualities that would make an effective IETF leader.
Opposed. (Disclosures: I've not used a day pass. I have
On Wed, 24 Mar 2010, Tony Hansen wrote:
Another factor is that the going IETF room rate may include other
items as part of the package. For example, in Hiroshima breakfast
was included in the IETF room rate, but not the off the shelf
rate. Other amenities will vary.
Indeed. There are also
On Wed, 24 Mar 2010, David Morris wrote:
If you care about hotel pricing, there is no excuse for complaining
about IETF rates in a location like Anaheim with dozens of alternatives
within walking distance.
So far, I haven't complained (at least not on this list). I've just
provided data.
On Wed, 24 Mar 2010, Andrew Sullivan wrote:
When you book a hotel as part of a large group like this, you are
effectively participating in a futures market. What you're asking for
is not to participate in a futures market, but for Hilton (or whatever
hotel) to agree to take all the risks and
On Wed, 24 Mar 2010, Dave CROCKER wrote:
As of right now, the Best Available Rate at the Anaheim Hilton
As of now is a sampling methodology error.
If you want to explore disparities, you need to do it with equivalent
conditions.
I see your point, but I disagree. A bed to sleep in tonight
Once again, we appear to be meeting in a hotel that's offering lower
rates to the general public than they're offering to us.
As of right now, the Best Available Rate at the Anaheim Hilton for
tonight, 23 March 2010, is $119. The senior rate is $113. That's
from hilton.com. With a 2 day
On Wed, 24 Mar 2010, Lou Berger wrote:
I have no issue if the hotel rates subsidizes the meeting. I've been
told that this is not the case, even though it is what I/many expect. I
guess I should just accept that there is one and that there is no
transparency on this point.
There is some
Once again, we appear to be meeting in a hotel that's offering lower rates to
the general public than they're offering to us.
As of right now, the Best Available Rate at the Anaheim Hilton for tonight,
23 March 2010, is $119. The senior rate is $113. That's from hilton.com.
With a 2 day
On Thu, 18 Mar 2010, Brian E Carpenter wrote:
In my opinion this is not ready for prime time.
+1
I concur with Brian's points #1 and #2.
I'm further concerned about DISCOURAGED. Here it is defined as
Implementations SHOULD support this functionality, which seems very
counter-intuitive.
On Thu, 18 Mar 2010, Brian E Carpenter wrote:
In my opinion this is not ready for prime time.
+1
I concur with Brian's points #1 and #2.
I'm further concerned about DISCOURAGED. Here it is defined as
Implementations SHOULD support this functionality, which seems very
counter-intuitive.
A New York Times article posted this afternoon may be of interest to
readers of this thread: Google, Citing Cyber Attack, Threatens to
Exit China.
http://www.nytimes.com/2010/01/13/world/asia/13beijing.html?hp
Google said that it had found 'a highly sophisticated and targeted
attack on our
On Wed, 18 Nov 2009, Alexey Melnikov wrote:
Further registrations will be done by the designated expert. I am
concerned that if I put all of them in the document, then the
document will never finish.
Sympathies.
And for the common-use:
Registration of an IMAP keyword intended for
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just
...@cisco.com URL: http://www.cisco.com/ipj
On Wed, 23 Sep 2009, Samuel Weiler wrote:
I'm interested in the answers to the questions asked by EKR a couple of weeks
ago...
I'd also like to know which frequency band these tags use: are these 125kHz or
13.56MHz tags?
-- Sam
On Mon, 7 Sep 2009
I think the point is that the IESG should probably refer the doc to
the uri-review team to look for any red flags. Mistakes in URI
specs are common (speaking has one that has made some).
The editors asked the uri-review list for feedback in July of this
year, as required by RFC 4395.
--
I'm interested in the answers to the questions asked by EKR a couple
of weeks ago...
I'd also like to know which frequency band these tags use: are these
125kHz or 13.56MHz tags?
-- Sam
On Mon, 7 Sep 2009, Eric Rescorla wrote:
Alexa,
Can you clarify what, if any, the security properties
[Sorry for the possible duplicate; my posting from last night hasn't
appeared yet.]
During the plenary yesterday, it came out that the IETF has retained
the working group attendance sheets (blue sheets) from previous
meetings, and those are occasionally the subject of subpoenas.
In the
During the plenary this evening, it came out that the IETF has
retained the working group attendance sheets (blue sheets) from
previous meetings, and those are occasionally the subject of
subpoenas.
In the interest of minimizing IETF overhead and reducing legal risks
to individual
[Sorry for the possible duplicate; my posting from last night hasn't
appeared yet.]
During the plenary yesterday, it came out that the IETF has retained
the working group attendance sheets (blue sheets) from previous
meetings, and those are occasionally the subject of subpoenas.
In the
On Wed, 10 Jun 2009, Olaf Kolkman wrote:
Earlier this month the IAB mailed IANA with a request to provide us plans:
http://www.iab.org/documents/correspondence/2009-06-02-Roseman-Signing-by-IANA-of-ARPA.html
Thank you again for following up with IANA.
It looks like IANA has not yet signed
On Wed, 10 Jun 2009, Olaf Kolkman wrote:
Thanks for your reminder.
Earlier this month the IAB mailed IANA with a request to provide us plans:
http://www.iab.org/documents/correspondence/2009-06-02-Roseman-Signing-by-IANA-of-ARPA.html
Thank you very much for following up on this.
-- Sam
Kind IAB,
Today is the thirty-seven month anniversary of the IAB's request that
IANA sign .arpa and related zones. Lather, rinse, repeat.
-- Sam
-- Forwarded message --
Date: Sat, 9 May 2009 08:28:55 -0400 (EDT)
From: Samuel Weiler weiler+i...@watson.org
To: i...@iab.org
Cc
On Sun, 24 May 2009, Iljitsch van Beijnum wrote:
Not sure if making attending IETF meetings as difficult as possible
is a winning strategy.
But at least this venue is not as difficult as possible.
For comparison, consider Mar del Plata, Argentina, the venue for the
April 2005 ICANN
level domains have signed
their production zones [4].
Why aren't these zones signed? When can we expect the production
zones to be signed? And what's the IAB doing to follow up on its
request?
-- Samuel Weiler
[1]
http://www.iab.org/documents/correspondence/2006-05-15-IAB-request-to-IANA
On Fri, 17 Apr 2009, Cullen Jennings wrote:
I really don't understand why Dean should be blocked from
rai-...@tools.ietf.org.
Dean is the subject of a PR Action; Henrik needs no other reason to
apply the blocking and, if there is a reason or triggering event
(which seems likely), he needn't
On Mon, 2 Mar 2009, John C Klensin wrote:
* Machines in the netbook category have gotten very cheap (cheaper
than IETF registration fees, for example). While I would not expect
your company to change policy, obtaining a few of those machines and
imaging them to contain nothing in local
On Tue, 2 Dec 2008, Jeffrey Hutzelman wrote:
It seems to me that there is a middle ground here. One can
stick with Informational publication as the WG intends, but
still modify the Security Considerations section, not only to
remove the reference to option 66 (if there is consensus that is
On Wed, 26 Nov 2008, Russ Housley wrote:
2. Independent submission informational RFC
...
Today, the IESG asks the RFC Editor to hold the rejected alternative
until the standards-track document is in the RFC Editor queue, and
the informational document will be published with a note indicating
On Wed, 3 Dec 2008, Harald Tveit Alvestrand wrote:
I thought the solution in the DLV case was useful, albeit not terribly so -
publish a specification that didn't really specify anything, but got the
codepoint, and then follow up with the real specification as an ind-sub when
that was
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like
On Thu, 3 Apr 2008, Ray Pelletier wrote:
Is there any good reason to retain that info bit?
No.
I have no objection to the change, though I'd make it in the interest
of streamlining the blue sheet process rather than to avoid spam. The
faster one can deal with the blue sheet, the less likely
... *definitely* food, and without stringent flow controls
on the caffeine.
Not being a caffeine user, I hadn't noticed this one. But I've found
the lack of water and the flow controls on it disturbing.
At 16:43 today, 13 minutes into the break, I could not find water in
the break area at
I think something is wrong. The only header on the IETF page is
From Charles de Gaulle Airport, and yet most of the instructions
seem to be germane for the Orly airport (specifically, the
instructions for the Metro Line 1 and the RER line C)
I you read the From CDG as only applying to the
It's 1:30am. There's a guard in the terminal room. He seems to be
guarding two printers and a whole bunch of CAT5 cable and powerstrips.
He doesn't seem to be guarding any terminals.
Would it be more efficient to leave the CAT5 unattended and just lock
the printers up at night? If there's a
[I sent this last Tuesday and again this afternon from a
non-subscribed address, but it looks like the moderator didn't approve
it. Sorry if you're seeing multiple copies.]
-- Forwarded message --
Clearly it seems that this is irrelevant (in general) to US people,
they don't
49 matches
Mail list logo
