RFC Editor Services Bidders Conference

[Ray Pelletier]

The RFC Editor Services Bidders Conference will be June 3, 2009  from  
10:00 AM to 1:00 PM PT (UTC-7).

The conference will permit those considering the positions of RFC Series
Editor, Independent Submissions Editor, or bidding on the RFC Production
Center RFP to appear and ask questions of the incumbent RFC Editor, the
University of Southern California's Information Sciences Institute,  
which

is not pursuing the opportunity.

Attendance at the Bidders Conference is optional. Attendance will not  
be used as part of the

selection criteria for the position sought.

Presentations for the conference will be posted prior to the  
conference at:

http://iaoc.ietf.org/rfced-procurement.html  See below for the agenda.

Those interested in listening to the conference can call:
Domestic - (866) 209-6438
International - (865) 297-1127
Participant code: 889324

Written questions received at rpellet...@isoc.org prior to June 3rd will
be answered at the conference without divulging the source of the query.
A reasonable attempt will be made to provide answers to questions raised
during the conference prior to the conclusion of the conference.

If questions asked at the conference cannot be adequately answered  
during
the discussion, answers will be provided online by June 12th. Oral  
answers
provided at the conference may be updated or modified when published.   
The

published answers are the official responses.

The deadline for the submission to rpellet...@isoc.org of any questions
is June 5, 2009. Answers to those questions, together with the questions
and answers from the Bidders Conference will be published online at
www.iaoc.ietf.org no later than June 12, 2009.

Ray Pelletier
IETF Administrative Director

The Agenda for the conference is as follows:

1.  Welcome and Introductions
2.  Bidders Conference Process & Agenda
3.  RFC Editor Restructuring Model
4.  RFC Editor History
5.  How an Internet Draft becomes an RFC: The Process and Demo
6.  Questions and Answer Period
7.  Wrap Up

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [Enum] Last Call: draft-ietf-enum-3761bis (The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)) to Proposed Standard

[Lawrence Conroy]

Hi IESG members, folks,
 I'm one of the authors of the draft, so this is rather odd. But...
as per request, I'm pushing this issue as a comment into the IETF
LC/IESG review for draft rfc3761bis. This has an error that should be
fixed and has caused confusion.

draft rfc3761bis-04 inherits a lot of text directly from rfc3761.
In particular, the DDDS application template specifications covered in
rfc3761bis-04 sections 2.1, 2.2, 2.3 and 2.4 define respectively the
Application Unique String (AUS), the First Well Known Rule, expected
output of this application, and the Rules database & the way that
record fields are used. Unsurprisingly, large chunks of this came
straight from rfc3761.

Unfortunately, these sections include a bug that has been present since
rfc3761.

ENUM (as defined in rfc3761 and in rfc3761bis) is a DDDS application,
and so has to fit within the DDDS framework.

DDDS states that the "First Well Known Rule" is used to turn the AUS
into a key that is used to query the database.
Unfortunately, rfc3761 describes this as identity -- given that the AUS
is a string holding a telephone number, this is NOT going to produce a
suitable domain name. It was wrong then and rfc3761bis-04 inherits this
error.

rfc3761 then goes on to describe how keys into the database are used;
it shows how a telephone number can be converted into a domain name
that can be queried in DNS. For most cases the two steps will cancel
out each other's errors.

However, non-terminal NAPTRs generate domain names that are then
queried to get the "next round" of NAPTRs. If the steps described in
the database section are applied to those domain names then the result
will not be what was intended -- in effect, it reverses the telephone
number as it re-constructs an "ENUM domain".

What *should* be present is a description of the first well known rule
that does create a domain name (i.e. including the steps currently in
the database section), and the database section should just refer to
rfc3403 -- this database is the DNS and is unsurprisingly used as
expected, i.e. domains are queried for NAPTRs, and those NAPTRs hold
DDDS rules.

This is a relatively simple bug fix, has no impact at all on the vast
majority of ENUM systems that do not hold or use non-terminal NAPTRs,
whilst permitting ENUM to work correctly with non-terminal NAPTRs where
it is, at best, ambiguous at present.

Proposed text for this fix can be found in:
.

That text should replace the existing section 2.1 through to the end of
section 2.4. The main changes are to sections 2.2 and 2.4 (which loses
the misplaced 2.4.1 and so subsequent sub-sections are renumbered).

Finally, is it worth raising an erratum against rfc3761 as well, when
rfc3761bis is intended to replace it and can incorporate this fix RSN?

all the best,
  Lawrence

On 26 May 2009, at 15:12, The IESG wrote:

The IESG has received a request from the Telephone Number Mapping WG
(enum) to consider the following document:

- 'The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation
  Discovery System (DDDS) Application (ENUM) '
   as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to  
the

ietf@ietf.org mailing lists by 2009-06-09. Exceptionally,
comments may be sent to i...@ietf.org instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP

[John C Klensin]

--On Monday, June 01, 2009 21:47 +0300 Jari Arkko
 wrote:

>> As written, this violates provisions of RFC 4846 as well as
>> some of the language in the current RFC Editor Model draft.
>> The IESG may _request_ that notes or other language be added.
> 
> Indeed -- thanks for catching this. It should say "may choose
> to request" or some words to that effect.

