gmane.ietf.general

MalcolmBETTS90013533 is out of the office.

2012-05-26T02:01:02

I will be out of the office starting  25/05/2012 and will not return until
04/06/2012.

I will not have access to email, I will respond to your message when I
return.

RFP for IETF Meeting Agenda Scheduling Tool

IETF Administrative Director — 2012-05-25T22:00:16

The IETF Administrative Oversight Committee (IAOC), on behalf of the IETF, announces this Request for Proposals for an IETF Meeting Agenda Scheduling Tool.  The successful bidder will enter into a contract with the Internet Society.

The agenda tool will manage all meeting scheduling and space allocation associated with interim meetings, Large Interim Meetings and regular IETF meetings. This includes working group sessions, leadership meetings, EDU sessions, BoFs, office hours, registration, breaks, and more.

The Secretariat will construct the agenda template in the tool by entering venue, date and time information. The community will input the agenda content by submitting session requests. The tool shall include an interface for an automatic schedule creation capability, which may optionally be included in the initial delivery or procured in the future. The schedule creation capability will generate a proposed agenda by finding the most appropriate match of venue (room capacity and availability) and the se

Gen-ART review of draft-ietf-dnsext-dnssec-bis-updates-18

Richard L. Barnes — 2012-05-25T21:02:28

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-dnsext-dnssec-bis-updates-18
Reviewer: Richard Barnes
Review Date: May-25-2012
IETF LC End Date: Not known
IESG Telechat date: Jan-05-2012

Summary: Almost ready, couple of questions

MAJOR:

4.1.
It's not clear what the threat model is that this section is designed to address.  If the zone operator is malicious, then it can simulate the necessary zone cut and still prove the non-existence of records in the child zone.  

5.10.
I find the recommendation of the "Accept Any Success" policy troubling.  It deals very poorly with compromise (and other roll-over scenarios): Suppose there are two trust anchors, one for example.com and one for child.example.com.  If the private key corresponding to the TA for child.example.com is compromised, but the v

Weekly posting summary for ietf< at >ietf.org

Thomas Narten — 2012-05-25T04:53:03

Total of 59 messages in the last 7 days.
 
script run at: Fri May 25 00:53:03 EDT 2012
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
  8.47% |    5 |  5.54% |    25712 | randy< at >psg.com
  6.78% |    4 |  7.16% |    33268 | stpeter< at >stpeter.im
  3.39% |    2 |  9.13% |    42391 | ron.even.tlv< at >gmail.com
  5.08% |    3 |  6.59% |    30626 | shanna< at >juniper.net
  5.08% |    3 |  4.94% |    22928 | marshall.eubanks< at >gmail.com
  5.08% |    3 |  4.57% |    21219 | brian.e.carpenter< at >gmail.com
  5.08% |    3 |  4.30% |    19950 | rdroms.ietf< at >gmail.com
  1.69% |    1 |  6.05% |    28097 | bclaise< at >cisco.com
  3.39% |    2 |  3.54% |    16456 | trammell< at >tik.ee.ethz.ch
  3.39% |    2 |  3.27% |    15189 | sm< at >resistor.net
  3.39% |    2 |  3.15% |    14620 | hsantos< at >isdg.net
  3.39% |    2 |  2.53% |    11729 | cabo< at >tzi.org
  3.39% |    2 |  2.52% |    11728 | ned+ietf< at >mauve.mrochek.com
  1.69% |    1 |  2.94% |    13672 | alexey.melnikov< at >isode.com
  1.69% |    1 |  1.8

Inconsistent behavior of IETF meeting registration page

Vinayak Hegde — 2012-05-24T17:58:13

Hi,

I was trying to register for IETF 84 and tried the link
http://www.ietf.org/meeting/register.html from the main site.
Sometimes it takes me to the IETF 80 page (registration over) and
sometimes it takes me to the right note well page.

Trying to replicate the issue, I am seeing that it works well on IE
and Safari on Windows but not on Firefox on Linux/Windows. Further
attempts to replicate this problem on Firefox on Windows did not work.

Posting this here as I am not sure what is the right place to post
such issues. Please point me there. Also hoping that I would get more
datapoints of this problem from other people on this list (which
probably will help pinpoint the problem). Looks like a cache-expiry or
an improper redirection issue.

