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

Re: Last Call: (PromotingCompliancewith Intellectual Property Rights (IPR) Disclosure Rules) toInformational RFC

Peter Saint-Andre — 2012-05-25T00:25:16

Got it. Thanks!

Peter

Re: Last Call: (PromotingCompliance with Intellectual Property Rights (IPR) Disclosure Rules)to Informational RFC

SM — 2012-05-24T23:10:18

Hi Peter,
At 15:01 24-05-2012, Peter Saint-Andre wrote:

Ok.


The audio seemed like a grey area to me.  I'll keep that discussion 
for another day.


Ok.


The possible steps are:

   1. Reminder checks whether there are claims of IPR that needs
      to be disclosed

   2. Someone mentions a claim

   3. Ask the WG whether they are ok given the new information

   4. consensus call on the technical work

Step 3 is the follow-up question.  I consider it as separate as what 
is being asked of the WG participant is not clear.  Some guidance is 
needed so participants know what they are being asked to do or what 
they can say (see past OAUTH thread as an example).

Regards,
-sm

Re: Last Call: (PromotingCompliancewith Intellectual Property Rights (IPR) Disclosure Rules) toInformational RFC

Peter Saint-Andre — 2012-05-24T22:01:44

OK, Tim and I will look into perhaps adding a sentence or two about this.


Even if a document is mentioned in a charter as a likely starting point,
the chairs still need to make an explicit call for adoption of that
document as a WG item.


The slides and audio are part of the record.


Naturally it would be best if the disclosure were explicitly called out
in the minutes, as well. However, I agree with you that a formal
disclosure is always best. Let me chat about this with Tim.


WFM.


Yes, I saw that message, and I thought it was helpful.


Now your wording is not clear to me. What do you mean by "the follow-up
question"?


Good point.

Thanks for the feedback!

Peter

Re: Future Handling of Blue Sheets

Russ Housley — 2012-05-24T18:42:45


During the IESG off-site meeting, this topic received quite a bit of discussion.  The IESG recognized that blue sheet information is valuable for peer pressure to abide by the IPR rules.  In contrast, I understand the concerns that have been raised on this thread.  As a result, I am looking into a mechanism where a datatracker password is needed to get the blue sheet images.  This would be the same password that an IETF community participant will to use with the soon-to-be-released Internet-Draft Tracking features (see RFC 6293).  These accounts are available to anyone; however, the need for an account to access blue sheet images raises the bar for access.  Additionally, the need for an account will keep the blue sheet images hidden from web crawlers.

Thanks to Ted hardie for the question that lead to this potential solution.

Russ

Re: Inconsistent behavior of IETF meeting registration page

Bob Hinden — 2012-05-24T18:32:20

Please sent it to <ietf-action< at >ietf.org>.

Bob

On May 24, 2012, at 10:58 AM, Vinayak Hegde wrote:

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.

Re: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option

Jeffrey Hutzelman — 2012-05-24T17:50:37


It does need copy-editing.  As far as I know, the IETF does not have a
team of volunteer copy-editors, and multiple attempts to get help from
within the working group have met with only limited success (most
notably in the form of help from Stephen, who did quite a bit of work on
this before starting on his AD review).  If anyone wants to volunteer to
spend some time on helping to clean up this document, let me know.

Otherwise, I think our only options are either to ask the paid editors
at the RFC production center to take a stab, or block an otherwise
completed document on cycles that may never appear.



It does; I somehow missed that in my review.



The algorithm is fine, but the description requires careful reading.
Step 2 kicks in only if you get a DHCP response containing Kerberos
configuration but no nameservers.  



There are only two branches here.  Either you get a response containing
one or more relevant SRV RRs, or you don't.  The latter is phrased as
"no answer from the DNS server", but is

Re: Future Handling of Blue Sheets

Carsten Bormann — 2012-05-24T15:37:20


To me this seems to be the compelling, non-surprising result of this discussion.
We don't need another 100 messages to finally arrive at the same result.
So it would help if the responsible I* would make a decision, please.

Grüße, Carsten

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

Re: Future Handling of Blue Sheets

Marshall Eubanks — 2012-05-24T14:12:09

For what it is worth, here is my opinion on this subject (which I was
asked to post here).

I see  possible privacy law problems with posting the blue sheets, so
I would not.

I see a good reason to scan and have images of new blue sheets, make
it easier to respond to subpoenas.