Either that, or Russ's wording, would be fine with me.

I believe that the bottom-line principles here are:

(1) As above, the IESG requests that the ISE do things;
it does not insert text or require that text be inserted.

(2) Regardless of whether words like "exceptional"
appear, the expectation should be that the typical
independent submission document (or other
non-IETF-stream document) will contain only the stream
identification and whatever statements about review and
consensus go with it, per headers and boilerplates.
Requests for Additional statements should be unusual and
very specific to the circumstances of a given document.

(3) There are no statements to the effect that something
is not an IETF-stream documents or, for that matter, not
the Constitution of Lower Slobbovia.  I don't think
those need to be formally prohibited (partially because
I have no idea how such a rule would be written) but I
would hope that the ISE and RSE would ignore any such
request.

My impression has been that all three of those principles had
already achieved consensus, either on the RFC-Internet list or
in the process of reviewing and approving other documents.  Of
course, that impression could be wrong or the broader community
could have something else to say.

best,
   john

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP

[Russ Housley]

The IAB and the RFC Editor have made updates to the formatting
of the title page for all RFCs [N3]. With these changes, the
upper left hand corner of the title page indicates the stream
that produced the RFC. This label replaces some of the
information that was previously provided in mandatory IESG
notes on non-IETF-stream documents. The IESG may choose to add
an IESG note to an Independent Submission or IRTF Stream
document that explains the specific relationship, if any, to
IETF work.



As written, this violates provisions of RFC 4846 as well as some
of the language in the current RFC Editor Model draft.  The IESG
may _request_ that notes or other language be added.


Indeed -- thanks for catching this. It should say "may choose to 
request" or some words to that effect.


I suggest: "The IESG may request the inclusion of an IESG note to an 
Independent Submission or IRTF Stream document that explains the 
specific relationship, if any, to IETF work."


Russ

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP

[Jari Arkko]

John,


The IAB and the RFC Editor have made updates to the formatting
of the title page for all RFCs [N3]. With these changes, the
upper left hand corner of the title page indicates the stream
that produced the RFC. This label replaces some of the
information that was previously provided in mandatory IESG
notes on non-IETF-stream documents. The IESG may choose to add
an IESG note to an Independent Submission or IRTF Stream
document that explains the specific relationship, if any, to
IETF work.



As written, this violates provisions of RFC 4846 as well as some
of the language in the current RFC Editor Model draft.  The IESG
may _request_ that notes or other language be added.


Indeed -- thanks for catching this. It should say "may choose to 
request" or some words to that effect.


Jari

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP

[John C Klensin]

--On Monday, June 01, 2009 17:47 +0300 Jari Arkko
 wrote:

> I am bringing this draft to its second last call. After the
> completion of the headers and boilerplates document and
> extensive discussions within the IESG, it has become clear
> that several ADs had an issue with the 3932bis draft. I have
>...
> Note that there has been past discussion of what the header
> and boilerplates should say. This discussion happened on the
> rfc-interest list. 3932bis is about IESG notes and IESG
> processing, and the notes are of course very much related to
> what the boilerplates have already said. However, the
> boilerplates should be taken as given for the purposes of our
> discussion here. The rfc-interest list had consensus to
> publish the headers and boilerplates in its final form. Only
> changes to 3932bis are under consideration now.