Either ways the workaround is to change the number of the IETF meeting
in the link as this
(https://www.ietf.org/registration/ietf84/ietfreg.py) works.

Question on DHCPv6 / RFC3315

pradeep ramachandran — 2012-05-23T23:31:02

Hello All

Had a question on RFC 3315, Section 18.1.2 Creation and Transmission of
Confirm messages

When a client changes its configuration from dhcpv6 enabled to static ipv6,
is this considered as moving to a new link and is the client required to
send out a Confirm message ?

Thanks
pradeep

secdir review of draft-sakane-dhc-dhcpv6-kdc-option

Samuel Weiler — 2012-05-23T23:12:17

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 any other last call comments.

This doc specifies several DHCPv6 options for carrying Kerberos config 
info.  There are obvious risks to doing this, but they're discussed 
reasonably well in this and similar cited docs (e.g. RFC3634, which 
specifies a much more limited option for DHCPv4).  The doc explains by 
DNS service discovery isn't ideal for some environments.

With that said, there are some things that need clarification, and the 
doc sorely needs an editorial pass.  As-is, the doc is not ready for 
publication.  I will be happy to review the doc again once it's been 
thoroughly edited.


Things that need clarification or consideration:

For the transport type field, would it be better to use a bitmask? 
The

abnf discussion list?

Dave Crocker — 2012-05-23T16:56:49

Folks,

g'day.

There are periodic questions about ABNF that go beyond the specifics of 
a specification attempting to use it.

While these are not hot topics, they do occur periodically.  Also, there 
is support material (software, documentation) for ABNF that has no 
single, natural home.

I'd like to suggest an abnf-discuss< at >ietf.org mailing list and an 
abnf.ietf.org web page.

Thoughts?

d/

Weekly posting summary for ietf< at >ietf.org

Thomas Narten — 2012-05-18T04:53:03

Total of 57 messages in the last 7 days.
 
script run at: Fri May 18 00:53:03 EDT 2012
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 10.53% |    6 |  7.75% |    35365 | dhc< at >dcrocker.net
  5.26% |    3 | 11.69% |    53304 | elwynd< at >folly.org.uk
  3.51% |    2 | 11.14% |    50783 | jmvalin< at >jmvalin.ca
  7.02% |    4 |  4.31% |    19674 | randy< at >psg.com
  3.51% |    2 |  6.19% |    28233 | hartmans-ietf< at >mit.edu
  5.26% |    3 |  4.02% |    18321 | adrian< at >olddog.co.uk
  5.26% |    3 |  3.92% |    17857 | stpeter< at >stpeter.im
  3.51% |    2 |  3.11% |    14177 | hsantos< at >isdg.net
  3.51% |    2 |  2.80% |    12792 | ole< at >cisco.com
  1.75% |    1 |  4.43% |    20226 | fluffy< at >cisco.com
  3.51% |    2 |  2.60% |    11865 | dot< at >dotat.at
  3.51% |    2 |  2.53% |    11557 | sm< at >resistor.net
  3.51% |    2 |  2.40% |    10960 | ned+ietf< at >mauve.mrochek.com
  1.75% |    1 |  2.35% |    10703 | mary.ietf.barnes< at >gmail.com
  1.75% |    1 |  2.04% |     9307 | narten< at >us.ibm.c

RFC 2119 terms, ALL CAPS vs lower case

Barry Leiba — 2012-05-16T13:59:08

Some snippets from another discussion thread, in a galaxy far, far away:

Murray:

Ned:

Murray:
 That


In fact, RFC 2119 says that the normative keywords are "often 
capitalized", but doesn't require that they be.

As Murray says, my habit is to use this for 2119 boilerplate:

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119] when they
   appear in ALL CAPS.  These words may also appear in this document in
   lower case as plain English words, absent their normative meanings.

This passes all nit checks, including those involving the eyes of the 
IESG, and I think it makes the situation absolutely clear.  We could, 
certainly, as Murray notes, update 2119 to require all caps in order to 
use the words as 2119 terms.

Alternatively, Tony and Dave had submitted this draft, now expired:
   http://tools.ietf.org/html/draft-hansen-nonkeywords-non2119
It sugges

Gen-ART LC Review of draft-ietf-ccamp-assoc-info-03

Ben Campbell — 2012-05-14T19:12:10

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-ccamp-assoc-info-03
Reviewer: Ben Campbell
Review Date: 2012-06-14
IETF LC End Date: 2012-06-14

Summary: This draft is ready for publication as an informational RFC.

Major issues:

None

Minor issues:

None

Nits/editorial comments:

Gen-art last call review of draft-ietf-codec-opus-12.txt (completed)

Elwyn Davies — 2012-05-14T15:06:13

I am the assigned Gen-ART reviewer for this draft. For background on 
Gen-ART, please see the FAQ at 
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. 

Please resolve these comments along with any other Last Call comments 
you may receive. 

Document: draft-ietf-codec-opus-12.txt
Reviewer:  Elwyn Davies
Review Date:  14 May 2012 (completed)
IETF LC End Date: 10 May 2012
IESG Telechat date: (if known) -