I do see a historical benefit to keeping the blue sheets (as blue
sheets, not just scans), and the expense
of doing so is minimal, so I would urge that their archiving be continued.

Regards
Marshall

On Thu, May 10, 2012 at 6:11 PM, SM <sm< at >resistor.net> wrote:

Updated secdir review of draft-ietf-emu-chbind-16.txt

Stephen Hanna — 2012-05-24T13:07:33

Sam,

Thanks for addressing my comments in draft-ietf-emu-chbind-16.txt.
I'm happy with this version. All my substantive concerns are addressed.

I do see two non-substantive issues. These can be addressed in some
future version or not at all.

1) The word "subvert" is misspelled as "subvirt" in the new text.

2) Editing Charles Clancy's address in the Authors' Addresses section
   has apparently caused the list of authors in the top right corner of
   the first page to revert to this suboptimal form:

EMU Working Group                                        S. Hartman, Ed.
Internet-Draft                                         Painless Security
Intended status: Standards Track                               T. Clancy
Expires: November 25, 2012                      Department of Electrical
                                        Engineering and Computer Science
                                                               K. Hoeper
                                                Motorola Solutions, Inc.

Re: abnf discussion list?

Julian Reschke — 2012-05-24T06:34:09

Sounds good to me.

Best regards, Julian

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/

Re: RFC 2119 terms, ALL CAPS vs lower case

Abdussalam Baryun — 2012-05-23T10:49:28

Hi

It is preferable to update RFC2119 to be more suitable for IETF RFCs
in the future, IMO importance of using CAPS is understood, but when to
use lower case (e.g. must, should, etc.) is not clear. Some use their
sensibility to determine when to use lower case. In the end we can
leave it for the editors to feedback on that when submitting, or use
different sentences. In summary, from some discussions, RFC2119 seems
not to be the best practice so far.

Abdussalam

+++++++++++++++++++++++++++++++++++++++++++++
--On Sunday, May 20, 2012 07:53 +0100 Brian E Carpenter
<brian.e.carpenter at gmail.com> wrote:


Brian,

I've been trying really hard to avoid this discussion, but I
think the above is misleading.

In recent years, various IESG members have insisted that any
IETF Track document that contains anything approximating
conformance language include the 2119 reference and whatever the
strict interpretation of the week is about caps, etc.  As Randy
suggests, there have been signs of more nuance in the last IES

Re: [mile] Last Call: (Guidelinesfor DefiningExtensions to IODEF) to Informational RFC

Brian Trammell — 2012-05-23T12:08:28

Hi, Peter,

One minor point, inline...

On May 21, 2012, at 5:16 PM, Peter Saint-Andre wrote:


This is IMO the right way to go. During the creation of this document, we envisioned in most cases that work to extend IODEF would not have any other "natural" home, and as such would be done within the IETF in the MILE WG; this assumption is probably apparent in the document.

In cases where the work _does_ have a natural home (the application of IODEF to XMPP-specific events is a perfect example), it definitely makes sense to do work there in possible consultation with the MILE WG.

Indeed, for such cases, the IODEF expert review on IODEF extension schemas specified by draft-ietf-mile-iodef-xmlreg would be a final backstop to ensure that specified extensions are consistent with IODEF.

Best regards,

Brian (as author, draft-ietf-mile-template)

Re: Last Call: (PromotingCompliance with Intellectual Property Rights (IPR) Disclosure Rules)to Informational RFC

SM — 2012-05-23T08:16:45

Hi Peter,

I understand why the intended status is not BCP.  I suggest taking 
into account the wider audience feedback to determine whether the it 
should not be made clearer.

A question which is not covered by the draft is when a draft is 
"adopted" through a charter.  I assume that the AD will contact the 
authors in such cases.

In Section 2:

There is a typo, "secretatires".

in Section 3.1:

   "If necessary disclosures have not been submitted, the chairs have a
    choice: insist on an informal disclosure in the presentation, or deny
    the agenda slot unless the IPR disclosure is submitted.  One factor
    in this decision could be the number of revisions that have occurred:
    the chairs might wish to permit presentation of a -00 draft with a
    verbal disclosure, but not after a draft has gone through multiple
    cycles."

The boilerplate explicitly states that this draft as any other draft 
is submitted in full conformance with the provisions of the usual 
BCPs.  If disclosures are necessary