But there is one important interaction with what you write
below.  The big change (from today's forms) in Headers and
Boilerplates isn't the identification of the stream.  It is to
permit (very nearly require), statements about review and level
of consensus behind a document.  Those statements are expected
to be factual and (except for the IETF stream) do not depend on
IESG judgments about protocol quality, relationships, etc.
 
> The core of the issue is what non-IETF RFCs say about their
> relationship to IETF. According to the new headers and
> boilerplates document, the source is clearly indicated.

Not just the source, but the level and type of review and
consensus.

> However, the issue brought up in the IESG review was that this
> can be insufficient at times.

Insufficient if only the stream is identified?  Or insufficient
even after a "kind of review and level of consensus" statement
is made?

> In general, additional
> information about the role of the relationship of the RFC to
> the IETF work would be useful for readers. The new version of
> the 3932bis draft suggests that the IESG may add a statement
> to a non-IETF RFC about its relationship to IETF work.
> Previous language indicated that such statements would be
> exceptional.

If the intent is to make them common, I think there is a
fundamental disconnect.If the intent is to not say
"exceptional" but to treat them that way, then see my earlier
response to you and Joel.

> The consensus view on the h&b document was that the front
matter
> should say what the RFC is, as opposed to saying what the RFC
> is not. IESG's issue with the 3932bis notes under this
> situation was three-fold. First, there is an assumption that
> the readers are familiar with the different streams (what they
> are and what they're not) -- which many readers of RFCs might
> not be. Second, the relationship between some non-IETF RFC and
> IETF work is often more complex than is captured by just the
> stream and maturity level. Third, additional explanation (not
> boilerplate) specific to the situation could help putting the
> work in context

This discussion leads me to wonder whether the IESG has lost
sight of the descriptions of relationships, review, and
consensus for which H&B provides.  Is that possible?

> The relevant changes from the previous version of the draft
> are in Section 1.1:
> 
> OLD:
> The IAB and the RFC Editor have made updates to the formatting
> of the title page for all RFCs [N3]. With these changes, the
> upper left hand corner of the title page indicates the stream
> that produced the RFC. This label eliminates the need for a
> mandatory IESG note on all Independent Submission and IRTF
> Stream documents.
> NEW:
> The IAB and the RFC Editor have made updates to the formatting
> of the title page for all RFCs [N3]. With these changes, the
> upper left hand corner of the title page indicates the stream
> that produced the RFC. This label replaces some of the
> information that was previously provided in mandatory IESG
> notes on non-IETF-stream documents. The IESG may choose to add
> an IESG note to an Independent Submission or IRTF Stream
> document that explains the specific relationship, if any, to
> IETF work.

As written, this violates provisions of RFC 4846 as well as some
of the language in the current RFC Editor Model draft.  The IESG
may _request_ that notes or other language be added.The ISE
may respond to that by 

-- adding the notes,

-- handing the document back to the authors with a
request to address the underlying issues,

-- adding some other note, presumably with the approval
of the author(s),

-- withdrawing the document, or 

-- rejecting the IESG request.

In the last case, I would hope that the ISE would provide the
IESG with an explanation.  But nothing we have now requires that
explanation or requires the ISE to engage in a dialogue with the
IESG on the subject.  And, IMO, that is the right balance.  
 
> and Section 3:
>...

The Section 3 change does not encounter that procedural
objection because it sa

Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP

[John C Klensin]

--On Monday, June 01, 2009 18:30 +0300 Jari Arkko
 wrote:

> Joel,
> 
>> However, the devil is in the details.
>> As I understand it, the reason for calling the extra note 
>> "exceptional" is that the IESG has in the past sometimes used
>> that  note to place far more pejorative language than you
>> suggest, in places  that it really does not belong. That can
>> turn a reasoanble publicaiton  request into a political fight.
> 
> That's true. However, I think that 3932bis (any version) is
> already supposed to reduce that problem, by not having
> standard, default pejorative language.

Joel, 

I share your concerns.  While I have not yet read -07 carefully,
my sense is that -06 was more satisfactory and that the
substantive differences to -07 tend to reopen doors and
encourage behavior best avoided.   That said, 3932bis is clearly
better than 3932 (at least as it has been interpreted) and I
have to pretty much agree with Jari that the differences don't
amount to anything if one or more ADs decide to misbehave and
the IESG decides to go along.

> The changes in -07 relate to the frequency of notes and their
> content. I'm not sure the frequency matters for avoiding the
> pejorative language problem. If the IESG puts in bad language,
> they can do so both in -06 and -07... if you want to solve
> that problem you need a couple of things: first, remove the
> bad default language. Second, provide a better instruction on
> what the note, if any, should contain. I think -07 is an
> improvement in this respect, because it now talks about the
> relationship of the RFC to IETF and pointers to standards
> track specifications. Third, the IESG folk simply need to have
> good judgment about using the notes. And if they don't, Nomcom
> should hear about it...

Actually, I would hope that, under the new RFC Editor system,
the ISE and/or RSE would feel enabled to appeal every time the
IESG pushes past the kind of evaluation or statements on which
the spirit of both 3932 (as I originally read it) and 3932bis
focus... or to simply ignore the IESG statement/request.
Indeed, I would hope that, unless the reasons for the IESG
statement are clear, that they would feel obligated to do so --
from my point of view, any legitimate situation in which the
IESG feels obligated to make a statement is one in which authors
and the ISE process have failed to make the document and its
relationship to other work clear.  In general, if the problems
are real, it is better to fix documents that exhibit them than
to patch in "statements", regardless of where those are coming
from.   

I hope and trust that it will never be necessary to develop or
invoke procedures in that area.  But, were abuses to occur, I
would hope that there would be a sufficient record of appeals
and the associated discussion to make the issues far more clear
to a relevant Nomcom than just being passed a message.  In fact,
I'd expect an AD who lost one or two such appeals to either
adjust his or her attitudes or resign, without having to wait
for a Nomcom.

I would encourage everyone interested in the topic to study the
RFC Editor Model document, RFCs 4844 and 4846, and any job
descriptions and SOWs to be sure that none of them contain any
language that would prevent the use of the appeals process to
deal with abuses in this area by IESG members.

john

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP

[Jari Arkko]

Joel,


However, the devil is in the details.
As I understand it, the reason for calling the extra note 
"exceptional" is that the IESG has in the past sometimes used that 
note to place far more pejorative language than you suggest, in places 
that it really does not belong. That can turn a reasoanble publicaiton 
request into a political fight.


That's true. However, I think that 3932bis (any version) is already 
supposed to reduce that problem, by not having standard, default 
pejorative language.


The changes in -07 relate to the frequency of notes and their content. 
I'm not sure the frequency matters for avoiding the pejorative language 
problem. If the IESG puts in bad language, they can do so both in -06 
and -07... if you want to solve that problem you need a couple of 
things: first, remove the bad default language. Second, provide a better 
instruction on what the note, if any, should contain. I think -07 is an 
improvement in this respect, because it now talks about the relationship 
of the RFC to IETF and pointers to standards track specifications. 
Third, the IESG folk simply need to have good judgment about using the 
notes. And if they don't, Nomcom should hear about it...


Jari

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Appropriate forum? (was: DNSSEC is NOT secure end to end)

[Thierry Moreau]

To the IETF mailing list subscribers:

The US government involvement in DNSSEC operations is almost certainly 
not in-scope for the ietf mailing list. Thus, it would be 
counterproductive to start a discussion based on Mr. Baptista comments 
on this topic (hence no in-line comments in the original message below).


However, the question remains: which forum, if any, is appropriate for a 
discussion? I don't have the answer, so I merely share the following 
observations.


A) ICANN was specifically requested to abstain from public consultations 
about its proposal to deploy DNSSEC at the root. This is in a letter 
from US Department of Commerce to ICANN, ref 
http://www.icann.org/correspondence/baker-to-twomey-09sep08.pdf (filed 
among other documents in http://www.icann.org/correspondence/ ).


B) The US Department of Commerce issued a public comment notice (the 
deadline is now past), see http://www.ntia.doc.gov/DNS/DNSSEC.html . 
This forum has been used by Mr. Baptista. I was favourably impressed by 
the material written by NTIA staff (and published in the Federal 
Register), so I would recommend this reading (at 
http://www.ntia.doc.gov/frnotices/2008/FR_DNSSEC_081009.pdf ). However, 
this "forum" is not really interactive.


C) Some other forums on which DNSSEC protocol and operational aspects 
are discussed frequently avoid and/or terminate discussions about US 
government involvement in DNSSEC operations for the DNS root. I do not 
blame their moderator or anybody else, I'm just reporting an observation.