Summary: 
Before offering some views on the document, let me say that this piece
of work seems to be a tour de force on behalf of its developers.  It is
certainly one of the (if not the) most technically complex pieces of
work that has been presented to the IETF, and is far more mathematically
complex and rigorous than our usual run of standards.  It is also
perhaps a vindication of the rough concensus and running code
philosophy. So congratulations to the authors and the companies that
have supported this work.  But back to the review....

I came to this review with a very outdated view of what go

SecDir review of draft-ietf-ccamp-assoc-info-03

Yoav Nir — 2012-05-13T06:46:39

Hi,

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 any other last call comments.

The document does not define any new procedures or mechanisms, and mentions this fact three times throughout the document. It formalizes an email by Adrian Farrel clarifying the procedures for processing an ASSOCIATION object on a path message. 

The security considerations section repeats that the document does not define new procedures, and concludes that no security considerations are added. This is not a valid deduction, as clarification often involves prohibiting non-functional or insecure interpretation of the original document text. However, in this case the clarification is not about such insecure configurations, so the document is fine.

One textual comment, though: sectio

Weekly posting summary for ietf< at >ietf.org

Thomas Narten — 2012-05-11T04:53:03

Total of 137 messages in the last 7 days.
 
script run at: Fri May 11 00:53:03 EDT 2012
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
  8.03% |   11 |  7.81% |    75340 | sm< at >resistor.net
  5.84% |    8 |  6.11% |    58911 | ynir< at >checkpoint.com
  5.84% |    8 |  5.74% |    55379 | john-ietf< at >jck.com
  3.65% |    5 |  5.12% |    49405 | hsantos< at >isdg.net
  3.65% |    5 |  4.54% |    43771 | brian.e.carpenter< at >gmail.com
  3.65% |    5 |  4.40% |    42406 | tobias.gondrom< at >gondrom.org
  4.38% |    6 |  3.12% |    30131 | randy< at >psg.com
  3.65% |    5 |  3.57% |    34387 | chair< at >ietf.org
  3.65% |    5 |  2.87% |    27711 | mrex< at >sap.com
  2.92% |    4 |  3.10% |    29856 | msk< at >cloudmark.com
  2.92% |    4 |  2.65% |    25521 | dwm< at >xpasc.com
  2.19% |    3 |  2.60% |    25080 | sant9442< at >gmail.com
  2.19% |    3 |  2.39% |    23047 | marshall.eubanks< at >gmail.com
  2.19% |    3 |  2.35% |    22671 | scott< at >kitterman.com
  2.19% |    3 |  2.06% |    19886 | hannes.tsc

Finally, It's The Year Of Linux^H^H^H^H^HIPv6

Sabahattin Gucukoglu — 2012-05-09T03:34:32

I really shouldn't, so soon after his last inflammatory rant, but here:
http://www.theregister.co.uk/2012/05/08/ipv6_coming_next_month/

<Quote>
One month from now, World IPv6 Launch Day with be upon us. Numerous online services will be enabling IPv6 and leaving it on. AAAA records will be published, and those of us with IPv6 enabled systems will start to use IPv6 preferentially to IPv4. But what does this all mean? For the short term at least, the truth is "not much". …
</quote>

Ignoring the obvious error with the preceding quote, on this occasion, he does at least appear to have one thing right: most people really aren't all that motivated, in the short term.  The apathy continues a pace, and most of the industry is obliged to help in turn by doing almost nothing.  Whether it will after June 6 is an open question, but I don't imagine he'll be far off there, either.  What's important here, I think, is simply that the desire to have IPv6 deployed and running is outpaced by people's ongoing desire to ignor

a favor from the list about Jon Postel

Joe Touch — 2012-05-08T23:19:26

Hi, all,

My apologies for contacting this list with a non-IETF issue, but since 
this community knew Jon well, I'm asking for its help (among others).

---

There is a Facebook page that falsely implies being owned by Jon Postel:

https://www.facebook.com/jon.postel

Facebook has declined requests from Jon's family to have this page removed.

To everyone on this list:

PLEASE do not "LIKE" or interact with this page. Jon passed in 1998, as 
you know, 5 years before Facebook ever existed. He never had a page on 
this or any other social networking site, and whomever is running this 
should stop misrepresenting themselves.

If anyone here can help, please let me know.

Joe
touch< at >isi.edu

[Fwd: IETF posting delays]

Hector Santos — 2012-05-08T11:35:31

-------- Original Message --------
Subject: [Fwd: Re: [IETF] Re: IETF posting delays]
Date: Tue, 08 May 2012 07:31:13 -0400
From: Hector Santos <sant9442< at >gmail.com>
To: Warren Kumari <warren< at >kumari.net>
CC: SM <sm< at >resistor.net>, John C Klensin <john-ietf< at >jck.com>, 
ietf-action< at >ietf.org