D) If any stakeholder group or representatives see some effectiveness in 
the WSIS, the discussions on DNSSEC deployment would fall under the 
heading "critical Internet resources." I don't see much potential for 
active discussion on this front, but it's only my opinion.


So, that's it. Anybody has other suggestions for an appropriate forum 
for DNSSEC deployment at the root *including* US government involvement?


Regards,

- Thierry Moreau


Joe Baptista wrote:



DNSSEC indeed violates the end to end principle.  It's simply that 
simple.  And it asks us to put our trust in the root a.k.a. ICANN.  I 
don't think governments world wide are going to put their trust and 
faith in ICANN.  The U.S. Government is the only government that has 
been bamboozled into adopting DNSSEC into .gov infrastructure.


I wonder how President Obama would feel about handing over the keys to 
U.S. Government infrastructure to a U.S. contractor.  I'd have trouble 
sleeping at night if that was the case.


I've addressed this at length in my comments to the NTIA.

http://www.ntia.doc.gov/DNS/comments/comment034.pdf

If the U.S. government wants DNSSEC today then it must nationalize the 
roots.  I don't even trust Vixie with the root.  I remember when he 
hijacked the root with Postel.  Or as they put it "we were only running 
an experiment".


In any case the new infrastructure campaign demands U.S. government 
roots be set up to exclusively serve U.S. network infrastructure.


regards
joe baptista

p.s. If you want to secure the DNS end to end - think DNSCurve - not DNSSEC.

http://dnscurve.org/


On Sat, May 30, 2009 at 7:27 PM, Masataka Ohta 
> wrote:


Francis Dupont wrote:

 > => not only this is very arguable (for instance about the resource
 > exhaustion) but no hop-by-hop/channel security, even something as
 > strong as TSIG, can provide what we need, i.e., end-to-end/object
 > security (*).

Unless your meaning of end-to-end differs from that of David Clark,
the following argument of his paper is applicable to DNSSEC.

   http://portal.acm.org/citation.cfm?doid=383034.383037
   Rethinking the design of the Internet:
   The end to end arguments vs. the brave new world

   The certificate is an assertion by that (presumably
   trustworthy) third party that the indicated public key
   actually goes with the particular user.

   These certificates are principal components of essentially
   all public key schemes,

That is, security of DNSSEC involves third parties and is not end
to end.

 > PS (*): I use the common meaning of end-to-end, not Masataka
Ohta's one.

I'm afraid you don't know who David Clark is and how he is related
to the end to end argument.

However, all the people who are qualified to discuss end to end do
know him and his argument.

   Masataka Ohta

___
Ietf mailing list
Ietf@ietf.org 
https://www.ietf.org/mailman/listinfo/ietf




--
Joe Baptista

www.publicroot.org 
PublicRoot Consortium

The future of the Internet is Open, Transparent, Inclusive, 
Representative & Accountable to the Internet community @

Re: DNSSEC is NOT secure end to end

[Dave Cridland]

As a disinterested third party...

On Mon Jun  1 16:09:39 2009, Mark Andrews wrote:
> Totally different from DNSSEC which indeed uses chains of trust -  
i.e. root

> to tld to sld etc.etc.

And DNSCurve uses chains of trust from root servers to tld
servers to sld servers etc. etc.


After skimming DNSCurve to get the general idea, I agree with Mark  
here. I don't see any particular way in which the NS records (which  
specify the keys) from the parent are themselves validated, other  
than by trusting the parent domain's nameservers, which essentially  
means they give equivalent protection to DNSSEC from that standpoint.


I did wonder whether there was additional scope for "leap of faith",  
but I'm not sure even that exists.


Moreover, since DNSCurve only operates hop-by-hop, rather than  
end-to-end (in the sense of the DNS resolution process as a whole) it  
relies on a hop-by-hop trust arrangement. In particular, my servers  
here would have to use either a trusted resolver, or no resolver at  
all.


I do note that DNSCurve looks like a neat hack, just one that, on  
closer inspection, turns out to have no obvious benefits in this  
particular respect.


Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Fwd: [Unicode Announcement] New Public Review Issue #147: Proposed Deprecation of U+0673 ARABIC LETTER ALEF WITH WAVY HAMZA BELOW

[Patrik Fältström]

As the liaison from IETF to the Unicode Consortium, I would like to  
make the IETF community aware of the following opening for public  
comments.


The character U+0673 ARABIC LETTER ALEF WITH WAVY HAMZA BELOW that the  
review is related to has today the derived property value "PVALID" in  
the current proposal discussed in the IDNABIS working group.


Because of this, I encourage interested parties to respond to the  
questions stated below.


I am confident IETF and Unicode Consortium will be able to synchronize  
the two standards so that there is no incompatibility issues.


Patrik Fältström

Begin forwarded message:


From: announceme...@unicode.org
Date: fr 29 maj 2009 00.25.49 GMT+02:00
To: announceme...@unicode.org
Subject: [Unicode Announcement] New Public Review Issue #147:  
Proposed Deprecation of U+0673 ARABIC LETTER ALEF WITH WAVY HAMZA  
BELOW

Reply-To: r...@unicode.org

The Unicode Technical Committee has posted a new issue for public
review and comment. Details are on the following web page:

   http://www.unicode.org/review/

Review periods for the new item closes on August 3, 2009.

Please see the page for links to discussion and relevant documents.
Briefly, the new issue is:


PRI #147: Proposed Deprecation of U+0673 ARABIC LETTER ALEF WITH WAVY
HAMZA BELOW

The UTC has recently approved a proposal to encode an ARABIC WAVY  
HAMZA

BELOW for a future version of the Unicode Standard. That character is
used productively in Kashmiri and other languages, and is applied to
letters other than ALEF. The intent is to deprecate the existing
character U+0673 ARABIC LETTER ALEF WITH WAVY HAMZA BELOW, in favor of
the sequence of an ALEF plus the new ARABIC WAVY HAMZA BELOW. (Because
of normalization stability constraints, a canonical equivalence  
relation

cannot be established.)

The UTC is seeking feedback on whether U+0673 should be deprecated  
when
ARABIC WAVY HAMZA BELOW is encoded. Pertinent information would  
include
data on how widespread usage of this character is. Note that  
deprecation

of a character does not mean removal of that character from the
standard; it merely constitutes a strong recommendation not to use the
character.


If you have comments for official UTC consideration, please post  
them by

submitting your comments through our feedback & reporting page:

   http://www.unicode.org/reporting.html

If you wish to discuss issues on the Unicode mail list, then please
use the following link to subscribe (if necessary). Please be aware
that discussion comments on the Unicode mail list are not  
automatically

recorded as input to the UTC. You must use the reporting link above
to generate comments for UTC consideration.

   http://www.unicode.org/consortium/distlist.html




All of the Unicode Consortium lists are strictly opt-in lists for  
members

or interested users of our standards. We make every effort to remove
users who do not wish to receive e-mail from us. To see why you are  
getting
this mail and how to remove yourself from our lists if you want,  
please

see http://www.unicode.org/consortium/distlist.html#announcements






PGP.sig
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: DNSSEC is NOT secure end to end

[Christian Huitema]

> That is, security of DNSSEC involves third parties and is not end
> to end.

That is indeed correct. An attacker can build a fake hierarchy of "secure DNS" 
assertions and try to get it accepted. The attack can succeed with the 
complicity of one of the authorities in the hierarchy. It is a classic "attack 
by a trusted party".

Problem is, hop-by-hop security will not protect against an attack by an 
intermediate authority. If an intermediate authority has been compromised, it 
can just as well insert a fake NS record -- that's not harder than a fake 
record signature. Hop-by-hop security will securely connect to the wrong name 
server, to which the wrong NS record points...