I'm giving up. Now using gmail account.

As you can see with the response below to Warren and cc: Mary, John,
and the IETF list, was sent last night at May 7, 23:01.  My MTA
transport logs show it was sent to all four, so I am presuming the
direct mail was received and perhaps you can confirm you received it.
Yet, not posted on the list, not on the IETF archive, my copy never sent.

Thats now two submissions by a subscribed member that are in la la
land.  So its not working.

The IETF wants to improve its image with the minority engineering
community?  Wants to reduce the noise? Wants to increase IETF meeting
attendance?

IMO, this policy in place for subscribed member mail holding and
filtering when the mail is never posted

IETF posting delays

Hector — 2012-05-05T22:39:27

For IETF mailing lists like this, I would prefer to use my real 
"professional" email address hsantos< at >santronics.com. However, since it 
often takes over 24 hours or longer, and in cases over the year "lost" 
(never posted), I regularly now use my junk gmail.com alias account 
which is posted on the IETF list "immediately" with a copy sent my 
santronics.com account hosting server and picked up within minutes of 
my next mail reader pop3 poll.

Have others experience similar delays with their accounts? and had to 
use other domains, like gmail.com?

When I first begin to take notice a while back and last year I decided 
to ask the list admin.  He replied shortly and indicated there was no 
moderation. I also asked a few IETF veterans, a WG chair and AD, and 
they all repeated there was no moderation going on.

But I believe I read an IETF person in the list explained delays was 
mostly due to moderation. If so, while I don't see any reason for it, 
I was never given any notice my email would be moderated and

Weekly posting summary for ietf< at >ietf.org

Thomas Narten — 2012-05-04T04:53:01

Total of 125 messages in the last 7 days.
 
script run at: Fri May  4 00:53:01 EDT 2012
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
  6.40% |    8 |  9.28% |    93921 | mary.ietf.barnes< at >gmail.com
  6.40% |    8 |  5.17% |    52339 | dworley< at >avaya.com
  5.60% |    7 |  4.37% |    44283 | melinda.shore< at >gmail.com
  4.80% |    6 |  5.10% |    51614 | ynir< at >checkpoint.com
  4.80% |    6 |  4.02% |    40699 | sm< at >resistor.net
  3.20% |    4 |  4.06% |    41134 | jgunn6< at >csc.com
  4.00% |    5 |  3.05% |    30885 | john-ietf< at >jck.com
  3.20% |    4 |  3.54% |    35851 | msk< at >cloudmark.com
  3.20% |    4 |  3.34% |    33782 | mmorrow< at >cisco.com
  0.80% |    1 |  4.59% |    46476 | nurit.sprecher< at >nsn.com
  2.40% |    3 |  2.46% |    24903 | sant9442< at >gmail.com
  2.40% |    3 |  2.33% |    23568 | narten< at >us.ibm.com
  2.40% |    3 |  2.19% |    22127 | hallam< at >gmail.com
  2.40% |    3 |  2.11% |    21375 | framefritti< at >gmail.com
  2.40% |    3 |  1.88% |    19051 | ned

IETF Trust Minutes since August 2011

SM — 2012-05-03T10:48:35

Dear IETF Trust,

The IETF Trust reported during the IETF83 meeting that the "Minutes 
are complete except for the meeting held this morning".  I don't see 
any minutes published since August 2011.    Could these minutes be 
published in a timely manner?

It was also mentioned the subpoenas would be published as they come 
in.  Where can I find them?

Does the amount of US$600 cover the storage cost of the "blue 
sheets"?  Can the IETF Trust review the second paragraph of the 
message at 
http://www.ietf.org/mail-archive/web/ietf/current/msg73049.html and 
provide feedback to the IETF Community?

Regards,
-sm

Mailing list for LGBTQ participants in the IETF

Ted Hardie — 2012-05-02T18:16:50

For those not aware of it, there is a long-standing mailing list for
LGBTQ participants in
the IETF: ietf-motss< at >lists.pensieve.org (with subscription at
ietf-motss-request< at >lists.pensive.org).


About the IETF-MOTSS List:
 ----- --- ---------- -----

 This list is for use by members of the IETF-MOTSS (Members of the Same
 Sex, an out of date term for lesbian, gay, bi, transgendered, etc.)
 community.

 Topics of discussion include social events held during IETF meetings
 (traditionally called "anti-socials" if they occur at the same time,
 but separate from, the main social or "sub-socials" if they occur
 within the main social), and anything else of interest to the
 community.

regards,

Ted