-- Christian Huitema


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (Improving TCP's Robustness to Blind In-Window Attacks) to Proposed Standard

[Anantha Ramaiah (ananth)]

Fernando,
I was modifying the document to update the last call comments and I
would want to make sure if we are on same page w.r.t to your comments.
Pl see inline. 

> -Original Message-
> From: fernando.gont.netbook@gmail.com 
> [mailto:fernando.gont.netbook@gmail.com] On Behalf Of 
> Fernando Gont
> Sent: Thursday, April 16, 2009 10:15 PM
> To: Anantha Ramaiah (ananth)
> Cc: ietf@ietf.org; t...@ietf.org
> Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure 
> (Improving TCP's Robustness to Blind In-Window Attacks) to 
> Proposed Standard
> 
> On Mon, Apr 13, 2009 at 10:23 PM, Anantha Ramaiah (ananth) 
>  wrote:
> 
> > > * The document never mentions the fact that this document is 
> > > IPR-encumbered. As far as I recall, much of the dicussion within 
> > > tcpm with respect to the level of requirements of this document 
> > > (MAY/SHOULD/MUST, etc.) had to do with this fact. I believe the 
> > > document should include a warning mentioning that there's 
> an IPR on 
> > > the document, so that implementers can consider this 
> point in their 
> > > decision of whether to implement the described mechanisms or not.
> >
> > I am confused what to do since this is being brought up 
> very late in 
> > the game. That said, there are *many* drafts/RFC's that have IPR on 
> > them in the whole of ietf. Do all them explicitly state the 
> IPR link ? 
> > I'll leave it to the collective wisdom of the group and the 
> chairs to 
> > offer guidance on this matter.
> 
> I personally believe this should be noted in all RFCs on 
> which there's a known IPR. However, Joel Halpern mentioned 
> this is not current practice. If that's the case, I'd have no 
> problem with leaving it "as is". (FWIW, if you look at our 
> tcp-security document, we do recommend the implementation of 
> the counter-measures you propose, but just note that there's 
> an IPR, and that implementers should research how this would 
> affect them).

I think we seem to have concluded this. As per Brian Carpenter's
suggestion I have done an iprnotified = yes in my xml2rfc. I hope that
should take care of this.



> 
> > Now the scope of this document is to improve robustness to 
> TCP esp. in 
> > cases where the TCP connection is not protected by other means like 
> > TCP MD5 or TCP AO etc., Now this point is very clear in the 
> document. 
> > That said I have no issues putting a reference to the port 
> > randomization in the document.
> 
> What I mean is that anybody that cares about this stuff 
> (FWIW, I do) would also implement port randmization, ISN 
> randomization, etc. One might argue that there's no use in

It depends on how you view this document. To me, this document is about
improving TCP's robustness on some type of scenarios. It is not intended
to be a plethora of all possible TCP attacks and mitigations.  
> 
> > > and other quite a few times in the tcpm wg list, pre and 
> post wglc, 
> > > but this comment was never addressed. It's particularly 
> curious that 
> > > port randomization is not mentioned when tsvwg is working on it 
> > > (draft-ietf-tsvwg-port-randomization).
> >
> > Yes, you did raise this issue last time, but I did defer it 
> to the WG 
> > and did not receive any response, so I simply left it at that.
> 
> IIRC, both Joe and me had agreed on this one (yeah, we did :-) ).

Like I said earlier, I have no issues putting a reference to port
randomization document. Can you suggest a right place for this?
> 
> 
> 
> > > * Among the factors that determine how easy these attacks be 
> > > exploited is the window size. This document should 
> provide, at the 
> > > very least, pointers with advice on what to do with the 
> tcp window. 
> > > While quickly skimming through RFC 4953, it
> >
> > It does mentions about the window size relationship, For example in 
> > the beginning sections of the document we briefly mention 
> the window 
> > size and the # of packets that is required to generate a 
> successful attack.
> 
> What I mean is: you should not use windows that are larger 
> than necessary. Using larger windows than necessary doesn't 
> come for free (e.g., it increases the chances of an attacker 
> of successfully performing these attacks).

Provide advice on window sizes is deemed beyond the scope of this
document, IMO.

> 
> 
> > > * Yet another factor is TCP ISN randomization. At the very least, 
> > > this document could/should a pointer to RFC 1948. We do offer a 
> > > lengthy discussion of this and other issues in 
> > > draft-gont-tcp-security and 
> > > http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf
> >
> > Why should it talk about ISN randomization since ISN 
> randomization, is 
> > somewhat orthogonal to the type of attack here, it is not 
> even one of 
> > the attack vector.
> 
> If I can predict the ISN, I don't have to guess it. 
> Therefore, it's easier to successfully perform the attack.

Well, predicting ISN helps, but it really depends on how much v

Re: DNSSEC is NOT secure end to end

[Mark Andrews]

In message <874c02a20906010608p3e7fbdd3wa31c9ea5452a7...@mail.gmail.com>, Joe 
Baptista writes:
> On Mon, Jun 1, 2009 at 12:30 AM, Mark Andrews  wrote:
> 
> >
> >If you believe that I have a bridge to sell you.
> 
> 
> Keep the bridge - it's all yours.  Remember - in order to sell the bridge
> you first have to own it.  Your convenced you have something to sell.  I am
> not.
> 
> > > Totally different from DNSSEC.
> >
> >
> >You can disagree all you want but it doesn't change the
> >fact that DNSSEC and DNSCurve both have chains of trusts.
> >The proponents of DNSCurve even say this.
> >
> >Note the chain of trust as described on
> >http://www.dnscurve.org/tld.html/.
> 
> 
> The correct URL is http://www.dnscurve.org/tld.html not
> http://www.dnscurve.org/tld.html/
> 
> And yet again - it has nothing to do with chains of trust.  It does learn
> how to trust and whom to trust.  Thats part of the job.  What DNSCurve does
> do is it "adds link-level public-key protection to DNS packets" therefore
> guaranteeing the integrity of the packets end to end.

DNSCurve protects authoritative server to iterative resolver
if and only if you can authenticate the names of the
nameservers and that they are supposed to be serving the
zone you are querying against.  If you can't do that then
you are just talking to some random server using a cryptographic
channel and you shouldn't be trusting the results.
 
> Totally different from DNSSEC which indeed uses chains of trust - i.e. root
> to tld to sld etc.etc.

And DNSCurve uses chains of trust from root servers to tld
servers to sld servers etc. etc.

> I am totally amazed at the propaganda that comes out of ISC these days.
> When you guys start comparing DNSSEC to DNSCurve - we'll - all I can say is
> this - I have this really nice bridge on the Hudson I'd like to sell you
> that will compliment the bridge you've already have.

> cheers
> joe baptista
> 
> -- 
> Joe Baptista
> 
> www.publicroot.org
> PublicRoot Consortium
> 
> The future of the Internet is Open, Transparent, Inclusive, Representative &
> Accountable to the Internet community @large.
> 
>  Office: +1 (360) 526-6077 (extension 052)
> Fax: +1 (509) 479-0084
> 
> Personal: www.joebaptista.wordpress.com
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP

[Joel M. Halpern]

The changes described in your other note (copied after your text to 
preserve context) are reasonable in the abstract.  However, the devil is 
in the details.
As I understand it, the reason for calling the extra note "exceptional" 
is that the IESG has in the past sometimes used that note to place far 
more pejorative language than you suggest, in places that it really does 
not belong.  That can turn a reasoanble publicaiton request into a 
political fight.


In fact, in most cases where there is a published RFC on the same topic, 
the RFC Editor has demonstrated an expectation that the author will 
define accurately and clearly the relationship of their work to the 
existing published work.  So it is not at all clear to me that the case 
you site is even particularly important.


My inclination would be to stick with the "OLD" wording.

Yours,
Joel

Jari Arkko wrote:
And to start off the comments, I wanted tell my personal opinion about 
this.


First, I have not been extremely happy with either the h&b or the 
3932bis document, as some people who have been reading the various lists 
may gather. However, I think they were already good enough to be shipped 
before the changes to 3932bis. (And indeed, h&b has been shipped by the 
IAB.) And I can't get that excited about debates regarding the role of 
the various boilerplate texts, because I suspect that the only people 
reading them are the ones who are going to respond to this thread :-)


I do think though that additional information at the level of "This RFC 
describes FOO. A standardized version of FOO can be found from RFC 
." is useful. I think -07 version of the 3932bis is an improvement 
over the previous one, and should be approved.


Jari


(From Jari's earlier message...)
The relevant changes from the previous version of the draft are in 
Section 1.1:


OLD:
The IAB and the RFC Editor have made updates to the formatting of the 
title page for all RFCs [N3]. With these changes, the upper left hand 
corner of the title page indicates the stream that produced the RFC. 
This label eliminates the need for a mandatory IESG note on all 
Independent Submission and IRTF Stream documents.

NEW:
The IAB and the RFC Editor have made updates to the formatting of the 
title page for all RFCs [N3]. With these changes, the upper left hand 
corner of the title page indicates the stream that produced the RFC. 
This label replaces some of the information that was previously provided 
in mandatory IESG notes on non-IETF-stream documents. The IESG may 
choose to add an IESG note to an Independent Submission or IRTF Stream 
document that explains the specific relationship, if any, to IETF work.


and Section 3:

OLD:
Generally, the RFC headers and boilerplate clearly describe the 
relationship of the document to the IETF standards process [N3]. In 
exceptional cases, when the relationship of the document to the IETF 
standards process might be unclear, the IESG response may be accompanied 
by a clarifying IESG note and a request that the RFC Editor include the 
IESG note in the document if the document is published.

NEW:
The RFC headers and boilerplate is intended to describe the relationship 
of the document to the IETF standards process [N3]. In addition the IESG 
may request that the RFC Editor include the IESG note to clarify the 
relationship of the document to the IETF standards process, such as 
pointers to related IETF RFCs.


A more detailed diff is available at 
http://tools.ietf.org/rfcdiff?url2=draft-housley-iesg-rfc3932bis-07.txt

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP

[Jari Arkko]

And to start off the comments, I wanted tell my personal opinion about this.

First, I have not been extremely happy with either the h&b or the 
3932bis document, as some people who have been reading the various lists 
may gather. However, I think they were already good enough to be shipped 
before the changes to 3932bis. (And indeed, h&b has been shipped by the 
IAB.) And I can't get that excited about debates regarding the role of 
the various boilerplate texts, because I suspect that the only people 
reading them are the ones who are going to respond to this thread :-)


I do think though that additional information at the level of "This RFC 
describes FOO. A standardized version of FOO can be found from RFC 
." is useful. I think -07 version of the 3932bis is an improvement 
over the previous one, and should be approved.


Jari

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP

[Jari Arkko]

I am bringing this draft to its second last call. After the completion 
of the headers and boilerplates document and extensive discussions 
within the IESG, it has become clear that several ADs had an issue with 
the 3932bis draft. I have asked Russ to post a new version which I 
believe resolves the issue. However, the changes -- even if small -- 
relate to what information there exists about the status of RFCs in the 
RFCs themselves, so I felt that it this is an issue that needs to be 
taken to the community. I am formally asking for the community review of 
the new version of the draft, but I like to think about this last call 
as a way to find out what the IETF community is thinking about the 
topic. Once we know, I hope we can approve the draft version that 
matches that opinion. Comments should be sent to the ietf@ietf.org 
mailing list.


Note that there has been past discussion of what the header and 
boilerplates should say. This discussion happened on the rfc-interest 
list. 3932bis is about IESG notes and IESG processing, and the notes are 
of course very much related to what the boilerplates have already said. 
However, the boilerplates should be taken as given for the purposes of 
our discussion here. The rfc-interest list had consensus to publish the 
headers and boilerplates in its final form. Only changes to 3932bis are 
under consideration now.


The core of the issue is what non-IETF RFCs say about their relationship 
to IETF. According to the new headers and boilerplates document, the 
source is clearly indicated. However, the issue brought up in the IESG 
review was that this can be insufficient at times. In general, 
additional information about the role of the relationship of the RFC to 
the IETF work would be useful for readers. The new version of the 
3932bis draft suggests that the IESG may add a statement to a non-IETF 
RFC about its relationship to IETF work. Previous language indicated 
that such statements would be exceptional.


The consensus view on the h&b document was that the front matter should 
say what the RFC is, as opposed to saying what the RFC is not. IESG's 
issue with the 3932bis notes under this situation was three-fold. First, 
there is an assumption that the readers are familiar with the different 
streams (what they are and what they're not) -- which many readers of 
RFCs might not be. Second, the relationship between some non-IETF RFC 
and IETF work is often more complex than is captured by just the stream 
and maturity level. Third, additional explanation (not boilerplate) 
specific to the situation could help putting the work in context


The relevant changes from the previous version of the draft are in 
Section 1.1:


OLD:
The IAB and the RFC Editor have made updates to the formatting of the 
title page for all RFCs [N3]. With these changes, the upper left hand 
corner of the title page indicates the stream that produced the RFC. 
This label eliminates the need for a mandatory IESG note on all 
Independent Submission and IRTF Stream documents.

NEW:
The IAB and the RFC Editor have made updates to the formatting of the 
title page for all RFCs [N3]. With these changes, the upper left hand 
corner of the title page indicates the stream that produced the RFC. 
This label replaces some of the information that was previously provided 
in mandatory IESG notes on non-IETF-stream documents. The IESG may 
choose to add an IESG note to an Independent Submission or IRTF Stream 
document that explains the specific relationship, if any, to IETF work.


and Section 3:

OLD:
Generally, the RFC headers and boilerplate clearly describe the 
relationship of the document to the IETF standards process [N3]. In 
exceptional cases, when the relationship of the document to the IETF 
standards process might be unclear, the IESG response may be accompanied 
by a clarifying IESG note and a request that the RFC Editor include the 
IESG note in the document if the document is published.

NEW:
The RFC headers and boilerplate is intended to describe the relationship 
of the document to the IETF standards process [N3]. In addition the IESG 
may request that the RFC Editor include the IESG note to clarify the 
relationship of the document to the IETF standards process, such as 
pointers to related IETF RFCs.


A more detailed diff is available at 
http://tools.ietf.org/rfcdiff?url2=draft-housley-iesg-rfc3932bis-07.txt


Jari

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNSSEC is NOT secure end to end

[Joe Baptista]

On Mon, Jun 1, 2009 at 12:30 AM, Mark Andrews  wrote:

>
>If you believe that I have a bridge to sell you.


Keep the bridge - it's all yours.  Remember - in order to sell the bridge
you first have to own it.  Your convenced you have something to sell.  I am
not.


> > Totally different from DNSSEC.
>


>
>You can disagree all you want but it doesn't change the
>fact that DNSSEC and DNSCurve both have chains of trusts.
>The proponents of DNSCurve even say this.
>
>Note the chain of trust as described on
>http://www.dnscurve.org/tld.html/.


The correct URL is http://www.dnscurve.org/tld.html not
http://www.dnscurve.org/tld.html/

And yet again - it has nothing to do with chains of trust.  It does learn
how to trust and whom to trust.  Thats part of the job.  What DNSCurve does
do is it "adds link-level public-key protection to DNS packets" therefore
guaranteeing the integrity of the packets end to end.

Totally different from DNSSEC which indeed uses chains of trust - i.e. root
to tld to sld etc.etc.

I am totally amazed at the propaganda that comes out of ISC these days.
When you guys start comparing DNSSEC to DNSCurve - we'll - all I can say is
this - I have this really nice bridge on the Hudson I'd like to sell you
that will compliment the bridge you've already have.

cheers
joe baptista

-- 
Joe Baptista

www.publicroot.org
PublicRoot Consortium

The future of the Internet is Open, Transparent, Inclusive, Representative &
Accountable to the Internet community @large.

 Office: +1 (360) 526-6077 (extension 052)
Fax: +1 (509) 479-0084

Personal: www.joebaptista.wordpress.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf